bug-gnupod
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug-gnupod] mktunes.pl creates corrupt iTunesDB ?


From: Richard van den Berg
Subject: [Bug-gnupod] mktunes.pl creates corrupt iTunesDB ?
Date: Thu, 11 Jun 2009 22:46:29 +0200
User-agent: Thunderbird 2.0.0.21 (Windows/20090302)

I finally built my 240GB iPod. Syncing my 30000 mp3s using gnupod took
23 hours to complete. However, when it was all done, my iPod did not
show any of the files. It was as if the iTunesDB was not recognized.
Cutting the GNUtunesDB.xml down to 100 <file> definitions (and changing
nothing else) worked fine after running mktunes.pl. The 100 songs showed
up and could be used.

So I started the iterative process to find out where the problem was. It
tuned out that number 11184 (with id 11210 because I deleted and
re-added some incorrectly tagged mp3s) is the issue:

  <file addtime="3327445787" album="Love, Luther - Disc 1"
artist="Luther Vandross" artworkcnt="1" bitrate="205" cdnum="0" cds="0"
comment="" composer="" dbid_1="ca1683ce8c7195e7"
desc="/d01/mp3/marcel/Luther Vandross/Love, Luther/Luther Vandross - 05
- Never Too Much (Extended Version).mp3" fdesc="MPEG 1 layer 3 file"
filesize="8762139" genre="Soul" has_artwork="1" id="11210" mediatype="1"
path=":iPod_Control:Music:f04:g0__Extended_Version_.mp3" playcount="0"
songnum="5" songs="0" soundcheck="2661" srate="44100" time="340532"
title="Never Too Much (Extended Version)" volume="0" year="2007" />

When this file is present, the iTunesDB is not recognized. When it is
not in the GNUtunesDB.xml, the iTunesDB works fine up until file numer
11531 (id="11558"):

  <file addtime="3327446393" album="Collected" artist="Massive Attack"
artworkcnt="1" bitrate="156" cdnum="0" cds="0" comment="" composer=""
dbid_1="261883ce8c7195e7" desc="/d01/mp3/marcel/Massive
Attack/Collected/Massive Attack - 06 - Protection.mp3" fdesc="MPEG 1
layer 3 file" filesize="9100998" genre="Electronica" has_artwork="1"
id="11558" mediatype="1"
path=":iPod_Control:Music:f47:g0____06___Protection.mp3" playcount="0"
songnum="6" songs="0" soundcheck="5408" srate="44100" time="465423"
title="Protection" volume="0" year="2006" />

The weird thing is, if I put these "broken" files by themself in
GNUtunesDB.xml it does work (iPod shows 1 song and plays ok).

I'm kind of lost how to fix this, or to predict which files will cause
problems. Any ideas anyone?

I've saved the GNUtunesDB.xml and iTunesDB during my testing here:
http://richard.vdberg.org/gnupod/
The directory names are the number of <file> entries in the
GNUtunesDB.xml. The ones in the "ok" top dir work on the iPod, the ones
in "not_ok" do not.

At first I thought it might be a size limitation of the iTunesDB (around
16 million bytes) but this theory does not really hold:

    4744 ok/00001/iTunesDB
10759264 ok/07603/iTunesDB
13347604 ok/09503/iTunesDB
14604996 ok/10453/iTunesDB
15229342 ok/10928/iTunesDB
15553196 ok/11166/iTunesDB
15574042 ok/11181/iTunesDB
15575618 ok/11182/iTunesDB
15577038 ok/11183/iTunesDB
15582446 ok/11187/iTunesDB
15876648 ok/11403/iTunesDB
16035782 ok/11522/iTunesDB
16046372 ok/11530/iTunesDB

15577026 not_ok/11183a/iTunesDB
15578438 not_ok/11184/iTunesDB
15583846 not_ok/11188/iTunesDB
15595182 not_ok/11196/iTunesDB
15634814 not_ok/11225/iTunesDB
15715538 not_ok/11285/iTunesDB
15878048 not_ok/11404/iTunesDB
16047658 not_ok/11531/iTunesDB
16047682 not_ok/11531a/iTunesDB
16048968 not_ok/11532/iTunesDB
16051572 not_ok/11534/iTunesDB
16055490 not_ok/11537/iTunesDB
16074306 not_ok/11552/iTunesDB
16112168 not_ok/11581/iTunesDB
16192112 not_ok/11640/iTunesDB
16497676 not_ok/11878/iTunesDB
17123302 not_ok/12354/iTunesDB
18414934 not_ok/13304/iTunesDB
21081010 not_ok/15205/iTunesDB
21082410 not_ok/15206/iTunesDB
42045876 not_ok/30414/iTunesDB
42047276 not_ok/30415/iTunesDB

Maybe it doesn't have to do with the iTunesDB size but a limit of the
internal structures?

I used the unaltered mktunes.pl from CVS (to make sure my title patch
did not cause the issue). I have a 5th generation iPod Video.

Cheers,

Richard




reply via email to

[Prev in Thread] Current Thread [Next in Thread]