Odd interface stuff in current/recent dev builds

[speachy]

I have now reverted to my fully personalized installation of 1bf19eaaff-241124, with the language setting commented out of the .old, .new and current versions of my config.cfg files, and all the No/Yes menus look as they should.

...Grab the latest dev build (or the 1124 daily when it lands) and see what happens when you try changing the language.

(If this does resolve the issue, it's due to a buffer overflow of the low-level disk cache code that has been been there a for a _long_ time.  It could also explain some of the random wonkiness on the ipod5g, fuzeplus, and some uncommon devices...  The ipod6g was accidentally immune until I ripped out bunch of device-specific hacks in its ATA device driver...)

[iPodVT]

...Grab the latest dev build (or the 1124 daily when it lands) and see what happens when you try changing the language.

(If this does resolve the issue, it's due to a buffer overflow of the low-level disk cache code that has been been there a for a _long_ time.  It could also explain some of the random wonkiness on the ipod5g, fuzeplus, and some uncommon devices...  The ipod6g was accidentally immune until I ripped out bunch of device-specific hacks in its ATA device driver...)

I just now updated to dcec6828a3-241124 and I'm sorry to have to report that I'm still seeing "ouping" and "and artist at the bottom" when I switch the language back and forth between english and english-us.

I have to sign off for tonight.  I'll check back in again tomorrow.

[iPodVT]

This morning I did a little more testing to try to drive this bug, using an iFlash-modded 160GB 7th Gen iPod Classic running dev build 7ea64a315b-241124.  I successively changed languages and observed the displayed "Yes" item in the "Start Sleep Timer On Boot" No/Yes menu after each language change.  At the outset, the language was set to english-us and the "Yes" item was displayed as "ouping".  Here is a list of the languages I subsequently tried and what the menu displayed for "Yes", listed in the order in which I changed languages:

english - "and artist at the bottom"
english-us - "ouping"
francais - "Press LEFT to cancel"
espagnol - "ror de archivo: %d"
deutsch - "ht wiedergeben"
dansk - "Ja"
english-us - "Yes"
english - "Yes"
english-us - "Yes"

When I saw "Ja" after changing to dansk I guessed that it translated to "Yes", so I again selected english-us, english, and english-us one more time, and at each turn the menu correctly displayed "Yes".  At that point I checked the contents of the .cfg files and they all contained "lang: /.rockbox/langs/english-us.lng" (as had previously been the case).  So I rebooted, still in english-us, and the menu reverted to "ouping", though the .cfg files still contained the same "lang: /.rockbox/langs/english-us.lng".

Is there a glimmer of a clue in any of this?

[speachy]

Is there a glimmer of a clue in any of this?

WEll, that's just reaffirming that the I/O pattern that the language load paths use manages to pathologically trigger the underlying issue.

So, here's a build that turns on a bunch of instrumentation when the language stuff is used.

  https://www.shaftnet.org/~pizza/ipod6g-exp1.zip

Load it up (pristine .rockbox dir please), then go into the settings, change the language (thereby triggering the problem, please make sure it happens too), then go into the debug menu and select 'dump log file'.

That will create '/logf.txt' -- please send that my way.  Hopefully that will tell me wtf is going on behind the scenes, and from there maybe figure out where things are going awry.

[iPodVT]

So, here's a build that turns on a bunch of instrumentation when the language stuff is used.

  https://www.shaftnet.org/~pizza/ipod6g-exp1.zip

Load it up (pristine .rockbox dir please), then go into the settings, change the language (thereby triggering the problem, please make sure it happens too), then go into the debug menu and select 'dump log file'.

That will create '/logf.txt' -- please send that my way.  Hopefully that will tell me wtf is going on behind the scenes, and from there maybe figure out where things are going awry.

A pristine installation of this experimental build did produce the "Yes" -> "ouping" bug.  Attached is the log file (which I found in the .rockbox directory).

Question:  are there dev builds older than 14 days that I can access/download or would I have to build them myself from source code?  At this time I'm specifically interested in those between the beginning of October and now.  Thanks.

[iPodVT]

Question:  are there dev builds older than 14 days that I can access/download or would I have to build them myself from source code?  At this time I'm specifically interested in those between the beginning of October and now.  Thanks.

The reason I want access to those dev builds older than 14 days (or more specifically from Sept 9 through Oct 29) is that I have an ipod6g currently running f7db73097a-240909 that doesn't exhibit the problem with the No/Yes menus.  And I first noticed and reported the No/Yes menu bug with an ipod6g that was running 914a56f34c-241029 [https://forums.rockbox.org/index.php/topic,55041.0.html].  So using a binary-search-type process of elimination with dev builds from the earlier to the later, it should only take me a handful or so of tries to find the dev build in which the bug first appeared.  That could lead us to the change(s) that caused the bug.

[speachy]

The reason I want access to those dev builds older than 14 days (or more specifically from Sept 9 through Oct 29) is that I have an ipod6g currently running f7db73097a-240909 that doesn't exhibit the problem with the No/Yes menus.  And I first noticed and reported the No/Yes menu bug with an ipod6g that was running 914a56f34c-241029 [https://forums.rockbox.org/index.php/topic,55041.0.html].  So using a binary-search-type process of elimination with dev builds from the earlier to the later, it should only take me a handful or so of tries to find the dev build in which the bug first appeared.  That could lead us to the change(s) that caused the bug.

Oh, I know exactly _what_ change introduced the problem; it was part of a long series of patches to make it possible to use more modern ATA drivers (and eventually, exFAT).  The question was _why_ it broke; the symptoms don't make sense given the actual code.

As for the reason for not keeping builds older than 2 weeks, that's quite simple -- each set of daily build artifacts takes up about 5.3GB, and storage gets expensive fast. 

There's a reasonable argument to be made to staggering things a litle (eg daily builds for a week, then weekly, then monthly) but that needs to be scripted robustly, and the retention timeframe is still going to be fairly short due to trying to keep the disk space in check.  The "proper" solution is more frequent releases but bugs like this (iie regressions caused from trying to deal with ongoing joy of needing to deal with folks modding two-decade-old hardware) need to be solved first.

Meanwhile.  Please try the latest dev buiild.  It includes a change for a corner case that I'd missed when doing the ata/bigsector refactoring.

  https://build.rockbox.org/data/rockbox-ipod6g.zip

EDIT:  pressed send to soon, added description of the link.

[iPodVT]

As for the reason for not keeping builds older than 2 weeks, that's quite simple -- each set of daily build artifacts takes up about 5.3GB, and storage gets expensive fast. 

Meanwhile.  Please try the latest dev buiild.  It includes a change for a corner case that I'd missed when doing the ata/bigsector refactoring.

  https://build.rockbox.org/data/rockbox-ipod6g.zip

EDIT:  pressed send to soon, added description of the link.

Re the storage requirements of archiving older dev builds:  Right - of course.  I tend to forget that there are many different makes and models of Rockboxed DAPs other than the one that I am holding in my hand in any given moment.

I tried the exp build you posted above (before your edit to the build's description) and "Yes" remained "Yes" in the No/Yes menu.  I didn't find a 'Dump log file' item in the Debug menu so I'm guessing you are not looking for a log file with this one.