[allan87]

I have had local buffering enabled in advancedsettings throughout. I can't remember the buffer size at the moment - I think it is really large - 50MB - but not positive. For sure, buffermode is set to 1 and readbufferfactor is set to 4.0.

There's more to it, though. I am not currently using wifi. I fixed the problem with a D-Link PowerLine Network Adapter — this worked fine for months, but the rebuffering problem reemerged a few weeks ago. The PowerLine Network Adapter should have ample bandwidth for this purpose. It's supposed to be 500 Mb/sec.That's way faster than the ethernet port on the Pi.

[DBMandrake]

Claimed speeds and actual speeds may not live in the same universe. Seriously. In tech support I used to do I've seen plenty of 200Mb+ power line adaptors that can't even achieve 50Mbits from one end of a moderate size house to the other but can achieve their full speed when plugged in a bit closer to each other.

What you have to realise is that power line adaptors are still basically wireless (RF) technology that transmit their RF signals through the power lines rather than through the air using antennas, but otherwise the technology is very similar to wifi.

You really need to test the actual network performance between the RPi and your server otherwise everything is guesswork, so I'd suggest you run some throughput tests using iperf. To test in the right direction (server to RPi) run an iperf server on the RPi and an iperf client on your server.

To get buffering free playback your network thoughput needs to be greater than the average bit rate if you use a very large buffer, or greater than the PEAK bit rate (which can be much higher) if you use a small or no buffer.

Run some iperf tests with your power line adaptor, wireless client if you feel like it, and a direct hardwired Ethernet connection, and post the results here. I think you'll find the results of those tests will speak for themselves though. As I said, if the RPi can stream perfectly with an actual hardwired connection then it is the performance of the wireless/powerline adaptors that is marginal.

Some protocols as not as efficient as others which is why it might work without buffering on one but not another with the same marginal network performance. For example NFS will work better than SMB if network performance is barely fast enough.

[allan87]

Claimed speeds and actual speeds may not live in the same universe.

I'm aware. I initially had the two adapters farther apart, and it did not alleviate the problem. Moving them closer together (about 15 feet apart, on the same circuit in the same room) fixed it, and the solution worked fine for months. I am also mindful of the fact that the powerline adapter doesn't have to be in the same universe as 500Mbps. 25 would probably do the job (~4GB for a half hour program)

In any event, I will test with the macbook, plugged into the powerline adapter. Using the Pi for iperf tests will not accurately demonstrate the real network speed, as the Pi is involved in the issue. It will also not reflect the full powerline adapter speed if it is fast, due to known bottlenecks in the Pi's ethernet implementation.

[DBMandrake]

Let me get this straight. You're having problems with video buffering on the RPi, but only when its going through your power line adaptor or wireless adaptor - when you use a hardwired Ethernet connection its fine.

I suggest that you run some iperf tests to compare the difference in network throughput in those three different situations to give us an idea of what the difference is, but you decide that running the test on the RPi isn't a valid test and will run it only on a Macbook - a machine that is dozens of times more powerful and has a gigabit ethernet adaptor instead of 100Mbit ?

I'm not trying to be funny here, but if you don't test the throughput TO the RPi you will never get to the bottom of the issue. By all means test the performance with your Macbook as well, that will provide extra useful information to compare with the RPi, but alone it will not answer the question.

It's the RPi that you're trying to stream video to so its the RPi that you must test to find out what network throughput you are achieving to IT.

The fact that the RPi's Ethernet implementation isn't the best is well known - I've been doing my own testing on it recently and find that with the CPU busy also rendering high bitrate video I only see a maximum of around 60Mbps compared to 94Mbps when the CPU is idle. I've also been unable to stream any video with a bitrate higher than 40Mbps without pauses despite the above 60Mbps figure. (The CPU is completely pegged at 100% even at 40Mbps, with 40% of that in kernel IO and 60% in xbmc.bin)

At the end of the day though you have to accept that even if another device can stream ok over the powerline adaptor, if the RPi is working fine on a hardwired connection but not through the powerline adaptor SOMETHING external to the RPi is reducing network performance when it is not directly connected. You need to find what and why if you want to fix it and continue to use the RPi for your purposes.

[allan87]

I appreciate your point and understand that there is information to be gained from doing a test via the Pi.

My only point was in response to your apparent focus on the capability of the powerline adapter. Testing the capability of the powerline adapter with the Pi will not be informative. I think it makes sense to provide results for both scenarios.

[allan87]

Well, iperf doesn't seem to be installed under openelec and installing the iperf add-on from the openelec repository failed, so I was unable to do iperf tests from the pi.

