Bugzilla – Bug 10889
Place configurable upper limit on playlist length
Last modified: 2010-04-08 17:24:26 UTC
Like it or not, SC is not good at handling long playlists. "Long" may be 500 or 50, depending upon the hardware you are using. Use of the Controller reduces the effective usable maximum size. Proposal: add an option to set the maximum playlist size. Attempts to add additional tracks will get an error message. Propose default value of 100.
Brandon/Dean: would this fall under new schema?
Sure, why not, everything else is.
I'm not sure we want to do this, and it's certainly not a new schema thing. Sorry, Brandon. Alan: Can you describe the root problem?
If you mean the now playing playlist, I regularly kick off folders with many more than 100 tracks, and I see no problem anymore - although there was several versions ago. If there is a problem, fix it, don't ban it.
Yes, I am talking about the NowPlaying playlist. No, this is not a new_schema thing. Sure, we should fix the underlying problems. In theory it would be nice to be able to have arbitrarily large playlists. How about 10,000 tracks, or maybe 50,000? But we are a long way from that now. It might be possible to design how all that stuff is handled in SC but it will certainly be a big job. And it is not likely to happen in the short term. In the meantime, the problem is that if you, perhaps accidentally, add too many tracks to your playlist, then the server becomes somewhere between very slow and totally unresponsive. This includes, for example, being unable to respond to volume-change commands. "Too many" depends upon several factors but mostly the CPU speed and available memory of the server running SC. My guess is that "too many" is in the range 100-1000 for most common systems used as servers. The problem is exacerbated if a Controller, or other SqueezePlay instance, is in use. (I think this is still the case.) The periodic playlist refresh that SP invokes really hammers the server - there are some other related bugs open about this (bug 9194, bug 8658 - which is closed, but there is still a 30s refresh of the playlist by each connected SP). The bottom line is that it is reasonably easy, especially when using the Controller/SP UI, to add more tracks to your playlist than SC can handle. Fixing SC so that it can handle large playlists is hard. The consequences of a too-large playlist are close to disastrous.
Ok, let's take a look at this when we bring up SC on Fab4 and see what an appropriate length is. Cc'ing andy, as I think that this hammering and long list management is something he's already thinking about. It may be appropriate to limit the length of the playlist, on top of other optimizations.
Long playlists also grow the memory use of the server, as the client is maintaining a bunch of Track objects. Ideally a playlist would simply be an array of URLs, which are only inflated when necessary.
The fact that SqueezePlay refreshes the complete playlist every 30s, in quite some level of detail, would also have to be tackled to make this possible.
Moving to the product SqueezePlay because this bug appears to apply to any player based on that application code. Feel free to move it back if it's specific to the original product.
Pat: who should this be assigned to?
This has component=TinySC. Is this only TinySC or does it also apply (maybe to a lesser extent) to SC on your PC?
I think that it should be a general SC setting. I can certainly kill my home-network server by creating a large playlist, for example by playing Top Tracks for a Rhapsody artist with many tracks ( > 1000).
Changing this back to Product SqueezeCenter as it is a general SC problem and not restricted to SP-based products (they just exacerbate the issue). Adding TinySC keyword as we need to consider this especially for TinySC.
I assume that we will implement this as a server (SC) preference. Weldon, we need UI design for each of the UIs to cover the cases when: (a) one tries to add one or more tracks to a playlist that is already full (at maximum length); (b) one tries to add several tracks to a playlist that is almost full, such that not all the tracks can be added. Also, we need to consider the semantics that we want when attempting to add a track or tracks that would not fit but which could be made to fit by removing already-played tracks from the start of the playlist.
Update hours
== Auto-comment from SVN commit #28991 to the slim repo by ayoung == == https://svn.slimdevices.com/slim?view=revision&revision=28991 == bug 10889: Place configurable upper limit on playlist length Add maxPlaylistLength server preference with default of 500 (100 on TinySC) and WebUI under Advanced / Performance. Consolidate all manipulation of player playlists into Slim::Player::Playlist. New method Slim::Player::Playlist::addTracks() used for adding tracks to playlist. Slim::Player::Playlist::removeTrack() extended to be able to remove multiple consecutive tracks. If the playlist is full when attempting to add tracks, then tracks in the (possibly-shuffled) playlist before the 'current' (possibly playing) track will be removed to make room. After that, if the playlist is still full and the attempt is an insert, rather than an append, then tracks will be trimmed from the end of the playlist as far as possible. An error message (show-briefly) is shown if not all tracks are added.
== Auto-comment from SVN commit #28992 to the slim repo by ayoung == == https://svn.slimdevices.com/slim?view=revision&revision=28992 == bug 10889: Place configurable upper limit on playlist length
Awaiting any updated UI requirements.
update hours
My smallest playlist is over 2000 tracks. Booting squeezebox server takes forever! I have just started to load my music collection and already have over 40K tracks. I expect to have playlist in the 10,000 track range. You must solve this problem ASAP. Right now I have 3 devices (Transporter, Squeezeboox, boom) that when I reboot the server take ages to connect. The goal is to have all music on-line using the squeezebox sever. THINK HUGE NUMBERS OF TRACKS. By this time next year i expect to have over 100K tracks on-line
I think that you may need to reconsider the way you use playlists with SbS. Working with active (now-playing) playlists of more than a couple of hundred tracks is never going to be a good experience with the current architecture. There are no active plans to change the architecture in this area. A large library (200k tracks), however, should be much less of an issue.
I do things like load all the tracks from the 60s and then play then shuffled for days. I would like to load up ALL my tracks and then just play them shuffled. If Squeezebox server has a problem with large playlist It should fix it.
It works just fine with a dynamic playlist (now playing) create by selecting the "folder" and saying play. It is static playlists that casue the problem. If I take the dynamic list and save as a playlist, the next time I boot the server I have problem. If I boot the server with the now playing "playlist" and no static playlist it works just fine.
can someone from slim please define the terms? i consider a "static" playlist to be an actual file where specific tracks are listed in a finite amount, OR a static playlist is to me, selecting a folder with X sub-folders and just hitting play (with shuffle perhaps), b/c again it draws from a finite source yet loads all the songs in that source. a dynamic playlist, to me, is when SBS picks songs by itself, based on criteria like genre, or even just random mix, yet what it does NOT do is load every such song, but rather just 50 or 100 or 500 at a time. is that accurately stated? also, in a dynamic playlist, of lets say 500 songs, when one is played, a new one is picked (without repeating) and put at the end of the list to replace it. is that also true? i have used automation software at a radio station, and i have long considered how it works. in my perfect world, an "auto dj" could be assigned rules, like say doubleshots during certain times, etc, but also would plan out a song order with the first major rule being don't repeat anything until everything else has played at least once. so what that would mean to SBS, is that SBS would have to consider a few things. 1. the last time something was played and playcount. 2. the difference between something manually played and automatically played and if that should be accounted for (user optional) 3. the creation of a viewable upcoming playlist (say 500 songs) 4. the creation of a non-viewable list of all the other songs that would be "next" to be mr.500 after a song in the viewable list played. 5. any other "rules" like category order or artist separation. i think this all could be done without it being a memory hog or loading everything into memory.
== Auto-comment from SVN commit #29496 to the slim repo by ayoung == == https://svn.slimdevices.com/slim?view=revision&revision=29496 == bug 10889: Place configurable upper limit on playlist length Honour maxPlaylistLength in playlist parsing and expansion.
This bug has been marked fixed in a released version of Squeezebox Server or the accompanying firmware or mysqueezebox.com release. If you are still seeing this issue, please let us know!