totem isn't buffering correctly

Bug #108623 reported by zerwas on 2007-04-21
This bug affects 20 people
Affects Status Importance Assigned to Milestone
Won't Fix
totem (Ubuntu)
Ubuntu Desktop Bugs

Bug Description

Binary package hint: totem

Playing a video directly from the web often leads to the fact that it has to buffer every 2 seconds. The bandwith is not the problem.

Using Ubuntu 7.04 with GNOME totem 2.18.1

Sebastien Bacher (seb128) wrote :

Thank you for your bug. Do you use totem-gstreamer or totem-xine? What connection speed did you choose to the preferences? Could you give an URL example where it's happing? Does it stop reading while it's downloading?

Changed in totem:
assignee: nobody → desktop-bugs
importance: Undecided → Low
status: Unconfirmed → Needs Info
zerwas (zerwas) wrote :

Thank you for your answer.

I am using standard totem-gstreamer. No matter what connection speed i choose, it's every time the same. It stops while it's playing.

An example is

Cardy (andrei-bogomolov) wrote :

I confirm this bug in Feist. Gconf can change /apps/totem/network-buffer-threshold value. It should change buffering size. But it does not. Totem ignores network-buffer-threshold.

Sebastien Bacher (seb128) wrote :

The bug should be sent upstream by somebody getting it, the buffer works correctly on my desktop

Changed in totem:
status: Needs Info → Unconfirmed
Pedro Villavicencio (pedro) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better. This also works fine here, May you please try to reproduce your problem with our development version of Ubuntu the Gutsy Gibbon? You may grab a CD Image from here: thanks and we appreciate your help.

Changed in totem:
status: New → Incomplete
zerwas (zerwas) wrote :

Thank you for your answer Pedro Villavicencio.

This also happens on the latest updated Gutsy. Some videos are buffering every 10 seconds.

I took this testvideo:
It buffers every 9 seconds with the default setting /apps/totem/network-buffer-threshold set to 2.

If i set the network-buffer-threshold on anything greater than 3, it buffers to 40-80%, then it is displayed that the video is played, but nothing happens.

If you need any additional information to fix this please tell it.

Pedro Villavicencio (pedro) wrote :

That works fine here, as Sebastien already suggested someone getting the bug should send this upstream. thanks.

Changed in totem:
status: Incomplete → New
Bálint Magyar (balintm) wrote :

This is seemingly happening to me on Gutsy. No matter what I set my connection speed to, all embedded videos are unplayable unless I pause it and wait for it to buffer in the background.

Basilio Kublik (sourcercito) wrote :

Hi there
Thank you for taking the time to report this bug and helping to make Ubuntu better. You reported this bug a while ago and there hasn't been any activity in it recently. We were wondering is this still an issue for you? Can you try with the development version of Ubuntu, Hardy Heron?

Thanks in advance.

Changed in totem:
status: New → Incomplete
zerwas (zerwas) wrote :

Thanks for asking about Hardy. I tried it in Hardy Heron with the latest updates, but this issue still exists in the exact same behavior.

HaMF (hamfbohne) wrote :

I've got the same behaviour here
* Buffering every few seconds
* Setting apps/totem/network-buffer-threshold to 10 (or whatever >3) also causes that buffering fails and the playback does not start properly.

Imho Totem really needs a setting where you can adjust the buffersize (in MB oder in secs) manually; ideally just below the connection settings.
Btw. what effect has the setting "Connection Speed"? I did not notice any difference after setting it from "Intranet/Lan" to "14.4 Kbps Modem".

Maybe we are talking about two different things here.

* totem: does buffer correctly according to /apps/totem/network-buffer-threshold value.
Note: /apps/totem/buffer-size has to be set at least as high as network-buffer-treshold, otherwise it won't play, as some people have noted above. I don't know what other effects the second setting has.

[Also it has to be said that the buffering is not done very intelligently. Totem should adjust buffering based on download rate and stream length (if known). This would be more in line with the gnome principles because "it is the right thing to do". But this belongs to another bug.]

* totem-plugin-viewer: this is the totem firefox plugin. This is what the plugin calls itself in its "about" dialog. There is no such package name. I guess this is the totem-mozilla package.
Here, buffering does NOT respect the gconf settings, resulting in unplayable or frequently buffering streams.

zerwas, which program do you mean?
Sebastian, Pedro: can you reproduce my problems with totem-plugin-viewer? Maybe you have to throttle your available bandwidth for the test, because obviously if the download rate is greater than the bitrate of the stream, it will never buffer.