I was able to do LAN speed tests on my mac, however.
65-70 Mbps: powerline adapter
70-75 Mbps: macbook internal wifi
over 400 Mbps: Wired LAN

If someone can help with the iperf issue, I'll give it another shot. Again, however, the mac tests still suggest there is plenty on bandwidth available to the pi.

[Milhouse]

How did the iperf install fail? Can you upload a debug log of the problem? What build is this? Presumably you're installing iperf from the unofficial repository. If you've installed the iperf binary but it doesn't execute (no execute permission) then just reboot - it's a known issue with add-ons and permissions will be correctly applied during the next boot.

[allan87]

> How did the iperf install fail?
A "Downloading 0%" popup appeared for an instant before disappearing. Nothing was installed.
> Can you upload a debug log of the problem?
Can't until this evening. Inclined to install the iperf binary instead, if that can be done in openelec.
> What build is this?
Your 0320b
> Presumably you're installing iperf from the unofficial repository.
Yes

Is there a way to install the iperf binary in openelec?

[DBMandrake]

Good luck trying to install iperf manually on OpenElec - it's locked down as tight as a drum. I feel your pain.

I'm sure its possible but I gave up after half an hour of wasted time. Among the problems were that the required dynamic libraries aren't present on the system, (so copying the binary from elsewhere won't work) and you can't easily install them. (Read only ramdisk filesystem for most of the system directories) I did eventually get iperf installed by installing the unofficial repository, when I eventually managed to track down a link to it from some obscure forum post somewhere. (No obvious link to it on the website that I could find) Not user-friendly at all even for a long time Linux user, partly due to the highly non-standard filesystem layout.

Sure makes me glad I run Raspbmc - 'sudo apt-get install iperf' and 20 seconds later I have iperf installed and working...OpenElec is very much a locked down "appliance" whereas Raspbmc is more of a cut down Raspbian Linux distro optimised for XBMC.

[allan87]

I found the zip file here: http://webcache.googleusercontent.com/se...ing.iperf/

If the zip doesn't install, will it work if I just expand it and move it into /storage/.xbmc/addons? I'm guessing that more is required.

[DBMandrake]

I can't speak for that one but I think this is the one I used: (I deleted my test OpenElec install after I became fed up with it)

http://unofficial.addon.pro/

Download the bottom RPi link which is repository.unofficial.addon.pro-3.0.0.zip. Copy that onto your Pi somehow then use the normal XBMC "install add-on from zip file" process to install that repo. After you do that you'll find that you can install iperf from that repo as if it was an add-on and it will then exist in the correct location on the filesystem so that you can run it from SSH. Weird system huh...(give me apt-get any day)

[allan87]

I have the repo installed. Installing iperf from the rep failed. That's why I am looking for alternatives.

The zip file IS at http://unofficial.addon.pro/, but you can only see the directory with the link to network.testing.iperf-4.1.0.zip in the google webcache.

[DBMandrake]

I know very little about OpenElec unfortunately so I'd suggest you ask for help with getting iperf installed on the OpenElec forum or in a separate thread in the Raspberry Pi section of this forum as the discussion about getting it installed really is off topic here and diluting the main thrust of the thread, which is figuring out whether there is a buffering regression with Gotham or not.

It's also not clear from your posts whether you are experiencing a new problem in Gotham or whether you had the same problem in Frodo on the RPi, or have never tested the same config on Frodo.

If that's the case what you're experiencing may simply be marginal performance on the Raspberry Pi due to pushing it near its limits or a Raspberry Pi specific bug that is not related to any changes between Frodo and Gotham, and again not relevant to this thread as I'm specifically trying to address changes that seem to have occurred between Frodo and Gotham.

What I'm reporting on and testing is an apparent worsening of buffering performance and behaviour between Frodo and Gotham (at least Gotham with default buffer settings) on the SAME hardware with basically the same config, and I see the same issues on BOTH a Mac running Mac OS and a Raspberry Pi running Raspbmc, even on relatively low bitrate files <5Mbps where the Raspberry Pi hardware is not being pushed hard so isn't a factor.

[allan87]

Here is a summary of my information above, which may clarify things for you:

In all cases, the information pertains to:
- the same Pi;
- the same mythbackend source;
- Gotham alphas that were periodically updated;
- Playing back MPEG2 recordings (aprox. 8GB/hr, recorded from an HDhomerun - by my math, <20Mbps on average)
- Using the myth plugin.
The rebuffering problem experienced with a wifi connection was resolved in ± October by replacing a wifi device with a powerline network adapter;
The rebuffering problem resurfaced at some point in the last few weeks;
The powerline network adapter, as set up, consistently delivers ± 67 Mbps download speed. This was tested with a macBook plugged into the adapter, with wifi turned off;
67 Mbps download speed should be ample for playback without periodic stalling, and was, from October until ± February;
The Pi is able to play back the same media over a wired connection without buffering, using the myth plugin;
Wired connection has not been speed tested, but it has a theoretical maximum of 100Mbps due to Pi hardware. I doubt it hits 100Mbps, however.

Also:
The macBook's built in wifi consistently delivers ± 72 Mbps download speed;
The macBook was always able to play back the same media over wifi, using XBMC and the myth plugin, without buffering;
Even the Pi was able to play back the same media over wifi without buffering, but using UPnP instead of the myth plugin;

[DBMandrake]

What bit rate are the files you're having problems with buffering though ?

The symptoms I'm describing are even occurring with files with low bit rates, as low as 1Mbps, and are the same on Mac and Pi.

What I talking about are problems with the buffering algorithm when the source stream bandwidth is only marginally faster than the average bit rate of the clip and/or fluctuating a lot. Under these conditions the stream isn't handled as well as Frodo and buffering occurs a lot more frequently.

It sounds to me that you just have a throughput problem with the Pi where it isn't able to keep up with playing across the network of higher bit rate files, while your Mac can keep up. That's a completely different problem, even though both result in buffering.

In your case the network throughput (only on the Pi) is slower than the bit rate of the video, and no clever buffering algorithm will solve that, only finding and fixing the cause of the poor network performance will. In my case the network throughput is fast enough but has a relatively small headroom above the video bit rate (eg internet streams) and the cache is not handling this as well as it could be.

In any case with a bit more testing I think the regression between Frodo and Gotham that I started this thread about boils down to two factors:

1) The cache figure in the codec info screen no longer updates in realtime when playback is paused which gives the impression that no downloading is occurring during pause when in fact it is. Related to this there is a large lag when un-paused of around 5-10 seconds where the cache figure is out of date albeit updating before it suddenly jumps up to the correct figure - this too can give the impression that no downloading occurred during pause, but this is misleading. Whether the cache figure not updating correctly in pause is a bug or a known compromise related to new code only devs can answer.

