-
-
Notifications
You must be signed in to change notification settings - Fork 135
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
Iris ignores lookup(playlist) track data when browsing, pulls track data one-by-one, resulting in hanging spinner in the UI #692
Comments
After looking at some other backends, I'm closing this, as it seems adding cache to the Tidal backend will fix this. |
@jaedb I am still a little curious about what Iris is doing when browsing, Why does Iris do
|
@kingosticks the sole purpose (rightly or wrongly) of However many backends are not as complete as Mopidy-Spotify (I'm looking at you, Mopidy-Dleyna) and So for Iris to deliver a consistent experience across these backends, these double-up requests are necessary. A workaround could be to call |
I'm not sure I entirely follow that sequence (I thought the ideal sequence would always be lookup first, and if that's empty then fallback to browse) but I appreciate the backends provide inconsistent levels of support so it's not as simple as we'd like. I just wanted to double check it was as you expected. Cheers for the explanation. |
FYI, adding caching to the mopidy-tidal backend eliminated the performance issues that spawned all of this. |
I'm looking at how we can improve this. The benefit of the double-up is that objects that are a Track Ref object is fetched, giving the full track object (for a more complete experience). But the cost is performance. I would like to implement some kind of 'fetch full object on render' so we only need to get full objects when a track/album/playlist/etc is in view. But that is a separate piece of work. |
Describe the bug
This comment WRT "slow browsing" using the Tidal backend sums up what I think is going on.
To Reproduce
Expected behavior
That tracks load and display quickly. Internally, I think Iris should use the results of
lookup(playlist)
to show track lists.Environment details:
Additional context
At present, the
mopidy-tidal
backend doesn't return track data when doinglookup(playlist)
(moods are just a type of playlist). Even after implementing that, it is ignored by Iris, which will use the track ref list obtained bybrowse(playlist)
, and then do alookup(track)
for each track. The Tidal API seems rate limited, so this takes a long time, and Iris (I presume) times out internally. If I artificially limitbrowse(playlist)
to return 5 tracks, it works. But some of these mood playlists are 100+ tracks.The text was updated successfully, but these errors were encountered: