I’ve noticed a couple of things where Mopidy’s MPD output is not in line with the latest MPD (since 0.18) and thought it would be a good exercise for me to try and get my head around git and see if I can update it.
Firstly, when a track has multiple ‘Artist’ tags, MPD is now outputting these as multiple lines in the output, eg
Artist: Artist 1
Artist: Artist 2
whereas mopidy is concatenating them into a single string. Separate lines in the output is much more useful for a client. The same applies to AlbumArtist and all their respective Musicbrainz IDs.
Secondly, mpd still concatenates Composer and Performer tags, but it does them using a semicolon whereas mopidy is using a comma. The semicolon has become the defacto standard for ID3 tags and it makes it much simpler for a client to split the string into an array - since artist names may contain commas but almost never contain semicolons.
Thirdly, I’d very much like to extend the MPD output to include some extra mopidy-specific information such as the album link and images when outputting track information from list commands or search results. I’ve already done a quick test and it hasn’t broken any MPD client I’ve tried it with. I was thinking of adding something like
I think given that there is no set number or specifically defined set of output for a track from MPD that this will be completely safe, and will allow any MPD client that is mopidy-aware to have this extra information available to it.
I’ve been wondering when we should try and do an other syncup with the newer protocol changes. As for now we’ve only been trying to mimic, or at least claim to be 0.17 Anyway, multiple artists and a clearer delimiter for the other cases does sound like something we want to add. A PR updating our translators and tests would be very welcome.
I take it the “Link” things are really just the artist URIs etc?
I’m guessing adding something like this would be safe enough. Biggest change would be in our “policy” of not doing anything beyond the main MPD impl. This also brings to mind the question of how clients can know if they are speaking to Mopidy and if the should know.
For these things we’ve mostly tried to pretend to only be an MPD server, though slightly buggy one do to the spec not always being clear, and us not having implemented everything. Reasoning behind this has mostly been to avoid clients having to have extra mopidy specific code paths. Currently I’m unsure of where I stand on this.
On a side note I’ve seen an other MPD-alike server which basically just added a protocol upgrade command to opt in extra behavior / speaking something else. If run against a plain MPD you would just get an unknown command error and continue on your way. The other possible safety need would of course be to have a feature toggle in the config.
Please make separate pull requests for protocol catchup changes and custom
additions, so the former are not blocked on decisions about the latter.
If we decide to allow custom additions, I prefer them to be on the form
X-AlbumFoo instead of Mopidy-AlbumFoo. This is similar to adhoc HTTP and
email headers, and encourages implementation by other servers that would
like to expose the same concept without naming something after Mopidy.
I’ve had a poke around with telnet on mpd 0.19 and it looks as though it has stopped producing multiple ‘Artist’ lines and is now just concatenating everything with semicolons, which means changing 2 characters in translator.py will clear that up So if I can get my head around the wierd mysteries of git I’ll have a go at that. Your docs are pretty clear so I’ll give it a shot, although git has always confounded me in the past…
Yes by ‘Link’ I meant artist/album URIs. They’re very useful.
As far as code paths are concerned, up until recently I had two very specific code paths - one for mpd and one for Mopidy-HTTP. This turned out to be a maintenance nightmare so, in the interest of my own sanity, I’ve stripped the Mopidy-HTTP code out. Now, there are still a few areas where code is either mopidy or mpd specific but in the main it’s to do with hiding or showing specific features in the UI or displaying information in a way I consider neat and tidy (I’m pretty fastidious about look and feel). As far as the majority of the backend code is concerned, output either appears from mopidy/mpd or it doesn’t, and I either act on it or not. I refactored the code in a couple of places and there is now nowhere where there are two distinct code paths - just a few ‘if player == “mopidy”’ specifics to handle. I think this small overhead is well worth the effort if it means I can do useful and interesting things that mpd isn’t capable of, or display things in the most appropriate way. I personally think that clients should not need to be aware that they’re speaking to mopidy, but that doesn’t rule out the idea that if they can be aware of it they can provide extra functionality.
So at the moment I detect mopidy by issuing an mpd command that mopidy doesn’t support. This obviously isn’t safe but it’s the best I’ve got currently. Your idea of having a mopidy-specific command to switch on extra output is a safe and neat way to resolve that and won’t affect any clients that don’t know about mopidy.
So if I can get my head around the wierd mysteries of git I’ll have a go at that. Your docs are pretty clear so I’ll give it a shot, although git has always confounded me in the past…