subtitle file not loaded for files on smb share

[j^]

Binary package hint: totem

opening an avi with an srt file on a samba server, totem does not find the srt file.
eather totem should be fixed to also check for srt files on smb shares or
nautilus should not hand smb://.../Movie.avi to totem but the new gvfs path ~/.gvfs/share/.../Movie.avi

opening the movie via the fuse gvfs path, the subtitle works.

[Marcus Asshauer (mcas)]

Thank you for reporting this bug. Please add your ubuntu version and the output of "apt-cache policy totem".

[j^ (j)]

that would be ubuntu/hardy, the first one to have gvfs/gio/fuse support in nautilus.

totem:
  Installed: 2.22.0-0ubuntu3
  Candidate: 2.22.0-0ubuntu3
  Version table:
 *** 2.22.0-0ubuntu3 0
        500 http://archive.ubuntu.com hardy/main Packages
        100 /var/lib/dpkg/status

[FaberfoX (faberfox)]

I can confirm this, running hardy beta with up to date patches, totem freezes when .srt is present.

totem:
  Installed: 2.22.0-0ubuntu3
  Candidate: 2.22.0-0ubuntu3
  Version table:
 *** 2.22.0-0ubuntu3 0
        500 http://espelhos.edugraf.ufsc.br hardy/main Packages
        100 /var/lib/dpkg/status

Everything is right when running from fuse path.

[Adolfo González Blázquez (infinito)]

Loading subtitles makes Totem hangs from a smb and a sftp share here. Very big regression!

[Adolfo González Blázquez (infinito)]

In fact, If you wait around five minutes or so, the film starts playing with the subtitles loaded correctly.
If no subtitles available, the film just loads in 2 seconds.

While totem seems to hang, it looks like it's cacheing the film, 'cause there's too much network activity, so, maybe is this a cache loading problem?

[Kamil Páral (kamil.paral)]

I confirm this. The totem "freezes" on smb share when subtitles are present (actually, it doesn't freeze, it just downloads the whole film in advance, which is bad). It happens only sometimes, I think it's connected with public/non-public shares somehow. Using the ~/.gvfs directory works fine. This is a bug in totem and also a bug in nautilus (nautilus should pass another path, totem should not buffer all).

[A. Walton (awalton)]

Nautilus will only pass a path if the application asks for a path in its .desktop file. Unfortunately, applications that haven't been ported to GIO/GVFS yet will often request URIs (assuming the VFS in use is still GnomeVFS, or in many cases just developer's copy and paste errors), which leads to this misbehavior. This is not a bug at all in Nautilus, but in Totem.

Simply changing the Exec key in Totem's .desktop file to %F instead of %U will allow Nautilus to pass it a path instead.

[Kamil Páral (kamil.paral)]

Yes, you are right! Changing %U to %F really fixes this problem and totem is using gvfs instead.

I have created a patch to totem.desktop file, please send it to hardy-updates.

[j^ (j)]

wow thats an easy fix, any chance to get this in hardy-updates?

[Adolfo González Blázquez (infinito)]

Wow, that was easy, why is not on updates?

[Sebastien Bacher (seb128)]

the change is not right, totem uses gnome-vfs and access smb directly so there is no need to force the fuse use, especially than not all users are using the fuse integration

[Kamil Páral (kamil.paral)]

I don't know whether some ubuntu users may choose not use the gvfs, but if not, this change can stay ubuntu-specific instead of going to upstream.

What is the correct solution then? I suppose fix the bug in totem in upstream. But that means waiting a long time, and probably not having this problem fixed until Intrepid.

[A. Walton (awalton)]

Sebastien is right, and it's the unfortunate downside of using GVFS-Fuse. It's not perfect and not everyone is using it. And of course Totem in Hardy is still using the old GnomeVFS so it can't make use of GIO/GVFS URIs, which makes life really hard on its users with both Nautilus and the file chooser passing it URIs. The method I mentioned is merely a workaround, and it's probably not best for general consumption.

Totem upstream is already using GIO, which is the correct solution here, but it won't be ready for release until Intrepid. Not sure what we can do at this point to make life easier for Hardy users though.

[Sebastien Bacher (seb128)]

the issue should be fixed in intrepid, feel free to reopen if you still get the bug though

[Alex Stanev (realender)]

The issue still remains in Intrepid (up to date beta, "4 days to go").
[When/If] subtitle load fuzzy matching by name is implemented in Totem, I believe it will not be practical to check for every possible subtitle file via GnomeVFS.
Nowadays many users store their video/audio on separate storage device, accessed via SMB. So I belive it will be much easier for them all this to work out-of-the-box.

[Sebastien Bacher (seb128)]

don't reopen closed bugs only because you have a similar issue, the intrepid version doesn't use gnomevfs