The home menu is using INPUT.List.  Not sure why one menu would behave differently from another when using the same INPUT mode.

I get it now.  I could maybe tackle this one.

2006-08-18 00:26:36.4873 skipping sending redundant knob position
2006-08-18 00:26:36.4876 pushing button mode: home
2006-08-18 00:26:36.4953 pushing button mode: INPUT.List
2006-08-18 00:26:36.4964 skipping sending redundant knob position
2006-08-18 00:26:36.4968 skipping sending redundant knob position
2006-08-18 00:26:36.5278 changepos: newpos: 0 = scroll dir:0 listindex: 0


the problem stems from the eval in Common.pm at line 1270:
eval { &$newModeFunction($client, 'push') };

This runs the Home mode function setMode(), which pushes into INPUT.List. This means the knob update is done for the list during teh eval.  However, following the eval, the knob is updated for the home mode at line 1292.  This would indicate that any mode that jumps immediately into an INPUT.* mode will have this problem. 

There is also some sort of init problem coming into play, as neither of these two knob updates actually DO anything.  the update comes back with the message that the settings are redundant.  Missing a default knobPos on startup maybe? Setting knobPos(0) in Transporter->init does seem to relieve some aspect of the problem.  There is now an update done on the INPUT.List entry.  I'll keep working on this, but would appreciate any ideas on the proper place to fix these kinds of things.

definately a problem with listLen being set in browseplaylistindex.  I get better results just by knocking that out. Home menu still broken, for example, but popping back into homer works perfecty once that one line is commented out.

just need to get it to work on startup. Somethign strange is going on.  Normally, when entering INPUT.List we just enter and wait.  however, on startup, the server does setMode('home') then pushes into INPUT.List.  This time and this time only, the server picks up a knob function.  INPUT.List registers knobPos of 0 and listIndex of 0, resulting in direction 0...little messy after that.  Here is a backtrace from the 'knob' function in INPUT.List when listIndex == knobPos:

$VAR1 = [
          0,
          0
        ];
2006-08-18 21:49:53.9855 Backtrace:

   frame 0: Slim::Buttons::Input::List::__ANON__ (/usr/local/slimserver/trunk/Slim/Hardware/IR.pm line 743)
   frame 1: Slim::Hardware::IR::executeButton (/usr/local/slimserver/trunk/Slim/Networking/Slimproto.pm line 927)
   frame 2: Slim::Networking::Slimproto::_knob_handler (/usr/local/slimserver/trunk/Slim/Networking/Slimproto.pm line 392)
   frame 3: Slim::Networking::Slimproto::client_readable (/usr/local/slimserver/trunk/Slim/Networking/Select.pm line 238)
   frame 4: Slim::Networking::Select::select (/usr/local/slimserver/trunk/slimserver.pl line 503)
   frame 5: main::idle (/usr/local/slimserver/trunk/slimserver.pl line 456)
   frame 6: main::main (/usr/local/slimserver/trunk/slimserver.pl line 1053)

2006-08-18 21:49:53.9860 changepos: newpos: 0 = scroll dir:0 listindex: 0

why would the server get ir from transporter when I haven't touched the knob?

another thing is that it works AFTER letting it go into screensaver.  however, turning the knob right doesn't break out of saver.  turning left does.  after that, home menu works fine.  This is based on having the two other knob patches in place (bug 3561 and bug 3545

looking at d_slimproto, I'm also not seeing anything from the _knob_handler until the knob is turned left (counterclockwise).  Initially, any movement clockwise gives no response.  Is there something in firmware that could be causing this?

With the latest trunk the slimserver is not sending a knob update when the transporter connects to the slimserver. This leaves the knob in the default mode (infinite detents). The infinate detnet mode in the firmware is not working correctly. This is fixed in fw 8.

An addition the updateKnob needs to be called when transporter connects to the slimserver to initialise the knob correctly. This seems to be more complex than adding $client->updateKnob(1) in reconnect. Any ideas?

There needs to be an initial value for knobPos, or the update skips the important bits.  I am not sure whether Player:Transporter::init() is the best place for that or not.  After that, the updateKnob sends the params.

This should be fixed as of change 9084