Summary: | Rio karma transfer duplicate track problem | ||
---|---|---|---|
Product: | [Applications] amarok | Reporter: | H Richardson <68guns> |
Component: | Collections/Media Devices | Assignee: | Amarok Developers <amarok-bugs-dist> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | andy |
Priority: | NOR | ||
Version: | 1.4.4 | ||
Target Milestone: | --- | ||
Platform: | unspecified | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Attachments: |
Tescase MP3s in ZIP archive with instructions
Patch for checking track number to determine uniqueness |
Description
H Richardson
2006-11-10 14:37:03 UTC
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") |