On Thu, May 07, 2009 at 06:23:01PM +0200, Richard van den Berg wrote: > On 5/7/09 1:50 PM, H. Langos wrote: >> I wasn't aware of a limitation to 40 characters. This seems a rather >> arbitrary limit imposed on the user by itunes. It doesn't even resemble the >> original id3v1 comment tag limit as that was 30 characters. >> ( http://www.id3.org/ID3v1 ) > > My bad. I took the width value of %FILEATTRDEF in iTunesDB.pm to mean > the width of the field in the iTunesDB. It turns out it is only used as > display width in FindHelper.pm. The mk_mhod() / mk_mhit() functions that > actually convert the fields to iTunesDB format do not seem to impose any > size limit.
I probably should move that %FILEATTRDEF stuff over to FindHelper.pm . Initially I thought I could combine the iTunesDB format information that is in the code of iTunesDB.pm with the information regarding its presentations that I added in %FILEATTRDEF. But I don't have the time to dig into the itunesdb format deep enough to combine those. Meanwhile code that used to be in gnupod_find has been generalized and moved into the new FindHelper.pm and that is now probably be better place for %FILEATTRDEF. > I haven't been able to read the "desc" field I set on my mp3s using > gnupod_addsong.pl + mktunes.pl either on my 5G iPod or using the iTunes > GUI. Seems like that only works for audio podcasts. > I can use it in smart playlists though. Smart playlists can have a "desc" attribute? I didn't know that. Does tunes2pod retain it? If so, could you send me the relevant lines from your GNUtunesDB.xml ? I will probably not do anything with it but I'm curious. > Googling shows that my iPod > should be able to display lyrics, but I guess the lyrics_flag needs to > be set first. Gnupod doesn't seem to do that for mp3s (which I guess is > a bug). Could be. Could you test if the "desc" attribute in combination with the "lyrics_flag" attribute result in displayed lyrics? Apart from the "desc" attribute i wouldn't know where the lyrics could be stored. >> If you need to get the information that currently is encoded in the file's >> path into the file itself I would recommend using a comment tag. > > I thought about that, and mass tagging my collection is not a big deal, > but I'll have to redo it every time I add something, or move files from > one directory to another. Hacking gnupod is much easier, and I won't > have to change my habits. :-) I'll see if keeping a customized version > of gnupod is better than changing the way I tag/select my mp3 collection. Maybe you can minimize the change by simply add the information that you need to the __merge_strings call. That way you can use the desc attribute both ways. (unless your mp3 collection has a lot of garbage in the comment tags. mine has.) cheers -henrik _______________________________________________ Bug-gnupod mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/bug-gnupod