I'm adding totem-mozilla to affected packages until it becomes clear what we are talking about here.

Just noticed that the 'totem' source package provides the binary package 'totem-mozilla'. So ignore the last sentence of my previous comment.

siafok (wlar-siafok-wp) wrote :

I have the same problem like brothers and sisters above. It happens on Xubuntu HH. Maybe it is a Gstreamer problem? because I have the same issue with playing network streams on Rhythmbox. Interesting thing is that I dont have problems with playing YouTube’s videos with Totem plugin, I have issues only with audio streams. I have used rather mplayer but l wanted to try Gstreamer stuff. When I get more experiences with T & RB I will send here more useful informations about this bug.

Thank You all

madblueimp (madblueimp) wrote :

I can confirm this bug on Ubuntu Hardy Heron (64bit version).
Totem stops to buffer any two seconds when playing any of the trailers here:
The codec of those streams is H.264 / AVC.

I, too, can confirm this bug on Ubuntu Hardy Heron (64-bit version). When attempting to play any streaming video, Totem will only buffer a few seconds at a time, despite configuring the correct connection speed. There appears to be no way to alter this behavior. Any of the videos linked above produces this behavior.

Pedro Villavicencio (pedro) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better. The issue that you reported is one that should be reproducible with the live environment of the Desktop CD of the development release - Intrepid Ibex. It would help us greatly if you could test with it so we can work on getting it fixed in the next release of Ubuntu. You can find out more about the development release at . Thanks again and we appreciate your help.

Pedro Villavicencio (pedro) wrote :

Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information asked for. Thanks!.

Changed in totem:
status: Incomplete → Invalid

I can confirm this bug remains in Intrepid, upgraded today. Both totem and the totem firefox plugin don't buffer enough. This occurs regardless of the totem connection speed setting.

Changed in totem:
status: Invalid → Confirmed
Sebastien Bacher (seb128) wrote :

could somebody having the issue send it to

Changed in totem:
status: Confirmed → Incomplete
Dylan McCall (dylanmccall) wrote :

I also encounter frequent network buffer loss in Totem. There are some interesting numbers to be found with the system monitor's Network graph. If I pause playback (so that the buffer can catch up!), download appears to cease entirely. It may be a related issue; most applications buffer more aggressively, while Totem seems almost ignorant of the need.

The issue has been recently observed with the streams on this page:

For me, though, it truly happens Everywhere! My Internet connection is reasonably stable so Totem should be able to predict how much it must download, but it does not.

Marking bug as confirmed, because this makes at least three people reporting similar issues, and I have had the same issue myself on a number of different computers. If any information is needed, please advise.

Changed in totem:
status: Incomplete → Confirmed
Changed in totem:
status: Unknown → Confirmed
Changed in totem:
status: Confirmed → Triaged
Koopee (koopee1234) wrote :

I have also some nuisance with Totem and Youtube. It seems to me that Totem buffers the stream in real-time. If I pause the player, the stream ceases as Dylan said. And when I start again, the transfer rate tries to adjust to the player data consumption rate.

I would quess that If I pause the Youtube stream long enough, Youtube thinks that the connection is lost thus yielding Totem "Could not read from resource." error

Alexej D. (aschmir) wrote :

I am heaving exactly the same problem since about Gutsy. Now I'm using Intrepid (Gnome) and nothing changed. I've already tried players like Totem, Kaffeine and Vlc without success. I'm also using ndiswrapper for my netgear wlan pci card, maybe it has something to do with that?

svebert (ebert-s) wrote :

I can't increase my buffer to more than 5.5 seconds. (of course the other "buffer-size" is greater than "network-buffer-threshold".
Using totem/gstreamer. I did remove and reinstall all components (totem, gstreamer) but nothing helped.
When I set "network-buffer-threshold" to 5.5 the video is running, but totem buffers every, lets say 3 seconds. When I increase the buffer the film won't even start.

TBerk (bayareaberk-yahoo) wrote :

I'm somewhat new to these particulars but not computing (and Quicktime MOV files) in general.

I just added a request for info (w/ a little more end user explanation) over on .

What I'd like to see happen would be to be able to hit the PAUSE button and have the streaming continue on until either/or the whole file/whatever large chunk are on the local drive and can then be played without hickups.

With some direction, I'd be glad to run commands, test, report, whatever, as needed to help fix this.

Bottom line? Buffering is Broke.

