Re: [Bug-gnupod] mktunes.pl creates corrupt iTunesDB ?
Hi Richard, On Tue, Jun 16, 2009 at 11:46:47AM +0200, Richard van den Berg wrote: On Tue, June 16, 2009 00:44, H. Langos wrote: My first idea now is to strip the iTunesDB of the stuff that is optional. Absolutely. I was thinking the same thing. More along the lines of setting all titles, artists and albums to a single character. But leaving out complete mhods makes a lot more sense. Shortening might not change a lot if memory management is generous and memory alignment of those objects occures on something more than word borders. But you could find out simply by taking the first not-ok state, shorten lots of attributes and try again if the newly genereated iTunesDB works. That would be valuable information regardless of how we solve the problem in the end. Last friday I wrote a patch that will not add them if they are empty. I just need to commit it. Please do, or send me the patch. I'm planning to work on it tonight, and it would be good if my code did not conflict with yours. It's a simple one line patch .. I already commited it. If it works, I'll probably make a switch for it to mktunes.pl. That might be a good idea. My patch only takes out one attribute for one file format. Having a universal switch for big collections could be a good idea. The code there could weed out the not-so-important fields and maybe limit the size of others. Kind of a last-resort switch for big collections. 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. That would be very helpful, thanks. I now keep my custom patches in files, and reapply them when needed. To do that you don't even need write access. You simply clone the upstream repository, create your own local branch and from time to time you pull the changes from origin and either merge the master into your private branch or rebase your private branch onto the HEAD of the master branch. Lets hope Adrian finds time to answer some of my questions so that I can compete the transition to git realy soon. After rcs, sccs, cvs and svn git will be the 5th versioning system I'll have to master. :-) You will love it. I worked with rcs and cvs before but git simply feels better. Working with local branches makes things also much easier. And I actually _enjoy_ working with git. Something that never happend with CVS. Just one example.. When weeding out those empty desc attributes, I inittially commited the patch with a '== ' comparison. Comparing a string numerically with the empty string (Did I mention that I hate weakly typed languages). Then I did some other changes and, commited those. Then I realised that the comparison was wrong, reverted that commit fixed the problem once more. Now my commit history was correct but looked messy. 1. wrong fix 2. some other change 3, revert of 1. 4. correct fix git-rebase to the rescue! You can give it a past commit and it will replay the patches and commits from that past commit to the current state. So I used git-rebase -i to edit the requence of patches, simply took out the initial wrong commit, and the revert and only left 2. and 4. in there. I also could have squashed 1.,3. and 4. into one commit. Or instead of reverting in 3. and commiting a new patch in 4. I could have used rebase when I realized that 1. was wrong. I could have used rebase to replay both commits but pause after applying 1. before commiting it, manually fixed the fix, and then continue that git-rebase. With git you are realy in control of your repository and if you screw up you while manipulating the local history can even reset those changes (before you run garbage collect to remove unaccessible objects from the git repository). cheers -henrik ___ Bug-gnupod mailing list Bug-gnupod@nongnu.org http://lists.nongnu.org/mailman/listinfo/bug-gnupod
Re: [Bug-gnupod] mktunes.pl creates corrupt iTunesDB ?
On 6/16/09 12:44 AM, H. Langos wrote:
My first idea now is to
strip the iTunesDB of the stuff that is optional.
Thanks again for the suggestion, that worked really well. I can now see
all my 30415 songs! Whoohoo. :-)
These are the mhods that gnupod supports:
my %mhod_id = ( title=1, path=2, album=3, artist=4, genre=5,
fdesc=6, eq=7, comment=8, category=9, composer=12, group=13,
desc=14, podcastguid=15, podcastrss=16,
chapterdata=17, subtitle=18, tvshow=19, tvepisode=20,
tvnetwork=21, albumartist=22, artistthe=23,
keywords=24, sorttitle=27, sortalbum=28, sortalbumartist=29,
sortcomposer=30, sorttvshow=31);
I've determined that all you really need is the path and title. This
created a 25MB iTunesDB. That's only 57% of what I started with. I've
settled for keeping these mhods:
path
artist
title
album
desc
This gave me an iTunesDB of 32MB (34MB with my title patch) which works
just fine on my 64MB iPod Video.
Since different users will want to keep different attributes I went for
a keepattr option in gnupodrc. A second patch is needed for tunes2pod
which will read the missing attributes from GNUtunesDB.xml, otherwise
they are gone forever after tunes2pod is run. I'll work on that later.
Cheers,
Richard
? .gnupod_version
? Makefile
? autom4te.cache
? config.log
? config.status
? configure
Index: doc/gnupodrc.example
===
RCS file: /sources/gnupod/gnupod/doc/gnupodrc.example,v
retrieving revision 1.7
diff -u -r1.7 gnupodrc.example
--- doc/gnupodrc.example5 Jun 2009 12:55:56 - 1.7
+++ doc/gnupodrc.example16 Jun 2009 20:01:51 -
@@ -51,6 +51,14 @@
# mktunes.volume = +10
## Enforce iPod serial number:
# mktunes.fwguid = 000ba3100310abcf
+## Only keep some attributes to make the iTunesDB size as small as possible
+## The minimum attributes needed by the iPod are path and title
+## Valid attributes are:
+## title path album artist genre fdesc eq comment category composer group
+## desc podcastguid podcastrss chapterdata subtitle tvshow tvepisode
+## tvnetwork albumartist artistthe keywords sorttitle sortalbum
+## sortalbumartist sortcomposer sorttvshow
+# keepattr = path title artist album
# *** gnupod_search.pl ***
Index: src/mktunes.pl
===
RCS file: /sources/gnupod/gnupod/src/mktunes.pl,v
retrieving revision 1.86
diff -u -r1.86 mktunes.pl
--- src/mktunes.pl 8 Dec 2007 10:26:08 - 1.86
+++ src/mktunes.pl 16 Jun 2009 20:01:51 -
@@ -41,7 +41,7 @@
$opts{mount} = $ENV{IPOD_MOUNTPOINT};
GetOptions(\%opts, version, help|h, ipod-name|n=s, mount|m=s,
volume|v=i, energy|e, fwguid|g=s);
-GNUpod::FooBar::GetConfig(\%opts, {'ipod-name'='s', mount='s', volume='i',
energy='b', fwguid='s', model='s'}, mktunes);
+GNUpod::FooBar::GetConfig(\%opts, {'ipod-name'='s', mount='s', volume='i',
energy='b', fwguid='s', model='s', keepattr='s'}, mktunes);
$opts{'ipod-name'} ||= GNUpod ###__VERSION__###;
@@ -69,7 +69,7 @@
GNUpod::XMLhelper::doxml($con-{xml}) or usage(Could not read
$con-{xml}, did you run gnupod_INIT.pl ?);
print \r .$mktunes-GetFileCount. files parsed, assembling
iTunesDB...\n;
- $mktunes-WriteItunesDB;
+ $mktunes-WriteItunesDB(Keep=$opts{'keepattr'});
if($fwguid) {
my $k = GNUpod::Hash58::HashItunesDB(FirewireId=$fwguid,
iTunesDB=$con-{itunesdb});
Index: src/ext/Mktunes.pm
===
RCS file: /sources/gnupod/gnupod/src/ext/Mktunes.pm,v
retrieving revision 1.6
diff -u -r1.6 Mktunes.pm
--- src/ext/Mktunes.pm 6 Oct 2007 07:26:52 - 1.6
+++ src/ext/Mktunes.pm 16 Jun 2009 20:01:51 -
@@ -34,7 +34,7 @@
#
# Create and write the iTunesDB file
sub WriteItunesDB {
- my($self) = @_;
+ my($self,%args) = @_;
my $mhbd_size = 0;
my $mhsd_size = 0;
@@ -52,7 +52,7 @@
$mhsd_size = tell(ITUNES);
print ITUNES
GNUpod::iTunesDB::mk_mhlt({songs=$self-GetFileCount});
foreach my $item (@{$self-GetFiles}) {
- print ITUNES $self-AssembleMhit($item);
+ print ITUNES $self-AssembleMhit(Item=$item,
Keep=$args{Keep});
print \r $i files assembled if ($i++ % 96 == 0);
}
$mhsd_size = tell(ITUNES)-$mhsd_size;
@@ -267,7 +267,9 @@
#
# Builds a single mhit with mhod childs
sub AssembleMhit {
- my($self, $object) = @_;
+ my($self, %args) = @_;
+ my $object = $args{Item};
Re: [Bug-gnupod] Do not stretch artwork
On 6/15/09 6:01 PM, Christophe Fergeau wrote: The background color is specified in the SysInfoExtended file if you are using/parsing it. Thanks for the suggestion, but gnupod currently doen't parse this file. I think the best thing to do is have an option to select the background color. Cheers, Richard ___ Bug-gnupod mailing list Bug-gnupod@nongnu.org http://lists.nongnu.org/mailman/listinfo/bug-gnupod
Re: [Bug-gnupod] SoundCheck/ReplayGain
H. Langos wrote: Hi chris, I borrowed an ipod shuffle 3gen (what apple calls iPod shuffle 2nd generation Early 2008) from a collegue but that one seems to be up to date too. All the volume adjustment fields are 00 00 00 Does the revision as shown by udev represent the firmware version? ID_VENDOR=Apple ID_MODEL=iPod ID_REVISION=2.70 If iTunes shows the firmware version somewhere in device information you could compare it to the output of udevinfo --path /sys/block/sda --query env or /sbin/udevadm info --path /sys/block/sda --query env Actually I have a Firmware-131.1.0.3 loaded and I get: ID_VENDOR=Apple ID_MODEL=iPod ID_REVISION=2.70 I'm still playing around with ReplayGain and SoundCheck In particular I'm trying to see if there is a 1:1 ratio between RG and SC or not. I found they iTunes-SC values clearly unsatisfying so I'm trying SC calculated from RG now but I'm not done yet :) Well, you know that Richard and I implemented replaygain to sc conversion in april/early may, don't you? The current CVS version of gnupod will take in this order RVA2/XRVA tags, or replay_album/track_gain from APE tags or id3 TXXX tags or iTunes soundcheck values (as found in iTuneNORM comment tags) plus RVAD tags (iTunes way of encoding the -100%..+100% volume slider) Check out the the mailing list's archive http://www.mail-archive.com/bug-gnupod@nongnu.org/index.html#00222 Yes I will upgrade to the CVS version soon Implementing the conversion from soundcheck or any other volume adjustment value to something the ipod understands is very easy. I'd do it a 5 minutes if we find out how to distinguish between old ipod shuffles that interpreted the volume field as 100 minus volume adjustment in percent and those who interpret it as signed integer for volume adjustmend in dB. Currently gnupod writes a value of 100 into that field. Now according to the new semantics of that field this would mean a gain of +100dB. Obviously the new iPod shuffle ignores those values or your ear drums would simply go pop. Now what we don't know is how and old iPod who expects that 0..200 value will react to the values outside that range. Something like 00 00 03 would probably be interpreted as -97% instead of +3dB but how will it interpret a value of FF FF FB? Your guess is as good as mine. Finding itunes 7.4 was really easy but where might I well find an old firmware for a 2nd generation shuffle? Anyone have an idea? Google? Just look for ipod and firmware and the first hit was this: http://www.felixbruns.de/iPod/firmware/ Well, I tried that. I downloaded the iPod_130.1.0.3.ipsw and iPod_131.1.0.3.ipsw firmware from appldnld.apple.com.edgesuite.net. The Firmware part is identical and when connected to iTunes the firmware version shown is 1.0.4 for both of 'm. felixburns has a 133 version, I guess it is more recent. I haven't tried it. Do you want me to load a 130 firmware and send you the iTunesSD? Or just google for ipod firmware downgrade and I am pretty sure you'll find what you need. cheers -henrik ___ Bug-gnupod mailing list Bug-gnupod@nongnu.org http://lists.nongnu.org/mailman/listinfo/bug-gnupod
