Rockbox

This is the bug/patch tracker for Rockbox. Click here for more information.

Quick links: Bugs · Patches · Rockbox frontpage

Tasklist

FS#7006 - Dynamic data tags aren't refreshed properly on scrolling lines

Attached to Project: Rockbox
Opened by Nicolas Pennequin (nicolas_p) - Tuesday, 10 April 2007, 19:43 GMT+2
Last edited by Dominik Riebeling (bluebrother) - Saturday, 04 June 2011, 23:21 GMT+2
Task Type Bugs
Category Themes
Status Closed
Assigned To No-one
Player Type All players
Severity Very Low
Priority Low
Reported Version Daily build (which?)
Due in Version Future release
Due Date Undecided
Percent Complete 100%
Private No

Details

It's not possible to use a dynamic tag on a scrolling line in the WPS.
For example, with %s%ar%pc, the time won't be updated correctly even though the line doesn't scroll.
Another example is the next track information. If it is on a scrolling line, it won't be updated correctly either.

This bug isn't caused by the tokenizer. It was already present in the old code. In fact, it wasn't present in the tokenizer code until this commit : http://svn.rockbox.org/viewvc.cgi/trunk/apps/gui/gwps-common.c?r1=13080&r2=13081, which was in  FS#7000 .

So basically it looks like scrolling lines and dynamic tags are incompatible. Either lines with dynamic tags can't scroll, or dynamic tags on scrolling lines aren't updated right.
Currently, a workaround is to use sublines to force a refresh.

There is a forum thread with a rather interesting discussion about this issue: http://forums.rockbox.org/index.php?topic=12055.0
This task depends upon

Closed by  Dominik Riebeling (bluebrother)
Saturday, 04 June 2011, 23:21 GMT+2
Reason for closing:  Out of Date
Additional comments about closing:  Theme engine has been changed a lot since so this issue shouldn't be present anymore.
Comment by Marianne Arnold (pixelma) - Monday, 30 April 2007, 18:47 GMT+2
I can confirm this with the next track info on Archos, where it is very dynamic because it's only available when a part of the next song is already in buffer (within about the last minute of the current song depending on bitrate etc. - not to be seen in an Archos sim btw.).

I noticed that it didn't display the next track info properly a long time ago but wouldn't have thought that it has to do with it being on a line that should scroll. Forcing the update by putting the code into subline(s) worked - that's the reason why the next song info line in the svn Archos-iCatcher is the same code in two sublines...

Just now I removed the scrolling line tag and it works perfectly without forcing the refresh with sublines (haven't tried the earlier tokenizer though).
Comment by Magnus Holmgren (learman) - Sunday, 12 August 2007, 18:35 GMT+2
For next file information, it ought to be possible to with a work-around. As the only real problem (AFAIK) is when the next file information becomes available (due to the buffering), that special case could be detected and the scrolling line would then be updated. This would cause the scrolling to reset, but only seldom, and only when needed.

The scroll reset ought to be possible to fix too. It would certainly make lcd_puts_scroll_style_offset more complex, to put text correctly into the scroll buffer and handle the case where the line length changes. Of course, it requires someone interested enough to give it a try... :)
Comment by Jonathan Gordon (jdgordon) - Sunday, 15 June 2008, 14:37 GMT+2
*note... only done a half-assed attempt*

so, i've had a quick look at this and there are 3 options (of which ive had a quick try at the first 2)
1) add a lcd_scroll_change_text() call which works fine, excpet unless almost all the logic from the lcd_puts_scroll_style_offset() function is duplicated it only partially works (if the length of the string changes alot it might change the scroll type (bidirectional or not) which causes wierdness... also i found it would scroll fully to the left and instead of sliding in from the right (which unless im going crazy is expected) it spits out the whole string at the far left again.
2) modify lcd_puts_scroll_style_offset() so it tries to resume with the changed text.... failed attempt... need to try this one again though

3) the actual probalem is because wps_refresh is never called with (refresh_mode & WPS_REFRESH_SCROLL) == true.... so one easy fix is to just check update the scrolling lines forcibly every 3s or so?
Comment by Florian B. (Flowtek) - Saturday, 28 May 2011, 15:21 GMT+2
For everybody still having this Problem and looking for an easy solution,
the following worked on my Sansa Clip v1.
So far I only found these Topics and some suggestions and even as this is pretty old the problem still exists.
Therefore I suggest this example-code and maybe this saves some people some time.

%?if(%it, =, %It)<%?if(%ia, =, %Ia)<%t(0.1)%s%acNext Track Loading;%t(0)||%s%al%Sx(Next:) %Ia - %?It<%It|%Fn>>||%s%al%Sx(Next:) %Ia - %?It<%It|%Fn>>

Next Track loading is displayed as long as the next title info is not available. Then it updates after <= 100ms and scrolls and behaves as expected.

Greetings

Loading...