Created attachment 73903 [details]
Result of player media from share

This is seriously crippling for me. 
And it's now confirmed to be the same with the totem version that ships with GNOME 2.14. One of the updates must have broken it, because when I used GNOME 2.14 it did work.

Could you run totem like this:

 $ export GST_DEBUG_NO_COLOR=1
 $ GST_DEBUG=gnomevfssrc:5,totem:5  totem smb://..rest.of.your.uri  2>dbg.log
  .. wait until the error comes up, then close totem ...
 $ bzip2 dbg.log

and attach the dbg.log.bz2 please?

Created attachment 74239 [details]
Debug information

Attached output from:

finalbeta@finalbeta-laptop:~$ export GST_DEBUG_NO_COLOR=1
finalbeta@finalbeta-laptop:~$ GST_DEBUG=gnomevfssrc:5,totem:5  totem 'smb://finalbeta@192.168.20.2/finalbeta/hdb5/episode.avi' 2>dbg.log
finalbeta@finalbeta-laptop:~$ bzip2 dbg.log

Odd, gnome_vfs_src_start() is called 4 times within 2 seconds, that doesn't look right.

Do you get the same issue with

 $ gst-launch-0.10 playbin uri="smb://..."

?

If yes, could you create another (full) log like this

 $ export GST_DEBUG_NO_COLOR=1
 $ GST_DEBUG=*:5 gst-launch-0.10 playbin uri="smb://...."  2>dbg.log
 $ bzip2 dbg.log

please?

Created attachment 74247 [details]
GST_DEBUG=*:5 gst-launch-0.10 playbin uri="smb://finalbeta@192....

finalbeta@finalbeta-laptop:~$ gst-launch-0.10 playbin uri="smb://finalbeta@192.168.20.2/finalbeta/hdb5/Series/Dark Angel/Season1/S1 - E01 - Pilot.avi"
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
ERROR: from element /playbin0/source: Could not read from resource.
Additional debug info:
gstgnomevfssrc.c(692): gst_gnome_vfs_src_create (): /playbin0/source:
Failed to read data: Internal error
ERROR: pipeline doesn't want to preroll.
Setting pipeline to NULL ...
FREEING pipeline ...


Attached the output from :

finalbeta@finalbeta-laptop:~$ export GST_DEBUG_NO_COLOR=1
finalbeta@finalbeta-laptop:~$ GST_DEBUG=*:5 gst-launch-0.10 playbin uri="smb://finalbeta@192.168.20.2/finalbeta/hdb5/Series/Dark Angel/Season1/S1 - E01 - Pilot.avi" 2>dbg.log
ERROR: from element /playbin0/source: Could not read from resource.
Additional debug info:
gstgnomevfssrc.c(692): gst_gnome_vfs_src_create (): /playbin0/source:
Failed to read data: Internal error
finalbeta@finalbeta-laptop:~$ bzip2 dbg.log

Created attachment 74721 [details]
debug info from gst-launch

Here's another debug log, in case this helps. Please let me know if there's anything else that I can do to help debug this - It'd be a shame if this didn't get fixed in time for Ubuntu Edgy. 

greg@lappy486:~$ export GST_DEBUG_NO_COLOR=1
greg@lappy486:~$ GST_DEBUG=*:5 gst-launch-0.10 playbin uri="smb://nopants/drop/test.avi" 2>gst-debug.log
ERROR: from element /playbin0/source: Could not read from resource.
Additional debug info:
gstgnomevfssrc.c(692): gst_gnome_vfs_src_create (): /playbin0/source:
Failed to read data: Internal error
greg@lappy486:~$ bzip2 gst-debug.log

Versions:
libgstreamer0.10-0 = 0.10.10-1ubuntu2
totem-gstreamer = 2.16.2-0ubuntu1

Confirmed on a fresh ubuntu edgy install.

Same problem on FC6:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=212311

gnomevfssrc relies on gnome-vfs to work correctly in the first place, but I have serious doubts that it does on Edgy.  It seems to have really bad problems with smb URIs.

