Bugzilla – Bug 3612
Null track request ! - leads to slimserver ceasing to respond to connections
Last modified: 2008-09-15 14:39:24 UTC
I don't think this is the same as bug #3130 but it might be. In short, somehow, my 5 year old managed to get the slimserver to prevent connections (from my Squeezebox2 or even from the web browser) to it last night and I had to restart slimserver on my Linux server: This is all I could get glean from the slimserver log file: 2006-06-19 17:51:40.4605 Null track request! 2006-06-19 17:51:40.4768 Backtrace: frame 0: Slim::DataStores::DBI::DBIStore::objectForUrl (/opt/slimserver/Slim/Music/Info.pm line 322) frame 1: Slim::Music::Info::updateCacheEntry (/opt/slimserver/Slim/Utils/Scan.pm line 805) frame 2: Slim::Utils::Scan::readList (/opt/slimserver/Slim/Utils/Scan.pm line 275) He said he tried to play another song and this happened. (He is only 5 remember ;-) )
Would your son like a job in our QA department? :) Dan: does the backtrace give you any hint on what's going on?
Not sure if this is related to the bug, but once I got the server back up and running I noticed the following oddity in my Favourites list. On the Squeezebox2 (and on the web interface) I had 5 favourites, but the 5th favourite said Empty. I could not delete this Empty favourite, it just did nowt when I said delete. I then tried to delete the 4th entry; that did delete but the said Empty too. So favourites 4 and 5 both said Empty. I then added 3 new favourites, and these took up positions 4, 5 and 6 in the list and this seems to have fixed the list problem as it no longer has any Empty entries. So, I now have 6 Favourites in my list and they are all sensible (i.e. none say Empty.) HTH
removing a favourite, leaves an empty slot. motive behind this is that if you remove a fave at slot 3, you don't end up with 4 5 & 6 changing slots, and thus requiring you to shift the quick buttons that you were used to using. empties at the end of the list could probably be changed to go away.
A null track request generally points to an outdated favorite, such as a file that was removed or renamed. Will - have you seen this happen again? Thanks
Hi, No, I haven't seen it happen since, but then my son hasn't really been using it much since it went wrong that day. However, I did watch him as he used the remote control the other day and he pressed 6 then Play to play a track, then 7 the Play to play the next track. BUT, he tended to hold the 7 button down for too long, and this made it choose favourite 7. So, I think it most likely that when he used it the day it went wrong, he did press and hold down the 7 key and thus chose Favourite 7, which did not exist. He then would have hit play and that must be when it crashed saying, NULL track request. So, this all fits your hypothesis. The question is, why did this NULL track request cause slimserver to *lock up*? I mean, I had to stop and restart slimserver on my Linux server before I could get anything to work on the Squeezebox2. Do you know why the NULL track request caused the lock up and do you have a fix for it? (I'm assuming some extra NULL/condition checking is needed in the code to stop it trying to do something dangerous in this situation.) HTH
I think the lockup was solved a few days ago. A Rhapsody playback handling feature was causing a loop if you started playback on an empty playlist. The fix for that got rid of the looping, and probably takes care of the 'no response' problem here. As such, a NULL track request error would simply be log entry and playback should just stop, showing an empty list.
Yeah - thanks kdf. Will - I'm going to mark this as fixed. Please reopen if you can reproduce it. Thanks
Hi I have just discovered the steps my 5 year old took to crash the slimserver. Here they are: Starting point is with SB2 off, but displaying the time. Server is up and running. 1. I had previously tried to use the BBC Frontpage news ticker (the default one Slim devices provide), but it does not load for some reason. Either the page content is wrong or the URL is wrong perhaps. 2. Anyway, I assigned this BBC news ticker to Favourite #2, even though it doesn't work. 3. The SB2 is off. My son comes along and holds down the 2 key on the remote control, and the Squeezebox wakes up and tries to display BBC news ticker but cannot. It displays error message. 4. I turn SB2 off via remote control. It turns off OK. 5. I press and hold down the 2 key again. SB2 comes on and displays same error. I turn it off again. 6. I now press the PLAY button! SB2 wakes up and tries to *play* the BBC news ticker (as that was the last thing the SB2 was looking at last time it was activated.) Of course it cannot play it and now the slimerserver crashes/locks up!!! 7. I cannot do ANYTHING with the SB2 via the remote control so I power it off at the plug on the wall. 8. I power it on at the plug again, SB2 fires up and tries to find IP address, it does but then never ever finds the slimserver (as that is locked up somehow.) 9. To fix things I go to my Linux PC, stop the slimserver. Wait 1 minunte. Start the slimserver. N.B. /etc/init.d/slimserver restart is not enough, its took quick. You must stop, wait THEN start. 10. It is AOK now, and it at the Abba songs (i.e. at start the database.) All is OK now. HTH
Will - the latest 6.3 and 6.5 builds don't exhibit the lock up behavior for me. Could you give one of those a try? I believe the real bug here is that an RSS feed should not be allowed to be a favorite. Or, it should at least not try to be played.
Will - so the fix here for now is that we won't be allowing non audio or playlist types to be set as favorites. That may change in the future when the Favorites code is refactored. For now, go ahead and delete the RSS favorite (or manually remove it from the slimserver.pref file). The change that disallows the setting of an RSS feeds as a favorite is svn 8473