From: Jorg S. <Jor...@gm...> - 2008-05-25 14:31:53
Attachments:
sparse_artwork_V01.diff
|
Hi everyone, I finished the first round of supporting the smaller thumbnail files newer versions of iTunes are writing (sparse artwork). With the attached patch (for libgpod) it is possible to correctly parse and also to display (e.g. with gtkpod) the artwork. The second round (writing the iTunesDB) will follow later this week I hope. JCS. |
From: Christophe F. <te...@gn...> - 2008-05-25 20:43:42
|
Hi, 2008/5/25 Jorg Schuler <Jor...@gm...>: > I finished the first round of supporting the smaller thumbnail files newer > versions of iTunes are writing (sparse artwork). Great :) > > With the attached patch (for libgpod) it is possible to correctly parse and > also to display (e.g. with gtkpod) the artwork. I looked through your patch, it looks good. I'd put the huge block you added to mhfd in a separate function though (for readability). And I was wondering why you didn't add a get_song(s)_by_mhii_link similar to get_song_by_dbid ? Was there something which made that impossible to do ? Or does it look better the way you did it ? Thanks, Christophe |
From: Jorg S. <Jor...@gm...> - 2008-05-25 22:12:37
|
Christophe Fergeau wrote: > I looked through your patch, it looks good. I'd put the huge block you > added to mhfd in a separate function though (for readability). That's no problem -- can do. > And I was wondering why you didn't add a get_song(s)_by_mhii_link > similar to get_song_by_dbid ? Was there something which made that > impossible to do ? Or does it look better the way you did it ? I thought using a hash is more efficient as I won't have to walk through the longer track list so many times. Maybe I'm wrong, in which case a get_songs_by_mhii_link() will make sense. JCS. |
From: Jorg S. <jor...@gm...> - 2008-05-26 16:01:03
|
> 2008/5/25 Jorg Schuler <Jor...@gm...>: > > I finished the first round of supporting the smaller thumbnail files > newer > > versions of iTunes are writing (sparse artwork). > > Great :) > > > > > With the attached patch (for libgpod) it is possible to correctly parse > and > > also to display (e.g. with gtkpod) the artwork. > > I looked through your patch, it looks good. I'd put the huge block you > added to mhfd in a separate function though (for readability). > And I was wondering why you didn't add a get_song(s)_by_mhii_link > similar to get_song_by_dbid ? Was there something which made that > impossible to do ? Or does it look better the way you did it ? I wanted to present what I think is necessary before I implement it because it appears to be computationally quite expensive (and I won't be able to start before tomorrow night or even later anyway). For libgpod, each track will have associated artwork. However, if the iPod supports "sparse" artwork, we will only write the first occurrence to the ArtworkDB and thumbnail files -- the other occurrences are linked through the mhii_link that is part of the track structure. When we read the ArtworkDB, each Artwork will have assigned an artwork ID (mhii ID). We copy this Artwork to all tracks that reference this ID. Newly added artwork through the application (gtkpod) will be assigned an artwork ID of 0. When it's time to write out the iTunesDB and ArtworkDB the following steps have to be taken to write only one occurrence of each artwork newly added (previous artwork will already be grouped by unique artwork IDs). 1) If the maximum artwork ID is "too large" renumber the Artworks so we can assign unique IDs easily by adding 1 to the max_ID. 2) make a list of all artwork with ID = 0 for performance reasons 3) for each artwork with an ID of 0 - assign a new ID - find all identical artwork -- this involves looking for identical filenames, identical pixbuf and identical data for all the remaining ID=0 artworks and give the same ID. 4) renumber artwork IDs in order of occurrence. The first artwork with a certain ID will be assigned the dbid of the corresponding track. The other artworks of the same ID will receive a 0 as dbid. Set the mhii_link of each track to the artwork ID. When writing the ArtworkDB skip all artwork that has the dbid field set to 0. Obviously, steps 1-4 have to be done before even writing the iTunesDB. JCS. -- Super-Aktion nur in der GMX Spieleflat: 10 Tage für 1 Euro. Über 180 Spiele downloaden und spiele: http://flat.games.gmx.de |
From: Jorg S. <Jor...@gm...> - 2008-05-27 15:05:54
Attachments:
sparse_artwork_V02.diff
|
Christophe Fergeau wrote: > Hi, > > 2008/5/25 Jorg Schuler <Jor...@gm...>: >> I finished the first round of supporting the smaller thumbnail files newer >> versions of iTunes are writing (sparse artwork). > > Great :) > >> With the attached patch (for libgpod) it is possible to correctly parse and >> also to display (e.g. with gtkpod) the artwork. > > I looked through your patch, it looks good. I'd put the huge block you > added to mhfd in a separate function though (for readability). > And I was wondering why you didn't add a get_song(s)_by_mhii_link > similar to get_song_by_dbid ? Was there something which made that > impossible to do ? Or does it look better the way you did it ? I've attached V02 of the patch that pulls the association from artwork to track all in an extra function. The handling of the association through dbid and mhii_link is still different, mainly because the pointing direction is exactly opposite... It looks more sensible now, however. JCS. |
From: Christophe F. <te...@gn...> - 2008-05-27 21:00:23
|
Hey, 2008/5/27 Jorg Schuler <Jor...@gm...>: >> > > The handling of the association through dbid and mhii_link is still > different, mainly because the pointing direction is exactly opposite... It > looks more sensible now, however. Yep, this looks good to me as well. And since the association with a dbid and a mhii_link are nicely separated and grouped in a self-contained function, it's easy to rework that at a later point in time ;) Another good news is that there are only a few really trivial conflicts with the changes I made to the thumbnail handling :) (available from the thumbnail-rework branch on my git tree). Do you plan to commit the reading part and the writing part separately ? Or do you prefer to wait until you have finished both reading and writing and to commit everything in a single go ? > =================================================================== > --- src/db-artwork-parser.c (revision 1984) > +++ src/db-artwork-parser.c (working copy) > + artwork_fallback = itdb_artwork_new (); > + artwork = artwork_fallback; > + artwork->dbid = get_gint64 (mhii->song_id, I must admit I'm getting confused by this juggling with artwork_fallback (why the name ?) and artwork, but I've got the feeling that in that revision of your patch, artwork_fallback is unnecessary and can be killed (I might be wrong, I didn't try to remove it ;). Cheers, Christophe |
From: Jorg S. <Jor...@gm...> - 2008-05-31 16:43:48
|
Hi everyone, this patch allows to write sparse artwork to the iPod. I tried it on my iPod Nano Video and it seems to work. The code can be configured to either write sparse artwork (one artwork entry per album) or standard artwork (one artwork entry per track). This is currently hardcoded in ipod_supports_sparse_artwork(). I've also attached a thumbnail as it appears on my iPod in all sizes. The bottom 1/5 is all the same pixel line. I'm not sure why that is. Cheers, JCS. |
From: Christophe F. <te...@gn...> - 2008-06-02 12:15:44
|
2008/6/2 Rod Hull <iwa...@go...>: > > This time I grabbed another fresh SVN copy, and then answered "no" when > patching - and it now works... I'm not sure why the rejected hunks you listed would change anything, but as long as it works now, let's say it's ok :) Thanks, Christophe |
From: Jorg S. <Jor...@gm...> - 2008-06-02 14:35:26
|
Just for the record: I've submitted some changes unrelated to the sparse artwork patch, but also included in the sparse artwork patch. I second Christophe: they "should't" have influence... JCS. Christophe Fergeau wrote: > 2008/6/2 Rod Hull <iwa...@go...>: > >> This time I grabbed another fresh SVN copy, and then answered "no" when >> patching - and it now works... > > I'm not sure why the rejected hunks you listed would change anything, > but as long as it works now, let's say it's ok :) > > Thanks, > > Christophe |
From: Rod H. <iwa...@go...> - 2008-06-03 00:31:30
|
Just a quick update on my testing. Well, the size of the artwork DB is now MUCH better! Coverflow is responsive again, and for a ~50Gb collection, I only have ~165Mb of artwork stored. This is great! I also now have noticed some thumbnails with an extended bottom pixel line like you pointed out, Jorg now that I've managed to upload my entire collection. I'm pretty sure that it only happens on those images that have a greater horizontal resolution than that of the vertical. The image is placed at the top of the square "frame" then a pixel line repeated as necessary until it reaches the bottom of the square space to be occupied. It looks like that the amount of image that is taken up by this repeated pixel line is proportional to the percentage of the image that is wider than it is high (if that makes sense!). For instance, I had one bit of artwork that was very narrow compared to its height (akin to a 2.35:1 letterboxed movie), and sure enough the image started at the top and then a pixel line extended almost from the half-way mark right down to the bottom. Unfortunately, I think I've replaced any artwork that was affected, so I may not be able to find more examples... However, it doesn't seem to happen on ALL images whose horizontal is larger than its vertical - some will look complete and in the correct ratio, but have the bottom "space" filled with white instead of a repeat of a bottom pixel line. Perhaps it depends to what degree the images' dimensions differ? Filling with white is a good trade-off IMO - it used to be black from what I can remember, and that looked very odd against the iPod's white Now Playing and Coverflow backgrounds... Jorg Schuler wrote: > Hi everyone, > > this patch allows to write sparse artwork to the iPod. I tried it on > my iPod Nano Video and it seems to work. > > The code can be configured to either write sparse artwork (one artwork > entry per album) or standard artwork (one artwork entry per track). > This is currently hardcoded in > > ipod_supports_sparse_artwork(). > > I've also attached a thumbnail as it appears on my iPod in all sizes. > The bottom 1/5 is all the same pixel line. I'm not sure why that is. > > Cheers, > > > JCS. > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > ------------------------------------------------------------------------ > > _______________________________________________ > Gtkpod-devel mailing list > Gtk...@li... > https://lists.sourceforge.net/lists/listinfo/gtkpod-devel |
From: Rod H. <iwa...@go...> - 2008-06-02 11:16:40
|
Well, it looks like it nearly works! I just copied ~1Gb of music across to test (17 different artworks) and the resulting Artwork folder (when using the default sparse method) is only 3.9Mb which is a big improvement! This is using the SVN trunk version as of 2/6/08 of libgpod patched with v3 of the sparse_artwork code, with Amarok 1.4.9.1 to perform the transfer operation. However, now I only seem to have thumbnails for CoverFlow and Now Playing (which are the same sized large ones). If I browse by album, the mini-thumbs that were previously present when using iTunes to transfer are now not there... test-thumbnails comes back with: ========== ArtworkDB ========== Track 0 (8f8e9bc6ac970cc0) Bon Iver-For Emma, Forever Ago-Flume (00000064) Could not find on iPod: ':F1061_1.ithmb' 000_Bon Iver-For Emma, Forever Ago-Flume-80x80-8f8e9bc6ac970cc0.png 001_Bon Iver-For Emma, Forever Ago-Flume-140x140-8f8e9bc6ac970cc0.png Track 1 (1b326d3cd1e67a02) Bon Iver-For Emma, Forever Ago-Lump Sum (00000064) Could not find on iPod: ':F1061_1.ithmb' 002_Bon Iver-For Emma, Forever Ago-Lump Sum-80x80-1b326d3cd1e67a02.png 003_Bon Iver-For Emma, Forever Ago-Lump Sum-140x140-1b326d3cd1e67a02.png Track 2 (8073f675e7aeaf83) Bon Iver-For Emma, Forever Ago-Skinny Love (00000064) Could not find on iPod: ':F1061_1.ithmb' 004_Bon Iver-For Emma, Forever Ago-Skinny Love-80x80-8073f675e7aeaf83.png 005_Bon Iver-For Emma, Forever Ago-Skinny Love-140x140-8073f675e7aeaf83.png etc. The larger thumbs that are present look fine on my iPod Classic 80Gb, however... Any ideas? Jorg Schuler wrote: > Hi everyone, > > this patch allows to write sparse artwork to the iPod. I tried it on > my iPod Nano Video and it seems to work. > > The code can be configured to either write sparse artwork (one artwork > entry per album) or standard artwork (one artwork entry per track). > This is currently hardcoded in > > ipod_supports_sparse_artwork(). > > I've also attached a thumbnail as it appears on my iPod in all sizes. > The bottom 1/5 is all the same pixel line. I'm not sure why that is. > > Cheers, > > > JCS. > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > ------------------------------------------------------------------------ > > _______________________________________________ > Gtkpod-devel mailing list > Gtk...@li... > https://lists.sourceforge.net/lists/listinfo/gtkpod-devel |
From: Christophe F. <te...@gn...> - 2008-06-02 11:39:44
|
> However, now I only seem to have thumbnails for CoverFlow and Now > Playing (which are the same sized large ones). If I browse by album, the > mini-thumbs that were previously present when using iTunes to transfer > are now not there... This is probably unrelated to that patch, I'd say I broke something with the changes I did in svn. I have a few more changes queued in that area, once I'm done with them I'll fix any issue that is remaining (including that one since I'll be testing on an ipod classic). Btw, did these mini thumbs ever work with older libgpod and amarok ? Can you send a ls -l of /mountpoint/iPod_Control/Artwork ? Thanks for the testing and the feedback, Christophe |
From: Rod H. <iwa...@go...> - 2008-06-02 12:08:50
Attachments:
itdb_thumb.c.rej
|
OK, I think I know what happened. So I downloaded a fresh copy from SVN, then patched. I had received the following warning previously: --- Reversed (or previously applied) patch detected! Assume -R? [n] Apply anyway? [n] --- I'd previously answered yes to this. This time I grabbed another fresh SVN copy, and then answered "no" when patching - and it now works... ls -l now lists: -rwx------ 1 xxx root 12016 2008-06-02 12:59 ArtworkDB -rwx------ 1 xxx root 557056 2008-06-02 12:59 F1055_1.ithmb -rwx------ 1 xxx root 3481600 2008-06-02 12:59 F1060_1.ithmb -rwx------ 1 xxx root 106624 2008-06-02 12:59 F1061_1.ithmb Previously, it had listed as above but without the F1061_.ihmb file... I've attached the rejected hunks of the patch that were skipped and not applied. It all seems to be fine now. Christophe Fergeau wrote: >> However, now I only seem to have thumbnails for CoverFlow and Now >> Playing (which are the same sized large ones). If I browse by album, the >> mini-thumbs that were previously present when using iTunes to transfer >> are now not there... > > This is probably unrelated to that patch, I'd say I broke something > with the changes I did in svn. I have a few more changes queued in > that area, once I'm done with them I'll fix any issue that is > remaining (including that one since I'll be testing on an ipod > classic). Btw, did these mini thumbs ever work with older libgpod and > amarok ? Can you send a ls -l of /mountpoint/iPod_Control/Artwork ? > > Thanks for the testing and the feedback, > > Christophe |