2) The default readbufferfactor of 1.0 is woefully low, giving the impression that once a buffer under-run occurs during a temporary slow down of a download stream that it will never resume automatically and that auto resume is broken. In fact if readbufferfactor is increased to 1.5 or more, the stream WILL auto-resume after a buffer under run in a more timely Frodo-like fashion.

So in the testing I've done since I started this thread it appears that increasing readbufferfactor will address most of the regression apart from no visual update of the cache figure in pause.

I'm not sure that readbufferfactor is the entire story though, there are a couple of potential bugs in the code. One is that I see from the debug log that just after playback of a stream is started the network throttle bit rate is calculated (before being multiplied by readbufferfactor) but its unclear how it is derived.

Is it calculated based on a sample of a few seconds of playback, or is an average bit rate simply read from the file container ? In that case, what if the container lies on some files and the average bit rate claimed is lower than the actual bit rate for significant chunks of the video ? With a readbufferfactor of 1.0 will the network rate simply be throttled too low to sustain playback reliably ? (It does seem that way) If this is true increasing readbufferfactor may be giving more "headroom" above this inaccurately calculated average bit rate, thus disguising the problem.

Or is the network throttle rate periodically re-evaluated based on a moving average of the measured bit rate ? Any devs care to speak up on how it works ?

The other potential bug I can see is in the auto-resume - there is code that calculates based on average bit rate of the video, how much the buffer is filled and how fast the stream is currently downloading when it is safe to auto-resume without triggering another buffer under run. If the download rate is too slow for this to be satisfied then playback will not resume. (At least until the buffer fills completely) My question is, what happens when the network rate is purposely throttled based on readbufferfactor and predicted bit rate of the video - can the code end up in a situation where it is limiting network throughput below what is required to satisfy the auto-resume algorithm ?

Again, this seems to be the case, and once again increasing readbufferfactor gives extra "headroom" in allowed network throughput to allow auto-resume to be more easily satisfied, assuming that the bandwidth is actually there if called on. Again, any devs care to comment on how this algorithm works ?

So I'm not sure whether we're looking at a bug or two in the code, a poor choice of default readbufferfactor, or a bit of both, but for me increasing readbufferfactor to 1.5 seems to have solved most of the problems I was seeing and is now giving similar buffering performance to Frodo.