-
Notifications
You must be signed in to change notification settings - Fork 21
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
How to dispatch.browse(lookup=False) ? #25
Comments
Such a config option would effect all backends. The MPD client will expect full track metadata from |
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?
|
Currently
No, your backend's browse implementation must returns
|
> 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 `Ref`s 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?
|
No, your backend's browse implementation must returns `Ref`s 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?
|
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 ?
The text was updated successfully, but these errors were encountered: