iRiver H340, Amabee theme, progress bar not displayed

[bl999]

Hi all.  The progress bar on the amabee.WPS for iRiver H340 (with 3.13 Rockbox) is not displayed. See highlighted lines below with comments and PLEASE help if you can.

Thanks in advance !!!


%wd
%X(wpsbackdrop-220x176x16.bmp)
%xl(A,lock-220x176x16.bmp,50,1,2)
%xl(B,battery-220x176x16.bmp,2,2,10)
%xl(C,volume-220x176x16.bmp,28,2,10)
%xl(D,shuffle-220x176x16.bmp,122,4)
%xl(E,repeat-220x176x16.bmp,84,1,4)
%xl(F,playmode-220x176x16.bmp,103,2,5)

#commented out to bypass album art display:
#%Cl(138,41,75,75)

#original progress bar code: DOES NOT WORK:
%pb(11,137,199,8,pb-220x176x16.bmp)

#adding View port below displays part of status bar where progress bar is suppossed to be ??!!
#%V(11,137,199,8,1)
#%pb(0,0,199,8,pb-220x176x16.bmp)

%?mh<%xd(Aa)|%xd(Ab)>
%?bp<%?bc<%xd(Ba)|%xd(Bb)>|%?bl<|%xd(Bc)|%xd(Bd)|%xd(Be)|%xd(Bf)|%xd(Bg)|%xd(Bh)|%xd(Bi)|%xd(Bj)>>
%?pv<%xd(Ca)|%xd(Cb)|%xd(Cc)|%xd(Cd)|%xd(Ce)|%xd(Cf)|%xd(Cg)|%xd(Ch)|%xd(Ci)|%xd(Cj)>
%?ps<%xd(D)>
%?mm<|%xd(Ea)|%xd(Eb)|%xd(Ec)|%xd(Ed)>
%?mp<%xd(Fa)|%xd(Fb)|%xd(Fc)|%xd(Fd)|%xd(Fe)>
%?C<%Vd(a)%Cd|%Vd(b)>

%V(181,0,-,14,1)
%ar%cH:%cM
%V(0,18,-,16,1)
%al%t(5)%bl%%%pvdB%ar%?fc<mp1|mp2|mp3|AIFF|wav|vorbis|flac|mpc|a52|wavpack|alac|aac|shorten|SID|ADX|NSF|speex|SPC|APE|WMA|unknown> %?fv<~|>%fbkbps

%Vl(a,21,41,115,20,1)
%s%al%?ia<%ia|%?d(2)<%d(2)|%(root%)>>
%Vl(a,21,61,115,20,1)
%s%al%?id<%id|%?d(1)<%d(1)|%(root%)>>%?iy< [%iy]|>
%Vl(a,21,80,115,20,1)
%s%al%?it<%it|%fn> [%pt]
%Vl(a,21,99,115,20,1)
%s%al%?It<%In - %It|%Fn>

%Vl(b,21,41,190,20,1)
%s%al%?ia<%ia|%?d(2)<%d(2)|%(root%)>>
%Vl(b,21,61,190,20,1)
%s%al%?id<%id|%?d(1)<%d(1)|%(root%)>>%?iy< [%iy]|>
%Vl(b,21,80,190,20,1)
%s%al%?it<%it|%fn> [%pt]
%Vl(b,21,99,190,20,1)
%s%al%?It<%Ia - %It|%Fn>

%V(0,152,-,20,1)
%al %pc%ac%pp/%pe%ar%pr

[[Saint]]

Can you check the behavior against the development build please?

The release is absolutely ancient and there's been a fair amount of changes since then.


[Saint]

[Frankenpod]

At first glance, that WPS file won't work because

 (a) the progress bar doesn't have a view port statement (presumably this is something that worked before a rockbox syntax change?)

and

(b) when you put in the viewport statement for it as shown, it will mess up the subsequent %xd statements, because as written they have no viewport of their own and rely on just using the default whole-display viewport to appear in the correct place (don't know if this is intended behaviour or just an accident that it works this way).

With the progress bar viewport where it is, it's creating a viewport prior to those other statements, which is going to confuse them as they will try and load the bitmaps into that viewport.

Simplest solution would be to move the progress bar viewport and pb statement to the end of the file.

[bl999]

Simplest solution would be to move the progress bar viewport and pb statement to the end of the file.

Yes, this worked.  Thank you so much !!

[bl999]

Can you check the behavior against the development build please?

The release is absolutely ancient and there's been a fair amount of changes since then.


[Saint]

Same behavior with the 20161016 build, but it works fine if the viewport and pb code is moved to the end as Frankenpod suggested, so I guess I will use this latest build.

Just curious, under "dev builds" if I click on "For a stable build, download the latest stable release" I get back to the Rockbox 3.13 Download page.  Is 3.13 really the latest stable release or does this page need to be updated?

Thanks again,

Paul

[[Saint]]

Just curious, under "dev builds" if I click on "For a stable build, download the latest stable release" I get back to the Rockbox 3.13 Download page.  Is 3.13 really the latest stable release or does this page need to be updated?

The page is accurate and does not need to be updated, ...per se.

The ambiguity comes from our build classifications. Stable doesn't imply stability (and in fact the release builds are miles from stable on the majority of commonly used targets when compared to mainline git head/development builds), Unstable doesn't imply instability, and nor does Unusable literally mean that you can't use it. "Stable" as the main page outlines is just a classification term that means that the port meets a certain set of criteria (runs well, is supported by the installer, and has a manual).

In terms of actual stability, for any of the targets that actually have a 'stable' release the development build is going to be orders of magnitude more so because it will include several years worth of bug fixes, optimizations, and feature additions. There was a time, long ago, when the release builds actually mattered but that time has long since passed.

I freely admit that we could do a much better job of communicating this to the user base.

The consensus of opinion at this point is, in a nutshell, that anyone using the release builds are quite likely perfectly happy doing so (until they have an issue and are directed to not do so by support personnel such as myself or other volunteers), and those who are already using the development builds don't require this information.

We could, and should, do a better job of communicating that the release builds are for all intents and purposes to be considered deprecated.


[Saint]

[gevaerts]

Stable doesn't imply stability

I just have to disagree here :)

Stable does imply stability, but not in the sense that you're expecting. "stability" can mean "doesn't crash very often", but it can also mean "doesn't change very often", and the latter meaning is the one we use.

We have to admit of course that development has slowed down significantly over the last five years or so, so dev builds don't change that often either...