Bugzilla – Bug 640
Squeezebox display goes blank after pressing left arrow
Last modified: 2008-09-15 14:37:04 UTC
Using the nightly build from October 30th, I am seeing the following problem... 1) Play a track 2) Press pause 3) Press power-off 4) Press power-on 5) Press left arrow The display goes blank and most keys on the remote are unresponsive. Pressing power-off/power-on or 'Now playing' seem to fix things. I see the following in the log: 2004-11-01 22:00:21.8125 Backtrace: > > > > frame 0: Slim::Utils::Misc::assert > > (/home/usr_local/slimserver/Slim/Hardware/IR.pm line 251) > > frame 1: Slim::Hardware::IR::lookupFunction > > (/home/usr_local/slimserver/Slim/Hardware/IR.pm line 520) > > frame 2: Slim::Hardware::IR::executeButton > > (/home/usr_local/slimserver/Slim/Control/Command.pm line 209) > > frame 3: Slim::Control::Command::execute > > (/home/usr_local/slimserver/Slim/Hardware/IR.pm line 570) > > frame 4: Slim::Hardware::IR::processCode > > (/home/usr_local/slimserver/Slim/Hardware/IR.pm line 388) > > frame 5: Slim::Hardware::IR::processIR > > (/home/usr_local/slimserver/Slim/Control/Command.pm line 209) > > frame 6: Slim::Control::Command::execute > > (/home/usr_local/slimserver/Slim/Hardware/IR.pm line 40) > > frame 7: Slim::Hardware::IR::idle > > (/usr/local/slimserver/slimserver.pl line 432) > > frame 8: main::idle (/usr/local/slimserver/slimserver.pl line 398) > > frame 9: main::main (/usr/local/slimserver/slimserver.pl line 870) > > > > Here's the problem. /home/usr_local/slimserver/Slim/Hardware/IR.pm, > > line 251: > > > > 241 > > 242 sub lookupFunction { > > 243 my $client = shift; > > 244 my $code = shift; > > 245 my $mode = shift; > > 246 > > 247 $mode = Slim::Buttons::Common::mode($client) unless > > defined($mode); > > 248 my $map = Slim::Utils::Prefs::clientGet($client,'irmap'); > > 249 assert($client); > > 250 assert($map); > > 251 assert($mode); > > 252 # assert($code); # FIXME: somhow we keep getting here with > > no $code. > > 253 > > 254 if (defined $irMap{$map}{$mode}{$code}) { > > 255 $::d_ir && msg("found function " . > > $irMap{$map}{$mode}{$code} . " for button $code in mode $mode from map > > $map\n"); > > 256 return $irMap{$map}{$mode}{$code}; > > 257 } elsif (defined $irMap{$defaultMapFile}{$mode}{$code}) { > > 258 $::d_ir && msg("found function " . > > $irMap{$defaultMapFile}{$mode}{$code} . " for button $code in mode > > $mode from map " . defaultMap() . "\n"); > > 259 return $irMap{$defaultMapFile}{$mode}{$code}; > > 260 } elsif ($mode =~ /(.+)\..+/ && defined > > $irMap{$map}{lc($1)}{$code}) { > > 261 $::d_ir && msg("found function " . > > $irMap{$map}{lc($1)}{$code} . " for button $code in mode class > > ".lc($1)." from map $map\n");
the debug submitted previously seems to indicate an IR process during a non-existent mode. using the command sequence given by david, I cannot reproduce here with softsqueeze, however d_ir, d_files, d_command debug shows a point where the mode is blank. it could be that a left arrow during this would be a problem. 2004-11-02 07:41:06.8750 trying to execute button: power_toggle 2004-11-02 07:41:06.8770 executing button: power_toggle 2004-11-02 07:41:06.8793 Executing command 1d:be:b2:5d:1c:49: power () () () () () () Use of uninitialized value in concatenation (.) or string at /Users/fishbone/slim/server/Slim/Buttons/Common.pm line 1156. 2004-11-02 07:41:06.8851 popped to button mode: 2004-11-02 07:41:06.8870 pushing button mode: home 2004-11-02 07:41:06.8971 pushing button mode: INPUT.List 2004-11-02 07:41:07.0558 Returning array: power () () () () () () 2004-11-02 07:41:07.0586 Returning array: button (power_toggle) (12273.913) (1) () () () 2004-11-02 07:41:07.0606 Returning array: ir (768940bf) (12273.913) () () () () 2004-11-02 07:41:07.0655 Executing command 1d:be:b2:5d:1c:49: ir (768940bf) (12274.01) () () () () 2004-11-02 07:41:07.0691 768940bf 12274.01 1099410067.06866 2004-11-02 07:41:07.0724 irfile entry: Slim_Devices_Remote.ir 2004-11-02 07:41:07.0750 irfile entry: jvc_dvd.ir
vidur, can you reproduce this?
The problem turns out to be related to the fact that the new home menu system keeps track of menu depth using $client->curDepth(), in parallel with the existing $client->modeStack(). Certain menu operations, such as menu jumping using Slim::Buttons::Common::setMode(), reset the modeStack without changing curDepth. The root problem is that curDepth is managed in Slim::Buttons::Home::homeExitHandler(). This method is invoked from INPUT.List as a result of button clicks that cause mode changes. The method is not invoked when mode changes are triggered programmatically (as is the case un the menu jumping case). A short-term solution is to reset curDepth() when we enter Home's setMode. In that case, we're guaranteed to be at the root of the home menu system. This deals with the specific case of menu jumping, but not the longer term issue of maintaining sync. Patch forthcoming...
Created attachment 193 [details] Reset curDepth in home's setMode
I checked in the short-term fix. Re-assigning to Kevin to see if he wants to suggest a more complete fix at a later date.
The more I think about it, I can't see any way that we could ever go into home mode at any depth aside from zero. by definition, home mode is the top level (technically even above top level since it immediately pushes into INPUT.List for the top level menu list. Breaking out of the INPUT modes with setMode completely bypasses the exithandlers, so there no way to sync from the INPUT mode, not that it would be any better as a fix. What might need to be done, however, is alter the way that Slim::Buttons::Home::jump($client, 'NOW_PLAYING') works (playlist.pm, line 88). callign this has no effect when followed by Slim::Buttons::Common::setMode($client, 'home'), so their order likely needs to be reversed. Other uses of jump, when not followed by setMode are perfecly fine.
in fact, looks like line 88 of Playlist.pm isn't even needed since the setMode($client,'home'); call automatically goes to the "NOW_PLAYING" menu item
This appears to be fixed. Please verify and reopen if it's still an issue.
There are 536 bugs in the database with targets of '---' that were fixed prior to new year 2006. I am setting them to targets of 6.2.1 to keep them from showing up in my queries.