GNOME Bugzilla – Bug 743105
MTP backend could set filetype field when uploading a file, based on mimetype
Last modified: 2015-01-24 05:31:17 UTC
I've got Nokia Lumia 630 Dual SIM with Windows 8 on it. And when I upload files using console I can immediately see them in Music app: $ mtp-newfolder uploaded 0 0 libmtp version: 1.1.8 Device 0 (VID=0421 and PID=06fc) is a Nokia Nokia Lumia 630. ignoring libusb_claim_interface() = -6PTP_ERROR_IO: failed to open session, trying again after resetting USB interface LIBMTP libusb: Attempt to reset device object 1 has parent 0xffffffff (-1) continuing anyway object 2 has parent 0xffffffff (-1) continuing anyway object 3 has parent 0xffffffff (-1) continuing anyway object 8 has parent 0xffffffff (-1) continuing anyway object b has parent 0xffffffff (-1) continuing anyway object c has parent 0xffffffff (-1) continuing anyway Device have files in "root folder" 0xffffffffU - this is a firmware bug (but continuing) New folder created with ID: 13 $ mtp-filetree Device 0 (VID=0421 and PID=06fc) is a Nokia Nokia Lumia 630. Attempting to connect device(s) Device: Windows Phone Storage: Phone 1 Documents 2 Downloads 3 Music 4 Album 5 Artist 6 Playlist 7 PodcastSeries 4 Album 5 Artist 6 Playlist 7 PodcastSeries 8 Pictures 9 Camera Roll 10 Saved Pictures 9 Camera Roll 10 Saved Pictures 11 Ringtones 12 uploaded 13 Videos OK. $ mtp-sendfile /run/media/yuri/wdata/torrents/Metallica\ \(mp3\)/01\ -\ Studio\ albums/2008\ -\ Death\ Magnetic\ \[UICR-1077\]/07.\ The\ Unforgiven\ III.mp3 12 libmtp version: 1.1.8 Device 0 (VID=0421 and PID=06fc) is a Nokia Nokia Lumia 630. object 1 has parent 0xffffffff (-1) continuing anyway object 2 has parent 0xffffffff (-1) continuing anyway object 3 has parent 0xffffffff (-1) continuing anyway object 8 has parent 0xffffffff (-1) continuing anyway object b has parent 0xffffffff (-1) continuing anyway object c has parent 0xffffffff (-1) continuing anyway object d has parent 0xffffffff (-1) continuing anyway Device have files in "root folder" 0xffffffffU - this is a firmware bug (but continuing) Sending /run/media/yuri/wdata/torrents/Metallica (mp3)/01 - Studio albums/2008 - Death Magnetic [UICR-1077]/07. The Unforgiven III.mp3 to 12 type: mp3, 2 Sending file... Progress: 18757750 of 18757750 (100%) New file ID: 14 $ mtp-filetree Device 0 (VID=0421 and PID=06fc) is a Nokia Nokia Lumia 630. Attempting to connect device(s) Device: Windows Phone Storage: Phone 1 Documents 2 Downloads 3 Music 4 Album 15 Death Magnetic [UICR-1077{56C2A1D1-543D-4320-83BA-63E870526220} 5 Artist 16 Metallica 6 Playlist 7 PodcastSeries 4 Album 15 Death Magnetic [UICR-1077{56C2A1D1-543D-4320-83BA-63E870526220} 5 Artist 16 Metallica 6 Playlist 7 PodcastSeries 8 Pictures 9 Camera Roll 10 Saved Pictures 9 Camera Roll 10 Saved Pictures 11 Ringtones 12 uploaded 13 07. The Unforgiven III.mp3 13 07. The Unforgiven III.mp3 14 Videos 15 Death Magnetic [UICR-1077{56C2A1D1-543D-4320-83BA-63E870526220} 16 Metallica OK. As you can see some extra files are automatically created in Music/{Album,Artist} folders. And when you do `mtp-delfile -n 13` all those extra files disappear as well. But when you do using GUI (gvfs-mtp + Files app), nothing of the sorts happens. Files do appear where you copy them, but no additional files are created. And I can't make Music app see uploaded files, as opposed to doing all this from command line.
Today, the gvfs mtp backend simply sends files with a generic filetype (MTP concept). As such, the device will do whatever it does for generic files. I've experimented with setting the filetype explicitly before - based on the mimetype - but I was never able to observe any difference in behaviour on Android devices running Google's MTP stack (the only kind of device I have access to). So, without a meaningful test case, I couldn't be sure I was handling things correctly, or doing anything useful. From your experience, we can say that Lumias do have special handling for music files, but that doesn't help me test any changes I make to try and enable this.
Created attachment 294815 [details] [review] Patch to add logic to set file type. Here's a change that tries to set the filetype based on mimetype. No idea how well it works.
Well, it mostly works. But extra files don't appear/disappear until remount. Probably not a big deal. Also, the dir I created disappeared. I can't reproduce it now. And the mount point becomes empty occasionally. Again until remount. Additionally, I'm getting some warnings when building the thing: https://bbs.archlinux.org/viewtopic.php?pid=1494461
File notifications are up to the device. It may not be sending them for the extra files, in which case you won't see them until you refresh, or remount, or even until after a device side media scanner runs (in the case of android). There's a lot of variation out there. I think I'll push this. It doesn't hurt for Android devices, and maybe it will help people like you.