In the latest Documentation the composers field in the Track Model is stated as being of type String.
composers (string) – track composers
When ncmpcpp builds up the Media Library i see thev following error
file "/home/tom/projects/audio/mopidy/local/lib/python2.7/site- packages/mopidy/mpd/translator.py", line 73, in track_to_mpd_format
result.append(('Composer', artists_to_mpd_format(track.composers)))
File "/home/tom/projects/audio/mopidy/local/lib/python2.7/site-packages/mopidy/mpd/translator.py", line 98, in artists_to_mpd_format
artists.sort(key=lambda a: a.name)
File "/home/tom/projects/audio/mopidy/local/lib/python2.7/site-packages/mopidy/mpd/translator.py", line 98, in <lambda>
artists.sort(key=lambda a: a.name)
AttributeError: 'unicode' object has no attribute 'name'
Obviously mpd/translator.py expects composer to be of type list(Artist).
I changed the beetslocal extension accordingly and the error is gone.
Not sure though if this breaks anything for clients using the http protocol.
I have yet to come across a client that displays the composer though.
So am i right in assuming the documentation should be changed then?
On a slightly related note i noticed, while the documentation states a SearchResult to consist of uri, Artists, Albums and Tracks, most BE only return Tracks. And as far as i can see clients seem to extract the Artist, Composer, Album etc. information out of the Tracks Model and ignore Artists and Albums given as separate Models in SearchResult. Under this conditions returning Albums and Artists in a SearchResult seems like a waste of resources.
Would it then not be best, if a client could specify whether it wants Tracks, Artists or Albums returned (with Tracks as a default)?
Unless you’re working on a local library extension, there’s nothing that stops you from providing artist and album search results. In fact, there are backends that don’t provide tracks with their search results (Mopidy-InternetArchive only returns albums, for example).
If clients extract artists and albums from tracks, and don’t use the information included in Mopidy search results… well, blame the clients
As for advanced_search… Well, I sincerely hope that will never make it into Mopidy core. At least not in its current form.
Well, what is stopping me a bit at the moment are considerations about performance. I will have to do some tests on a raspberry to see how massive the impact of the additional searches actually is.
While this certainly is true, it also means that when writing a client that is using the artists and albums information, there has to be extra code to take in account those BE that do not provide these results. I can understand why authors of clients might shy away from that.
Anyway, got a bit sidetracked here. I should limit myself to one issue per thread i guess.
So what about the documentation?
Shouldn’t it be changed?
How to procede?
Should i raise an issue on github?