Ubuntu 9.04
w32 codecs

TBerk (bayareaberk-yahoo) wrote :

I'd like to add:

Why, once the whole file has been streamed to completion, can't I hit PLAY and have it run from a local cache? What I experience is the whole file streams from the source all over again.


molecule-eye (niburu1) wrote :

I agree with TBerk that there should be a genuine 'pause' function, which currently acts like a 'stop' instead. One should be able to pause a movie at any point in the stream, have it continue buffering, and then be able to resume from the time paused.

Alternatively, but not as good, would be to be able to manually set a buffer size.

I'm running Jaunty and the latest version of totem in the repos.

Changed in totem:
status: Confirmed → Won't Fix
Andrew Henry (adhenry) wrote :

status confirmed, Won't fix !?!?

Can someone please investigate this issue further. Whether it is a Totem bug, Gnome bug, Gstreamer bug, we still need to know so that it can be pushed upstream. There is no indication at gnome bugs on the link at the top of the page or here, where the issue lies!

I am using Ubuntu 9.10 amd64 and STILL have this issue when playing Quicktime trailers or ISO/MKV files on my LAN (wireless).

VLC in Ubuntu 9.10 can play the same ISO over the wireless LAN with next to no buffering/stuttering issues, but Totem-gstreamer has major stuttering issues, probably due to the buffering problem mentioned in this bug.
Playing Quicktime trailers at Standard Def are OK, but play a 480p HD trailer and it can start stuttering after 10-20s or so, and when it gets to that point, it will just buffer continuously and play 1-2s clips until the buffer runs out and then re-buffer. Playing 720p is even worse.

I edited gconf-editor and set the buffer_size=5 and network_buffer_threshold=4 and this enabled 480p trailers to work, but when playing 720p the issue still exists. My settings did take effect, and now it buffers 5s and then when the buffer runs out it buffers another 4s and plays that but bever gets to the point where it can play without stopping to rebuffer.

I have a 24Mbit broadband connection and can download a steady 1.6MB/s without issue. I tested this in the morning on a weekday when Quicktime trailers is probably not so utilised.

I assume that the only way to fix this is to set buffer_size=30 seconds to cope with large amounts of video data when streaming. But the buffering in Totem is inherently broken and should be fixed. The way the two settings I mention above work appear to function as intended and expected (little hard to tell actually), but "the Totem pipe is too thin" is the feeling I get. How come VLC and Mplayer can buffer more and display less stuttering? Do they buffer in the background? buffer more? I have Totem set to connection_speed=11 by the way, for LAN.

One other broken function in Totem is that when I pause the Quicktime trailer (in the hope it will contine buffering the rest of the movie), it just stops downloading entirely.

That this problem has existed since Fesity is just amazing.

TBerk (bayareaberk-yahoo) wrote :

Just a follow up to my previous post; as you can see here in Bug Reporting and over on the Ubuntu Forums as well- this in not an isolated problem.

Perhaps those who are responsible for shagging these bugs might have the professional courtesy to recommend a competing app/util that will behave as expected/intended. That way we could retire Totem altogether.

I'm only _partly_ sarcastic...

molecule-eye (niburu1) wrote :

I'm sure the problem is prevalent. E.g., anyone using the Greasemonkey script "YouTube without Flash Auto" that plays YouTube content in totem rather than a Flash container will have experience this bug when playing back HD videos. And that script has been installed 21,966 times as of this date, so there must be quite a few users experiencing this bug!

The script can be found at

Rajinder Sandhu (sandy744) wrote :

so the problem lies with Totem buffering as i was under the impression that because I am downloading with Deluge this problem is coming ...breaking of internet radio station even changing many connection speeds did not help....raised the bug but no use refer bug # 500918 , Whereas I am using ubuntu 9.10 and 10.04 both....... facing same problem....
here is the link of my bug
Rajinder Sandhu

floid (jkanowitz) wrote :

Observed annoying with totem-gstreamer 2.28.2-0ubuntu3, whether in the browser plugin or natively in Totem. I haven't fiddled with any of the gconf settings, I did go in and tell Totem I have "1.5Mbps T1/Intranet/LAN" (which is true, 1.5mbit/s AT&T DSL - though that does mean it craps out just shy of a full 1.5mbits after PPP and line overhead). I could go in and poke at it, but I shouldn't really have to, right?

More annoying is the failure to cache, combined with a failure to seek properly [either refuses to seek back at all or jumps back to 0:00], which I've been hunting for the (surely-existing) bug for.

