*PANIC* Stkov tagcache error on building DB with 1 mp3 on v3.3

[alienrider]

Hi,

Rockbox Version: 3.3
MP3 Player: Iriver H3xx

I get this error "*PANIC* Stkov tagcache" when trying to build a brand new database with 1 known good mp3. Can someone explain what this error message means please ? As this may give me some pointers as to how solve the problem.

I have been using a daily build from July 2008 with very few problems, but would like to move to a 3.x build and its new features. I had been getting this problem when all my music files were on the device, it processes all the way through the list and then "*PANIC* Stkov tagcache". It seems to be the very last file it is processing in the list that seems to cause the problem.

I then reduced the files to just one mp3 I believed was good and shouldn't present any problems. Same result. I tried a number of other solitary mp3s to ensure I hadn't picked a bad file and Rockbox 3.3 exhibits the same behaviour with all of them. None of them have embedded art were taggedby mp3tag and don't have any long or out of the ordinary tags.

Any explanations on that "*PANIC* Stkov tagcache" error or suggestions as to what may be causing my issue would be greatly welcomed.

Thanks

A
 R

[Multiplex]

I can't really help with the why (I haven't upgraded my H300 and it's still at work) but the error is from the very low levels of Rockbox and it is a stack overflow.

It may be worth doing a a disk check of the H300 with Windows Tools > Check for errors after doinf a right click and Properies on the drive letter that the H300 is.

[Didgeridoohan]

I had this problem as well and was very glad to see this the other day:

Major changes since version 3.3 (in SVN)
2009-06-20: Database stability improvements.

Now the database works again (at least for me). If you're not running a build from after 2009-06-20, try it out and see if that fixes your problem.

Otherwise, try following Multiplex's advise and do a disk check. You can also try to add a database.ignore file (see the manual for a more thorough explanation) to any folders on your player that doesn't have any music in it. In my efforts to solve the problem (prior to 2009-06-20) I found this helped.

[alienrider]

Many thanks Multiplex and Didgeridoohan for your info and suggestions.

I still have this problem here is what I did:

Upgraded to current build r21484M-090624.
Did a full chkdsk with option to find and fix bad sectors: no problems or bad sectors found.
Placed database.ignore in every folder except the music directory.
Have a done a full defrag and chose a defrag method which moved all the files (about 150MB of files), I did this to ensure files weren't sitting on a bad sector.

The result of all this is *PANIC* Stkov tagcache.

Is there a debug logging build I could use ? To establish what its unhappy about. I think it must be something unique to my player but it seems strange that the July 2008 build works flawlessly, and that there no bad sectors according to Windows Disk check.

Please any further help or advice would be greatly appreciated. I am huge fan of Rockbox and been using it for a few years on my H300, and I really want to move to v3.x but I really need to get the DB to work as that is the killer feature of Rockbox for me.

Thanks,

A
 R

[gevaerts]

Does this also happen with the official build?

[Multiplex]

Over lunch I put Release 3.3 on my H320 and built the database (I don't normally use it) and all went fine if a little slowly (like I said I don't use it but last time I'm sure it didn't take so long to do the initial scan on my 6500 OGG files - no MP3 on my player).

You say that this file is "known good" - what is that based on?
 - plays on PC based program and shows tags
 - or was OK with the database on a previous Rockbox build

[alienrider]

Hello Gevarts appreciate you time, Hello again Multiplex,

To answer your question first Gevaerts I initially used v3.3 but then tried a latest current build, both showed the "Stkov" error with just 1 mp3. My earlier post has more information about what I have done, if you feel I could do something else I am happy to give any reasonable action a go. : )

To answer your question Multiplex: This file works on a number of PC's I have and the tags can be seen; I use Foobar v9.5.8 and Windows Media player. Could you recommend a application I could use to validate whether my tags are 'dubious' ? Thanks for taking the time to check v3.3 on your H320. I feel my player is contributing to this problem but I can't see how, everything checks out great!!!! 

All my tagging is done in mp3tag, for the reason that I believed that constructed tags using that tool would cause Rockbox the least trouble. The thing I find odd is that I had no trouble database wise the July 2008 build I have. It maintained a database of nearly 9000 tracks (the same 9000 tracks that v3.3 seems to have a problem with).

I would appreciate any more advice as I am desperate to get v3.3 to work on my H340 (with a 60 GB drive).

Thanks,

A
 R

[Multiplex]

THis only thing I can think to suggest now is to look at the tags for this file while playing it (long press NAVI then select "Show Track Info" - there amy be another way but this is how I do it) and see if all is OK.

