Mopidy/MPD - Sort albums by Date Added?

General
1

Hey community!

In the recent days, I’ve run to a number of dead-ends trying to view and navigate my music collection through Mopidy. At first, I thought the issue might be the Front-end I’m using, but now after comparing a bunch, it seems the problem might be in the core of Mopidy/MPD itself.

For me, having a decent sized music collection, and having the habit of listening to new music by new artists often times, the most common way for me to browse my collection would be by checking my latest additions. How I have it in my head, and how I’m used to having it in Bandcamp/Spotify/Soundcloud/etc, is a grid view of covers, with newest showing up on top, that would then expand into the tracks inside the album. Sounds simple enough, eh?

It seems to me now, that Mopidy doesn’t support this sort of Sort, at least not easily? Using Iris and going into the Album view, I’m able to sort my Spotify-collection by Date Added, but my local collection refuses to Sort by date Added. I thought the issue might be due to the front end, and thus I checked a more elaborate one, which led me to RompR, which seems to be favored by many. At least according a brief glance through the documentation led me to think, that also with RompR the album view can’t be sorted by Date Added / Newest first.

Which now leads me to a place where I’m wondering whether the Mopidy / MPD world is meant for me in the end, which would be a bummer after coming this far!

I wanted to ask - is the case really how I just reasoned or am I just missing something? Is it not possible to sort my music via Mopidy/MPD by Date Added? Or maybe there’s an awesome front-end that I don’t know of, that would allow for all sorts of customized sorting with some sort of clever customizable column system, a la Rekordbox, that I don’t know of?

(I’m not looking for a automatic/smart playlist-based option)

2

You can see the fields we currently support in our data model documentation. There is a last modified field:

last_modified

Integer representing when the track was last modified. Exact meaning depends on source of track. For local files this is the modification time in milliseconds since Unix epoch. For other backends it could be an equivalent timestamp or simply a version counter.

But I dont think many backends support it. Local does, and I believe you can use the configurable directory functionality to add an entry for recently added tracks. Don’t ask me the syntax for that though… Maybe you can find it with a search on here.

There’s also an album release date field. That should be much better supported by backends.

1 Like
3

Hey @kingosticks!

Thanks for the swift reply and insights ( once again! )!

Hmm, the ‘last modified’ would do the job pretty closely actually! Thanks for pointing me towards the data model docu. And actually, now that I look closer, when I sort my files with Nautilus, or CLI even, the field I’m always looking at is Date Modified, not Date Added, so it’s pretty darn close!

What do you mean with configurable directory functionality exactly?
I couldn’t find anything with a quick search.

And since we are getting closer to an answer here, could I maybe ask whether you’d be aware of a Mopidy/MPD front-end with support of ‘date modified’ field for local-files?

Thanks again for your time! Knowing that at least the back-end supports ‘date modified’ has partly revived my hope towards my personal utopian music server implementation!

4

It has a configuration option which allows you to add custom stuff to the browse list:

local/directories : List of top-level directory names and URIs for browsing.

The default value (below) has two options which might be close to what you want:

# top-level directories for browsing, as <name> <uri>
directories =
    Albums                  local:directory?type=album
    Artists                 local:directory?type=artist
    Composers               local:directory?type=artist&role=composer
    Genres                  local:directory?type=genre
    Performers              local:directory?type=artist&role=performer
    Release Years           local:directory?type=date&format=%25Y
    Tracks                  local:directory?type=track
    Last Week's Updates     local:directory?max-age=604800
    Last Month's Updates    local:directory?max-age=2592000

And since we are getting closer to an answer here, could I maybe ask whether you’d be aware of a Mopidy/MPD front-end with support of ‘date modified’ field for local-files?

Anything that supports browsing will let you access the “Last Month’s Updates” (or similar) folder above. Other than that I can’t help, you’ll have to try some.

1 Like
5

Actually, I’ve just realised that Mopidy-MPD doesn’t output the Last-Modified field in it’s track info so even if you found an MPD client with true support for it, it wouldn’t work with Mopidy. That’s pretty easy to fix if someone was interested in doing so.

EDIT! I am going mad, all of the above is rubbish. It does support that field.

6

Hey @kingosticks

Thanks for your insights again!

Re: configurable directory functionality:
Oh, yeah now I get it! We are talking of the “Browse” options and it’s features. Thanks for pointing out it’s customizable as well, I never tweaked ‘local’ really, and hadn’t realized the directories are also customizable! Thanks for the heads up!

And now after thinking about this thing for a couple of days, and looking at the ‘data model’ implementation ( thanks for pointing me towards the docu, I hadn’t really looked so far under the hood yet ), I think the main problem, that also the ‘Iris’ front-end developers pointed me towards, is that the data model doesn’t provide ‘date modified’ for Albums, and thus sorting by Date Added/Modified is not easily supported when looking at albums. Maybe there would be some sort of a work-around involving looking at the ‘Date Modified’ of tracks, and then sorting Albums using that info, but at least the ‘Iris’ developers hadn’t found a way.

Also, I checked RompR in the meanwhile and confirmed I can’t sort my Music Collection / Albums by Date Modified / Added as I suspected.

The quest continues…

7

