[Milhouse]

Just to point out that you should be able to install the "Unofficial" OpenELEC repository from within the "Official" OpenELEC Repository: System -> Add-ons -> Get Add-ons -> OpenELEC Mediacenter OS Add-ons -> Add-on repository -> Unoficial OpenELEC Mediacenter OS Add-ons -> Install. Doesn't get much easier than that!

Hard to say what the problem is with iperf without a debug log, but maybe start a new thread if it's ongoing.

[allan87]

Hard to say what the problem is with iperf without a debug log, but maybe start a new thread if it's ongoing.

I have started a new thread here: http://forum.xbmc.org/showthread.php?tid...id=1663243

Respecting my specific buffering issue, I was able to substantially alleviate it by overclocking from the stock settings (which do the job on a wired connection) to 1000/500/500/6.

I suspect there is an interplay here, with buffer settings being required on this Pi (using a powerline network adapter), but certain buffer settings requiring more horsepower. My wired pi has no buffer settings in the user's advancedsettings file and it streams MPEG2 without issue.

[Handaloo]

I'm also experiencing some buffering issues with Gotham. I'm running Openelec 4.0 on a Dell Optiplex SFM box to an HP microserver through power line. Never had buffering issues at all with Frodo or any of the Gotham Betas, but since full release any 720p movies will pause to buffer at least 3 - 4 times per movie.

It has yo be a Gotham issue as it's the only change to my setup.

I'm afraid I'm not as technical as the guys discussing things in this thread, but I'm happy to provide any further information if required.

Thanks!

Handaloo

[GEEMac]

I pretty much gave up with Gotham for watching any streaming video.
There is a major issue in Gotham with the lack of buffering the video. In my case with my Verizon Fios speeds of 50/25 it is a disaster. and it shouldn't be. In Frodo you can see the video buffering while streaming and even in pause it kept buffering. Now when in pause it is just that || PAUSE ||

I even noticed that in quite a few streams the voice is running a slower pitch. I can't tell if the video is off along with the audio. It all seems lead back to an issue with the buffering since it sometimes corrects itself when it gets to a somewhat buffered point I have another post on the slow audio playback issue with no replies.

I got to the point that I don't even use XBMC that much at all anymore and went back to other methods such as VLC and my browsers for watching streams. In my case when the video stream gets to the point where it may need to buffer it just stops dead and does not buffer thus causing me to restart the video, head into task manager and kill XBMC since it locked up and in the worse case I have to reboot the computer. I have never had these issues in Frodo.

Speaking of Frodo. Is it possible to back up all my settings and then remove Gotham and use the backup in Frodo?
Apparently this issue is not going to be corrected since the March post. I have seen this issue on other forums and not a word from the Devs.

Don't get me wrong here. XBMC is a Great all around HTPC package, but as the old saying goes, "If it ain't broke, don't fix it" meaning if Frodo did not have a buffering issue. What was changed and or why did someone think the video buffering needed fixing in Gotham that now almost completely broke the buffering.
OK, I said my piece. I feel almost better now.

Thanks....

[DBMandrake]

Have a look at the setting readbufferfactor in advancedsettings.xml - if you increase that to a value between about 2.0 and 4.0 then most of the buffering issues that weren't there in Frodo will be avoided. (OpenElec and Raspbmc have both chosen to override this setting to 4.0 by default, but on other platforms the default is 1.0)

