Re: [Bug-gnupod] new branches

[H. Langos]

On Wed, Jun 24, 2009 at 11:20:06PM +0200, Richard van den Berg wrote:
> On 6/24/09 10:58 PM, H. Langos wrote:
>> I guess the do_not_stretch_artwork feature is harmless. I'll merge
>> that into master.
>>   
>
> Ok, cool. I still want to add a selectable color in gnupodrc for that  
> when I have some time.

Sure. That would be nice. Just put that in your do_not_stretch_artwork
branch and I will merge it again into master later.

>> The decrement_plid feature would be nice to include into master
>
> The reason I keep it around is that it seemed to make a difference in  
> RAM usage the first time I tried it out..
>
>> Instead of decrementing from MAXINT, I would suggest to make the sequence
>> counter jump to the next 2^n value before the playlists are added?
>> This would not rise the values too high and still in most cases it would
>> avoid the massive shifting of IDs.
>>   
>
> Why not just always start it at 2^30 ? This get's rid of the  
> signed/unsigned issue and still leaves room for 1 billion songs and  
> playlists. (Or 2^20 with leaves room for 1 million songs.) And you have  
> the added benefit of easily comparable iTunesDB that contain a different  
> number of songs or playlists, even if you cross a 2^n boundary.

Do you know how iTunes handles those IDs? In the iTunesDB that I looked at
just now, It seems to interleave the IDs for mhit, mhia, and other elements
that need one. Still they are all pretty small values < 2^16.

Did anybody ever test itunes with more than 2^16 files? I mean for all we
know the ID field could be two bytes and those next two bytes could be just
plain zeros. ;-)

How about starting at 2^15 and jumping to the next 2^n in case we already
have more than 2^15 songs? Crossing of those 2^n boundaries gets really
rare from that point onwards. 

I am a defensive driver on the road (i.e. I try to anticipate the mistakes
of others) and I'd like to say the same about my programming style. (Tough I 
am still far from it.)

> Thanks for the help with git. I think I know enough of the basics now,  
> but there's quite a few advanced features that still puzzle me. :-)

No worries.  I also learn something new about git every day. 

BTW: What do you think about the changes in hlangos/doc ? (Getting rid of the
separate man page files and integrating them as pod into the scripts.)

I am still not sure weather I should write a small preprocessor into 
gnupod_install to merge the templates there (the same way as PERLBIN and 
VERSION are merged there. Or rather create a separate make target that would
create the man pages before the install target.
I wonder whats easier to handle for package maintainers. I guess I'll 
ask Raphael and Brian (the Debian package maintainers) about that.

cheers
-henrik