Other than that I'm at a loss - sorry.

[alienrider]

Thanks Multiplex for your efforts much appreciated.

I looked at the Track Info while playing and the info isn't corrupted!!!! 

I'm fairly certain it isn't a tagging problem, the issue seems to be when tag cache finishes processing the files and tries to build the database. I say this because if I add 400 files to the first solitary mp3 file I can see that tagcache happily processes them (this can be seen from the debug info) until it reaches the end of the list then 'bang'. The full 9000 tracks exhibited the same behavior, processes pretty much all of them, until it gets to the end and ten 'bang'.

I blanked all the tags in the 1 mp3, removing replaygain and still the same behaviour.

However by chance I discovered something that supports my theory while writing this post... I did a disktidy from the Rockbox applications menu and when it tried to start cleaning it threw an error *PANIC* Stkov main.

This seems to indicate a disk problem... so my questions to the developers is:

Can a type of disk read/write failure that cannot be detected by Windows cause these *PANIC* Stkov failures within Rockbox ?

Thanks for any info you can suggest.

: )

A
 R

[alienrider]

Hello,

After a lot of investigation, I believe this is what is causing this problem and it is reproducible on my H380 (80GB Disk) everytime, the steps are as follows:

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 H380 now (changed disk to rule out disk problem) 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 H380 now from USB safely.
7. Select 'Update Now' in Database Settings -> This will not produce the *PANIC* Stkov tagcache error.

As I have stated this has happened everytime on my H3xx (I have directory structures longer than this!). I don't know whether this simply happens on my machine or is reproducible by other H3xx users/rockbox users.

Can anyone check to see if they experience the same issue under the same circumstances please ?

Thanks for any info...

A
 R

[Multiplex]

Good work

Now that you've isolated this it would be worth adding an entry to the Bug Tracker - the forums are a bit 'noisy' for some of the developers.

I'm sure that there is a published limit for the maximum depth of the directory structure - but it aught to be handled a bit better than stack overflow!

EDIT: Not exactly "documented" but it has cropped up before;
http://forums.rockbox.org/index.php?topic=18979.0
http://forums.rockbox.org/index.php?topic=14265.msg108148#msg108148
No sign of anything in Flyspray though so I'd definately get it raised and maybe it'll get fixed

[alienrider]

Hi Multiplex,

Thanks for dropping by. I jumped onto irc to check with some of the rockbox team to see if it was an expected issue and they have advised me to raise a Flyspray http://www.rockbox.org/tracker/task/10396.

Potentially it seems to affect coldfire based machines as someone confirmed the issue on an M5 but the issue didn't occur on a Sansa MicroSD.

We'll see what happens from here.

Thanks for your help.

Regards,

A
 R

[ComposerDude]

Confirmed same problem on my H320 while rebuilding database, version r21574-090630

As far as Windows not giving me errors, fsck.vfat on Ubuntu Linux gave me this pretty little picture:

Code: [Select]

kudos@xbmc-media:~$ sudo fsck.vfat -vatw /dev/sdb1
dosfsck 3.0.1 (23 Nov 2008)
dosfsck 3.0.1, 23 Nov 2008, FAT32, LFN
Checking we can access the last sector of the filesystem
There are differences between boot sector and its backup.
Differences: (offset:original/backup)
  65:02/00
  Not automatically fixing this.
File system has 1219839 clusters but only space for 1219838 FAT entries.

My guess is that chkdsk recognizes this and also refuses to fix it... thank God for verbose mode! My understanding at this point is that I need to back up the files on the disk, wipe it, and reformat it. I'll get back to you on wether or not this resolves the problem on my disk.

@alienrider:
Can you see if you're getting the same error as I am?
If you have access to linux, try running the following in a terminal(assuming /dev/sdbi is the drive):

Code: [Select]

sudo fsck.vfat -vatw /dev/sdb1

To check which device is your H300, run the following:

Code: [Select]

sudo fdisk -l

Your device will be under something like this heading:

Code: [Select]

Disk /dev/[whatever]: 20.0 GB, 20000268288 bytes

[Chronon]

It looks like a fix for this just went into SVN. 
http://svn.rockbox.org/viewvc.cgi?view=rev;revision=21576

[autofyrsto]

I don't think I had the Six Folders Deep error, but I was hitting a "stkov tagcache" error as my database build count hit about 9700.  Installing the new Rockbox build r21577-090630 solved that problem.  The database build count went beyond 15000 and through to completion.  I now have a database!