GNOME Bugzilla – Bug 597448
Playing movie inside mounted archive fails
Last modified: 2014-11-30 10:38:06 UTC
I have a movie.avi (cca 700MiB), import it into archivedmovie.tar.gz archive, mount the archive with gvfs-mount, open the movie.avi from the mounted archive in Totem, processor works on 100% a few secs, than I get " An error occured Could not read from resource. " (i.e. opening 50 KiB pdf document from mounted *.tar.gz archive in Evince works) if it's not Totem's, but gvfs's fault, please move the bug there
What's the error on the command-line? Does: gst-launch playbin2 uri=file:///path/to/file.avi work? (drag'n'drop from nautilus onto your terminal to check)
Created attachment 144835 [details] debug info from totem
Created attachment 144836 [details] debug info from gst-launch
How should gvfs-mount be called to mount a tar.gz archive?
[4] I don't know, i mount the archives using the nautilus's context menu (right click on the archive in nautilus, choose Open with "Archive Mounter")
this problem exists also with ogg (Theora) movie that is only 200MiB big.
also with mp3 file 6MiB
the mp3 file was tried in .zip, .tar.gz and tar.bz2 than I tried flac file (34MiB) and interresting thing happend for the first time i played it in totem, it played for about 500ms or 200ms and that it stopped and i got the error. when I tried to play it again I got the error right away
affects me too on gnome 2.28 ubuntu karmic
I committed this which works around problems with gvfs, when using GStreamer's filesrc. Reassigning to gvfs for gvfs testing. commit 559493aa5af713994f9aad3b9f3ed71469bc16eb Author: Bastien Nocera <hadess@hadess.net> Date: Tue Jan 5 10:52:22 2010 +0100 Use the giosrc when reading from gvfs archive mounts Reading that same file through FUSE fails. https://bugzilla.gnome.org/show_bug.cgi?id=597448 (Fake filenames) This fails, and uses filesrc in GStreamer and gvfs-fuse: gst-launch playbin2 uri="file:///home/user/.gvfs/mount.zip/mount.avi" This works, and uses giosrc: gst-launch playbin2 uri="archive:///mount.zip/mount.avi"
*** Bug 575723 has been marked as a duplicate of this bug. ***
The patch series I posted here (https://mail.gnome.org/archives/gvfs-list/2013-September/msg00002.html) should to take care of this issue. There were a few problems; firstly fuse issues out of order readahead calls by default which causes ENOTSUPP read errors on a nonseekable stream. This is fixed by the second patch. The second problem is that gst-launch tries to lseek to the end of the file to determine if the file is seekable; this succeeds so it assumes it is and then it issues a read which fails with ENOTSUPP. The third patch takes care of this by making lseeks fail if the underlying file is not seekable. gst-launch can then stream videos from a fuse mount correctly.
(In reply to comment #12) > The patch series I posted here > (https://mail.gnome.org/archives/gvfs-list/2013-September/msg00002.html) should > to take care of this issue. Use git-bz to upload the patches here instead. GNOME doesn't use mailing-lists for patches, and what will come out of it is, very likely, for your patches to be lost and forgotten. Add the bug URL in each one of your commits and run "git bz attach [commit range]"
Created attachment 255981 [details] [review] fuse: Fix seek offset calculation Since fh->pos is already incremented by n_bytes_skipped, check if offset == fh->pos. This error was hidden by the fact that the operation is retried when -EIO is returned. When it was retried, the stream was already in the correct position and so no seek operation was required.
Created attachment 255982 [details] [review] fuse: Enforce sync_read When running multithreaded, fuse can issue readahead requests out of order which can cause subsequent reads to fail with ENOTSUPP (if seeking backward is not supported on the stream). Force readahead to occur in order to prevent this problem.
Created attachment 255983 [details] [review] fuse: Make file nonseekable if it actually is Instead of failing in read() with ENOTSUPP after the lseek on a nonseekable stream succeeds, make the lseek fail with ESPIPE, as it should. This is important for applications which test the return value of lseek to determine if the file descriptor is seekable.
(In reply to comment #13) > (In reply to comment #12) > > The patch series I posted here > > (https://mail.gnome.org/archives/gvfs-list/2013-September/msg00002.html) should > > to take care of this issue. > > Use git-bz to upload the patches here instead. GNOME doesn't use mailing-lists > for patches, and what will come out of it is, very likely, for your patches to > be lost and forgotten. > > Add the bug URL in each one of your commits and run "git bz attach [commit > range]" OK, I wasn't aware of that. Thanks.
Thanks for the patches, they have been already committed by alexl yesterday.
Playing movies from the archives thru the fuse daemon works like charm for me with gvfs 1.16.3 without these patches. One from the tested movies is (packed to .zip, .tar.gz using the File Roller): http://mirror.bigbuckbunny.de/peach/bigbuckbunny_movies/big_buck_bunny_1080p_stereo.ogg (909 MB) So it looks like to be fixed. Do you facing with this issue on newer versions of gvfs?
Ahhh, when I start Totem like: totem /run/user/1000/gvfs/archive\:host\=file%253A%252F%252F%252Fhome%252Foholy%252Fmovie.ogg.tar.gz/movie.ogg ...video location in Totem is: archive://file%253A%252F%252F%252Fhome%252Foholy%252Fmovie.ogg.tar.gz/movie.ogg ...how to force him to play it thru the fuse backend?
You can't without modifying the code I'm afraid.
Ok, successfully tested using mplayer. It works only with attached patches, so thanks for them.
the problem is still present on Fedora 20 > gst-launch playbin2 uri="file:///run/user/1000/gvfs/archive:host=file%253A%252F%252F%252Fhome%252Fuser%252Fmount.zip%252Fmovie.mp4" Setting pipeline to PAUSED ... ERROR: Pipeline doesn't want to pause. ERROR: from element /GstURIDecodeBin:uridecodebin0/GstFileSrc:source: Resource not found. Additional debug info: gstfilesrc.c(1042): gst_file_src_start (): /GstPlayBin2:playbin20/GstURIDecodeBin:uridecodebin0/GstFileSrc:source: No such file "/run/user/1000/gvfs/archive:host=file%253A%252F%252F%252Fhome%252Fuser%252Fmount.zip%252Fmovie.mp4" Setting pipeline to NULL ... Freeing pipeline ... > gst-launch playbin2 uri="archive://file%253A%252F%252F%252Fhome%252Fuser%252Fmount.zip%252Fmovie.mp4" Setting pipeline to PAUSED ... Pipeline is PREROLLING ... ERROR: from element /GstPlayBin2:playbin20/GstURIDecodeBin:uridecodebin0/GstDecodeBin2:decodebin20/GstQTDemux:qtdemux0: GStreamer encountered a general stream error. Additional debug info: qtdemux.c(4435): gst_qtdemux_chain (): /GstPlayBin2:playbin20/GstURIDecodeBin:uridecodebin0/GstDecodeBin2:decodebin20/GstQTDemux:qtdemux0: no 'moov' atom within the first 10 MB ERROR: pipeline doesn't want to preroll. Setting pipeline to NULL ... Freeing pipeline ... > gst-launch --version gst-launch-0.10 version 0.10.36 GStreamer 0.10.36 http://download.fedora.redhat.com/fedora
I can't reproduce this on Fedora 20, nor on any of my other machines. Your first example doesn't play because the URL is wrong. It needs to be correctly URL-encoded: "file:///run/user/1000/gvfs/archive%3Ahost%3Dfile%25253A%25252F%25252F%25252Fhome%25252Fuser%25252Fmount.zip/movie.mp4" The second example is not using the fuse backend, afaik, just the archive backend directly. It is possible that this is failing because decoding this video requires seeking which is not supported by the archive backend. Can you upload this archive somewhere so that I can test it? Feel free to send a link directly to my email address, rosslagerwall@gmail.com. Thanks
I sent the video to rosslagerwall@gmail.com
Thanks. As I suspected, the problem is that playing this particular video requires seeking, which is not supported by the archive backend. It works for other videos because they don't require seeking to be played. I'm going to close this again since it is different from the original bug, and generally seeking in a compressed archive is difficult. There is bug 711050 for this, but it is not clear whether it is possible to do it properly.