- Status Closed
- Percent Complete
- Task Type Bugs
- Category ID3 / meta data
- Assigned To No-one
- Operating System All players
- Severity Medium
- Priority Very Low
- Reported Version
- Due in Version Version 3.0
-
Due Date
Undecided
- Votes
- Private
FS#4941 - Tagcache cache update fails with Prefetch abort at 86AD43D8
This is my first bug report, so apologies if I did something wrong. I wasn’t sure what category to put it in either..
Anyhow,
You can read my forum post/discussion with Llorean here: http://forums.rockbox.org/index.php?topic=3039.msg22908#msg22908
Basically whenever I try to ‘force tagcache update’, after a minute or two it stops and completely freezes. It displays ‘Prefetch abort at 86AD43D8’. I’ve tried it about 10 times, reset rockbox’s settings, and downloaded the latest bleeding edge build. It fails with the same message every time.
More info that may or may not be needed:
iTunes library size: 3248 songs ~17.4GB.
iPod 5G 30GB Black
I’m really stumped.
Closed by pondlife
2006-11-03 10:34
Reason for closing: Fixed
Additional comments about closing: Warning: Undefined array key "typography" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 371 Warning: Undefined array key "camelcase" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 407
2006-11-03 10:34
Reason for closing: Fixed
Additional comments about closing: Warning: Undefined array key "typography" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 371 Warning: Undefined array key "camelcase" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 407
Probably fixed, no response from
reporters.
Loading...
Available keyboard shortcuts
- Alt + ⇧ Shift + l Login Dialog / Logout
- Alt + ⇧ Shift + a Add new task
- Alt + ⇧ Shift + m My searches
- Alt + ⇧ Shift + t focus taskid search
Tasklist
- o open selected task
- j move cursor down
- k move cursor up
Task Details
- n Next task
- p Previous task
- Alt + ⇧ Shift + e ↵ Enter Edit this task
- Alt + ⇧ Shift + w watch task
- Alt + ⇧ Shift + y Close Task
Task Editing
- Alt + ⇧ Shift + s save task
After major experimenting, it appears that it is probably either a bug in the way tagcache reads the metadata, or the parser in rockbox. I'm still trying to find the exact cluprit. But I did a restore, and still had the problem. Removed all my music, and added two albums back on and it worked. Added half of my music back, and it didn't.
It's not caused by: AAC files, videos, etc. I removed all that and still had the problem.
I got more or less the same problem with my H300. The Tag database doesn't get built on "Force tag cashe update". No Tagcache directories are created in the .Rockbox directory! No error is displayed.
Data about my system:
Device: IRiver H300
CVS: 060413 (tried 060411 and 060409 as well)
Bootloader: H300 V5
IRiver BIOS: V130 (Europe)
Audio files: ~5000 tunes (~34 GB). → some 4GB free and not fragmented
Type of audio: MP3 only. Most ID3V1 only. Some are both ID3V1 and ID3V2.
Location of audio: All sorted in subfolders //GENRE/ARTIST/ALBUM/..
Playlists: All in Root directory
Checking on INFO-DEBUG-VIEW TAGCACHE INFO the info displayed is: -1%
It feels as if I did not even attempt to get the database build.
With CVS060409 the system did lock after starting the tag build and playing around with the settings menu. No action was possible except hard reset. Even the clock did lock. This does not happen any more with CVS060413!
Even including this essential bug Rockbox is WAY BETTER than the original firmware as for the first time the H300 can be really used. I was very close dumping the H300!
Note: I hope I posted my comment at the right place.
Well.. my problem has been fixed, sorta.
The problem was I had fairly large album art embedded into some of my files, and it was cuasing Rockbox's ID3 parser to have a buffer overrun (IIRC). They put together a half-patch, that'll basically just skip over files that cause that instead of crashing. So I have a few files missing from my library, but TagCache is working fine now. :)
Josh
It seems I have to correct myself.
After about 8 hours of playback (on battery) a few hundred files of the 5000 on the player are tagged. So it works but VERY slow.
Doing it overnight in idle mode with power on (what I did before twice) did not tag any of the files!
→ I'll try it with playback overnight with power… lets see if that's better.
Thomas
Does this bug still exist in newer CVS versions?
There has been some tagcache fixes and enhancements lately…
Summary first: No, it still does not work.
Thanks to the new status enties in the info area I know now the following.
1: The tagscan starts
2: It works pretty fast at start (~50 tags / second) and slows down later (~5 tags per second)
3: Using the info area I see that it will stop at some file with the tagging.
I've seen it counting to 300 entries in the time I need to navigate from the start tagging to the info screen. It will stop completely at 1958 which is a 20% progress by the indicator. The navigation still works, but I hear the HDD running without further progress for many minutes (>10 minutes).
4: I have about 6600 MP3 files on the player (not "just" 5500 as I thought).
5: On a first try it did stop tagging at a lower number (tag 517) as I plugged in power?!
6. All ID3 tags are created using the program MP3TAG
7. All the MP3 files were recognised without difficulty by WINAMP 5.21 and by ifish… but ifish reported some LONG tag entries which were cut.
8. Opening the Database navigagion while just 517 files are tagged it worked with the tagged files.
9. With 1958 tags the database seems to consist of 10 files (the indication of the bootup screen above the version indicator). Checking in the info area I'm told there are 0 tag entries. After a second boot the database is gone altogether. Not even the bootup screen indicates the presence of a tag database any more.
10. I tried it both: Database in RAM or on HDD
Does this make any sense?
Thomas
I believe I located the problem on my system (still with Version 060512).
Due to the power-on bug I always did the following:
- start the H300 without external power.
- start the tagging procedure.
- cheched the status of the tagging in the info.
- If NOW the external power is plugged in (expecting it to take longer) the tagging will stop!
If instead I do the following it works correctly:
- start the H300 without external power.
- plug in external power after completion of the boot procedure
- then start the tagging (and check as above in the info panel)
→ Pluggin in of the external power seems to mess something
Without fiddling with the power plug during the tagging I managed to complete tagging of meanwhile ~11000 files. The "commit step" counter did proceed to step 9 and then return to 0. After rebooting everything was well.
Note: I used the plain power supply without docking station
Thomas
Hi Thomas and Josh,
Please retest with a new build - there have been several fixes to tagcache recently (committing in particular).