Bug 139722 - Transferring music files named with non-ascii characters to generic media devices fails
Summary: Transferring music files named with non-ascii characters to generic media dev...
Status: RESOLVED UNMAINTAINED
Alias: None
Product: amarok
Classification: Applications
Component: Collections/Media Devices (show other bugs)
Version: 1.4.4
Platform: Debian testing Linux
: NOR normal
Target Milestone: ---
Assignee: Amarok Developers
URL:
Keywords:
: 140501 144719 146277 146445 (view as bug list)
Depends on:
Blocks:
 
Reported: 2007-01-07 14:20 UTC by Jörn Reder
Modified: 2009-04-26 06:02 UTC (History)
8 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Change from latin1 encoding to utf8 encoding for filenames on file transfer. (674 bytes, patch)
2007-08-22 05:10 UTC, Kevin Becker
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jörn Reder 2007-01-07 14:20:26 UTC
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
Comment 1 Jörn Reder 2007-01-07 14:44:38 UTC
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.
Comment 2 Kevin Funk 2007-05-10 20:16:20 UTC
*** Bug 144719 has been marked as a duplicate of this bug. ***
Comment 3 Kevin Funk 2007-05-10 20:18:38 UTC
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.
Comment 4 Kevin Funk 2007-06-03 22:51:56 UTC
*** Bug 140501 has been marked as a duplicate of this bug. ***
Comment 5 Seb Ruiz 2007-06-04 02:34:04 UTC
*** Bug 146277 has been marked as a duplicate of this bug. ***
Comment 6 Kevin Funk 2007-06-06 16:00:13 UTC
*** Bug 146445 has been marked as a duplicate of this bug. ***
Comment 7 Erik Ramseth 2007-06-24 13:40:03 UTC
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...
Comment 8 Erlend Hamberg 2007-06-27 19:41:38 UTC
Same problem here:
"Failed to copy track to media device: /home/hamberg/Dokumenter/Musikk/Sigur Rós/( )/07 - Dauðalagið.mp3"
Comment 9 Nicolas Cedilnik 2007-07-10 15:55:03 UTC
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 !
Comment 10 Oscar Curero 2007-07-12 23:45:20 UTC
Same problem here. I didn't had this problem before, just in the last two releases (using Zen V Plus).  

Comment 11 Kevin Becker 2007-08-22 05:10:05 UTC
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().
Comment 12 Jeff Mitchell 2007-08-22 05:57:47 UTC
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.

Comment 13 Jeff Mitchell 2007-08-22 14:54:18 UTC
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();
Comment 14 Mark Kretschmann 2007-08-31 14:58:29 UTC
Seems to be fixed with the above commit, so I'm closing. Or was this kept open on purpose?

Comment 15 Jeff Mitchell 2007-08-31 21:12:00 UTC
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.
Comment 16 Kun Xi 2007-12-16 00:37:54 UTC
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/

Comment 17 Jonas Vejlin 2009-04-25 21:09:15 UTC
Should this be clouse becouse it is field against 1.4 with is unmaintained?
Comment 18 Seb Ruiz 2009-04-26 06:02:36 UTC
Thanks Jonas. Feel free to close bugs that are marked against 1.4. (We can reopen any false positives).