It seems that the throttling algorithm added in Gotham is perhaps Ill conceived and a high value for this setting effectively disables the changes that were introduced since Frodo. Try 4.0 and see if it helps. (I'm not seeing any of the problems I described in this thread even with a setting of 2.0)

http://wiki.xbmc.org/index.php?title=HOW...ideo_cache

By the way when paused the cache amount in the codec info page will not update like it did in Frodo but it WILL still actually keep downloading. (A network sniffer will confirm this) After un-pausing it takes at least 5 seconds for the cache figure to catch up to the real value. (If you watch carefully for that first five seconds it will suddenly jump to a much larger value)

[GEEMac]

Hi
I already tried that with the readbufferfactor. I started with 4.0 and reduced it to 1.2, 1.5, 2.0, 3.0 then back to 4.0.
It is still a mess.

On my Windows 7 Laptop (first mistake win 7) I foolishly removed Frodo and installed Gotham, second big mistake. I tried with various different streams and it won't even stream any video for more then 5-10 seconds now before it has to buffer.
The laptop will be an easy fix going back to Frodo since I did not put hours into setting XBMC up with skins and other items as I did with my main HTPC.
I should have gone by that saying I mentioned above. "If it ain't broke don't fix it".

I'm not messing with Gotham until the mess that was made is fixed. When I have time and hopefully I can pass some of the changes from Gotham over to Frodo, I'm pulling Gotham off the HTPC. At this point I can't even enjoy watching it. If its not the slowed audio issue as stated in one of my posts its dealing with this buffering issue.

Note to Devs....
Please look into what was messed with in Gotham that is now causing these issues with the buffer and create a update for it. There are other aspects of Gotham that are big improvements, its a shame that some of us have to go backwards or should I say regress.
Thanks.

[Ned Scott]

Don't get me wrong here. XBMC is a Great all around HTPC package, but as the old saying goes, "If it ain't broke, don't fix it" meaning if Frodo did not have a buffering issue. What was changed and or why did someone think the video buffering needed fixing in Gotham that now almost completely broke the buffering.
OK, I said my piece. I feel almost better now.

Note to Devs....
Please look into what was messed with in Gotham that is now causing these issues with the buffer and create a update for it. There are other aspects of Gotham that are big improvements, its a shame that some of us have to go backwards or should I say regress.

I can understand that you're frustrated, but that's a bad attitude to have, and an uninformed statement to make. Things change and get improved because there were things that were broken or needed to be improved. No one is just messing around in code just to stir it up.

Don't assume just because you and a few other users have an issue with buffering that there is some widespread regression. We did extensive testing with this. I pushed out a guide on how to use the new buffering settings and "pimped" it out to whoever was willing to try it. The majority of people I've heard from didn't have these issues. I'm not saying the issues don't exist. I believe that the problems you guys are having are real, but understand that for most people nothing is broken for buffering. There is no great outcry of injustice.

Things like buffering can be caused by countless reasons, and the worst thing you can do is just do a "me too" post when we don't even know if you're having the same issue that the OP of that thread is having. We need details on your situation, what you've tried, what is the content you are trying to stream, etc. Most importantly, get us a debug log (wiki). Things like this have a lot of variables involved, so in order to track down the issue we have to collect clues about those variables.

I get so burnt out on these forums asking people over and over about getting details, often just trying to get the very basics. I wish I could reproduce the issue easily, I wish I could at least tell you it's a known issue and that it's on someone's to-do list, but it's not always that easy.

[DBMandrake]

For what its worth Ned, I don't think GeeMac is seeing the same problem that I reported at the beginning of this thread. The simple reason is the problem I was seeing only occurs with a readbufferfactor of 1.0 - if I set it even as high as 2.0 the problem goes away.

I've been running with 2.0 for a couple of months now and have not seen any buffering issues that I could attribute to Gotham rather than just slow server speeds. I generally have very little if any buffering problems. If GeeMac sets it to 4.0 and it makes no difference, his problem is something else.

I agree, a me too post with no debugging details telling the devs to "look into it" is just not helpful, and implies that the devs know what the problem is and can reproduce it, and that even if they had an idea what it might be, that it was necessarily an easy fix when so much code has already changed and entire subsystems have been redesigned since then. (Making a simple reversion to remove some changes impossible)

The only way is forwards, which means doing actual debugging on the issue, whatever the issue might be. As its not the same issue I was seeing, I can't really be that helpful, and it might be better to start a new thread with at the very least a debug log and a thorough description of how to reproduce the problem to see if anyone else can reproduce it.

[fritsch]

I did not see a single Debug Log of GEEMac, might be I overlooked it in the wall of text.

[GEEMac]

Update:

**I tried a change to the advancedsettings.xml

<advancedsettings>
<network>
<buffermode>1</buffermode>
<cachemembuffersize>20971520</cachemembuffersize>
**<readbufferfactor>10</readbufferfactor>
</network>
</advancedsettings>


The read buffer may be overkill at 10, but on my laptop (win7) it made a big difference. Only two buffer events in 15 minutes on a live stream compared to trying to buffer every 5-10 seconds.
Not sure if it is my imagination or if it is actually working on the laptop. The laptop; Acer, single core Intel and 3g of ram running at 64bit.
As for my main system HTPC; see below, It seemed to help a bit. It is actually buffering and the stream is playing a bit longer.

No need to answer since it is off the buffer subject but under the same xml file. Just was wondering.
These two lines, do they have anything to do with connecting to a stream (first two lines) and the timeout if it does not connect (second two lines)?
I would like to set the connect time short if the stream is not there and also kill that lengthy WAITING time which sometimes never recovers without a restart.
<curlclienttimeout>10</curlclienttimeout>
<curllowspeedtime>10</curllowspeedtime>

<playlistretries>10</playlistretries>
<playlisttimeout>20</playlisttimeout>

[asiantuntija]

I can confirm that there's serious problems with xbmc gotham buffering. Problems were not present in test versions between Frodo and Gotham, but all Gothan versions I was able to compile with latest xbmcbuntu fail.

Like other have told in this and couple other threads issue is buffer not filling fast enough (regardless new advancedsettings buffer tweaks) and not filling at all when playback is paused. Which may actually not be true, looking at network utilization xbmc is indeed buffering to some extent, but counter shown in diagnostics screen when pressing O is not increasing at all. Could it be that playback part is looking at same value that O diag screen shows and incorrectly forcing pause when it runs to zero while there's actually still plenty of data left in buffer?

So after buffer runs out, playback is paused, buffer is stuck at near zero but network traffic continues. Next I seek back, seek forward and suddenly O shows there's data on buffer (proper value is read from somewhere) and playback continues. Yet buffer doesn't increase at proper rate and quickly runs again to zero requiring same seek back, seek forward cycle. Content is over http and same computer is capable of downloading exactly same file over http at 100Mbit/s (ethernet interface is 100Mbit) when testing with wget while xbmc struggles with 15Mbit/s rates with low CPU load. Problem does not occur with very low bitrate streams which do get enough buffering.

Running xbmcbuntu 13.0 x64 with all available updates to OS and xbmc installed. Also tried with 13.2-beta1, didn't help. Hardware Intel Atom D510 with Nvidia ION2, 2GB RAM and 60GB SSD. Since logs don't show anything unusual (dangerous statement - I know, will provide logs but need to scrub then first due passwords, urls, etc. shown) when problem occurs and it seems devs are unable to reproduce problem I guess maybe there's need to film clip and posting to youtube showing that problem is real? I'll try to find some time to create proper test scenario using free content and fresh xbmcbuntu install with all updates installed. I've done fresh reinstall already and it didn't help but just to be sure everything is repeatable.

[Zokkel]

Having the same problem as 'asiantuntija' describes.

I must say that in version 13.0 the following advanced settings file worked most of the time:

PHP Code:

<advancedsettings>
 <network>
  <buffermode>1</buffermode>
  <cachemembuffersize>104857600</cachemembuffersize>
  <readbufferfactor>2.0</readbufferfactor>
 </network>
</advancedsettings> 


But that doesn't seem to do anything from version 13.1 till version 13.2 beta 3. So I disabled it and created two log files (V13.2 beta 3):

One where xbmc just buffers and continues playing:
http://xbmclogs.com/show.php?id=266035

One where xbmc buffers and stops playing:
http://xbmclogs.com/show.php?id=266037

Hardware specs in signature. Any help would be much appreciated. This is a very annoying bug...
Version 13.0 with the advanced setting file works most of the time, but it's not ideal...

[asiantuntija]

Forced 13.0 quantal packages to trusty based xbmcbuntu with settings from Zokkel's advancedsettings and it works far better. Still stops buffering while paused (network traffic shows it's actually buffering but buffered data is not used?), at least those parameters work now and buffer is large enough for smooth playback in most conditions.

edit: Latest build 14.0~git20140827.0200-afdbb56-0trusty_amd64 behaves slightly differently than 13.1 and 13.2 (for example 13.2~git20140817.2155-final-0trusty). Buffer still runs empty too quickly on stats shown after pressing "O", but playback no longer stops unless buffer actually is empty. Improvement but I don't think bug has been fixed, just masked by some other change.

[psilo]

Just wanted to say "me too". Buffering state stays @ 0% when stopped/paused and cache does not grow. Strangely, it was buffering while paused before I started playing around with advancedsettings.xml. Attempted all matter of setting combinations to no avail.

Anyone found a work around for this?

[ironic_monkey]

it is just the gui not being updated. it's caching just fine. i'm more worried about the 100% spin of a core during buffering..