I think that workaround should work OK but I see Iris has implemented something now anyway. Exposing an album last modified field is a bit abstract, where would we stop? Artist last modified? Genre last modified? Like mpd (the program), everything revolves around tracks. So while we could work out the album last modified from the associated tracks, it might be a potentially expensive operation for Internet-based backends (and difficult to cache. Not sure about this.

8

Hey @kingosticks!

Yes, the Iris team has answered to my prayers and actually implemented album sort based on 'last_modified" as given by the tracks inside the albums! Soooooo gooooood! So yes, the work-around is pretty much a solution.

Also, I agree with your reasoning on ‘where to stop’. But I do think being able to see one’s music acquisitions in a chronological order in the library is quite essential. My analogy would be buying new LPs/CDs/tapes and then having them next to your record player as the latest things to listen to. And since it’s always been a feature in all the digital music platforms that I can think of right now, I was feeling confused at first when I wasn’t able to sort my Mopidy collection based on that info.

Anyways, sorry for my long ramblings. Everything seems to be in order now and I’m quite excited for this!

9

I’ll revive this old topic, since I’m still puzzled with Mopidy’s logic when it comes to sorting albums. This post is a bit of a ramble due to my underlying confusion, so try to bare with.

The topic raised it’s head again due to my Bandcamp Wishlist, as returned by mopidy-bandcamp, gets listed in a different order in Iris (alphabetical) in contrast to the native Bandcamp web interface (recently added first = my preference). I dug into mopidy-bandcamp and found that the scraper that pulls the data from Bandcamp creates a list of mopidy.models.Ref instances to store the data. While the list itself is in correct order, the used data-model doesn’t support holding any information about the “newness” (!= release date). Looking at other options for storing album information, none of the alternatives support anything that would translate to “when was it acquired”.

For this specific instance, I can show the list in my preferred order by using an alternative front end, ncmpcpp, and applying ‘do not sort’ as the sorting option. Unfortunately this doesn’t seem to work, for example, if I would like to show my recently acquired ambient releases as given by mopidy-beets (Browse → Beets → By Genre → Ambient). Knowing that no matter which data model mopidy-beets is using under the hood, there’s no way of storing “newness” information for albums, and thus the only way to show the ambient releases newest first would be to make sure the lists are created in that order. This feels somehow backwards to me.

I guess my question is, why is “newness”-information for albums such a bad thing in the Mopidy-land? What would be the “Mopidy-way” of dealing with the aforementioned situations? Am I doing / thinking about this the wrong way?

Looking forward to any input / thoughts!

10

Mopidy’s current Track model has a date field and also a last_modified field. The former is the release date, the latter is backend-specific and maybe could be used as you want (if it isn’t already, not checked). We could also add a new date_added field to our Track model.

But that’s (probably) only half the problem. You are absolutely right that a Ref doesn’t have any date fields and Mopidy’s browse API returns Refs. If a frontend (such as Iris) wanted to do richer sorting in its browse viewer, it would have to look up the Refs and get the associated fat Track objects for them that hold the complete metadata. Sometimes that lookup is expensive (slow) because the backed has to do extra API calls itself to get all the data to populate a full Track, hence clients might try to avoid this and just use the Ref fields.

I’m not convinced a date or (relative) order_index field should be added to our Ref model; but we could have browse return a new BrowseRef model providing such a field. Or perhaps there’s a solution where we provide a lookup(uris, field) API which provides a way to get just one field, for cases like this. But depending on the specific backend, that might still end up being unusably slow.

11

Hey @kingosticks,

Thanks again for your insights, they’ve been really helpful along the way, not only in this specific case.

Regarding the Track-model - Yes, that seems to be the most complete model in use. More specifically, the last_modified field serves the purpose most accurately. Generally, I don’t think that specific model is the bottleneck here, and wouldn’t prioritize extending it with anything.

Like you said, I think the issue is with the browse API handing over a list of Refs, which are quite limited. To sort the items newest first, the options are to either 1) construct the list in the correct order or 2) recurse into each of the albums, which can be costly.

You mentioned some solutions going forward with the issue, and I trust your intuition in what seems like the most reasonable thing to do. Creating a new BrowseRef-model sounds like a nice solution, as it wouldn’t bring additional overhead anywhere else, and would keep the Backend code mostly the same (at least how I see it). I also like the idea of the lookup API for making it easier to fetch some metadata that is needed.

Do you see realistic that any of these ideas would end up in the development pipeline? Would there be some positive overlap with anything else you might be planning?

Thanks again for your time!

12

I’m just not sure how we decide what fields to include. Realistically, someone might want to sort under any of the existing Track fields. Maybe the other field-lookup API is better suited after all.

I think we need to move this discussion to a Mopidy GitHub issue and get more input from other developers. They probably have better ideas than me.

13

So, having re-read this thread from the beginning, I don’t think I’ve been quite on the right page (lately, at least).

It’s currently possible to obtain either a Track or Playlist from a ref with the appropriate controller’s lookup function amd some clients (e.g. Iris do this). But I don’t think there’s any way to get an Album or Artist from a ref and that seems like an omission when using browse. I think we should either:

  • add a way to do album and artist lookups to our API
  • re-think why browsing only returns refs. For maximum flexibility I think this still make sense, but only if there’s also a way to get full models of everything.

Additionally we should also add a last_modified field to both those models.

Assuming we do the above, would lookup(uris, field) still be useful? I don’t think so and it feels wrong, but we could revisit that idea if someone has a good case for it.

Either way, we still need to take this to GitHub or Zulip to progress further with an API change.

1 Like
14

@kingosticks I confirm the limitation for the artist model. I tried to report this limitation in Retrieving artist details from an artist ref through HTTP API

15

Thanks for thinking through this @kingosticks! If this one ends up in the pipeline and an issue is created for it in Github, let us know so I can follow the progress! For what it matters, in my opinion improving Mopidy’s support for ‘newness’-based sorting would be a great enhancement to an already awesome platform.