Rockbox

This is the bug/patch tracker for Rockbox. Click here for more information.

Quick links: Bugs · Patches · Rockbox frontpage

Tasklist

FS#10396 - *Panic* Stkov tagcache errors when music files are in folders > 5 deep on H3xx

Attached to Project: Rockbox
Opened by B Sinclair (alienrider) - Monday, 29 June 2009, 18:31 GMT+2
Last edited by Magnus Holmgren (learman) - Wednesday, 01 July 2009, 14:06 GMT+2
Task Type Bugs
Category Database
Status Closed
Assigned To No-one
Player Type Iriver H300 series
Severity Low
Priority Normal
Reported Version Daily build (which?)
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Private No

Details

Hello,

DB build/update will fail with *Panic* Stkov tagcache on iriver H3xx (also confirmed by pixelma on his M5 in irc dated 29 June 2009 approx 17:00 BST) if music files are found in folders greater than 5 deep.

To reproduce:

Using Rockbox version: r21534-090627 also confirmed with r21546-090628

1. Create a directory tree and a valid mp3 file thus:
\Music\2\3\4\5\6\my.mp3
2. Disconnect H3xx now from USB safely.
3. Select 'Update Now' in Database Settings -> This will produce the *PANIC* Stkov tagcache error.
4. Reconnect H3xx to USB.
5. Move mp3 file to directory above thus:
\Music\2\3\4\5\my.mp3
6. Disconnect H3xx now from USB safely.
7. Select 'Update Now' in Database Settings -> This will not produce the *PANIC* Stkov tagcache error.

This does not effect all targets as the evilnick confirmed this problem did not effect his Sansa microSD (in the same irc log section).

Behaviour expected: I am unsure, but I didn't expect a *Panic* Stkov tagcache. : )

I am unsure of which revision of rockbox this bug was introduced. However I have been unable to get a DB built on any 3.x Rockbox until I discovered this. By keeping all music directories within the 5 deep rule, has allowed me to build a complete DB in the r21546-090628 build.
This task depends upon

Closed by  Magnus Holmgren (learman)
Wednesday, 01 July 2009, 14:06 GMT+2
Reason for closing:  Fixed
Additional comments about closing:  Fixed in r21580.
Comment by Pierre Maréchal (smokeshield) - Tuesday, 30 June 2009, 13:06 GMT+2
I confirm the bug on M5 with RockBox 3.3
Never seen it on 3.2 and before, but not sure I had folders deeper than 5 (I did a rework of my directory structure just before upgrading to 3.3)

Regards,
Comment by Magnus Holmgren (learman) - Tuesday, 30 June 2009, 19:10 GMT+2
Hm, a thought: could it be that r20926 or earlier works with 6 levels? (If so, it should fail with 9 levels, I think...)
Comment by Magnus Holmgren (learman) - Tuesday, 30 June 2009, 19:14 GMT+2
Wait a sec, regardless of my previous comment, I think I see a way to noticeably reduce stack usage so that it isn't a problem any more. :) (And the fundamental problem was introduced in late 2007.)
Comment by tom barnes (tttt) - Tuesday, 30 June 2009, 20:23 GMT+2
I can confirm this bug also - I am using an Iriver H320.

The bug seems to appear in the official 3.3 build and the current build incorporating Magnus' update (r21576).

I cannot confirm as to when this problem first came to light as I have not tried to use the database function until now.
Comment by Magnus Holmgren (learman) - Tuesday, 30 June 2009, 21:39 GMT+2
That's strange. Folders down to level 10 works fine with my fix on an e200 (didn't test before the change). Only half of the tagcache thread's stack has been used then.
Comment by Pierre Maréchal (smokeshield) - Tuesday, 30 June 2009, 22:11 GMT+2
Magnus, I can also confirm that your fix did not work for me either.
If you need specific tests to be run, my time and M5 are all yours.
Comment by B Sinclair (alienrider) - Tuesday, 30 June 2009, 22:26 GMT+2
Thanks for the confirmations.

Magnus you say the fundamental problem was introduced in late 2007. I know I was using a r18013-080711 build and this had no problems with folder structures 6 deep. This is how I ended up investigating this problem; trying to get my H3xx to build a DB with 3.3 (previously had tried with other 3.x builds), as my current DB within r18013 wouldn't rebuild under 3.x. Hope this helps. : )

Regards

A
R
Comment by Magnus Holmgren (learman) - Tuesday, 30 June 2009, 23:34 GMT+2
Hm, interesting. Had to build a compiler for Coldfire, and I'm pretty sure I see the problem now. Gcc inlined a function that used a lot of stack in the wrong place (same place as the first fix)...
Comment by B Sinclair (alienrider) - Wednesday, 01 July 2009, 00:11 GMT+2
I can confirm that your fix Magnus in r21580 seems to have resolved the problem, this is a test with one file 6 deep: no *PANIC* Stkov tagcache error. I can test with my old directory structure later which had lots of files at 7 deep (I have a backup), but I will need to do that later this week as I have re-arranged all my music to fit within this bug; and to be honest my old directory structure was out of control. :) I'll see if I can do a test with my old structure at the weekend.

Thanks for your efforts so far.

Regards,

A
R
Comment by Pierre Maréchal (smokeshield) - Wednesday, 01 July 2009, 10:09 GMT+2
OK, this time I've been able to build the database with several folders deeper than 5.
Many thanks for your efforts and great support Magnus.

Cheers,
Pierre

Loading...