Version: 2.4.0 (using KDE 4.6.0) OS: Linux When transferring .m4a audio files to a 2G iPod Touch, the file extension changes from .m4a to .mp4 and the iPod reads the file as video (sending it to the Video .app) rather than audio (where it would fall under Music). It does not appear to be a mime error, as the files are correctly labeled audio/mp4, so it looks like it's a problem in the way that Amarok handles .mp4 files regardless of the extension or mime type. Reproducible: Always Steps to Reproduce: In Amarok, transfer any file of type .m4a to iPod Touch. Actual Results: Transfered audio file has the file extension changed to .mp4 and can be found under the iPod Touch's video application. Expected Results: Audio file should maintain file extension .m4a and be found under the iPod Touch's music application. OS: Linux (i686) release 2.6.35-27-generic // Ubuntu 10.10 Compiler: cc
still a problem in 2.4.1
Thank you for the feedback.
Same issue with iPod Classic 6G.
Setting status to confirmed.
Also happening with iPod nano 4G
This is happening on iPOD clasic as well
I'm working on this. The problem is that Amarok itself doesn't differentiate between audio and video MP4 files. I plan to work on this for the 2.6 release.
Git commit 1a721e7f41e0225df1c2cbcff3e56b23c3ffa77d by Matěj Laitl. Committed on 03/04/2012 at 18:57. Pushed by laitl into branch 'master'. distinguish between mp4, m4a, m4v types in Amarok::FileType iPod Collection (the new one) needs to distinguish somehow between MPEG-4 audio and video files; to make this generic, least bad approach it probably to use Meta::Track:type(). MetaFile::Track's type() is okay, as it just returns lowercased file extension. SqlTrack stores file type in db as numeric index to the Amarok::FileType enum, which currently has just one generic entry for MP4 files. This patch extends Amarok::FileType with M4a and M4v values and TagHelper to try to detect more specific MP4 file format. (currently just file extension based, can be extended in future) Users will need to do a full rescan for Local Collection to pick up more specialised file types. I'm running this through review board as there seems no general agreement on Meta::Track:type() semantics. (Speaking of which, I'd be most satisfied if it returned (the most specific) mime-type represented using dedicated class that would support mimetype hierarchy) FIXED-IN: 2.6 REVIEW: 104481 M +2 -0 ChangeLog M +3 -1 shared/FileType.cpp M +4 -2 shared/FileType.h M +10 -1 shared/tag_helpers/TagHelper.cpp http://commits.kde.org/amarok/1a721e7f41e0225df1c2cbcff3e56b23c3ffa77d
*** Bug 299991 has been marked as a duplicate of this bug. ***