Why is the ipod4g UI so slow with the most recent dailies? (SOLVED)

[Shovas]

I mentioned in a previous post that the 2007-03-01 daily seems to have the fixed the long standing aggravation of instability for ipod4g users. But, now I'm finding unacceptable UI responsiveness. When I first experienced this, I started boosting the cpu freq manually so it was running at 75mhz all the time. It still doesn't help. As an example, sometimes I'll be able to hit Next a few times and it's pretty quick. Then on a random Next it'll take upwards of 15-20 seconds. It doesn't matter if I've hit Next once or many times, it's random.

If I'm playing a song and I hit Menu it will sometimes be almost instant but sometimes it will take the same 15-20 seconds.

Not only that, but I'm finding songs above 192kbps (all oggs) can't be decoded fast enough for play without stops. I've tried the anti-skip buffer but nothing helps. I am also not running some of those backgrounds tasks such as directory cache or the database features.

None of this used to be an issue with the dailies from Jan 1st and Feb 1st. I noticed that new menus and icons have been introduced during that time. Maybe this is where the problem lies? Maybe the ipod4g can't handle the extra features introduced related to the new icons and menus?

[Llorean]

Firstly: What bootloader version are you using?
Secondly: Please, don't report problems with an older daily. At least be using the current build to make sure it wasn't a temporary problem. Make sure you're using the most recent bootloader and most recent build first, then see if it can be reproduced.

[Shovas]

While I only download a specific date daily, I download the latest bootloader at the time I create the build.

    60972 Feb  4 08:50 bootloader-ipod4g.ipod

Point of interest, I reinstalled 20070201 and I'm not running into any problems 20070301 on the same songs.

I will try today's daily and see if it had the problems the first of the month had.

[Llorean]

So, your bootloader is from Feb 4th? Please, update to the latest official one following the official installation process.

Also, is your build at all patched, since you mention making your own build?

[Shovas]

Actually, while the timestamp on the bootloader file said Feb. 4th, that's actually the timestamp from the server when I downloaded it on 2007-03-01 to install that daily.

I just downloaded the boot loader today (2007-03-10) and it's timestamp is March 6. Still you have a point.

I'm running 2007-03-10 right now testing the song that killed 2007-03-01 and I'm not hearing any problems yet.

As a side note, this is how I easily install dailies:
http://me.selah.ca/pub/tmp/do.sh

[Shovas]

Not patched.

[Llorean]

Firstly, we don't recommend dailies. That's why there's no direct link to them. We instead recommend the 'Current Build' which is what the link is to. That's why I kept using the phrase current build, rather than daily. A daily can be as much as 23 hours and 59 minutes old, and a bug in it could be long fixed by the time you download and install it.

And yes, the newest bootloader is important before reporting a bug because when the bootloader changes it is usually an important change.

This is why before reporting a bug we want you to be using the current build, not the latest daily, and we want you to be using the most up to date bootloader. Otherwise the bug may not even exist any more, and you're just experiencing a strange interaction from two pieces of software that aren't meant to be used together (old bootloader, new build, for example) or a bug that has been fixed days or even so little as hours ago, but is in fact gone.

That being said, if you can reproduce it with the newest current build and bootloader, we do want to hear about it.

[Shovas]

With 2007-03-10, all my complaints are resolved satisfactorily: (1) Next always works pretty quickly, a little delay, but not much, (2) Songs don't stop and then start again (apparently waiting to buffer or something), (3) Menus work decently quickly even when a song is playing.

You know, I check the cvs logs every time I install a daily and I rarely find ipod (let alone ipod4g) related changes so I'm surprised dailies have been having this much impact on my ipod.

At any rate, I guess this goes to show dailies are definitely development builds.

[Llorean]

It's very hard for most people to identify changes that affect their target. 95% of changes affect all players.

There is no "iPod Rockbox", there's just "Rockbox" which happens to run on several players, with small bits here and there that are specific to certain ones, the drivers primarily, but the vast majority of the software is the same code on all of them.

[Shovas]

What's the definition of the "current" build? I was under the impression dailes were more up-to-date than the current build?

So, you're saying that (for example) in my "do.sh" script, I should rather download the current build, but keep all the rest of the parts the same? Then the current build might have intra-day changes so I could run it twice in a day to see if a bug had been caught and fixed in that day?

[Llorean]

The current build is all the most recent changes. That's why it's current. If you read the current build page it even explains that the daily build is older.

Dailies are made once per day. Current builds are made every time Rockbox is changed by a developer, which includes the most recent bug fixes (and the most recent bugs, but if a daily gets a major but easily fixable bug it's stuck with it for 24 hours, a current build with a major but easily fixable bug is likely to have it for only a few minutes to a few hours).

[Shovas]

Wow, you know I read that but I assumed it was only rebuilt for major changes because I didn't imagine they had a system setup to recompile everything any time a change committed, heh. Impressive.

[Llorean]

We actually have a distributed build set up.

Every time a change is committed, 59 builds take place across 12 computers (currently) which are then delivered back to the master build server, with the 23 builds that users can actually download being made available on the page for download as they're completed. The other builds are simulator and bootloader builds that aren't intended for use, and are just intended to verify that the committed changes have not introduced compilation errors.

[Shovas]

Downright impressive. I updated my script to use the current build. I enabled a wack of features to see if I could crash it / bog it down when playing that particularly problematic song. Still testing.

[Shovas]

Well, it doesn't want to actually start playing the file. I can't force it to play a file. It just loads up the file info, displays the normal playing screen but doesn't get into playing the file.

I'll try again tomorrow.