Bug 137152 - Rio karma transfer duplicate track problem
Summary: Rio karma transfer duplicate track problem
Status: RESOLVED FIXED
Alias: None
Product: amarok
Classification: Applications
Component: Collections/Media Devices (show other bugs)
Version: 1.4.4
Platform: unspecified Linux
: NOR normal
Target Milestone: ---
Assignee: Amarok Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-11-10 14:37 UTC by H Richardson
Modified: 2007-08-12 00:12 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
Tescase MP3s in ZIP archive with instructions (34.02 KB, application/zip)
2006-11-14 12:44 UTC, H Richardson
Details
Patch for checking track number to determine uniqueness (826 bytes, patch)
2006-11-15 05:16 UTC, Andy Kelk
Details

Note You need to log in before you can comment on or make changes to this bug.
Description H Richardson 2006-11-10 14:37:03 UTC
Version:           1.4.4 (using KDE 3.5.1 Level "a" , SUSE 10.1)
Compiler:          Target: i586-suse-linux
OS:                Linux (i686) release 2.6.16.21-0.25-default

This problem occurs mostly when transferring audio book MP3s to the Rio Karma. It may affect other portable devices too.

When trying to transfer a playlist of an audio book, the transfer process will complain that some of the tracks are already present on the media device and refuse to transfer them. This is because the uniqueness of the track appears to only be calculated from the "title" and "album" tags, and doesn't take into account the track number tag.

It is quite common to have track titles such as "track 01" occur many times within the same audio book album, because they may have been ripped from multiple CDs. The solution to this usually is to use the "track number" tag to specify the playing order. This is quite acceptable to the Rio Karma. It can handle duplicate track titles in the same album and always sorts by track number tag instead.

Currently, the only workaround for this is to re-tag the MP3 "title" tags to be unique, or to have a separate album for each CD of the audio book. This becomes cumbersome when your audiobook is 10 CDs long!

Solution: include track number tag in the detection of the uniqueness of each track to be transferred to the Rio Karma.
Comment 1 H Richardson 2006-11-10 14:39:30 UTC
PS. This problem also occurs if no "title" tag is set at all in the files to be transferred.
Comment 2 H Richardson 2006-11-10 14:53:43 UTC
Located the code probably causing the problem at riokarmamediadevice.cpp line 143.
Comment 3 Andy Kelk 2006-11-14 06:15:49 UTC
Do you mean include the disc number tag?
I agree this should be implemented. I'll take a look at it, but AFAIK, libkarma (and probably the Karma itself) doesn't support setting/getting the disc number property.
Comment 4 H Richardson 2006-11-14 12:43:45 UTC
It's not the disc number tag, it's the track number tag.

I'll attach a testcase to demonstrate the point.
Comment 5 H Richardson 2006-11-14 12:44:43 UTC
Created attachment 18544 [details]
Tescase MP3s in ZIP archive with instructions
Comment 6 H Richardson 2006-11-14 12:55:06 UTC
PS. As far as I've seen Karma doesn't obey the disc number tag anyway, so it's not so important, but the track number tag is very important as it's always orders by this tag within an album. When the "album" contains multiple discs, it's easy to renumber the track tags using Amaroks "Iteratively Assign Track Numbers" tagging feature (right click on track column while multiple tracks selected). However I then have to reboot into Windows to transfer my newly ordered files, because of this bug!
Comment 7 Andy Kelk 2006-11-15 05:16:01 UTC
Created attachment 18560 [details]
Patch for checking track number to determine uniqueness

OK. I understand now. I was assuming that Track 01 would always have a track
number of 1, but I can see why that might not be the case.

I've had a go with the test files with a simple patch (attached) to check on
track number as well as album/artist/title.

Unfortunately there appears to be similar checking within libkarma and so even
if Amarok lets the file through, libkarma fails to write it because it sees a
duplicate.

I'll discuss this on the linux-karma-devel list to see if we can add the track
number checking in there as well (I'll cc you on the mail). Assuming that goes
ahead, I'll re-test and commit my patch when the next libkarma is released.

Andy
Comment 8 Andy Kelk 2006-11-15 05:26:25 UTC
Don't you just hate it when that happens... Just after I sent my last comment, I realised there is a setting for libkarma : lk_karma_write_dupes which is off by default. If we set this on, then libkarma itself won't check for duplicates and my patch works fine.

As Amarok is already checking for duplicates, there should be no problems enabling this setting in libkarma.
Comment 9 Andy Kelk 2006-11-15 05:31:40 UTC
SVN commit 605039 by kelk:

When checking for duplicate items on a Rio Karma, use the track number in addition to artist, album & title. We also turn off libkarma's duplicate-checking as it would not let these files through (and we are confident in our own duplicate checks).

BUG: 137152



 M  +2 -0      ChangeLog  
 M  +9 -1      src/mediadevice/riokarma/riokarmamediadevice.cpp  


--- trunk/extragear/multimedia/amarok/ChangeLog #605038:605039
@@ -10,6 +10,8 @@
       you move and rename them.
 
   CHANGES:
+    * When checking for duplicate files on a Rio Karma media device, use
+      track number in addition to artist, album & title. (BR 137152)
     * The XMMS visualization interface has been removed. LibVisual supersedes
       this feature.
     * It is now possible to select the time unit for length-based smart
--- trunk/extragear/multimedia/amarok/src/mediadevice/riokarma/riokarmamediadevice.cpp #605038:605039
@@ -149,7 +149,13 @@
         MediaItem *album = dynamic_cast<MediaItem *>( artist->findItem( bundle.album() ) );
         if( album )
         {
-            return dynamic_cast<MediaItem *>( album->findItem( bundle.title() ) );
+            MediaItem *track =  dynamic_cast<MediaItem *>( album->findItem( bundle.title() ) );
+            if( track )
+            {
+                debug() << "track bundle " << track->bundle()->track() << " matches " << bundle.track() << " ?" << endl;
+                if( track->bundle()->track() == bundle.track() )
+                    return track;
+            }
         }
     }
     return 0;
@@ -308,6 +314,8 @@
 
     lk_karma_use_smalldb();
 
+    lk_karma_write_dupes( 1 );
+
     RioKarmaMediaDevice::readKarmaMusic();
 
     return true;
Comment 10 Seb Ruiz 2006-11-15 06:07:55 UTC
Please don't upload mp3 files to the bugzilla. apart from the enormous file sizes, they have potential legal complications involved.

For the future, you are welcome to contact us personally to send us problematic files, we'd be happy to help out :)

Thanks!
Comment 11 H Richardson 2006-11-15 12:45:23 UTC
Hi Seb - I took this into consideration. The MP3s are each one second of silence, so they're not copyright or large :-)
Comment 12 Seb Ruiz 2006-11-15 13:30:34 UTC
but they are still patented ;-)

On 15 Nov 2006 11:45:24 -0000, H Richardson <68guns@gmail.com> wrote:
[bugs.kde.org quoted mail]
Comment 13 slowrobot 2007-08-12 00:12:43 UTC
I have the same problem using a Creative Zen Xtra with Amarok 1.4.6 (Feisty packages) as an NJB media device.  My libnjb version is 2.2.5.  If an album contains more than one track with the same song title (e.g. "Interlude"), Amarok will report that the track already exists and not transfer it, despite the track numbers and filenames being different ("03 - Interlude.mp3" vs. "07 - Interlude.mp3")