GNOME Bugzilla – Bug 724727
Playback of a track inside an MTP device, within Banshee, doesn't work
Last modified: 2020-03-17 10:03:50 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. Double-click on any track. Expected results: should start playing the track. Current results: it doesn't play (shows a loop of GStreamer retry-and-error in the log).
Created attachment 271312 [details] [review] Enables playback for mtp devices This one actually begs the question, why were mtp tracks playing anyway? First time I tried to write a handler I was going to put it in the MtpTrackInfo and cast back with a null check, then download and play from the internal track struct but it's not an MtpTrackInfo we get, just a plain old DatabaseTrackInfo. Hence the reason why the CanPlay attribute of MtpTrackInfo is apparently ignored. Anyhoo, two birds, one stone. We can play now :) It doesn't handle cleanup, hopefully the user is on tmpfs... However, we'll only create as many temporary files as there are file types in the user's player so maybe it's not that bad ;)
Thanks for the patch, sorry it took so long to have a think about this! Two things: a) I'm guessing this operation is synchronous: + mtp_track.Download (path); This would be bad if we want to play a big video, then. Could we make this operation asynchronous? (Begin to play the file even if the download of the file has not finished yet?) b) Most importantly (before investigating (a) please), can you look how totem handles this? If I open totem and click on Movie->Open Location... and I paste an MTP path like mtp://[usb:003,007]/Internal%20storage/Music/The%20Suburbs.mp3 , it works! So it would be nice to know their approach, to know if it's better than what we're cooking here (or even if it's not better, maybe it's still good to follow the same approach).
(In reply to comment #2) > Thanks for the patch, sorry it took so long to have a think about this! > > Two things: > > a) I'm guessing this operation is synchronous: > > + mtp_track.Download (path); > > This would be bad if we want to play a big video, then. > Could we make this operation asynchronous? (Begin to play the file even if the > download of the file has not finished yet?) Definitely something to look into. > b) Most importantly (before investigating (a) please), can you look how totem > handles this? If I open totem and click on Movie->Open Location... and I paste > an MTP path like mtp://[usb:003,007]/Internal%20storage/Music/The%20Suburbs.mp3 > , it works! So it would be nice to know their approach, to know if it's better > than what we're cooking here (or even if it's not better, maybe it's still good > to follow the same approach). That's very interesting! If totem can do it, then I'm guessing it just goes through gstreamer. I tried to open a music file on my gentoo (totem 3.10.1) and on ubuntu (also 3.10.1) but neither one managed the feat. Gentoo's totem complained that I had no plugin to support MTP URIs which sounded promising but there's no use flags or configure arguments I can see talking about it in totem. Ubuntu's totem gave me a generic "couldn't load file" message. Last, I tried with gst-play but that also failed to play. Can you have a look in your totem for its version and also see if there's an enabled plugin for MTP too please? Aso, would you mind trying gst-play with your test Uri? If you find gst-play works, then I think the proper solution to this bug is to make sure we format our MTP URIs correctly on track load, which should make the above prototype unnecessary :)
(In reply to comment #3) > > b) Most importantly (before investigating (a) please), can you look how totem > > handles this? If I open totem and click on Movie->Open Location... and I paste > > an MTP path like mtp://[usb:003,007]/Internal%20storage/Music/The%20Suburbs.mp3 > > , it works! So it would be nice to know their approach, to know if it's better > > than what we're cooking here (or even if it's not better, maybe it's still good > > to follow the same approach). > > That's very interesting! If totem can do it, then I'm guessing it just goes > through gstreamer. > > I tried to open a music file on my gentoo (totem 3.10.1) and on ubuntu (also > 3.10.1) but neither one managed the feat. Gentoo's totem complained that I had > no plugin to support MTP URIs which sounded promising but there's no use flags > or configure arguments I can see talking about it in totem. Ubuntu's totem gave > me a generic "couldn't load file" message. That's definitely weird. Are you sure you used the correct URI? You can also test by opening the folder in nautilus, then right-click the file -> Open with -> Videos ("totem" is now called "Videos" AFAIK). > Can you have a look in your totem for its version and also see if there's an > enabled plugin for MTP too please? Videos 3.10.1 (stock version from Ubuntu 14.04 AFAIK), with no plugins enabled. > Aso, would you mind trying gst-play with your test Uri? It worked! (Well, in this Ubuntu version, the tool is called 'gst-play-1.0') > If you find gst-play works, then I think the proper solution to this bug is to > make sure we format our MTP URIs correctly on track load, which should make the > above prototype unnecessary :) Yes, but: > Last, I tried with gst-play but that also failed to play. How come it doesn't work for you? Maybe your 'gst-play' tool is mapped to GStreamer 0.10.x instead of 1.x? We need to figure this first I guess.
(In reply to comment #4) > (In reply to comment #3) > > > b) Most importantly (before investigating (a) please), can you look how totem > > > handles this? If I open totem and click on Movie->Open Location... and I paste > > > an MTP path like mtp://[usb:003,007]/Internal%20storage/Music/The%20Suburbs.mp3 > > > , it works! So it would be nice to know their approach, to know if it's better > > > than what we're cooking here (or even if it's not better, maybe it's still good > > > to follow the same approach). > > > > That's very interesting! If totem can do it, then I'm guessing it just goes > > through gstreamer. > > > > I tried to open a music file on my gentoo (totem 3.10.1) and on ubuntu (also > > 3.10.1) but neither one managed the feat. Gentoo's totem complained that I had > > no plugin to support MTP URIs which sounded promising but there's no use flags > > or configure arguments I can see talking about it in totem. Ubuntu's totem gave > > me a generic "couldn't load file" message. > > That's definitely weird. Are you sure you used the correct URI? You can also > test by opening the folder in nautilus, then right-click the file -> Open with > -> Videos ("totem" is now called "Videos" AFAIK). > Definitely, I used the right click method, then copied the URI from totem for the gst-play test :) > > Can you have a look in your totem for its version and also see if there's an > > enabled plugin for MTP too please? > > Videos 3.10.1 (stock version from Ubuntu 14.04 AFAIK), with no plugins enabled. > > > Aso, would you mind trying gst-play with your test Uri? > > It worked! (Well, in this Ubuntu version, the tool is called 'gst-play-1.0') Same here, I don't think there's a version of that for 0.10. > > If you find gst-play works, then I think the proper solution to this bug is to > > make sure we format our MTP URIs correctly on track load, which should make the > > above prototype unnecessary :) > > Yes, but: > > > > Last, I tried with gst-play but that also failed to play. > > How come it doesn't work for you? Maybe your 'gst-play' tool is mapped to > GStreamer 0.10.x instead of 1.x? We need to figure this first I guess. Probably worth figuring out but I thought about it a little more and I don't think it matters, since we're not using gvfs to access the URI. I'm emerging all the gstreamer plugins I can find in portage now to see if one of them gives me the functionality, so I can have a look at how they do it.
(In reply to comment #5) > I'm emerging all the gstreamer plugins I can find in portage now to see if one > of them gives me the functionality, so I can have a look at how they do it. Given that it works for me in Ubuntu 14.04, you may want to try with your Ubuntu as well, to be as similar as possible. I'll copy-paste the gstreamer packages I have installed here: ii gstreamer1.0-alsa:amd64 1.2.3-1 amd64 GStreamer plugin for ALSA ii gstreamer1.0-clutter 2.0.8-1build1 amd64 Clutter PLugin for GStreamer 1.0 ii gstreamer1.0-fluendo-mp3:amd64 0.10.23.debian-3 amd64 Fluendo mp3 decoder GStreamer 1.0 plugin ii gstreamer1.0-libav:amd64 1.2.3-1 amd64 libav plugin for GStreamer ii gstreamer1.0-nice:amd64 0.1.4-1 amd64 ICE library (GStreamer plugin) ii gstreamer1.0-plugins-bad:amd64 1.2.3-1ubuntu2 amd64 GStreamer plugins from the "bad" set ii gstreamer1.0-plugins-bad-faad:amd64 1.2.3-1ubuntu2 amd64 GStreamer faad plugin from the "bad" set ii gstreamer1.0-plugins-bad-videoparsers:amd64 1.2.3-1ubuntu2 amd64 GStreamer videoparsers plugin from the "bad" set ii gstreamer1.0-plugins-base:amd64 1.2.4-1~ubuntu1 amd64 GStreamer plugins from the "base" set ii gstreamer1.0-plugins-base-apps 1.2.3-1 amd64 GStreamer helper programs from the "base" set ii gstreamer1.0-plugins-good:amd64 1.2.4-1~ubuntu1 amd64 GStreamer plugins from the "good" set ii gstreamer1.0-plugins-ugly:amd64 1.2.3-2build1 amd64 GStreamer plugins from the "ugly" set ii gstreamer1.0-pulseaudio:amd64 1.2.3-1ubuntu2 amd64 GStreamer plugin for PulseAudio ii gstreamer1.0-tools 1.2.3-1 amd64 Tools for use with GStreamer ii gstreamer1.0-x:amd64 1.2.3-1 amd64 GStreamer plugins for X11 and Pango ii libgstreamer1.0-0:amd64 1.2.4-0ubuntu1 amd64 Core GStreamer libraries and elements ii libgstreamer1.0-0:i386 1.2.4-0ubuntu1 i386 Core GStreamer libraries and elements ii libgstreamer1.0-dev 1.2.4-0ubuntu1 amd64 GStreamer core development files If we find one that allows MTP playback, we should put as a mandatory dependency for MTP compilation (as a change to be included in the patch that fixes this bug).
(In reply to comment #3) > If you find gst-play works, then I think the proper solution to this bug is to > make sure we format our MTP URIs correctly on track load, which should make the > above prototype unnecessary :) I just realised that this is exactly what we need to do. I mean, right now Banshee has the URI mapped to "mtp://5071/The Cure - Other Voices.mp3", but the correct one I guess is "mtp://[usb:001,006]/Internal%20storage/Music/The%20Cure%20-%20Other%20Voices.mp3". If we manage to fix those URIs I think it will start playing inside Banshee (at least in my machine).
(In reply to comment #7) > (In reply to comment #3) > > If you find gst-play works, then I think the proper solution to this bug is to > > make sure we format our MTP URIs correctly on track load, which should make the > > above prototype unnecessary :) > > I just realised that this is exactly what we need to do. > > I mean, right now Banshee has the URI mapped to "mtp://5071/The Cure - Other > Voices.mp3", but the correct one I guess is > "mtp://[usb:001,006]/Internal%20storage/Music/The%20Cure%20-%20Other%20Voices.mp3". > > If we manage to fix those URIs I think it will start playing inside Banshee (at > least in my machine). They would, if we were using gvfs to talk to the device but I'd forgotten that at the time of my reply. What stops us from gvfs is that taglib doesn't work. For example, on my Gentoo system at the moment if I plugin my device and the Mtp extension doesn't claim it, and Mass Storage is enabled, then Mass Storage attempts to enumerate the tracks on it, at which point I see a bunch of taglib errors.
(In reply to comment #8) > (In reply to comment #7) > > (In reply to comment #3) > > > If you find gst-play works, then I think the proper solution to this bug is to > > > make sure we format our MTP URIs correctly on track load, which should make the > > > above prototype unnecessary :) > > > > I just realised that this is exactly what we need to do. > > > > I mean, right now Banshee has the URI mapped to "mtp://5071/The Cure - Other > > Voices.mp3", but the correct one I guess is > > "mtp://[usb:001,006]/Internal%20storage/Music/The%20Cure%20-%20Other%20Voices.mp3". > > > > If we manage to fix those URIs I think it will start playing inside Banshee (at > > least in my machine). > > They would, if we were using gvfs to talk to the device but I'd forgotten that > at the time of my reply. What stops us from gvfs is that taglib doesn't work. > > For example, on my Gentoo system at the moment if I plugin my device and the > Mtp extension doesn't claim it, and Mass Storage is enabled, then Mass Storage > attempts to enumerate the tracks on it, at which point I see a bunch of taglib > errors. Not sure I understand the above. Let's start with the facts: GStreamer is able to open that thanks to GstGioSrc, and I guess what you mean is that Gio has access to gvfs, but why Banshee doesn't? We have gio-sharp, do we need gvfs-sharp?
(In reply to comment #9) > (In reply to comment #8) > > (In reply to comment #7) > > > (In reply to comment #3) > > > > If you find gst-play works, then I think the proper solution to this bug is to > > > > make sure we format our MTP URIs correctly on track load, which should make the > > > > above prototype unnecessary :) > > > > > > I just realised that this is exactly what we need to do. > > > > > > I mean, right now Banshee has the URI mapped to "mtp://5071/The Cure - Other > > > Voices.mp3", but the correct one I guess is > > > "mtp://[usb:001,006]/Internal%20storage/Music/The%20Cure%20-%20Other%20Voices.mp3". > > > > > > If we manage to fix those URIs I think it will start playing inside Banshee (at > > > least in my machine). > > > > They would, if we were using gvfs to talk to the device but I'd forgotten that > > at the time of my reply. What stops us from gvfs is that taglib doesn't work. > > > > For example, on my Gentoo system at the moment if I plugin my device and the > > Mtp extension doesn't claim it, and Mass Storage is enabled, then Mass Storage > > attempts to enumerate the tracks on it, at which point I see a bunch of taglib > > errors. > > Not sure I understand the above. > > Let's start with the facts: GStreamer is able to open that thanks to GstGioSrc, > and I guess what you mean is that Gio has access to gvfs, but why Banshee > doesn't? We have gio-sharp, do we need gvfs-sharp? This is the only one that counts: - We use libmtp directly because there's no way (qualifier: AFAIK) to get at the file's metadata through gio/gvfs. Without the metadata, welcome to the world of bluetooth ;)
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.