WPS sometimes does not display clock (Gigabeat F40)

[Chronon]

I have seen this happen several times, but it's not very predictable.  I will occasionally turn on my unit and play some music only to notice that nothing is displayed by the RTC codes in the WPS.  The clock displays fine in the menu screens, but only plain text characters appear (such as the colon that should separate hours from minutes) on the WPS.  This happened last night and this morning.  But after a charge and reboot everything again displays properly.  I haven't been able to find any determining factor for when this will happen, nor what corrects it.

Has anyone else noticed this behavior?  I'm currently using a build from yesterday afternoon, but I had also noticed this a few weeks ago.

[bascule]

Yes, like yourself, it's an intermittent problem, but I just live with it.

I'm making an assumption that it's related to the WPS parsing/rendering rather than a core firmware/hardware problem, but I don't know for sure...

[Llorean]

Is the clock set to the right time when it shows in the status bar but not in the WPS?

[bascule]

Yes. For me, the clock is always set correctly, it is just that it is not displayed at all in the WPS, as if the RTC tags are not being populated...

It does not appear to be related to reboots, power cycling or switching the battery off

[Chronon]

Llorean, the clock is set correctly for me also.  It just seems to occur randomly.  At least I cannot find any pattern so far.  It hasn't happened again since I posted this.  

I would like to at least have a predictable way of producing this behavior before filing a bug report.  Otherwise, it doesn't seem that such a report would be terribly helpful.

[Llorean]

I've noticed a similar behaviour, but every time I've checked it's turned out that my clock has become unset due to a power off of the battery. The clock can often *look* set because the time it displays in the status bar shows up whether the clock is "set" or not. But if you're certain it's set, then yes, trying to figure out another way to reproduce this would be nice.

[Chronon]

Really?  Any time I have switched the battery off the status bar only displays --:-- for the time.  I have to go into the system settings and set the clock before the time will show up there.  

Also, I haven't noticed that setting the time had anything to do with the WPS returning to the expected behavior.  

I suppose I won't have much more to report on this until I can get this to happen again.

[Llorean]

If you leave the time unset for a certain period (I'm not sure what) it changed from --:-- in the status bar to a time. I'm not sure what triggers this. But after that my WPS still lacks the time, but the status bar shows an (incorrect) time.

[Chronon]

Interesting.  I didn't know this.  I always set my RTC immediately if it becomes un-set.

[Llorean]

I've noticed this because I never use the RTC, and had intended to leave it unset, only to discover it refused to stay that way.

[NicolasP]

I've fixed that problem so now maybe we'll know if the problem in the WPS is an actual one or not

[Chronon]

Good.  I'll download the latest build and see if this behavior reappears.

---------

Update: The RTC becoming unset does appear to account for some of this.  I turned on my player yesterday and noticed that the WPS was not displaying the time.  When returning to the menu I saw that the time in the status bar was reading --:--.  I still don't know what's causing this, but at least we can narrow it down to the RTC becoming unset for some reason.

I was going to file a bug report on Flyspray, but I found an existing bug report regarding unsetting of the RTC due to charging on an iRiver H3xx unit.  I was unsure of whether or not to file a separate report, so I just commented on that one.

http://www.rockbox.org/tracker/task/7337

[cvitullo]

yeah, i just noticed that too, i have TODAYS build (7/1), on a sansa e250

[bascule]

Update: The RTC becoming unset does appear to account for some of this...

I concur. I'm can see that my Gigabeat clock is now often unset, which wasn't noticeable before the change. It seems to happen on USB connection/build update type events.