Seen with and other sample content on that site if anyone's looking for more test cases.

@#29: mplayer has been the de-facto I-just-want-it-to-work-on-UNIX player for a while (and still has major performance advantages on sub-GHz systems), but gstreamer and Totem are supposed to offer GNOME the conveniences DirectShow and Quicktime do for the Other Major Platforms. So it'd be nice if they actually functioned properly.

mwm (mwm) wrote :

I'm waiting for totem to have this fixed for years!

I stream (wirelessly) videos all the time from my home-server on a LAN network and on HD content, I'd love to pause and see totem keep buffering the video (just like YouTube does).

Most of the time (with HD videos) I have to copy some GBs to my hard-drive, wait for it it to download the whole thing and then watch it.

That would be great if there was an input field on the preferences to set the stream-buffer value on non-local files.

Also, the network-buffer-threshold isn't for this. It states on the "Long description" » "Amount of data to buffer for network streams before starting to display the stream (in seconds)".

It's different. It's some kind of unit that defines how much data it has to buffer before auto-start playing.

michael ansey (der-brain) wrote :

Ubuntu 10.04 Lucid Lynx 64 bit

Fucking Bug still exist!


tekstr1der (tekstr1der) wrote :

This bug is still present as described by mWm above. Local network (wireless-N) playback results in repeated stuttering. Is there any way to modify the buffer of Totem with gstreamer on Ubuntu lucid 10.04 x64? The upstream bug is marked "wont-fix". Should a new bug be filed for this issue, or can the bug be re-opened?

jefdebruges (jefdebruges) wrote :

This is unbelievable. Other OS's can do this correctly for over 10 years now. Wether it's Totem or Ubuntu, it's hilarious and lots more annoying than everything combined in the main competing OS linux lovers love to bash. Get it fixed!

anezch (anezch) wrote :

Amazing! This bug still exists on Lucid and last status is a 'Wont Fix'. The workaround is awkward and not well documented.
Well, as TBerk wrote on 2009-11-18, I have a feeling that Totem will be replaced in future. I mean it's unbelievable that this bug's life spans over several releases. Either fix it or remove the streaming capabilities from it, so we can decide whether we should keep it or throw it away and use another player.

David Ayers (ayers) wrote :

The upstream bug was marked won't fix because it was reported against a backend which has been removed. The last comment also indicates that a new bug should be filed with new gstreamer backend. I have tried searching through the gstreamer bugs:

and I see a lot of buffer related bugs that may or may not be related. What also isn't clear is whether this particular bug should be reported against gstreamer or not since it's unclear whether the problem is within gstreamer or in totem's usage there of.

It would be great if someone with more knowledge of the related components could either nail this down or tell us users how we can help nail it down. It should be fairly easy to test this by using low bandwidth connections (or saturating bandwidth with other downloads).

c (clayton-spicer) wrote :

I get the same thing with every backend. It's ridiculous that i can actually stream videos more reliably over 3G on my phone than using totem on an 8mbit broadband connection (no joke). Seems like fixing this isn't a priority for anyone either considering this problem still persists after more than 3 years. No idea what 'triage' refers to but if it's changing the network settings that does nothing for me. Tried network-buffer-threshold at 1, 2, 3, 4, 5, 10, 20, 50, 100, 999, no effect. Didn't even have a 'buffer-size' setting but tried adding one at various levels, no effect. However there is good news; TBerk's fix - using a competing utility - works perfectly. By abandoning totem altogether and using gecko-mediaplayer plugin with mplayer, streaming works flawlessly, as it should do, and does everywhere else, including buffering on pause, intelligent starting, et c. Why does gnome default to totem and its browser plugin over gnome-mplayer and its plugin? Not sure who to ask about this but it seems like the switch should be made.

tschinke (schinke) wrote :

Please just fix this. Can't watch any streamed videos (e.g. Quicktime movie trailer *.qtl) due to this buffering issues.

tschinke (schinke) wrote :

I just upgraded an older ubuntu version to the current 10.04 and there I can play the *.qtl files properly. You can pause the playback and it will preload the movie just like the typical youtube flashplayer. It works for me now as expected.

Changed in totem:
importance: Unknown → Medium
Gordon Dracup (gordon-dracup) wrote :

I am having the same problem with UBUNTU 10.10. Audio stream cuts out whether the asx stream is played in Firefox, Chrome, Totem or Rythymbox.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Related questions

Remote bug watches

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