Version: 1.4.4 (using KDE KDE 3.5.5) Installed from: Debian testing/unstable Packages OS: Linux First thanks you guys for adding Rio Karma support to Amarok - this rocks! In general transferring Ogg files to my Rio Karma works, as long as their names don't carry any accented characters. For example all tracks of the artist "Röyksopp" are rejected with the error message "Failed to copy track to media". On the console these messages are repeated for each track: amarok: [RioKarmaMediaDevice] Could not write file-1 amarok: END__: virtual MediaItem* RioKarmaMediaDevice::copyTrackToDevice(const MetaBundle&) - Took 0.00022s amarok: BEGIN: virtual MediaItem* RioKarmaMediaDevice::copyTrackToDevice(const MetaBundle&) and then /media/karma//var/smalldb: No such file or directory amarok: [RioKarmaMediaDevice] error writing smalldb file amarok: END__: virtual void RioKarmaMediaDevice::synchronizeDevice() - Took 0.00019s Obviously the Karma has problems with the utf-8 character encoding of Ogg comments, because also when files are transferred with the original Java client, accented characters are not displayed correctly on the device - but at least they can be transferred and played back ;) Regards, Jörn
Sorry, I forgot to mention versions of affected libraries/modules - both compiled from source: libkarma: 0.0.6 omfs: 0.7.2 Amarok itself is compiled from source as well, using the Debian unstable source package 1.4.4-2 (because Debian's binary package currently lacks Rio Karma support). System is Athlon 64, running 32bit i386 Debian unstable.
*** Bug 144719 has been marked as a duplicate of this bug. ***
There are also troubles when transferring non-ascii file names to a MTP device, see bug 144719. Converting file names to VFAT compatible chars first could be the fix.
*** Bug 140501 has been marked as a duplicate of this bug. ***
*** Bug 146277 has been marked as a duplicate of this bug. ***
*** Bug 146445 has been marked as a duplicate of this bug. ***
The MTP device itself (in my case creative Zen V plus) supports the characters in the file name. gnomad2 has no problem transferring them. In konsole I have seen errors similar to Autodetected device "Creative Zen V Plus" (VID=041e,PID=4152) is known. PTP: Opening session Connected to MTP device. LIBMTP_Send_Track_From_File(): Could not open source file "/media/USB_HD/music/mp3/Volare - The Very Best Of The Gipsy Kings/Volare - The Very Best Of The Gipsy Kings (Disc 1 Of 2)/18 - Oh �h Oh �h.mp3 It seems the special characters are getting lost somewhere...
Same problem here: "Failed to copy track to media device: /home/hamberg/Dokumenter/Musikk/Sigur Rós/( )/07 - Dauðalagið.mp3"
Same problem here: Using latest libmtp, amarok and kde under arch linux. Transferring files works just fine except when they have special characters (I'm in France, so those characters are ç, à, é, è, ...) Using CLI mtp-senfile works just fine too (no metadata though, but I think it's normal) This little bug is really annoying. Until it is solved, I'll only listen anglosaxon music on my walkman :) Please help !
Same problem here. I didn't had this problem before, just in the last two releases (using Zen V Plus).
Created attachment 21447 [details] Change from latin1 encoding to utf8 encoding for filenames on file transfer. By changing the filename conversion from latin1 to utf8 in mtpmediadevice.cpp, I've successfully made non-ascii characters in filenames work under libmtp 0.2.1 and amarok 1.4.7 on my Zen Vision: M. I've attached a patch. It's based on 1.4.7, but by looking at the branch SVN, it appears that nothing has changed since then, so this should work there too. It appears that trunk SVN can be fixed by changing lines 300 and 302 of mtpmediadevice.cpp to use toUtf8() instead of toLatin1().
libmtp strings are always UTF-8. I guess the coder of the MTP device didn't know that :-| I'll try to remember to go through and adjust all of the relevant strings in the device and fix it up for 1.4.8.
SVN commit 703403 by mitchell: Fix accidental use of toLatin1 instead of toUtf8, causing transfer issues to MTP devices. Thanks to Kevin Becker <kevman3000@gmail.com> for the fix. CCBUG: 139722 M +2 -2 mtpmediadevice.cpp --- branches/stable/extragear/multimedia/amarok/src/mediadevice/mtp/mtpmediadevice.cpp #703402:703403 @@ -295,9 +295,9 @@ debug() << "Parent id : " << parent_id << endl; m_critical_mutex.lock(); - debug() << "Sending track... " << bundle.url().path().latin1() << endl; + debug() << "Sending track... " << bundle.url().path().utf8() << endl; int ret = LIBMTP_Send_Track_From_File( - m_device, bundle.url().path().latin1(), trackmeta, + m_device, bundle.url().path().utf8(), trackmeta, progressCallback, this, parent_id ); m_critical_mutex.unlock();
Seems to be fixed with the above commit, so I'm closing. Or was this kept open on purpose?
I think I might have left it open to remind me to check the rest of the locations for UTF usage, but then forgot to close it once I did. Should be good.
Question: Shall we use local8Bit instead of utf8? Since there is no guarantee the locale in the host is utf8. At least, I know MagicLinux still uses GB2312 as the default locale. I've tried local8Bit, it worked in utf8 environment, not have a chance to test it in other locale.Here is the long story. http://www.kunxi.org/archives/2007/12/migrate-to-mtp/
Should this be clouse becouse it is field against 1.4 with is unmaintained?
Thanks Jonas. Feel free to close bugs that are marked against 1.4. (We can reopen any false positives).