Rockbox

It's sort of an "out of memory" by audio but overly-severe treatment of it. Sure it's the build date and not just a huge database and/or alot of optional stuff enabled?

No optional stuff enabled. Rockbox is as it comes from the build (as I have to re-enable Timestretch every time to listen to podcasts at >100% speed and not listen to chipmunks).

Database is of 195 files, mostly flac files but a few mp3s. Total of about 5GB (in an 8GB Clip Zip. No SD card installed).

I am reasonably sure it's the build date as I tried every daily build after the 2nd of May and all of them show the same error.

I have not tried builds before the 1st May (except one but I can't remember which).

I will try earlier builds later today and report on their crashiness after making a database.

If I don't make a database, everything else works OK AFAICT.

Can you go to system > debug > buffering and report the values for the first 4 lines (pcm and below)? Should let you know how much memory is actually allocated.

One of the builds from today (May 24) works for me, starting with a completely new .rockbox folder.

No optional stuff enabled. Rockbox is as it comes from the build (as I have to re-enable Timestretch every time to listen to podcasts at >100% speed and not listen to chipmunks).

Database is of 195 files, mostly flac files but a few mp3s. Total of about 5GB (in an 8GB Clip Zip. No SD card installed).

I am reasonably sure it's the build date as I tried every daily build after the 2nd of May and all of them show the same error.

I have not tried builds before the 1st May (except one but I can't remember which).

I will try earlier builds later today and report on their crashiness after making a database.

If I don't make a database, everything else works OK AFAICT.

Sorry for the repost, my error.

In answer to the questions

With 2nd May build:
pcm: 0/5242

With 24th May build:
pcm : 0/0

Today's build has the same issue as reported.

All builds work up until 2nd May.

Misread earlier question so what follows is the buffer info for the builds of 2nd, 3rd and 24th May.

2nd May:

pcm: 0/5242
alloc: 0/59
real: 0/59
usefl: 0/59

3rd May:

pcm: 0/0
alloc: 0/0
real: 0/0
usefl: 0/0

24th May:

pcm: 0/0
alloc: 0/0
real: 0/0
usefl: 0/0

Sorry, you need to be actually playing (or at least have played and then paused) music. Just the 24 May build is enough.

pcm: 507904/5242
alloc: 5926239/59
real: 5925615/59
usefl: 5269019/59

I'm not expert on these things, but if the player thinks the audio buffer is only 59 bytes (and of those 59 bytes its used about 6 million of them), I think something has been terribly corrupted.

I don't suppose its this specific commit that stops working? http://git.rockbox.org/?p=rockbox.git;a=commit;h=da6cebb Was committed late on May 2 and touches the buffering code.

I may be incorrectly reporting the available memory as the screen is small and may not be displaying all the numbers.

Heh, so those numbers probably aren't correct? Might be nice to mention up front before i go trying to figure out what they mean :)

Here is what the screendump shows

"5242" should be "524288", so yeah, I'd say it's just cut off. It also shouldn't be an issue for the buffering itself if it hasn't been initialized yet, so the zero counts are nothing unusual if playback hasn't started.

If this is just a "normal" bug and not some kind of corruption, I wonder if we can duplicate it in the simulator, perhaps with the config file that John is using?
Also, can you post the exact build version (git hash) that corresponds to the *PANIC* message?

I am not using any custom config file AFAIK. I am using rockbox "as built". For each build, I am deleting and adding the .rockbox folder.

Simulator? Is this the simulator compilers that are in the Ubuntu VM?

Ubuntu can run the simulator. So can windows if you prefer that.

Still can't reproduce here, so there must be something different between your setup and mine, for example in the config file, or in the audio files.

Ok, correction:
I *can* reproduce it, but only when using RockboxUtility to install rockbox, it doesn't happen when I just unzip the result of 'make zip' when built from source. I suspect some voice-related stuff.
Also, the backtrace screen is mostly useless on the clip zip, it misses the last digit of the address, I guess we can skip the "0x" prefix.

Decoding the backtrace, I get:
playback.c: 827 - panicf("EOM"...) in audio_reset_buffer_no_alloc()
playback.c: 921 - audio_reset_buffer_no_alloc() in audio_reset_buffer()
playback.c: 3679 - audio_reset_buffer() in audio_restore_playback()
talk.c: 629 - audio_get_buffer() in restore_state()
talk.c: 786 - restore_state() in talk_id()
main.c:305 - talk_number() in init_tagcache()

I'm suspecting commit da6cebb6b0b17b4a75a2bd4f51b7cf70b5dafe40 ("Use buflib for the allocation of voice PCM resources.") now

Ok. It is probably not my config but my trash folder. I had some corrupted files that Nautilus (and Windows) wouldn't remove in my .Trash-1000 folder. This may be causing the instabilities. Formatting the device and re-running the installation has deleted them. Adding a few mp3 files and running the database initialisation hasn't caused any fatal panics so far.

I put a panic on the result of core_alloc_maximum in playback.c: audio_reset_buffer and it returns -1 and this panic fires. Next thing I'll try is to put audio_init before tagcache_init in main.c

The problem appears to be that during the database commit at startup of rockbox, the database and the voice menu systems are competing for memory, so one of them cannot get any memory allocated. I don't know the exact fix yet, but in the meantime you can try to disable voice menus (under settings / general settings). To recover from the bootloop, you can insert the USB plug and then hold the LEFT/PREVIOUS button until it boots to the original firmware and delete any .tcd files from the .rockbox directory.

I would just remove the voicing at that point for now (#if 0). It's done before audio (and the hardware) is initialized anyway and I can't see how it could even ever have worked unless it used to be done later , after audio init.

I just disabled the talking in init_tagcache for now in ba8e436. Any success?

I'm not the original reporter, but I had this issue earlier on the Sansa Clip v1 and even isolated it to the same commit da6cebb.

I compiled the latest HEAD (currently running dce80ea) and cannot reproduce the problem anymore. Presumably the latest patches have fixed the issue.