How to dispatch.browse(lookup=False) ?

[stacyharper]

Context: I work on a subsonic backend and I'm browsing artist/albums/tracks. When returning a list of Ref.track, mopidy-mpd want to lookup those uri one by one.

I'd like to not lookup browsed Ref.tracks. It is possible to add a config to toggle automatic lookup on browsing ?

[kingosticks]

Such a config option would effect all backends. The MPD client will expect full track metadata from lsinfo so it's not ideal to work around a particular backend's issue like this. Instead, would grouping the lookups rather than doing them one by one help?

[stacyharper]

Thanks a lot again for you fast returns. I really appreciate.

Instead, would grouping the lookups rather than doing them one by one help?

I don't think so. I cannot query my API using multiple songs id. I have to lookup them one by one. And in the end, I'm not sure this could be a good idea. library.lookup take uri and not uris for a good reason.

The dispatch.browse got an optional lookup parameter so I just guessed we could use it. My backend returns refs cause this just is enough to display my track names in a browse context.

Another point I though yersterday. Mopidy-MPD seems to browse recursively when I open a Ref.artist and Ref.album. This really confuse me. Why that? Why just not lookup my refs uris? My backend is capable to return tracks list for albums/artists/playlists uris.

Imho, this frontend try too hard to be smart. It should be a lot more lazy and stupid and just forward what mopidy return in browses and lookups methods.

What is your opinion on those points? I know those are really breaking points. But, a lazyness = true configuration could be possible?

[kingosticks]

library.lookup take uri and not uris for a good reason.

Currently Backend.LibraryProvider.lookup doesn't take a list of uris but I don't think there is a good reason for that shortcoming, it's just historical. We should address this in Mopidy 3 (@jodal) as many APIs do provide a feature for batched requests (IMO essential when talking to a remote data source).

My backend returns refs cause this just is enough to display my track names in a browse context.

No, your backend's browse implementation must returns Refs because that's what the Mopidy API specifies.

lsinfo uses recursive=False. The other ls* MPD commands use recursive browsing but they are disabled by default. add uses the recursive mode but that makes sense to me. And that's also where the browse without lookup mode originates from (which, yes, we could look at also using for lsinfo but I'm still not enthusiastic about a config that disables the extra metadata for those backends that can lookup properly). Exactly what MPD command are you referring to?

[stacyharper]

My backend returns refs cause this just is enough to display my track names in a browse context.

No, your backend's browse implementation must returns Refs because that's what the Mopidy API specifies.

Because we do not need another informations than the Ref ones to list elements right?

lsinfo uses recursive=False. The other ls* MPD commands use recursive browsing but they are disabled by default. add uses the recursive mode but that makes sense to me. And that's also where the browse without lookup mode originates from. Exactly what MPD command are you referring to?

Yes this is probably the add command (adding Ref to queue). I can understand the point of recurse browsing but this feel less performant if the lookup method can handle the uri by itself.

Conclusion: There is no way to prevent the mpd frontend to lookup any Ref.track in the browse context? I do not have alternatives than caching models.Track from browse to lookup contexts?

[stacyharper]

No, your backend's browse implementation must returns Refs because that's what the Mopidy API specifies.

Does Ref.track could have an intern track model? Giving alternatives to frontend as mpd to retrieve meta infos without looking up ?

Does browse could return Ref objects OR/AND models objects?