You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I planned to redesign the interface between the PlaybackManager and the mpv Player so that the Player only had the previous and next tracks in its play queue and only the PlaybackManager managed the full queue. The main reason for this being that once reordering the play queue is supported, it would be easier to implement if the MPV play queue only needed to be updated if the track that would follow the currently playing track was moved. Same for removing tracks from the queue, though that's already implemented with MPV having the full queue.
Another benefit would be that future Player implementations (eg DLNA cast) which aren't as lightweight as the local MPV player, wouldn't have to send an HTTP request to add every track to the queue when enqueuing a large playlist.
A drawback is that shuffling is probably harder to implement this way, though supporting shuffling for DLNA in the future may require the PlaybackManager to manage the play order, since I'm not sure if the DLNA (or Chromecast) protocols have a native shuffle option.
I actually tried refactoring the PlaybackManager to add only the current and next tracks to MPV, and couldn't figure out how to work out all the edge cases and gave up, for now. I think my brain was too entrenched in the current design of the PlaybackManager :P
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
I planned to redesign the interface between the PlaybackManager and the mpv Player so that the Player only had the previous and next tracks in its play queue and only the PlaybackManager managed the full queue. The main reason for this being that once reordering the play queue is supported, it would be easier to implement if the MPV play queue only needed to be updated if the track that would follow the currently playing track was moved. Same for removing tracks from the queue, though that's already implemented with MPV having the full queue.
Another benefit would be that future Player implementations (eg DLNA cast) which aren't as lightweight as the local MPV player, wouldn't have to send an HTTP request to add every track to the queue when enqueuing a large playlist.
A drawback is that shuffling is probably harder to implement this way, though supporting shuffling for DLNA in the future may require the PlaybackManager to manage the play order, since I'm not sure if the DLNA (or Chromecast) protocols have a native shuffle option.
@adamantike curious to hear your thoughts.
I actually tried refactoring the PlaybackManager to add only the current and next tracks to MPV, and couldn't figure out how to work out all the edge cases and gave up, for now. I think my brain was too entrenched in the current design of the PlaybackManager :P
Beta Was this translation helpful? Give feedback.
All reactions