Bugzilla – Bug 2079
Display shows nothing after power on
Last modified: 2008-12-18 11:38:22 UTC
I'm running the latest version of the trunk, but this problem was here in yesterday's build as well. I've been away for two weeks, so I'm afraid that I don't know when it appeared. When I turn my SB2 on using the power button, the display doesn't show anything until I press another key. My off display state is brightness==0. If I press power, it's as if nothing has happened i.e. the display remains dark. However, if I then press anything, e.g. the left arrow, the display comes to life and the button press is acted upon. My guess is that powering on the SB2 isn't triggering a redraw. Given that noone else seems to have spotted this, I'm also guessing that it's my brightness==0 in the off state that is partially to blame.
Max - if you try the patch I posted to the dev list on 3rd Sept for resuming the current playlist [file name resume2.diff] does it fix it? Mail me direct if you aren't on the dev list. I noticed a missing call to brightness whilst doing this patch and added it in. You also get a setting for whether to pause or play when the player stops/starts. NB patch has a remaining print statement if you see garbable in the log..
Hmm, this seems to have fixed itself, but something's definitely weird. Whilst using the player normally, I pressed Brightness in the now playing screensaver but it didn't do anything. No matter how many times I pressed Brightness, the level remained the same. I paused the track, tried Brightness again, but still nothing. I then pressed on and off as a last ditch, and noticed that this had cured the previous problem. Not quite sure what's going on! In case it's any use, my current off screen saver is 'none', but I'm fairly certain that I had the display issue before setting it this way - it was previously the rss ticker. Don't know whether this means that the bug is Resolved - I suspect there's still a bug lurking somewhere!
Is this on SB2 / Softsqueeze? If so can it be resolved by changing font size?
Max - was any of this seen with softsqueeze rather than a real squeezebox? I've just sent Richard a patch for softsqueeze as it currently interprets the brightness values in a different order to a real SB2. This impacts the logic slimserver uses to ensure does not power on in the zero brightness state.
I've seen this too. it seems that on power on, the display sticks at the brightness level of the off state (at least in my case). as soon as I hit a key, the brightness does go to the right level, so I suspect either the screensaver wakeup isn't reacting right on power, or the screen update isn't getting the brightness setting change.
This was with my real Squeezebox2. I've never seen the problem with SoftSqueeze or any other device. That said, I've only tried on my SB2. ;-)
Kdf - current power on code does not change the brightness, it relies on the screensaver mode check to do this... The patch I posted for resuming play does include this as I added a brightness call to the power on code. I think this looks better and should mean it is less dependant on the screensaver code. Lets see where this goes, but I would like to include the brightness change in the power on code.
I missed the patch you speak of. I'm sorry, I've been stupidly busy lately, so I guess I missed it in all the posting. It doesn't seem to have been attached in the forum version. It might be worth putting the brightness fix in now, since it looks like the rest is still under discussion.
On further examination I think svn 4111 onwards should work already for at least the power on case. Slim/Utils/Prefs has always included callback functions which are called when the brightness prefs are written. However until the update above $client was not passed to the onChange function meaning that these were not actually doing anything! Could you confirm that you see problems with 4111 onwards
I'd have to comfirm on that. I was at 4177 (well, about to commit it) when I wrote comment 5.
Disregard last post - but I am getting there. This is due to the preferences change in 4125. Will fix once it is agreed how the preferences code should work...
Triode: should I assign this bug to you?
Yes - put this down to me. Now we agree the brightness code should change (rather than preference code) I'll look at it.
Hopefully resolved in svn 4222. Please try.
seems better for the case I was seeing.
Marking as resolved as no negative feedback here on on forum thread.