GNOME Bugzilla – Bug 526794
[giosrc] totem doesn't work with some gvfs backends
Last modified: 2013-08-16 12:05:33 UTC
Works fine through the fuse mount using standard POSIX IO $ totem ~/.gvfs/cdda\ mount\ on\ sr0/Track\ 10.wav But no such luck with native gio $ totem cdda://sr0/Track\ 10.wav ** Message: Error: Stream contains no data. gsttypefindelement.c(742): gst_type_find_element_activate (): /play/decodebin0/typefind: Can't typefind empty stream $ gvfs-info cdda://sr0/Track\ 10.wav display name: /Track 10.wav name: /Track 10.wav type: regular size: 41303588 attributes: standard::display-name: /Track 10.wav standard::type: 1 standard::content-type: audio/x-wav standard::size: 41303588 standard::icon: GThemedIcon:0x8222198 standard::name: /Track 10.wav id::filesystem: host='sr0',type='cdda',mount_prefix='/' access::can-read: TRUE access::can-write: FALSE access::can-delete: FALSE access::can-execute: FALSE access::can-trash: FALSE access::can-rename: FALSE Any idea what's wrong? Maybe you're expecting to find some properties that are not set by the gvfs cdda backend? Thanks.
totem-gstreamer won't use gio to process cdda:// URIs, but rather cdparanoiasrc or cdiocddasrc (both of which expect an URI in the format cdda://<track-number>, can't remember if totem munges the URI and extracts the device automatically from URIs with device before passing them to GStreamer). Could you attach the output of: $ GST_DEBUG=*cdda*:5,*cdio*:5,*cdparanoia*:5,totem:5 totem cdda://... 2>dbg.log ?
Will attach the logs shortly... FYI same problem with a gphoto2 mount.. so there's definitely something fishy with the gstreamer gio source: $ totem gphoto2://[usb:001,017]/MUSIC/Nephew/06.%20En%20wannabe%20Darth%20Vader.mp3 ** Message: Error: Stream contains no data. gsttypefindelement.c(742): gst_type_find_element_activate (): /play/decodebin0/typefind: Can't typefind empty stream
$ gvfs-info gphoto2://[usb:001,017]/MUSIC/Nephew/06.%20En%20wannabe%20Darth%20Vader.mp3 display name: 06. En wannabe Darth Vader.mp3 name: 06. En wannabe Darth Vader.mp3 type: regular size: 7288207 attributes: standard::name: 06. En wannabe Darth Vader.mp3 standard::display-name: 06. En wannabe Darth Vader.mp3 standard::icon: GThemedIcon:0x9d2f198 standard::type: 1 standard::content-type: audio/mpeg standard::size: 7288207 standard::is-hidden: FALSE access::can-read: TRUE access::can-write: TRUE access::can-delete: TRUE access::can-execute: FALSE access::can-trash: FALSE access::can-rename: TRUE time::modified: 1204494998 time::modified-usec: 0 id::filesystem: host='[usb:001,017]',type='gphoto2',mount_prefix='/'
Created attachment 108803 [details] output Output of $ GST_DEBUG=*cdda*:5,*cdio*:5,*cdparanoia*:5,totem:5 totem cdda://sr0/Track\ 10.wav 2>dbg.log
This is on Fedora 9 if that's any help.
(In reply to comment #2) > FYI same problem with a gphoto2 mount.. so there's definitely something fishy > with the gstreamer gio source: > > $ totem > gphoto2://[usb:001,017]/MUSIC/Nephew/06.%20En%20wannabe%20Darth%20Vader.mp3 > ** Message: Error: Stream contains no data. > gsttypefindelement.c(742): gst_type_find_element_activate (): > /play/decodebin0/typefind: > Can't typefind empty stream > Forgot to mention this works fine through ~/.gvfs...
CDDA tracks won't work, as Tim mentioned. I thought I'd been testing Totem on gvfs, turns out it was using the gnome-vfs plugin instead, and getting the secrets from the session... This should work: gst-launch-0.10 giosrc location="gphoto2://[usb:001,017]/MUSIC/Nephew/06.%20En%20wannabe%20Darth%20Vader.mp3" ! fdsink > file.mp3 But will just spit out garbage. Could you please verify David?
This gives me a file called file.mp3 that is identical to the mp3 file on the gphoto2 mount....
Here's the detail $ gst-launch-0.10 giosrc location="gphoto2://[usb:001,017]/MUSIC/Nephew/06.%20En%20wannabe%20Darth%20Vader.mp3" ! fdsink > file.mp3 Setting pipeline to PAUSED ... Pipeline is PREROLLING ... Pipeline is PREROLLED ... Setting pipeline to PLAYING ... Setting pipeline to PAUSED ... Setting pipeline to READY ... Setting pipeline to NULL ... FREEING pipeline ... $ ls -l file.mp3 -rw-rw-r-- 1 davidz davidz 7288277 2008-04-07 16:08 file.mp3
(Identical.. although the file is 70 bytes longer.)
(and yes, file.mp3 does play fine (Nephew is awesome btw) - Bastien asked me on IRC)
$ gst-launch-0.10 giosrc location="smb://192.168.1.7/data/Other/funny/THX%20-%20Theme.mp3" ! fdsink > foo2 Setting pipeline to PAUSED ... Pipeline is PREROLLING ... Pipeline is PREROLLED ... Setting pipeline to PLAYING ... Setting pipeline to PAUSED ... Setting pipeline to READY ... Setting pipeline to NULL ... FREEING pipeline ... $ gst-launch-0.10 giosrc location="smb://192.168.1.7/data/Other/funny/THX%20-%20Theme.mp3" ! fdsink > foo3 Setting pipeline to PAUSED ... Pipeline is PREROLLING ... Pipeline is PREROLLED ... Setting pipeline to PLAYING ... Setting pipeline to PAUSED ... Setting pipeline to READY ... Setting pipeline to NULL ... FREEING pipeline ... $ diff foo2 foo3 Binary files foo2 and foo3 differ $ file foo2 # I know the file is a bit broken, plays fine in totem locally foo2: Audio file with ID3 version 23.0 tag, MP3 encoding $ file foo3 foo3: data I think there's something fishy in the giosrc. In the output of: GST_DEBUG='*:5' gst-launch-0.10 --gst-disable-registry-fork giosrc location="smb://192.168.1.7/data/Other/funny/THX%20-%20Theme.mp3" ! decodebin I get: 0:00:00.808687556 ^[[335m12346^[[00m 0x952e458 ^[[36mDEBUG^[[00m ^[[00m basesrc gstbasesrc.c:758:gst_base_src_default_query:<giosrc0>^[[00m duration query in format bytes• 0:00:00.808743708 ^[[335m12346^[[00m 0x952e458 ^[[36mDEBUG^[[00m ^[[00m basesrc gstbasesrc.c:866:gst_base_src_default_query:<giosrc0>^[[00m query duration returns 1• Huh. 1 byte? My guess is a dupe of bug 520244 (as seen in bug 510417).
In any case => GStreamer. I think giosrc shouldn't be advertising the cdda protocol, since it won't support the things usually assumed in this case (seeking to a different track/querying in "track" format, musicbrainz/cddb hashes (?) etc.). Also, btw, giosrc is still marked as experimental in GStreamer and should only be compiled with --enable-experimental. This is for a reason. If you have it enabled by default in Fedora don't complain about the fallout :)
2008-04-09 Sebastian Dröge <slomo@circular-chaos.org> * ext/gio/gstgio.c: (gst_gio_get_supported_protocols): Filter cdda from the supported URI schemes. We can't support musicbrinz tags and everything else one expects from a cdda source with GIO. Fixes bug #526794.
Bastien, the 1 in "query duration returns 1" means TRUE, quite confusing :) A few lines below you should get something like gstbasesrc.c:1691:gst_base_src_update_length:<giosrc0> reading offset 0, length 512, size 7372800, segment.stop -1, maxsize 7372800 If not, there's a bug... please open a new one for that then :) Also, are the files from the gphoto backends corrupted when using gvfs-copy too? I can only test the file, http and sftp backends here and they work fine for me with giosrc.
(In reply to comment #14) > 2008-04-09 Sebastian Dröge <slomo@circular-chaos.org> > > * ext/gio/gstgio.c: (gst_gio_get_supported_protocols): > Filter cdda from the supported URI schemes. We can't support > musicbrinz tags and everything else one expects from a cdda source > with GIO. Fixes bug #526794. I'm reopening as - this doesn't fix the problem; the gphoto2 backend still doesn't work; see earlier commments. - filtering cdda:// out seems like a bad idea; if the user specifically asks for "cdda://sr0/Track 1.wav" then I don't see what the problem of letting the gstgio backend handle it. (And I should probably rename the cdda:// gvfs gio backend to something else to avoid conflicts. I'll look at doing that in gvfs.) The implication of this bug is that you don't get sound previews (via totem-audio-preview) in the file manager.
(In reply to comment #16) > (And I should probably rename the cdda:// gvfs gio backend to something > else to avoid conflicts. I'll look at doing that in gvfs.) See bug 527159.
(In reply to comment #16) > (In reply to comment #14) > > 2008-04-09 Sebastian Dröge <slomo@circular-chaos.org> > > > > * ext/gio/gstgio.c: (gst_gio_get_supported_protocols): > > Filter cdda from the supported URI schemes. We can't support > > musicbrinz tags and everything else one expects from a cdda source > > with GIO. Fixes bug #526794. > > I'm reopening as > > - this doesn't fix the problem; the gphoto2 backend still doesn't work; > see earlier commments. As asked before, is the file also corrupted when using gvfs-copy? I can't think of any possible reason why only the gphoto2 backend produces broken files, we handle all URI schemes (except filtering for automatic usage) the same in the gio plugin. You said "(Identical.. although the file is 70 bytes longer.)", what are these 70 additional bytes? Maybe you can attach a sample to this bug :) > - filtering cdda:// out seems like a bad idea; if the user specifically > asks for "cdda://sr0/Track 1.wav" then I don't see what the problem > of letting the gstgio backend handle it. That will still work, my change only prevents it from being used automatically when asking for a cdda source. > (And I should probably rename the cdda:// gvfs gio backend to something > else to avoid conflicts. I'll look at doing that in gvfs.) That's not necessary IMHO... otherwise one could also argue that either gst or gvfs should use something different than http:// for http as gstreamer http sources are supposed to do more (icecast stuff, ...) than gvfs can possibly offer ;) This kind of conflicts will probably appear with other URI schemes sooner or later and I think the best solution for this is, to prevent the gstreamer gio source being used automatically for those schemes. > The implication of this bug is that you don't get sound previews (via > totem-audio-preview) in the file manager. Should be fixed with my change for cdda at least.
FWIW, it seems fixed to me, and I used nautilus to preview an audio file I uploaded onto an MTP phone (with a unplug/replug/remove battery/replug in between, so no caches). David?
I'm an idiot, it works because it's using the FUSE path. $ gst-launch-0.10 giosrc location="gphoto2://[usb:001,025]/store_00010001/music/Knight%20Rider%202008.mp3" ! decodebin Setting pipeline to PAUSED ... ERROR: Pipeline doesn't want to pause. ERROR: from element /pipeline0/decodebin0/typefind: Stream contains no data. Additional debug info: gsttypefindelement.c(776): gst_type_find_element_activate (): /pipeline0/decodebin0/typefind: Can't typefind empty stream Setting pipeline to NULL ... FREEING pipeline ...
Is this still a problem? And if it is, why is this a GStreamer problem and not a gvfs problem?
I believe it's still a problem. The problem is very likely in giosrc because the FUSE mounts, which use GIO at the backend, work perfectly fine. The easy way to test this is to disable the code in the backend that forces the FUSE path to be used: http://git.gnome.org/browse/totem/tree/src/backend/bacon-video-widget-gst-0.10.c#n3390 (Remove that whole section and just have: bvw->priv->mrl = g_strdup (mrl); instead) Seeking in files on SMB shares, etc. doesn't work as well with giosrc as it would with the filesrc.
This doesn't make much sense though, unless there's special GIO API that makes stuff work with SMB :) giosrc only gets a GInputStream from the GFile and then uses g_input_stream_read() and g_seekable_seek() on it. Can you think of any reason why it would work with the FUSE module, that probably uses exactly the same API, but not in giosrc?
The performance problems might have been caused by gvfs' read-ahead (bug 697298). CDDA through gvfs also works fine in recent Totems. I'd close this unless David has particular requirements here.
There was also a change recently to make giosrc work faster on smb (and not waste a lot of bandwidth).