Bugzilla – Bug 8693
Bad handling of a song that doesn't exist in the library any more
Last modified: 2008-12-15 11:58:53 UTC
A few days ago I renamed some folders within my music collection, which affected a dozen or so songs, and I haven't done a rescan since. This morning when my alarm kicked off it was set to play random songs. The first song in the playlist was a song that doesn't exist on the hard disk for the URN that it had stored in the database. The effect was that the alarm didn't play any sound. The alarm icon flashed, but the Now Playing screen reported a blank song title. In this situation, I'd expect it to skip over the song that it couldn't find and move to the next song. SqueezeCenter Version: 7.2 - TRUNK @ UNKNOWN - Windows XP - EN - cp1252 SVN version 21621
Created attachment 3555 [details] Log file The warning "Use of uninitialized value in string" from Slim/Player/Source.pm was logged about 10 times a second, whilst the song remained the now playing song (even with the player in off mode).
Andy says after 20 seconds of not playing something it should have gone ahead and played something else. Alan notes this will be fixed automagically with his 7.3 new streaming changes.
The alarm should have noticed that nothing was playing after 20 secs and reverted to 10 random tracks. Please enable alarm clock debugging and reproduce so we can see what's going on.
Is this even an issue with the alarm? Isn't there supposed to be code that detects the existence of a track, either when it's being placed into the playlist or at the time it's to be played and then skips to the next item in the playlist? The alarm should have a fallback mechanism that if nothing plays when the alarm sounds, it falls back to some default sound. But if the alarm is set to Random Mode from the local library that should seldom be necessary.
Created attachment 3629 [details] New logfile with alarm debug info I repeated this using the boom_new_streaming branch. Not sure if it's doing exactly the same thing as before. I've found other issues, in particular playlist editing is a bit broken, so I'll create some new bug reports.
That looks entirely suspect. There's plugin errors in there. Please disable all plugins and try again. The alarm code looks to be working as intended, but there's a stop event being generated which is stopping the alarm.
Okay, I tried again with TrackStat disabled. I think I stumbled across some other problem. I tried to update the time of the previous alarm (I had the settings window open from earlier), which was not set to repeat. It seemed to save okay, but didn't fire: [16:04:54.8668] Slim::Utils::Alarm::save (810) Saving alarm. [16:04:54.8685] Slim::Utils::Alarm::save (819) Alarm saved with id 84e48136 Rescheduling alarms... [16:04:54.8692] Slim::Utils::Alarm::scheduleNext (1083) Asked to schedule next alarm for Boom Study [16:04:54.8699] Slim::Utils::Alarm::scheduleNext (1134) No future alarms found [16:04:54.8705] Slim::Utils::Alarm::setRTCAlarm (1158) Asked to set rtc alarm for Boom Study [16:04:54.8716] Slim::Utils::Alarm::setRTCAlarm (1198) Clearing RTC alarm I deleted the alarm and reconfigured, and it then seemed to then fire.
Created attachment 3630 [details] New logfile with alarm debug info - no TrackStat
Okay, that's fairly clear. There's two things interesting going on here - the first is the SQL error, the 2nd is the stop request that cancels the active alarm towards the end of the log. I don't know what's triggering that stop, but I'm inclined to wait until the first issue is fixed before investigating it any further from the alarm point of view. I'm not volunteering to look into the SQL/DB part, I'm afraid, so I'll sit back and wait for other input. If it turns out that the stop command is expected in this situtation, then I'll clearly have to look into this further. By the way, I notice you've still got executescript running - it really would simplify things if you could disable ALL 3rd party plugins.
Created attachment 3631 [details] New logfile with alarm debug - no 3rd party plugins
Is this still an issue?
Philip: Can you please retest with the latest 7.2 boom build then report if the issue is still happening for you.
I have retested, and it is working now.
This bug has been fixed in the latest release of SqueezeCenter! Please download the new version from http://www.slimdevices.com/su_downloads.html if you haven't already. If you are still experiencing this problem, feel free to reopen the bug with your new comments and we'll have another look.