Bug 17590 - When alarm using very large playlist goes off, SB Server crashes
: When alarm using very large playlist goes off, SB Server crashes
Status: NEW
Product: Logitech Media Server
Classification: Unclassified
Component: Alarm
: 7.7.0
: PC Windows Home Server
: -- normal with 2 votes (vote)
: 8.0.0
Assigned To: Andy Grundman
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-09-25 10:31 UTC by canyoncarver
Modified: 2011-10-15 14:12 UTC (History)
3 users (show)

See Also:
Category: ---


Attachments
playlist having trouble. (196.02 KB, audio/x-mpegurl)
2011-09-25 10:31 UTC, canyoncarver
Details

Note You need to log in before you can comment on or make changes to this bug.
Description canyoncarver 2011-09-25 10:31:15 UTC
Created attachment 7477 [details]
playlist having trouble.

I have a 1900 track playlist that I have been using for years with older
versions of SB Server as my "wakeup" playlist for alarms set on my SB Radio.

Recently I converted my SB Server from 7.5.x with iTunes integration (where
this had been working properly for a long time) to SB Server 7.7.0 RC2 with a
standard library that includes 10,000 songs as well as several playlists that
are exported from iTunes as M3U files.

When I set the alarm on my SB Radio to use one of these playlists, "Mobile
Tunes" which has 1900 tracks, and the alarm goes off, the SB Server crashes. 
The SB Radio plays the "default" wakeup alarm noise and the SB Radio becomes
unresponsive (the dial to select the snooze or alarm off function does not work
properly for several seconds) and the SB Radio loses connection to the SB
Server.  

After a few minutes (after alarm is shut off), when the SB Server comes back
online, the alarm (with default sound) goes off a 2nd time, even if it was
selected to be turned off the first time.

Playlist causing this mayhem attached.  I have not tried with a smaller
playlist, the problem might exist there, also.

The server log does not show anything going on when this all occurs.  I am
suspicious that the playlist size is the problem, but it has been working great
for years as my wakeup alarm.

It is also worth noting that I have set maximum playlist size in the advanced
preferences of the SB Server to 3000 tracks.
Comment 1 Mikael Nyberg 2011-09-25 11:29:14 UTC
can partly confirm on 7.6.2

if use " current playlist " as alarm it works

If I choose the same large playlist directly as alarm signal server gets unresponsive as described.

the playlist I tested with is large it takes 10- 15s to start when i play it normlay but used as alarm it sends the server in to a coma for 5 - 6 minutes ?
Comment 2 Mikael Nyberg 2011-09-25 21:29:26 UTC
New test with 7.6.2

Radio=crash

Boom=Worked ,maybe ~40s late but working
Comment 3 Mikael Nyberg 2011-09-26 05:08:42 UTC
7.7/trunk/platforms/redhat/squeezeboxserver.spec

Has this in line 50

Obsoletes: squeezecenter, slimserver, SliMP3
Comment 4 Mikael Nyberg 2011-09-26 05:10:40 UTC
which means that I can upgrade from slimserver or squeezecenter :)
Comment 5 Mikael Nyberg 2011-09-26 05:23:09 UTC
sorry comented in the wrong bugg
Comment 6 Andy Grundman 2011-09-26 09:39:24 UTC
This is really just a generic bug about large playlists, they could be implemented better but it's a lot of work. Workaround: don't use large playlists, or use the default max playlist size.
Comment 7 Mikael Nyberg 2011-09-26 10:17:43 UTC
Ok it is known that large playlist are somewhat problematic and there may be no point in spamming you with yet another such bug, as you already know the underlying problem(s) .

But the interesting part about this bug is that user jmpage2 aka canyoncarver that reported the bug had this playlist working for a very long time and with SBS 7.5.X .

So it either got worse ? which in itself is alarming and enough cause to raise a bug.

Or the same playlist handled by the iTunes plugin works differently (better) ?

Current playlist is different (better) than a stored playlist of the same size, why ?

SqueezePlay vs ip3k player , I already suspected the outcome before trying against my boom so this is not new
Comment 8 Mikael Nyberg 2011-09-26 10:47:35 UTC
Another interesting aspect :

Playing the same playlist is resonable ok it takes some time to load 10-15s

But when used as an alarm the server gets bogged down for the 5 - 6 minutes.

So this points against this being a generic "large playlist" issue, why 50 times slower as an alarm ?
Comment 9 canyoncarver 2011-09-26 19:08:43 UTC
Just to add a little more data.

1.  If I play a smaller playlist (526 songs) it seems to work fine, with the alarm firing as expected.
2.  If I play the larger playlist (without it being an alarm sound) then it works fine and the delay to start of play back is only a few seconds on the SB Radio.
3.  If I set a favorite to a Pandora radio station and then set that as my alarm sound, it does not work.  The server does not disconnect from the SB Radio but I get the default alarm sound.

Considering that when I play the large playlist it plays perfectly it is very odd to me that using it as an alarm would be causing so many problems.  Obviously the server has the horsepower to handle this playlist size as it works great when not used as an alarm.

The fact that Pandora also can not be used as an alarm leaves me suspicious that there is some underlying alarm bug here.
Comment 10 canyoncarver 2011-09-29 06:54:05 UTC
Okay, this morning my 526 item playlist also failed to fire properly as my wake-up alarm.  I got the default alarm sound.  So, this appears to happen even with "reasonably" sized playlists, at least some of the time.
Comment 11 canyoncarver 2011-10-04 20:19:50 UTC
Guys, I see the target milestone for this breakage is in the 8.0 release.  Is there anything that can be done to re-prioritize this, since it appears to even be hit or miss with smaller <500 count playlists?
Comment 12 Mikael Nyberg 2011-10-04 23:04:18 UTC
(In reply to comment #11)
> Guys, I see the target milestone for this breakage is in the 8.0 release.  Is
> there anything that can be done to re-prioritize this, since it appears to even
> be hit or miss with smaller <500 count playlists?

Hmm how is your iTunes xml file bug going ?
You used iTunes integration exlusevily in7.5.x then alarms with 2000tracks sized playlists worked.
maybe if you get the iTunes integration going again this to starts to work again for you.
( this is still a bug no doubt about that but with only 2 voters , and abit odd use case )
 
I'm not logitech so I don't have all the facts, but I have a nasty suspicion that this is why it worked in the firstplace, by pure coincidence. the way you try now without iTunes integration maybe never worked ? Or have it.

Do you have a boom ? Or only radios, with a boom or any old player this works.

i think the target reflects that Andy want's to completely rewrite the whole playlist handling.

What makes this bug is imo the fact that using the same large playlist to just play works fine but not as an alarm, as an alarm you get that cpu locking for 5 minutes, if you just play it it works fine.
That suggest that there also is something else going on here.

Playlist triggered by an alarm behaves different !? Very different, this sets this bug apart from the " playlist problem".
Comment 13 canyoncarver 2011-10-05 14:41:42 UTC
I see no comment indicating that my bug with iTunes Library has been addressed.  However, I will install the latest RC4 and test again.

If the software can't handle my iTunes Library then I am probably stuck doing things with manual library scans, exported .m3u playlists, etc.

I am just surprised that more people aren't complaining about this since I thought many people used their SB Radios as alarm clocks and a 500 track playlist is pretty typical these days.
Comment 14 Chris Martin 2011-10-15 14:12:35 UTC
*** This bug has been confirmed by popular vote. ***