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

[H. Langos]

On Mon, Jun 15, 2009 at 11:57:22PM +0200, Richard van den Berg wrote:
> On 13-6-2009 22:36, Richard van den Berg wrote:
> > I'm now starting to think it's a RAM issue. According to
> > http://ipodlinux.org/wiki/Generations#Fifth_Generation_.285G.29_.2F_Fifth_Generation_Enhanced_.285.5G.29
> > my 30GB turned 240GB iPod has 32MB of RAM. Maybe I should try to get a
> > hold of a 60GB/80GB version (64GB of RAM)?
> 
> I just had to rule this out, so I got myself a nice and shiny 2nd hand
> iPod Video 80GB. After converting it to 240GB (needs to load different
> firmware than the 30GB!) and 23 hours of gnupod sync, I'm pretty sure my
> issue is RAM related. Before I was able to load 17759 songs in a 25MB
> iTunesDB. Now (after 2 iterations) I'm up to 22811 songs in a 34MB
> iTunesDB. However, the full 30415 in a 42MB iTunesDB still does not
> take. :-(

Well, at least we have a screw to play around with. My first idea now is to
strip the iTunesDB of the stuff that is optional.

I suggest you take a look at the iTunesDB.pm code and see which attributes 
are translated into optional mhods and thus could be left out. 

E.g. the last release hardly ever (never?) added a desc attribute but the 
current CVS code adds a desc attribute to all mp3 files. 
Last friday I wrote a patch that will not add them if they are empty. I just
need to commit it.

I don't know what else gets translated into an optional mhod but maybe even
the fdesc attribute could be stripped.

> I'll try to contact some other 240GB iPod owners to see how their
> experience is.

Also check out the mailing list archives ... There was a guy a while back
(November 2008) with a similar issue: "Problem over 32946 entries in 
GNUtunesDB.xml".

Cheers
-henrik

BTW: I've started converting the CVS gnupod repository into a git repository. 
If Adrian agrees I'd like to give you write access to it. In the beginning you 
could work on your own branches (at least for a while) and I'd cherrypick the 
changes that are mature into the master branch.
Private branches are also nice if you have private patches (like the 
artist-title concatenation patch) that you want to keep out of the master
branch. If you havn't seen it yet I strongly recommend Linus' talk on git:
www.youtube.com/watch?v=4XpnKHJAok8