Rockbox

  • Status Closed
  • Percent Complete
    100%
  • Task Type Bugs
  • Category Database
  • Assigned To No-one
  • Operating System Iriver H300 series
  • Severity Low
  • Priority Very Low
  • Reported Version Daily build (which?)
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by B Sinclair - 2009-06-29
Last edited by Magnus Holmgren - 2009-07-01

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

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.

Closed by  Magnus Holmgren
2009-07-01 12:06
Reason for closing:  Fixed
Additional comments about closing:  

Fixed in r21580.

Pierre Maréchal commented on 2009-06-30 11:06

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,

Magnus Holmgren commented on 2009-06-30 17:10

Hm, a thought: could it be that r20926 or earlier works with 6 levels? (If so, it should fail with 9 levels, I think…)

Magnus Holmgren commented on 2009-06-30 17:14

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.)

tom barnes commented on 2009-06-30 18:23

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.

Magnus Holmgren commented on 2009-06-30 19:39

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.

Pierre Maréchal commented on 2009-06-30 20:11

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.

B Sinclair commented on 2009-06-30 20:26

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

Magnus Holmgren commented on 2009-06-30 21:34

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)…

B Sinclair commented on 2009-06-30 22:11

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

Pierre Maréchal commented on 2009-07-01 08:09

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...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing