Rockbox Technical Forums
Support and General Use => Audio Playback, Database and Playlists => Topic started by: Toxikator on September 07, 2011, 11:40:34 PM
-
Just recently updated from Rockbox 3.3 to 3.9, and my database seems to have broken a bit.
Several songs are having their genre tags ignored by the database; I rebuilt the db from scratch twice in 3.9, thinking it was a bug; then, I updated to 3.9.1 AND attempted several things to fix the issue, figuring at least one of the two might solve the problem, but neither did.
What happens:
Certain tracks (sometimes a few, but not ALL, from an album, but other times all the tracks on an album) show up as <untagged> in my genre list. I made a list; in every case, it is the same 10 or so albums that show up in this list, it's not changing, meaning it's not a random bug. BUT, in many cases, one album inside an artist's subfolder on the drive will show up correctly even though another is missed. Also, one album (Imogen Heap's "Ellipse", not that it matters) shows up filed under a genre called "p", though I think it's a unicode symbol resembling a lowercase p because it sorts alphabetically after "Soundtrack/Videogame"in my genre list.
What it can't be:
The albums are using one of the same 10 values for genre ("Pop/Rock", "Hip-Hop/Rap", etc) that all 25,000-some songs in the database use, so it can't be the value I've put in the genre field. I even checked a bad album against a good one in foobar2k, selecting them all and clicking edit to see if the two seemingly identical strings would be returned as "multiple values" but foobar doesn't think so.
It also can't be damaged or corrupted files because foobar2k and MP3Tag both return the values I expect to show up, rather than the ones Rockbox sees.
Also weird: Genre is the only tag affected. If I sort by Artist or Album I get no <untagged> items in my list. So it's not as though Rockbox is simply reading the tags strangely, it's limited purely to Genre.
What I've tried:
I tried deleting, and then reapplying the genre field tags. I checked the files in MP3Tag to see if some strange non-standard genre value was being modified (no), or if the tags were a weird format (no, all id3v2.4). I checked the folders of albums for cue or playlist files that might be overwriting the file tags when Rockbox generates the db; none are present. I even tried adding and then removing id3v1 tags in Foobar just in case Rockbox was for some reason scanning those fields instead. This didn't work.
I think the secret here is to understand what has changed, fundamentally, in the way RB reads tags between v3.3 and 3.9 (and 3.9.1, since I know it fixed bugs present in 3.9 but this can't be a bug that update specfically caused).
I feel like there must be something obvious I'm missing which is why I'm here and not on Flyspray reporting the bug; when things foul up for me in Rockbox, that's usually the case, and it could easily be something like the skin-breaking changes in 3.6 wrt tagging that I've missed the discussion about by skipping so many updates.
Any insight is truly appreciated!
Post Merge: September 07, 2011, 11:45:45 PM
Forgot to mention:
(sorry, I'm on iPhone using wap2 and there's no edit button)
The device is an iPod 5.5G (60MB model), modded to use a 240GB HDD. The tracks in question have all been added at diverse times and are so few in number I doubt it's an issue of Rockbox not being able to see them on the drive, also they seem to play back fine.
I'm currently using 3.9.1 but, as I've said, the bug occurred in 3.9 as well, and did NOT happen on 3.3, though that version had been patched to include 240GB HDD support for iPods which, at the time, was nonstandard.
The issue occurs with my usual custom tagnavi AND the stock one. I am keeping DB loaded to RAM if that matters.
-
The was quite some rework done in several areas since v3.3 -- at least I can speak for the ID3-parser. To be able to further track this down it would be best to create a flyspray bug report and upload/link one of those files (or the tag itsefl).
-
FWIW, I also have a 5.5G modified to 240GB, and mine seems fine under 3.9x - my tracks are all M4A and MP3.
Did you try reinitializing the DB? I had to do that (for an unrelated reason) around the time I went to 3.9.
I noticed that in the examples you gave, the genre tags had a slash, e.g."Pop/Rock" - is it possible that is tripping it up somehow? None of my tags have a "/". Just a thought.
- Mark
-
I've already reinitialized the db thrice. No fix.
It COULD be the slash tags are the issue but it's doubtful as none of the OTHER tracks with those same genres (I've got thousands of tracks in Pop/Rock) are being mis-red.
-
What gerne is shown under "Show Track Info" in the WPS context menu (longpress SELECT while in WPS) if you play one of those untagged or wrong tagged files?
And again: If this is reproducible for you and always happens with the same files, please create a flyspray bug report and upload one of those files.
-
Track info (nice new feature BTW, I never knew that was there) shows the same issue.
I've uploaded a small pic so you can see; it looks like a lowercase "p" with a higher stem, and it sorts alphabetically after "s", so I'm guessing it's a unicode symbol.
I also checked the "<untagged>" tracks; they simply return no "genre" field in track info.
However, on MP3Tag AND Foobar2k, the values are returned properly, as the second screenshot shows (these are for the same track the Rockbox screenshot is showing).
Since it won't let me attach this, here's the song file itself if anyone wants to check it out on their copy of RB or their tagging program:
http://limelinx.com/files/22a897c882c4478c3032a12bd34dff3e
You can download it from there (use the small DL link below the Facebook icon, not the gaudy flashing ones, obviously). And I will open a Flyspray for this as well.
-
The file contains two genre frames (TCON), and the latter contains the strange "p". Rockbox shows the latter one.
However, I can't really match up the contents of the ID3 tag with the spec, so there still might be something odd with the tag itself. I'll look more into it.
[Edit:]
Ah, didn't take a flag into account. Now the contents match up much better. Still, the second genre frame was a little odd, as it was completely empty (even lacking a terminating 0 that's supposed to be there). This confuses Rockbox a little, causing the odd char to show up.
Ignoring empty tags seem reasonable, so I'll upload a patch for it. The change I have in mind might cause other problems, so some testing would be nice before commit.