Rockbox

Tasklist

FS#11267 - Database update hangs with CUE file

Attached to Project: Rockbox
Opened by Boris Nazaroff (bor_ka) - Thursday, 13 May 2010, 08:15 GMT
Last edited by Rafaël Carré (funman) - Thursday, 03 June 2010, 13:57 GMT
Task Type Bugs
Category Database
Status Closed
Assigned To No-one
Operating System Another
Severity Low
Priority Normal
Reported Version Daily build (which?)
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Sansa Fuze v1. ~ r24000 and up (may be lower versions too - don't know)

It appears that database update hangs the player with the cuesheet support (and cue/flac present). It started ~ with r24000. May be with lower versions too - don't know, I had not the cue on the player then :)


Steps to reproduce

1a. Delete database (for example manually), enter database in the rockbox menu to create
or
1b. Start the rockbox with the existing database and choose "Update Now"

2. Start playing music (or do not start - doesn't matter)
3. After some time player hangs. If the music was playing there is a good chance that it continue playing till the end of the playlist.

- Cue file is in the internal memory
- Internal memory is checked for filesystem errors
- If the cuesheet supoort is turned "off", player does not hang (!)
- The cue/flac that causes the hang during the db update plays Ok though. No errors, no skipping, no hangs during the playback.


P.S. I have C / Unix skills (some 5 years ago) and can compile RB with custom changes. If it is possible to add some logging to clarify the problem, I need only an instruction.
This task depends upon

Closed by  Rafaël Carré (funman)
Thursday, 03 June 2010, 13:57 GMT
Reason for closing:  Fixed
Additional comments about closing:  r26512

(almost) no difference in runtime, the little variation could be normal variation between benches.

Please make battery benches anyway (with r26511 and r26512) to verify, and report them on IRC / forum

thanks!
Comment by Jonathan Gordon (jdgordon) - Thursday, 13 May 2010, 08:23 GMT
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
Comment by Boris Nazaroff (bor_ka) - Thursday, 13 May 2010, 08:24 GMT
P.S. It is not reproducible in the fuze simulator with just the offending cue/flac.
Comment by Boris Nazaroff (bor_ka) - Thursday, 13 May 2010, 08:25 GMT
Ok, I will try to find the offending commit. BTW, is there an archive with old builds?
Comment by Steve Bavin (pondlife) - Thursday, 13 May 2010, 08:54 GMT
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.
Comment by Boris Nazaroff (bor_ka) - Monday, 17 May 2010, 10:17 GMT
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
Comment by Boris Nazaroff (bor_ka) - Monday, 17 May 2010, 10:25 GMT
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
Comment by Boris Nazaroff (bor_ka) - Tuesday, 18 May 2010, 08:03 GMT
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.
Comment by Boris Nazaroff (bor_ka) - Thursday, 20 May 2010, 13:15 GMT
r26185 - the bug is still there.
Comment by Rafaël Carré (funman) - Thursday, 20 May 2010, 13:20 GMT
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.
Comment by Boris Nazaroff (bor_ka) - Thursday, 20 May 2010, 13:29 GMT
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.
Comment by Boris Nazaroff (bor_ka) - Thursday, 20 May 2010, 13:50 GMT
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.
Comment by Rafaël Carré (funman) - Thursday, 20 May 2010, 14:08 GMT
- 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 ?
Comment by Boris Nazaroff (bor_ka) - Thursday, 20 May 2010, 14:12 GMT
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 :(
Comment by Marc Debacker (max131) - Thursday, 20 May 2010, 21:45 GMT
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.
Comment by Boris Nazaroff (bor_ka) - Friday, 21 May 2010, 08:09 GMT
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 :)
Comment by Boris Nazaroff (bor_ka) - Friday, 21 May 2010, 08:10 GMT
Ooops, I mean I _never_ used it on a day-by-day basis. Typo...
Comment by Rafaël Carré (funman) - Monday, 24 May 2010, 15:29 GMT
Can you give a try to this patch ?
Comment by Boris Nazaroff (bor_ka) - Monday, 24 May 2010, 19:28 GMT
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...
Comment by Boris Nazaroff (bor_ka) - Thursday, 27 May 2010, 07:31 GMT
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).
Comment by Rafaël Carré (funman) - Thursday, 27 May 2010, 20:30 GMT
disk led is shown (top right) in the freezes ?
Comment by Boris Nazaroff (bor_ka) - Friday, 28 May 2010, 13:32 GMT
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?
Comment by Rafaël Carré (funman) - Friday, 28 May 2010, 13:52 GMT
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.
Comment by Boris Nazaroff (bor_ka) - Tuesday, 01 June 2010, 19:44 GMT
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.
Comment by Rafaël Carré (funman) - Wednesday, 02 June 2010, 08:35 GMT
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)
Comment by Boris Nazaroff (bor_ka) - Wednesday, 02 June 2010, 09:18 GMT
Usually till the end of the active playlist. Will retest with the debug->buffering thread later.
Comment by Rafaël Carré (funman) - Wednesday, 02 June 2010, 11:12 GMT
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
Comment by Rafaël Carré (funman) - Wednesday, 02 June 2010, 18:54 GMT
I committed another less intrusive fix in 3.6 but i don't know how that affects battery life
Comment by Marc Debacker (max131) - Wednesday, 02 June 2010, 22:09 GMT
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.
Comment by Rafaël Carré (funman) - Wednesday, 02 June 2010, 22:55 GMT
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 :-)
Comment by Marc Debacker (max131) - Wednesday, 02 June 2010, 22:59 GMT
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.
Comment by Boris Nazaroff (bor_ka) - Thursday, 03 June 2010, 06:34 GMT
For me - no freezes also. Superb! :)

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

Loading...