Totem-Gstreamer seek problems

Bug #231538 reported by rossom on 2008-05-18
60
This bug affects 6 people
Affects Status Importance Assigned to Milestone
GStreamer
Expired
Medium
gstreamer0.10 (Ubuntu)
Low
Unassigned

Bug Description

Binary package hint: totem-gstreamer

Ubuntu 8.04 64bit Release

Totem 2.22.1 with Gstreamer 0.10.18

When I open a video to play everything works fine. If I drag the seek bar to move to a different point in the video there is a slight problem. If, for example, I'm at 1:19 into the video and I click and hold and drag to seek to 1:59 the video seeks, but will seek to either where I started orginally or about 10 to 20 seconds earlier then the time I chose.

Doing some actual tests now.

Played an MPG file. At 0.01 I drag the seek bar to 0.41 and let go. The video resumes at 0.31.
Same video file. At 0.01 I drag the seek bar to 1:19 and let go. the video resumes at 0.57
Same video file. At 0.01 I drag the seek bar to 0.08 and let go. the video resumes at 0.06

Same problem with divx and wmv files.

I did find I don't seem to have a problem with the Xvid videos I tried.

My fix was simply

sudo apt-get remove totem-gstreamer

sudo apt-get install totem-xine

I'm still new to Linux so I wasn't sure what else to post that would be helpful so just let me know.

description: updated
rossom (matthew-gamemail) wrote :

My so called fix is not as good as I thought. With Totem-Xine I am unable to play movies on an SMB share.

Unless of course I found where the share is automatically mounted in the /home/.gvfs folder. However when I tried this I got even worse seek performance and then the videos stopped playing. Then I simply couldn't find the /home/.gvfs folder at all.

I haven't retried since I shutdown to see if the folder is back. The SMB problems are really annoying.

Munchkinguy (10068660) wrote :

I have been able to replicate this problem and am marking it as "Confirmed".

Changed in gstreamer0.10:
status: New → Confirmed
Sebastien Bacher (seb128) wrote :

do you get the issue on any video? could you try if that's still an issue in intrepid?

Changed in gstreamer0.10:
importance: Undecided → Low
status: Confirmed → Incomplete
Pedro Villavicencio (pedro) wrote :

We are closing this bug report because it lacks the information we need to investigate the problem, as described in the previous comments. Please reopen it if you can give us the missing information, and don't hesitate to submit bug reports in the future. To reopen the bug report you can click on the current status, under the Status column, and change the Status back to New. Thanks again!.

Changed in gstreamer0.10:
status: Incomplete → Invalid
Endolith (endolith) wrote :

Still an issue in Intrepid. Not sure about any type of video.

apienk (andrzej-pienkowski) wrote :

I can confirm the problem persists in Intrepid. I have tested seeking in totem using libgstreamer 0.10.21-4 with MPEG2, AVI (xvid), FLV, and OGG (Theora) files, and got the following results:

mpeg2: Seek doesn't work as expected. When the slider is moved and then released, it jumps backwards. The length of the jump is progressively bigger towards the end of the file. For 50-minute mpeg film it is impossible to seek to the last 10 minutes, because when slider is moved to the far right the clock shows about 41 minutes! Seeking with keyboard also is unusable, and quite crazy. In play mode, using single keypresses (right arrow) advances my 50-minute film by decreasing leaps up to about timecode 04:37, and then the behaviour reverses - each keypress actually moves the film backwards. When I press and hold the key, it ultimately starts to seek forward, but never reaches the end, because at 00:30 minutes or so the slider just starts to jump wildly back and forth. In pause mode seeking works, but also stops at 00:41, unable to reach the final 10 minutes of the file.

avi: Seek works reliably, with a small backjump of 2-3 seconds.

flv: Seek works reliably, with a small backjump of 1-2 seconds.

ogg: Seek works reliably to the very second.

Changed in gstreamer0.10:
status: Invalid → Confirmed
Sebastien Bacher (seb128) wrote :

could somebody having the issue send the bug to bugzilla.gnome.org where the people writting the software will read it?

Pedro Villavicencio (pedro) wrote :

Thanks for sent it to GNOME.

Changed in gstreamer0.10:
status: Confirmed → Triaged
Changed in gstreamer:
status: Unknown → New
Changed in gstreamer:
status: New → Incomplete

We were wondering if this is still an issue for you. Can you try with the latest Ubuntu release? Thanks in advance.

Changed in gstreamer0.10 (Ubuntu):
status: Triaged → Incomplete

No i have not this problem anymore even though I have not upgrade my ubuntu
to next version (i still have 8.10)
thank you the same

----- Original Message -----
From: "Martin Mai" <email address hidden>
To: <email address hidden>
Sent: Wednesday, December 16, 2009 5:48 PM
Subject: [Bug 231538] Re: Totem-Gstreamer seek problems

We were wondering if this is still an issue for you. Can you try with
the latest Ubuntu release? Thanks in advance.

** Changed in: gstreamer0.10 (Ubuntu)
       Status: Triaged => Incomplete

--
Totem-Gstreamer seek problems
https://bugs.launchpad.net/bugs/231538
You received this bug notification because you are a direct subscriber
of a duplicate bug.

Status in The GStreamer Multimedia Framework: Incomplete
Status in “gstreamer0.10” package in Ubuntu: Incomplete

Bug description:
Binary package hint: totem-gstreamer

Ubuntu 8.04 64bit Release

Totem 2.22.1 with Gstreamer 0.10.18

When I open a video to play everything works fine. If I drag the seek bar
to move to a different point in the video there is a slight problem. If,
for example, I'm at 1:19 into the video and I click and hold and drag to
seek to 1:59 the video seeks, but will seek to either where I started
orginally or about 10 to 20 seconds earlier then the time I chose.

Doing some actual tests now.

Played an MPG file. At 0.01 I drag the seek bar to 0.41 and let go. The
video resumes at 0.31.
Same video file. At 0.01 I drag the seek bar to 1:19 and let go. the video
resumes at 0.57
Same video file. At 0.01 I drag the seek bar to 0.08 and let go. the video
resumes at 0.06

Same problem with divx and wmv files.

I did find I don't seem to have a problem with the Xvid videos I tried.

My fix was simply

sudo apt-get remove totem-gstreamer

sudo apt-get install totem-xine

I'm still new to Linux so I wasn't sure what else to post that would be
helpful so just let me know.

To unsubscribe from this bug, go to:
https://bugs.launchpad.net/gstreamer/+bug/231538/+subscribe

__________ Information from ESET NOD32 Antivirus, version of virus signature
database 4693 (20091216) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

__________ Information from ESET NOD32 Antivirus, version of virus signature database 4694 (20091216) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

rossom (matthew-gamemail) wrote :

This is still an issue, but I have noticed some improvements. It only seems to affect a certain either file type or codec from the file type. Any suggestions on how I can get the most useful information on what makes this video type special? Basically a tool that can tell Codec, compressions, etc etc?

This is using Ubuntu 9.10 x64

Thanks. I posted your comment on the upstream bug.

Changed in gstreamer:
importance: Unknown → Medium
status: Incomplete → Expired
Munchkinguy (10068660) wrote :

Could you please explain why the bug is marked as incomplete? What further information needs to be provided?

Munchkinguy (10068660) wrote :

Because nobody has explained why the bug is "incomplete", I am marking it as "confirmed"

Changed in gstreamer0.10 (Ubuntu):
status: Incomplete → Confirmed
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.