Rockbox

is this flac only? does the flac have embedded cuesheets?

the best help you could do is figure out which commit broke it. binchop the last X revisions to at least narrow it down to better than the last 1500 commits

P.S. It is not reproducible in the fuze simulator with just the offending cue/flac.

Ok, I will try to find the offending commit. BTW, is there an archive with old builds?

Your best bet is to use Subversion - do svn up -r<revno> in a binary chop on <revno> until you find the exact revision that broke it.

Well. Major update. (BTW, It seems that the reporter doesn't have right to edit the task description and title - not good IMO).

1. The title should read "Sansa Fuze v1 hangs on database update"

2. Steps to reproduce
- install the new firmware
- boot the player without SD card
- enter the database and press "select" to start database population
* very rarely player hangs here, say 1 of 10 times
- reboot to commit the database
- insert SD
- select any album (I selected the first one in the DB), start playing
- return to the rockbox menu, select database "update now" in the database settings (long press on the "database" menu item in the main screen)
* player hangs after a while, may be after 2-3 minutes, but the database update never completes (or completes, but the player is not responding and one needs to use long "power-off" command"

Versions up to 25298 work Ok, 25299 and higher - hang almost 100%.

Things to consider
- playback works rock solid without the database update: more than 8h, shuffle or album-based, sd and internal memory
- it seems that it is not directly caused by the SD, since there is sometimes a hang during the first update without a SD
- if rebooted in the case of the "initial population" hang, the next boot usually pass it until the playback-hang with the same build
- I have a mix of mp3 (tagged with id1/id2 by the foobar), mpc (!!) and some flacs.
- there is total ~ 2500-3000 songs in the internal memory+sd

P.S.
gcc: arm-elf-eabi-gcc (GCC) 4.4.3
ld: GNU ar (GNU Binutils) 2.20.1.20100303
Host gcc: gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-44)
Host system: Linux

P.P.S. It hangs with
gcc: arm-elf-gcc (GCC) 4.0.3
ld: GNU ar 2.16.1
Host gcc: gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-44)
Host system: Linux

And even it hangs with the 'official" 3.5.1 release.

r26185 - the bug is still there.

Here is what I did on my fuzev1:

format, install r26191.

shutdown, insert Transcend µSDHC 4GB class 6

init database, reboot

plugins -> pictureflow

No crash/freeze, debug menu -> database info reports 2080 entries.


Rockbox 3.5.1 was released on march 4th, and r25299 was committed on march 23rd, so
"Versions up to 25298 work Ok" and "it hangs with the 'official" 3.5.1 release" are not compatible.

Yes, this works for me too.

But I mean not the initital population, but the database _update_ with the music playing. Here is the difference. First this bug hit me, when I got freezes with the "autoupdate database" option.

BTW, there is no number of entries in the "debug -> database info" for me. Strange.

P.S. As for 3.5.1 - I was wrong. Re-checked it, it works Ok. Maybe it was the corrupted internal drive after previous hangs.

- remove .rockbox/database_*
- boot without µSD
- initialize database (reboot isn't needed anymore)
- album -> all tracks (playing start)
- insert µSD
- go to menu while playing continues
- database update now
- move to debug menu to see progress

Did that, it crashed while display was off.

Did it 2 other times with backlight forced on and it didn't crash.
Does it only happen with the µSD ? Do you have other µSD cards ?

Unfortunately I have only two microSD cards, and the other is only 1GB. Will try, but don't know if it is big enough to make any significant load :(

Small question, did you ever use PictureFlow yourself too? I got frequent lockups since r25299 too. It's better sinze r26160, but still get occasional hangs (thanks funman!). I'm also using a uSD-card, but one with a size of 16G, and my database gets over 6000 entries!

And about 10 minutes ago, i also suffered a freeze when doing a database update. I'm just guessing this might be caused by a spurious interrupt: the fuze v1 just freezes at an unpredictable point, and i didn't see any system in it ... yet. Maybe i can be of help over here.

Marc, I tried pictureflow - it is nice, but used it by day-by-day basis. Mostly due to the fact that it is not integrated with WPS and I usually select Artist -> Album. And browsing through 250+ albums is no good :)

