Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
[Music]Fix delay of playback on switching song in party mode #15557
This fixes a regression that got into party mode around Jan 2018, causing it not only to be slow but to block playback. While playing a smart playlist using "play in party mode", then clicking on a different song in the current playlist a user was experiencing delays of ~20s in both GUI and sound.
While analysing that issue I found that there was a much older issue where even though playback started immediately, the GUI was locked until party mode had finished refilling the current playlist to hold 10 songs. Both delays only became noticeable on large music collections and with complex smart playlists, that is those where the rules produced inefficient queries, but that is exactly where party mode is needed most. Neither should be happening.
Party mode is old, and there were some obvious improvements to be made
This also fixes a long standing issue with party mode playback of "mixed" smart playlists - they didn't work at all, they now do.
Finally it also ensures that if a new song selected while browsing the library during party mode playback then the "queue songs on selection" setting is observed and the selected song queued for play next rather than played immediately.
Had some positive user test feedback as well as own testing, but will wait for more.
The heavy processing of party mode now all happens on start up while "filling glasses" dialog showing, and subsequent refilling of playlist when switching song, especially when more than 1 new song is needed (e.g. having clicked on 10th current playlist), is immediate for GUI and playback regardless of music library size or complexity of smart playlist rules.
referenced this pull request
Feb 20, 2019
Well the 20s freeze got my attention! @arnova I doubt cancel ever worked - "Mixing Drinks" / "Filling Glasses" dialog and party mode process are in the same thread so you never get to move the pointer, let alone nothing in the processing loop allows cancelling.
I think I would like to get this fix in, and look at fixing cancel separately
Indeed: Afaik it never worked in the 12 years I've been working on Xbox-Media-Center/XBMC/Kodi. Your recent changes in this area just triggered me mentioning it. Obviously it's beyond the scope of this PR but it would be nice if we could fix it at some point.
I have done testing on Win x64 build for song playlists, musicvideo playlists and mixed playlists, all types launched from both music and videos window. In all test cases party mode was initiated and the appropriate playlist (musicplaylist or videoplaylist based on which media window party mode was initiated from) displayed with items drawn (apparently) randomly from the playlist content. Also monitored infolabel MusicPartyMode.MatchingSongs against Container.NumItems (from the parent playlist loaded in music or videos window) for consistency.