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.
PS. This problem also occurs if no "title" tag is set at all in the files to be transferred.
Located the code probably causing the problem at riokarmamediadevice.cpp line 143.
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.
It's not the disc number tag, it's the track number tag. I'll attach a testcase to demonstrate the point.
Created attachment 18544 [details] Tescase MP3s in ZIP archive with instructions
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!
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
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.
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;
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!
Hi Seb - I took this into consideration. The MP3s are each one second of silence, so they're not copyright or large :-)
but they are still patented ;-) On 15 Nov 2006 11:45:24 -0000, H Richardson <68guns@gmail.com> wrote: [bugs.kde.org quoted mail]
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")