(In reply to comment #5)
> Odd, gnome_vfs_src_start() is called 4 times within 2 seconds, that doesn't
> look right.
>
... 

If I compare the debug output (with gnomevfssrc:5) on Dapper vs. Edgy, the only difference (aside from the error occuring) is that the Edgy side has two extra lines like:

 ... gst_gnome_vfs_src_check_get_range:<source> undecided about URI 'smb://...', let base class handle it

> If I compare the debug output (with gnomevfssrc:5) on Dapper vs. Edgy, the only
> difference (aside from the error occuring) is that the Edgy side has two extra
> lines like:
> 
>  ... gst_gnome_vfs_src_check_get_range:<source> undecided about URI
> 'smb://...', let base class handle it

This shouldn't make a difference in this case (I think). At some point we introduced some code to white-list and black-list certain protocols/URIs for random access (get_range), to keep the base class from unnecessarily doing a start()/stop() cycle just to check whether random access is possible in this case. The 'undecided' code path should be the one that was always used before AFAIK.

This regression is not caused by GStreamer.  I just built core and base plugins as shipped by Edgy on Dapper, which works like a charm.  I suggest looking at libsmbclient or gnome-vfs next.

Here is a trivial python program, triggering the problem and not using GStreamer at all:

import sys, threading
h = gnomevfs.open (sys.argv[1], gnomevfs.OPEN_READ)
class T (threading.Thread):
    def run (self):
        h.read (4096)
        print "Success!"
t = T ()
t.start ()
t.join ()

Calling this with a smb:// URI raises "InternalError: Internal error" on read.  These are basically the steps that GStreamer's gnomevfssrc performs (leaving out getting of the file info and the no-op seek).  In gnomevfssrc, the vfs open is done in the "start" vfunc, which is called from the main thread.  Data is read in the "create" vfunc, called from the streaming thread.

If using gnome-vfs that way is supposed to work, the regression is there (it's just gnomevfssrc that triggers it).  Otherwise, gnomevfssrc was broken _all the time_, it's just that the new gnome-vfs shows it.

Digging a bit in gnome-vfs shows that the internal error is generated in daemon/daemon-connection.c:connection_handle_read (line 778).  The internal handle is not associated with the connection that the read () is coming through.  Apparently the client side starts another connection to the daemon for the read () because it is done in another thread.

SMB is the only affected method because it is the only one that is run in the daemon at all (using the [daemon]-option in the module configuration).

I need to investigate further to find out if this is really supposed to be like that, meaning applications are supposed to call vfs functions only from one thread (and it only worked using bonobo by chance).  Otherwise, it is a regression introduced with replacing bonobo usage by DBus.  In that case, either the client side should reuse the connection for other threads or the daemon has to try to look at other connections if the handle is not found.

that looks like the same issue than bug #351322

A GnomeVFS(Method)Handle given out for the daemon method is only useable in the thread that created it.  This seems to be the whole problem, I'm pretty confident that this is unintended.  I think it makes sense to change the summary to reflect that (sth. like "Daemon method handles only useable in one thread").

Bug #351322 looks indeed like a duplicate (although I have no explanation for ftp failing).  This bug tells me that the issue is known since even longer.  Is there any reason the bugs are still in the UNCONFIRMED state?

As I mentioned in bug #351322, downgrading gnome-vfs back from a 2.16.x to a
2.14.x version solved the problem. (well at least for me it did). 

I can play mp3, ogg, wav.
I haven't tried avi or other video-formats but I'm convinced they'll play fine
as well.

Looks like this also causes Ubuntu bug
  https://launchpad.net/distros/ubuntu/+source/nautilus/+bug/67289
  ([Nautilus] SMB network browse failing [in Edgy])

While experimenting with possible solutions, I found that the problem stated in above downstream bug also went away.

Tino: Downgrading to 2.14 works, as the bug was introduced by the migration to DBus.

a patch has been commited to the gnome-vfs CVS for the smb browser bug

Indeed, it's supposed to be fixed on 2006-11-02:

        Allow operations on file handles that were created in another
        DaemonConnection. This can happen if another thread in the client
        than the one that called open does an operation.

Unfortunately, it does not work as advertised.  While it fixes the problem that Nautilus triggers, the issue outlined on this bug persists (the simple test program from comment #14, which replicates GStreamer's usage of gnome-vfs, still fails).

This is pretty serious, since it seems to break streaming media playback on all remote files accessed through gnome-vfs. I also think #351322 is describing the same issue as this bug.

Confirmed with Ubuntu Feisty.

Possible workaround: Use another music player. Rhytmbox seems to read SMB fine.

*** Bug 536949 has been marked as a duplicate of this bug. ***

The original reporter of http://bugs.debian.org/484703 claims this is fixed now, maybe that’s gst-plugins-base 0.10.20. Is it still happening for other people?

Hi, I just downloaded Ubuntu and I'm a previous Windows User. I am having problems with this issue and all that you've said is greek to me. Is there a certain attachment or plugin I need to resolve this issue? I'd like to be able to resolve this in the next few days. Thanks much! :)

Hi Heidi,

This is a bug tracker for persons with insight about the issue.

If you need help please try

http://www.ubuntuforums.org

https://answers.launchpad.net/ubuntu

gnome-vfs got deprecated in 2008.

gnome-vfs is not under active development anymore and had its last code changes
in 2011. Its codebase has been archived:
https://gitlab.gnome.org/Archive/gnome-vfs/commits/master

gio (in glib) and gvfs are its successors. See https://developer.gnome.org/gio/stable/ch33.html and https://people.gnome.org/~gicmo/gio-migration-guide/ for porting info.

Closing this report as WONTFIX as part of Bugzilla Housekeeping to reflect
reality. Feel free to open a task in GNOME Gitlab if the issue described in this task still applies to a recent + supported version of glib/gio/gvfs. Thanks!