Ooops, I mean I _never_ used it on a day-by-day basis. Typo...

Can you give a try to this patch ?

Tried it with r26266 - it crashed (freezed) during the first update without the SD card with the screen on.

BTW, didn't test with the 1GB card yet - trying to find it, it hides from me somewhere...

Tested with r26319 - unfortunately it seems that r26291 didn't help

- got 1 freeze during the database initial population (without a SD card and music playback)
- after hard reboot and chkdsk got one more "freeze" during the background update with the playback (as usual - scrollwheel is not working, music still plays).

disk led is shown (top right) in the freezes ?

If the freeze is during the first update - yes, the "lightning" icon is shown, along with the text "Building database ... XXX found...". But, as I said earlier, the first update (that is initial population) freezes very rarely, say, 1 time of 10 or 20.

If it freezes during the real update with the SD, the screen is off, so I can't see, if this icon is on or not. And more, I've tried several time to rotate the wheel back and forth to see the progress, it seems that in this case rockbox doesn't freeze. But I'm not 100% sure, may be it was just a coincidence.

BTW, is it possible to add some logging to the internal disk? It will be lost 99%, as the database is, but maybe chkdsk will convert it to a readable file?

You can build rockbox with logf() but you must know what you are looking for.

Also you have to patch logf() since by default it writes to disk only on request (and if the system is crashed .. you're out of luck) - saratoga did that already.


As to see what's going on when freezing, you can still force backlight to be always on.

A little update. r26447 - still freezes, on simultaneous playback and database refresh, 1724 entries done (out of ~ 2500). Lightning "disk" icon is on.

Player continues to play and does respond to the power button - the scrollwheel light turns on. But no scrollwheel reaction, alas.

How long does the playback continue ?

You can check the state of audio buffer in debug -> buffering thread (but can't check database info at the same time obviously)

Usually till the end of the active playlist. Will retest with the debug->buffering thread later.

this seems to work for me, can you try it ?

If we don't find a better fix I want to add this into 3.6 release.

BTW I trigger the freeze by recording FM radio: 96kHz PCM seems to be the fastest way to crash (in about 5 minutes) because it's also the heaviest on SD writes

I committed another less intrusive fix in 3.6 but i don't know how that affects battery life

At first sight, no lockups anymore on my Fuze V1 while PictureFlow is preparing the album artwork.

I tried to build the pictureflow cache for 3 times, and no lockup yet ;-)

Can i test more thoroughly, i.e. repeat the building of the pictureflow cache for many more times? It was already better since a build of about 2/3 weeks ago (don't remember which one), but i still had occasional lockups on my Fuze V1. And when would you consider this entirely bug-free?

Anyhow, when the 'lockup' occured also in my situation the playback continues till the end of the playlist, but i obviously can not get into debug -> buffering thread as the pictureflow progress bar is stuck and the Fuze is not really 'listening' to the buttons and scrollwheel actions anymore.

In fact I was a bit in a hurry because I wanted to be sure to fix for 3.6 release tomorrow, so I committed something a bit different.
Because this patch will cause problems with µSD and button light I think.

First I want to check if this problematic code has any effect on battery life (because its only goal).

If it has no effect I will remove it completely and I think the bug will be gone :-)

At first sight, no lockups anymore on my Fuze V1 while PictureFlow is preparing the album artwork.

I tried to build the pictureflow cache for 3 times, and no lockup yet ;-)

Can i test more thoroughly, i.e. repeat the building of the pictureflow cache for many more times? It was already better since a build of about 2/3 weeks ago (don't remember which one), but i still had occasional lockups on my Fuze V1. And when would you consider this entirely bug-free?

Anyhow, when the 'lockup' occured also in my situation the playback continues till the end of the playlist, but i obviously can not get into debug -> buffering thread as the pictureflow progress bar is stuck and the Fuze is not really 'listening' to the buttons and scrollwheel actions anymore.

For me - no freezes also. Superb! :)

As for battery life - I believe we need a battery bench with and without the patch?