Re: [Bug-gnupod] DESC field in iTunesDB

[H. Langos]

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