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 _______________________________________________ Bug-gnupod mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/bug-gnupod
