Bugzilla – Bug 3970
Text scrolls on entry to Now Playing
Last modified: 2006-10-11 14:21:36 UTC
When using the remote to change into now playing, the text scrolls vertically as the player is returning a knob update: Following seen with fw 7: 2006-08-19 17:04:10.2822 Switching to playlist view 2006-08-19 17:04:10.2827 popped to button mode: empty! 2006-08-19 17:04:10.2833 skipping sending redundant knob position 2006-08-19 17:04:10.2860 popped to button mode: empty! 2006-08-19 17:04:10.2868 skipping sending redundant knob position 2006-08-19 17:04:10.2869 skipping sending redundant knob position 2006-08-19 17:04:10.2870 pushing button mode: home 2006-08-19 17:04:10.2899 pushing button mode: INPUT.List 2006-08-19 17:04:10.2911 sending new knob position: 3 with knobpos: 0 of 10 2006-08-19 17:04:10.2920 sending new knob position: 3 with knobpos: 0 of 10 2006-08-19 17:04:10.2932 pushing button mode: playlist 2006-08-19 17:04:10.2950 sending new knob position: 1 with knobpos: 0 of 10 2006-08-19 17:04:10.3231 knob position: 3 (old: 0) time: 7277430 2006-08-19 17:04:10.3244 funct: [knob] old: 1 new: 3 is after setting: [3] What appears to be happening is that the player sends a knob position update for the old list position and hence this causes the screen to change. Player should not send anything? More generically, it may be useful to include a mode id in the knob position sent to the player and knob update sent back [or just a sequence number for the knob list]. If the round trip time is large [squeezenetwork] there is a chance you will be receiving knob updates for the previous mode which you want to discard rather than process?
this is probably the same problem with browseplaylistindex() that is causing issues with a couple other knob bugs here. It hacks in a knob update. Your idea sounds like a much more thorough solution than what I came up with last night.
Firmware 8 (in r9077) now uses a sync code between the slimserver and firmware to check for knob updates from a previous mode. This firmware also fixes a timing issue when updating the knob encoder. The text still scrolls on entry to Now Playing, but the knob is now correctly set and should work fine in this mode. The extra scroll is caused by a loss of sync between the firmware and knob encoder - I need to think about this for a bit. I noticed when entering Now Playing from the settings menus several knobUpdate's are called with various parameters. It would help if the number of these updates could be reduced.
I suspect the multiple calls is again due to browseplaylistindex();
You will get multple calls going into modes - the server pops all current modes and then pushes into playlist and then INPUT.* mode. I'm not sure we can do something in the server to avoid this other than delay sending the knob update for a fraction of a second using a timer which gets cleared if a new knob update is created. I could look at this. Also with the knobSync we need to wrap it as you are only sending unsigned chars?
ah yes, right you are. timer would be one option. also possible to bypass the updateKnob on popMode for mass jumps such as that for entering 'now playing'. There are probably other applications for a shortcut pop for cases where we know it is just to quickly dump our way back to a fresh, top-level stack. Maybe a "clearModeStack" function?
I think bypassing the popMode is dangerous as it would avoid calling any exit functions people register and hence leave state that they didn't want? It also messes up my logic of what to put on the second screen.... One thing I would urge is that we are consitent on the way of supporting mode jumps - its different between Now Playing and other modes at present. Playlist does something special on exit which is different from all others etc. However probably best to leave for 6.5. Timer seems easy and safe to me at present.
Fixed in Transporter firmware 10 now available in slimserver 6.5 and trunk.