GNOME Bugzilla – Bug 724725
"Open containing folder" in a track of an MTP device doesn't work
Last modified: 2020-03-17 09:59:24 UTC
Steps to reproduce: 1. Connect MTP device that has some tracks in it. 2. Wait for it to show up in banshee. 3. Open its "Music" source. 4. Right-click on any track -> Open containing folder Expected results: should open nautilus and show the folder where the track is. Current results: throws an exception in the terminal (captured as a warning).
I wouldn't expect this sort of functionality from the MTP support in banshee. Since we take control of the device from Gvfs, we'd have to release the device and mount the volume before we tried to show the file browser. Then if the user switched back to banshee and tried to use the device from there we'd have to take control again. Lots of points of failure. The only way I could see this working is if we 'improve' the Mass Storage support so that we don't rely and parsing URIs for file name information. I think this is how banshee sees the files/directories on an MTP device, I'm looking through the fuse mount point here: nicholas@shambles /run/user/1000/gvfs/mtp:host=%5Busb%3A001%2C009%5D/131074 $ ls 1490 31 32 33 34 35 36 37 38 39 40 As you can see, I have an .is_audio_player file on one of the storage mediums provided by the device, but we don't find it with the current filesystem abstraction: nicholas@shambles /run/user/1000/gvfs/mtp:host=%5Busb%3A001%2C009%5D/131074 $ gvfs-info 1490 display name: .is_audio_player name: 1490 type: regular size: 134 attributes: standard::type: 1 standard::name: 1490 standard::display-name: .is_audio_player standard::copy-name: .is_audio_player standard::icon: application-octet-stream, gnome-mime-application-octet-stream, application-x-generic standard::content-type: application/octet-stream standard::size: 134 id::filesystem: mtp:host=%5Busb%3A001%2C009%5D access::can-read: TRUE access::can-write: TRUE access::can-execute: FALSE access::can-delete: TRUE access::can-trash: FALSE access::can-rename: TRUE time::modified: 1392838142 time::modified-usec: 0
(In reply to comment #1) > I wouldn't expect this sort of functionality from the MTP support in banshee. > Since we take control of the device from Gvfs, we'd have to release the device > and mount the volume before we tried to show the file browser. Then if the user > switched back to banshee and tried to use the device from there we'd have to > take control again. Lots of points of failure. I see... :( > The only way I could see this working is if we 'improve' the Mass Storage > support so that we don't rely and parsing URIs for file name information. But didn't you say that the latest versions of Android just use MTP and cannot be used in MassStorage mode? > I think this is how banshee sees the files/directories on an MTP device, I'm > looking through the fuse mount point here: > > nicholas@shambles /run/user/1000/gvfs/mtp:host=%5Busb%3A001%2C009%5D/131074 $ > ls > 1490 31 32 33 34 35 36 37 38 39 40 > > As you can see, I have an .is_audio_player file on one of the storage mediums > provided by the device, but we don't find it with the current filesystem > abstraction: Provided by the device? Did Android leave a .is_audio_player file there? > > nicholas@shambles /run/user/1000/gvfs/mtp:host=%5Busb%3A001%2C009%5D/131074 $ > gvfs-info 1490 > > display name: .is_audio_player > name: 1490 > type: regular > size: 134 > attributes: > standard::type: 1 > standard::name: 1490 > standard::display-name: .is_audio_player > standard::copy-name: .is_audio_player > standard::icon: application-octet-stream, > gnome-mime-application-octet-stream, application-x-generic > standard::content-type: application/octet-stream > standard::size: 134 > id::filesystem: mtp:host=%5Busb%3A001%2C009%5D > access::can-read: TRUE > access::can-write: TRUE > access::can-execute: FALSE > access::can-delete: TRUE > access::can-trash: FALSE > access::can-rename: TRUE > time::modified: 1392838142 > time::modified-usec: 0
(In reply to comment #2) > (In reply to comment #1) <snip /> > > The only way I could see this working is if we 'improve' the Mass Storage > > support so that we don't rely and parsing URIs for file name information. > > But didn't you say that the latest versions of Android just use MTP and cannot > be used in MassStorage mode? > No, what I mean is the device, even in mtp mode, could be supported by the mass storage support in banshee but I can imagine that being a lot of work if it is possible. The bonus of course would be that we'd not have to worry about device disconnections because we would actually need it mounted to work with it, and the user would be able to work with the device while we were handling it (I think). > > I think this is how banshee sees the files/directories on an MTP device, I'm > > looking through the fuse mount point here: > > > > nicholas@shambles /run/user/1000/gvfs/mtp:host=%5Busb%3A001%2C009%5D/131074 $ > > ls > > 1490 31 32 33 34 35 36 37 38 39 40 > > > > As you can see, I have an .is_audio_player file on one of the storage mediums > > provided by the device, but we don't find it with the current filesystem > > abstraction: > > Provided by the device? Did Android leave a .is_audio_player file there? > The two different mediums are my storage card and the internal storage on the phone, but they're just shown as folders through gvfs. I put the file there hoping that its presence might get banshee to recognize it as I wasn't sure exactly why the existing mass storage support wasn't working. The point was that the URIs we use for MTP objects gives us no information about what it actually is. <snip />
Banshee is not under active development anymore and had its last code changes more than three years ago. Its codebase has been archived. Closing this report as WONTFIX as part of Bugzilla Housekeeping to reflect reality. Please feel free to reopen this ticket (or rather transfer the project to GNOME Gitlab, as GNOME Bugzilla is being shut down) if anyone takes the responsibility for active development again. See https://gitlab.gnome.org/Infrastructure/Infrastructure/issues/264 for more info.