Hi, I am a fairly new user of Mopidy and MPDroid and noticed that with some albums, selecting a track causes the wrong track to be played. The error is systematic but being largely unfamiliar with the MPD protocol I can’t tell who’s at fault, Mopidy or MPDroid. Some facts:
Mopidy sends the list of tracks of an affected album in a different order wrt to the track number. Not sure if this is already an issue. OTOH, the track number of each track is correct.
MPDroid displays the tracks of an affected album in the correct order.
Selecting e.g. track 1 in MPDroid causes playback of 10, which happens to be the first track in the list sent to MPDroid. The correct title of the track that’s currently playing (10) is shown by MPDroid.
It happens with JSON, not sure about sqlite (that one has a few other issues which I will look into later).
A few days ago I filed an issue with MPDroid, which seems to assume that the “find” command returns items in track order, which the reference MPD apparently happens to do. The protocol specification doesn’t say anything about item order, so I am inclined to say that Mopidy is off the hook. Feel free to follow https://github.com/abarisain/dmix/issues/679
We could probably look at adding some ordering, at least within the local backend. But on the larger scale for mopidy I doubt we want to do any reordering “globally” as we would start interleaving things from various backends.
While I’d appreciate any progress on this and the proposed change would immediately solve my problem at hand, I have doubts that this is a proper long term solution. You’d have to special case for “all tracks of an album”, since sorting may not make sense for other types of query. The disc number would have to be a second sorting key.
I am afraid the missing connection between tracks and and their list position in MPDroid will bite its users sooner or later when other features get added.
As you point out, the spec doesn’t specify anything and track number order is one of many arbitrary orders that could be used. If they have done some arbitrary client-side reordering of the server’s findadd result then it’s probably their responsibility to then reorder the server’s tracklist (current playlist) to match.
Although I’m sure you could also sensibly argue that it leaves us annoyingly inconsistent with matching mpd behaviour when something is unspecified! What does mpd findadd do when the songs have no track number tags? Does Mpdroid handle that the same?