• Status Closed
  • Percent Complete
  • Task Type Bugs
  • Category User Interface → Themes
  • Assigned To No-one
  • Operating System Iriver H300 series
  • Severity Low
  • Priority Very Low
  • Reported Version Release 3.4
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by mikeholden - 2010-01-21
Last edited by jdgordon - 2010-08-03

FS#10926 - Backlight off causes track info to freeze

On my H340, once the backlight fades to off, the now/next track names in the WPS freeze. They remain frozen once the backlight comes on again (due to button press), even though playback has now progressed onto subsequent tracks the track 1 & 2 info remain on screen. Other info (track progress, time remaining etc are still correct, just the track title, track number etc are stuck.

This is tested with current CVS r24271, and a “clean” set of settings (i.e a fresh .rockbox tree from the build, all default settings).

To reproduce:
1. Play a playlist or directory with multiple tracks (at least 2).
2. Let backlight fade to off during 1st track.
3. Wait until track transition occurs to track 2.
4. Press Vol Up to activate backlight
5. Note the track names displayed are still track 1 & 2, not track 2 & 3.

Closed by  jdgordon
2010-08-03 07:28
Reason for closing:  Fixed

Actually, the problem only occurs with versions greater than Release 3.4.

Release 3.5 wasn’t an option at the time I filed the bug! “Release 3.4” in this context means 3.4 and/or later. I put a specific SVN revision number in to state explicitly the version with a problem.

I’ve been having this problem on my H320 lately and it’s getting really annoying, especially when I’m driving. I hope someone can figure out what’s wrong.

this is almost certainly because the backlight off is stopping the full refresh that happens on track change. what needs to happen is either a refresh happens while the backlight is off, or (probably better) do the refresh when the backlight comes back on

let me know if this is fixed… just looking at the code again, I dont think that fix fixed it :p

During one car ride, I thought I noticed it get out of sync again until I went into the file browser and back to the WPS. On the next car ride, it seemed to update correctly and I couldn’t seem to reproduce it. Now I’m wondering whether I mistakenly thought it was out of sync on the first trip. At the very least, it seems to work better now. I’ll post again if I notice it getting out of sync again.

I’ve tested it this morning and the infos are still out of sync.

Is it out of sync while the backlight is off, but back in sync when the backlight is turned back on? Or always out of sync?

Could it be that the WPS isn’t updatedwhile the backlight is off - even on targets where the display can be read without backlight.

When the track change is done while the backlight is on, the info are updated correctly.
But they aren’t refreshed when the backlight goes on after a track change and don’t change unless you launch & exit the file browser.
If the refresh is time driven, then it’s longer than the backlight fade off timer (30s maybe?).

I don’t see why the backlight status should be relevant to the update - at least not when the screen can be read without a backlight.

From what I remember of the svn history, that’s exactly what it’s trying to do.
Main LCD: not readable when backlight off ⇒ no update when backlight off, to power consumption.
Remote LCD: readable when backlight off ⇒ update every time.

The problem seems to be that when you turn backlight on, the screen isn’t automatically refreshed (maybe it’s trying to fast and the screen still says that it’s off?).

I’ve checked a few more times and this time the screen got refreshed every time 1-2s after the backlight came on.
It’s the same build that the last time I checked and from wich I wrote that it dind’nt work. Quite strange.
I don’t know what’s happening, maybe to much work ^^

I’ll continue to check to see if it’s really ok everytime.

There’s definitely a problem remaining.
Sometime the infos are refreshed, sometime they aren’t.
Can’t find a way to easily reproduce though…

Still having a problem with this. Like Ronald said, sometimes it works right, sometimes it doesn’t. I haven’t been able to find a pattern.

Any chance of this getting fixed? Pretty annoying having out of sync track info for the last year.

cE10 commented on 2010-08-02 12:31

I can confirm this erroneous behavior for 3.6 on my H340.

I think it is now fixed (again :D )

in 27666. let me know how it goes

cE10 commented on 2010-08-02 15:08

Well, build 27666 simply ignores my WPS theme (as described in  FS#11514 ) and uses the default.

because that wps is broken… ( and ) need to be escaped (i.e %( and %) )


Lines 5,7 and 8 need updating due to skin syntax changes. Here are the updated lines:

%s%ac%?ia<%ia|%?d(2)<%d(2)|%(root%)» %s%ac%?id<%id|%?d(1)<%d(1)|%(root%)» %ac%?iy<%(%iy%)|>

With build 27666, the informations are now on sync. Do they get refreshed every every time when the track change or are they just refreshed when the backlight goes on?
I did notice that the progress bar got broken? Did progress bar wps syntax changed recently?

cE10 commented on 2010-08-03 07:21

Well, build 27666 simply ignores my WPS theme (as described in  FS#11514 ) and uses the default.

cE10 commented on 2010-08-03 07:22

Please ignore my last double post. Firefox resent some old information.

cE10 commented on 2010-08-03 07:27

With Michael’s help on the new syntax, all works fine now. I do have a progress bar in my WPS theme, and it seems to work allright.

Ronald, it is doing what it was always supposed to and only updating when the backlight is on. progressbars may have chaged since you last updated…


Available keyboard shortcuts


Task Details

Task Editing