Kodi Community Forum
Gotham - buffering regression ? - Printable Version

+- Kodi Community Forum (https://forum.kodi.tv)
+-- Forum: Support (https://forum.kodi.tv/forumdisplay.php?fid=33)
+--- Forum: General Support (https://forum.kodi.tv/forumdisplay.php?fid=111)
+---- Forum: OS independent / Other (https://forum.kodi.tv/forumdisplay.php?fid=228)
+---- Thread: Gotham - buffering regression ? (/showthread.php?tid=189561)

Pages: 1 2 3 4


Gotham - buffering regression ? - DBMandrake - 2014-03-18

Hi All,

One feature I've been looking forward to in Gotham were the improvements to network / filesystem buffering - specifically, being able to enable read ahead buffering even on "local" file systems such as SMB, which is helpful when streaming video across a wireless network from a file server, as I do.

On starting to experiment with Gotham betas on both Raspbmc (miappa's builds) and Mac OS (Memphiz's airplay test 10, and now official Beta 2) in the last week I've almost immediately run into a couple of issues while testing the new buffering algorithm - one of them quite major in my opinion.

The first minor issue is that Gotham seems to have a mind of its own when it comes to observing/respecting the cachemembuffersize parameter. According to this page:

http://wiki.xbmc.org/index.php?title=HOW-TO:Modify_the_video_cache

The default is supposedly 5MB, however on an install with no advanced settings to override this setting I'm seeing the buffer (as displayed in codecinfo) build up to 20MB on an http stream.

If I set cachemembuffersize to for example 10MB it sometimes respects it, and sometimes doesn't. On some streams/videos it will hover almost precisely at half the requested value (5MB in this case) and at other times it will hover at the requested value. At yet other times it will sometimes far exceed the specified value - I've seen it climb up to 20MB when it is set to 10MB.

Any ideas why it has such a liberal interpretation of the setting ? Or is codec info lying to me ?

The second issue which is more severe is this - by default the readbufferfactor is only 1.0 so compared to Frodo Gotham is very slow at filling the buffer as its only downloading slightly faster than the average bitrate. This means if a momentary slow down or pause in the network stream occurs within say the first 30 seconds of starting a buffer under-run occurs almost immediately and the video stops.

This can be alleviated somewhat by increasing readbufferfactor so that it gets a bit more of a move on at filling the buffer when the playback first starts - I find 1.5 works quite well without over saturating the network, and allows the buffer to reach equilibrium in maybe 10 seconds or so. So for this aspect of the problem I just disagree with the default readbufferfactor being so low, and think that it should be at least say 1.2 to allow the buffer to fill in a reasonable amount of time.

The default readbufferfactor being low however exposes a bug / regression / design flaw - Gotham will not buffer ahead when the video is paused, either manually, or automatically due to a buffer under-run.

In Frodo if you had a buffer under-run the playback would pause automatically but the download would continue, when the buffer filled to a certain threshold playback would start again automatically. If the speed of the stream was a bit marginal and a bit variable it was possible to manually pause the video for a minute to allow the buffer to fully fill then manually resume playback - which on a marginal stream may be enough to get uninterrupted playback for a further 5-10 minutes, or perhaps to the end of the clip.

This no longer seems to be possible in Gotham. As soon as I pause playback the stream stops buffering ahead - as shown by the cache figure in codec info freezing and no longer increasing. I can wait a couple of minutes then un-pause and cache will only continue to build from the point I un-pause. So manually pausing to allow the buffer to fill is no longer possible.

Worse though is that if the stream slows down enough for a buffer under-run to occur playback will automatically pause and the download will also stop just as if you had manually paused it - left alone a pause caused by a buffer under-run will never recover by itself and sit forever on pause !

If you then manually press play, because the buffer is empty and the default readbufferfactor is so low unless the stream picks up in speed almost instantly the buffer will under-run again, playback will be automatically paused and you're back to square one - paused with an empty buffer that is not filling. Sometimes its nearly impossible to get playback started again in this situation, as there is no way to allow the buffer to build up before recommencing playback.

Increasing readbufferfactor to 1.5 alleviates the symptoms a lot (but isn't a fix on its own) because the initial download speed when pressing play is 50% faster (assuming the server has enough bandwidth) allowing the buffer to fill and get you out of danger quicker, however if the available bandwidth of the server is only slightly above the average bitrate the problem can still occur because a readbufferfactor of 1.5 may not be the limiting factor then.

Bearing in mind as well that TCP slow start means that even if a server can support say 120% of the required bandwidth for a stream, it can take a few seconds for the speed of the TCP connection to ramp up to maximum after the transfer has been suspended and then resumed - its not uncommon for some servers to take up to 5 seconds after un-pausing before full throughput is regained. (Watch a packet sniffer to see this)

So it seems to me that there are two problems, one just a default settings change, the other probably an easy fix:

1) The buffer/cache is not allowed to continue downloading/filling while playback is paused. I'll take a wild stab in the dark here and guess that this is a bug in the code that implements readbufferfactor where it is measuring the current video bitrate and multiplying this by readbufferfactor to arrive at a network throughput figure - the video bitrate of a paused video is zero, therefore zero times readbufferfactor is zero...opps... (perhaps an average bitrate of the last 10 seconds of video should be used in the calculation when the video is paused)

2) The default readbufferfactor needs to be at least 1.2, maybe as much as 1.5. 1.0 is just too stingy and means that the buffer takes an eternity to reach equilibrium again after a buffer under-run or at the start of playback, meaning the buffer might as well not be there as it spends most of the time when it's most needed (starting, resuming from an under-run) nearly empty and filling very very slowly even on a fast connection.

Has anyone else noticed these same issues or can any devs offer any insights into the changes in the buffer algorithms between Frodo and Gotham, and how it is working or should be working ? Frodo had its own problems with its buffering algorithm, but apart from being able to buffer more types of streams/filesystems Gotham seems to actually be worse off thanks to no buffering ahead during pause.


RE: Gotham - buffering regression ? - Ned Scott - 2014-03-19

(2014-03-18, 17:19)DBMandrake Wrote: The default is supposedly 5MB, however on an install with no advanced settings to override this setting I'm seeing the buffer (as displayed in codecinfo) build up to 20MB on an http stream.

If I set cachemembuffersize to for example 10MB it sometimes respects it, and sometimes doesn't. On some streams/videos it will hover almost precisely at half the requested value (5MB in this case) and at other times it will hover at the requested value. At yet other times it will sometimes far exceed the specified value - I've seen it climb up to 20MB when it is set to 10MB.

Any ideas why it has such a liberal interpretation of the setting ? Or is codec info lying to me ?

I try not to trust the codec info screen too much, but some of the confusion is likely because "5MB" is not the actual amount of cache being used. I guess the descriptions should be written better, but basically you have something along the lines of a past, present, and future cache, each being 5MB. This is why the description warns about using 3x of what ever is set. I'm not a dev, so I wouldn't know where to look to check this, but I imagine there could even be situations where XBMC will cache a little more. The "5MB" part is just one value in an equation, rather than the actual total cache being used.

I don't know if this would be practical, but I would like to eventually see this setting replaced with one that is just "cache limit". A straight up limit that says the cache will never go above X. The big concern with the cache is that you don't want it to use too much RAM and not have RAM left over for other functions in XBMC (or the OS for that matter), so it's a lot easier for the user to just draw a firm line than try to figure out the equation (which is probably not as simple as just 3x the cache value).

I'm also not sure if the default is still 5MB. If it is, then that's another default that should probably be bumped for modern times.

Quote:This can be alleviated somewhat by increasing readbufferfactor so that it gets a bit more of a move on at filling the buffer when the playback first starts - I find 1.5 works quite well without over saturating the network, and allows the buffer to reach equilibrium in maybe 10 seconds or so. So for this aspect of the problem I just disagree with the default readbufferfactor being so low, and think that it should be at least say 1.2 to allow the buffer to fill in a reasonable amount of time.

I agree, I think the default should be much higher than it is now.

Quote:This no longer seems to be possible in Gotham. As soon as I pause playback the stream stops buffering ahead - as shown by the cache figure in codec info freezing and no longer increasing. I can wait a couple of minutes then un-pause and cache will only continue to build from the point I un-pause. So manually pausing to allow the buffer to fill is no longer possible.

I can't duplicate your findings. It still works as described on my test systems, using SMB shares, on iOS, Mac OS X, Android, and Linux (Ubuntu). In fact, two days ago I had started a movie, paused it, the screen turned off in energy saver settings, and I completely forgot about it. Yesterday, when I pressed the remote and the screen came back on, it was still there, paused, with the entire movie cached (since I had set the cache to use the hard drive and thus have no limit on how much can be cached). I finished watching it and the networked hard drive never even spun back up.

It might be that certain conditions are needed to trigger this bug? I don't know if a debug log would tell us much about what is being cached, but that might shine some light on it.


RE: Gotham - buffering regression ? - Ned Scott - 2014-03-19

Alright, now this is spooky, it's doing it now. No buffering on pause, I can confirm.

EDIT: maybe? When I unpaused just now, the cache shot up to 272.9MB, which is the entire file size, in a few seconds.

Something is broken, that's for sure.


RE: Gotham - buffering regression ? - DBMandrake - 2014-03-19

I've done some more testing since my post and have discovered a few inconsistencies.

Contrary to what I first thought, although the cache figure on the codec info screen no longer updates in pause like it did in Frodo, it appears that some downloading does in fact continue in the background.

Secondly, there seems to be a large amount of lag between what is really going on and what the cache figure in codec info says - at least when playback is first un-paused.

For example I can skip ahead 10 minutes to a previously unbuffered section, thus emptying the cache, pause when the cache has reached 0.5MB (with cachemembuffersize set to 10) wait a couple of minutes, then when I play the figure will slowly climb from 0.5 to maybe 2MB over 5-10 seconds then suddenly jump to 10MB and stay there. So it seems downloading was continuing in the background but it took many seconds of playback before the cache figure on codec info reflected the true amount cached, so that may be part of the confusion.

So part of what I noticed may be cosmetic. However there is definitely a problem with the auto-resume of a stream that automatically paused due to a temporary buffer under-run with the default readbufferfactor - once paused either the download speed is much lower than it should/could be, (a problem with calculation of desired download speed based on readbufferfactor when paused perhaps) or the algorithm that decides when its ok to start playing again is broken.

Multiple times when this happened to me last night (on default settings) playback stopped, the buffering bar appeared (amber skin buffering bar, that works a bit differently to confluence) and the buffering percentage went ahead to 40% or so, then went backwards and stayed at a fairly low percentage. Left to itself it sat there for at least two minutes not auto-resuming before I got tired of waiting and pressed play.

When I pressed play the cache size reading grew to 6.8MB over only 5 seconds and the video continued to play to completion with the cache size sitting at a steady 6.8MB. (Why 6.8MB in particular ?)

So clearly there was enough buffer to resume playing and enough bandwidth to finish the clip uninterrupted, but auto-resume was sitting there stuck saying buffering 10%...I was able to reproduce this multiple times where it would not auto resume thinking it was unable to buffer properly yet when I forced it to resume the buffer quickly filled and playback was normal. It does seem like it was only trickling in data very slowly when paused - too slow to fill the buffer and resume.

I'll do some more testing and see what I can figure out, and see if I can set up something to monitor actual network throughput. I have one machine (Mac Mini on Beta 2) running with default buffering settings, and on the RPi (miappa's March 17 build) I have cachemembuffersize set to 10, buffermode 1 (so I can buffer SMB streams from the Mac Mini) and readbufferfactor 1.5.

Of the two the RPi with these settings is giving MUCH less trouble, if any, and I think that's largely down to the readbufferfactor being higher.


RE: Gotham - buffering regression ? - popcornmix - 2014-03-19

(2014-03-19, 08:57)DBMandrake Wrote: I'll do some more testing and see what I can figure out, and see if I can set up something to monitor actual network throughput. I have one machine (Mac Mini on Beta 2) running with default buffering settings, and on the RPi (miappa's March 17 build) I have cachemembuffersize set to 10, buffermode 1 (so I can buffer SMB streams from the Mac Mini) and readbufferfactor 1.5.

Of the two the RPi with these settings is giving MUCH less trouble, if any, and I think that's largely down to the readbufferfactor being higher.

Can you just confirm if all the issues reported affect both the Mac and the Pi?
It's possible that omxplayer on Pi may behave differently than dvdplayer on Mac,
so it would be useful to determine which behaviour is in common xbmc code, and which (if any) is omxplayer specific.


RE: Gotham - buffering regression ? - DBMandrake - 2014-03-19

(2014-03-19, 13:50)popcornmix Wrote: Can you just confirm if all the issues reported affect both the Mac and the Pi?
It's possible that omxplayer on Pi may behave differently than dvdplayer on Mac,
so it would be useful to determine which behaviour is in common xbmc code, and which (if any) is omxplayer specific.
Ok, I'll remove my custom buffer related settings on the Pi (although I think Raspbmc has a default system advancedsetting that bumps up the cachemembuffersize setting - and it's not clear what the default is on current XBMC builds, it doesn't seem to be the 5MB that the wiki suggests) and do a direct comparison between them to see if they behave the same.


RE: Gotham - buffering regression ? - ursli - 2014-03-19

I do have the same behaviour with the need to manually press play on buffer underrun, it's also not updating the cache figure in the codec info but does continue downloading as mentioned already.

That is on my Linux HTPC running lubuntu with xbmc nightly from launchpad. I did not fiddle with advancedsettings yet, the only thing I got in is cachemembuffer 0


RE: Gotham - buffering regression ? - popcornmix - 2014-03-19

(2014-03-19, 14:01)DBMandrake Wrote: Ok, I'll remove my custom buffer related settings on the Pi (although I think Raspbmc has a default system advancedsetting that bumps up the cachemembuffersize setting - and it's not clear what the default is on current XBMC builds, it doesn't seem to be the 5MB that the wiki suggests) and do a direct comparison between them to see if they behave the same.

The default is 20M:
https://github.com/xbmc/xbmc/blob/master/xbmc/settings/AdvancedSettings.cpp#L371

But note: 3 buffers are allocated, so this takes 60M of RAM.
Also note that in most cases (mkv, avi and mov files) only half the cache will be used.
https://github.com/xbmc/xbmc/pull/3963


RE: Gotham - buffering regression ? - DBMandrake - 2014-03-19

(2014-03-19, 14:22)popcornmix Wrote:
(2014-03-19, 14:01)DBMandrake Wrote: Ok, I'll remove my custom buffer related settings on the Pi (although I think Raspbmc has a default system advancedsetting that bumps up the cachemembuffersize setting - and it's not clear what the default is on current XBMC builds, it doesn't seem to be the 5MB that the wiki suggests) and do a direct comparison between them to see if they behave the same.

The default is 20M:
https://github.com/xbmc/xbmc/blob/master/xbmc/settings/AdvancedSettings.cpp#L371
Ah, that's interesting. That means when I manually set it to 10MB on the RPi thinking I was increasing it from 5MB I was actually decreasing it from 20MB... and yet the RPi was still having far less buffering issues, so unless its something to do with the different players as you're wondering (I suspect not) then it's probably down to the difference in readbufferfactor. I'll have a better idea when I've had time to compare the two with identical settings.

(Edit: I've just noticed Raspbmc hardwires the default cachemembuffersize to 5MB in the system advancedsettings.xml so I was in fact only getting a 5MB buffer until I added my 10MB override - but on the Mac it was defaulting to the Gotham default of 20MB, so I'll manually set both to 20MB in my testing to be sure)

Also interesting that the latest beta of OpenElec sets readbufferfactor to 4.0 in the system advancedsettings.xml - why do that unless the OpenElec devs noticed an issue. Personally I think 4.0 is way too high and defeats the purpose of readbufferfactor - eg not saturating the network with very bursty traffic when filling the buffer - a value between 1.5 and 2.0 seems more reasonable. What was the behaviour on Frodo ? Did it have no speed cap when filling an empty buffer (effectively equivalent to an infinite readbufferfactor) so that buffer filling to the high water mark was done as fast as the network would allow ? If that's the case a silly high readbufferfactor like 4.0 is effectively reverting to the old behaviour.
Quote:But note: 3 buffers are allocated, so this takes 60M of RAM.
Also note that in most cases (mkv, avi and mov files) only half the cache will be used.
https://github.com/xbmc/xbmc/pull/3963
Thanks. I had seen mention of that pull request come to think of it, I guess that explains the difference in buffer size for different clips - as you say most were effectively running at half the requested buffer size, but I definitely saw cases where I had manually set 10MB and it crept up as high as 20MB. Weird. I need to do more testing.

60MB worth of ram reserved for 3x 20MB buffers is fine for PC's and 512MB RPi's and I would argue a good idea with the higher and higher bitrate files we're all streaming these days, but that's a big chunk of ram for a 256MB RPi - it will be interesting to see if Raspbmc/OpenElec devs manually drop that figure when a 256MB RPi's is detected...(although truthfully a 256MB RPi must surely be on life support now with increasing demands for GPU and ARM memory in later XBMC releases, a bit like trying to run 3rd party apps on the iPhone 3G with its 128MB of system ram with barely 25MB free for apps! It's not like a brand new 512MB RPi costs a fortune to replace an old 256MB one for someone trying to push the performance envelope)


RE: Gotham - buffering regression ? - DBMandrake - 2014-03-19

Doing a quick test on readbufferfactor while streaming using the Apple iTunes Trailers addon, the trailer for the movie "The Machine".

Average bitrate looks to be around 4-5Mbps, and cache size was set to 20MB. With the default readbufferfactor of 1.0 it took 45 seconds of playback for the buffer to reach 10MB, and it didn't reach 20MB during the 1:30 run time of the clip. Throughput looked like this:

Code:
13:59:05   949Mhz   450Mhz   225Mhz  59.00C (64.00C)     765   1,108,454       8,366   51M ( 47%)   39.83    5.48   23.02   24.85    0.00    0.00    6.58   75.15  280,944 kB/26.8%
13:59:07   950Mhz   450Mhz   225Mhz  59.00C (64.00C)   1,268   2,933,549      20,579   51M ( 47%)   43.37    6.30   31.51    6.30    0.00    0.00   12.60   93.70  271,392 kB/29.3%
13:59:10   950Mhz   450Mhz   225Mhz  58.00C (64.00C)     699     766,311       6,246   57M ( 52%)   31.37    4.65   25.56   34.86    0.00    0.00    2.32   65.14  269,652 kB/29.7%

Time          ARM     Core     H264  Core Temp (Max)   IRQ/s      RX B/s      TX B/s  GPUMem Free   %user   %nice %system   %idle %iowait    %irq  %s/irq  %total  Memory Free/Used
========  =======  =======  =======  ===============  ======  ==========  ==========  ===========  ======  ======  ======  ======  ======  ======  ======  ======  ================
13:59:13   949Mhz   450Mhz   225Mhz  59.00C (64.00C)     697     765,741       6,280   57M ( 52%)   34.86    6.44   23.11   32.20    0.00    0.00    1.89   67.80  266,904 kB/30.4%
13:59:15   950Mhz   450Mhz   225Mhz  59.00C (64.00C)     775     764,452       7,157   57M ( 52%)   35.87    4.81   26.63   27.00    0.00    0.00    3.33   73.00  264,320 kB/31.1%
13:59:18   950Mhz   450Mhz   225Mhz  59.00C (64.00C)     706     760,108       6,154   57M ( 52%)   31.29    6.57   27.42   30.52    0.00    0.00    3.48   69.48  262,368 kB/31.6%
13:59:20   950Mhz   450Mhz   225Mhz  59.00C (64.00C)     681     760,601       5,549  121K (  0%)   33.82    6.61   23.72   30.33    0.00    0.00    3.89   69.67  260,256 kB/32.2%
13:59:23   950Mhz   450Mhz   225Mhz  59.00C (64.00C)     723     806,293       7,052   56M ( 51%)   33.99    6.25   26.57   28.52    0.00    0.00    1.95   71.48  258,292 kB/32.7%
13:59:26   950Mhz   450Mhz   225Mhz  58.00C (64.00C)     746     788,425       8,292   57M ( 52%)   31.67    6.41   16.21   38.83    0.00    0.00    5.66   61.17  256,284 kB/33.2%
13:59:28   950Mhz   450Mhz   225Mhz  59.00C (64.00C)     769     739,769       8,489   57M ( 52%)   27.73    5.78   22.34   38.52    0.00    0.00    3.85   61.48  254,424 kB/33.7%
13:59:31   950Mhz   450Mhz   225Mhz  59.00C (64.00C)     741     776,214       7,621   57M ( 52%)   32.19    4.17   23.48   31.43    0.00    0.00    3.79   68.57  253,784 kB/33.9%
13:59:33   950Mhz   450Mhz   225Mhz  58.00C (64.00C)     709     740,321       6,935   57M ( 52%)   30.58    5.03   26.71   33.68    0.00    0.00    2.71   66.32  252,260 kB/34.3%
13:59:36   950Mhz   450Mhz   224Mhz  58.00C (64.00C)     678     771,722       6,180   57M ( 52%)   31.93    1.86   25.24   33.78    0.00    0.00    5.20   66.22  252,272 kB/34.3%
13:59:39   950Mhz   450Mhz   225Mhz  59.00C (64.00C)     691     763,748       5,499   57M ( 52%)   32.23    5.82   26.41   32.23    0.00    0.00    2.72   67.77  252,276 kB/34.3%
13:59:41   949Mhz   450Mhz   225Mhz  58.00C (64.00C)     692     755,232       6,396   57M ( 52%)   26.52    5.07   20.67   40.55    0.00    0.00    4.68   59.45  252,276 kB/34.3%
13:59:44   950Mhz   450Mhz   225Mhz  59.00C (64.00C)     746     795,107       7,324   57M ( 52%)   33.24    5.14   24.14   32.45    0.00    0.00    2.37   67.55  252,164 kB/34.3%
13:59:46   950Mhz   450Mhz   225Mhz  59.00C (64.00C)     690     733,418       6,153   57M ( 52%)   29.55    4.67   22.94   36.55    0.00    0.00    4.67   63.45  253,516 kB/33.9%
13:59:49   950Mhz   450Mhz   225Mhz  59.00C (64.00C)     709     794,039       6,187   57M ( 52%)   30.08    6.17   23.52   34.70    0.00    0.00    3.47   65.30  253,520 kB/33.9%
13:59:51   950Mhz   450Mhz   225Mhz  58.00C (64.00C)     716     782,205       6,786   57M ( 52%)   29.10    4.78   20.73   39.47    0.00    0.00    3.99   60.53  253,528 kB/33.9%
13:59:54   950Mhz   450Mhz   225Mhz  58.00C (64.00C)     697     733,061       6,108   57M ( 52%)   27.30    5.77   21.91   39.21    0.00    0.00    2.69   60.79  255,248 kB/33.5%
13:59:56   950Mhz   450Mhz     0Mhz  59.00C (64.00C)     560     376,883       2,728   75M ( 69%)   57.89    1.73   20.30   17.71    0.00    0.00    2.16   82.29  283,684 kB/26.1%
Despite the readbufferfactor there was an initial burst of 2.9MB/sec for a couple of seconds before playback begun it then settled down to an average of 780KB/sec.

Here was the same clip with a readbufferfactor of 1.5:

Code:
14:11:22   950Mhz   450Mhz   225Mhz  59.00C (62.00C)     623     612,866       4,518  134M (124%)   22.83    8.23   18.71   43.41    0.00    0.00    4.87   56.59  286,804 kB/25.3%
14:11:24   950Mhz   450Mhz   225Mhz  60.00C (62.00C)   1,256   2,881,115      20,026   53M ( 49%)   52.95    3.81   25.52    0.00    0.00    0.00   17.90  100.00  274,540 kB/28.5%
14:11:27   950Mhz   450Mhz   225Mhz  60.00C (62.00C)     873   1,380,437      10,927   53M ( 49%)   20.94    6.44   23.76   40.67    0.00    0.00    4.83   59.33  271,892 kB/29.1%
14:11:29   950Mhz   450Mhz   225Mhz  59.00C (62.00C)     760   1,038,283       7,718   58M ( 53%)   19.05    4.97   13.66   52.17    0.00    0.00    5.80   47.83  268,424 kB/30.1%
14:11:32   950Mhz   450Mhz   225Mhz  60.00C (62.00C)     831   1,132,406       9,638   58M ( 53%)   24.04    6.22   16.58   44.36    0.00    0.00    4.97   55.64  265,840 kB/30.7%
14:11:34   950Mhz   450Mhz   225Mhz  59.00C (62.00C)     754   1,040,128       7,918   58M ( 53%)   22.22    5.25   17.37   46.86    2.02    0.00    7.27   53.14  263,048 kB/31.5%
14:11:36   950Mhz   450Mhz   225Mhz  60.00C (62.00C)     815   1,134,987       9,812   58M ( 53%)   25.43    6.36   22.25   36.16    0.00    0.00    5.96   63.84  260,124 kB/32.2%
14:11:39   950Mhz   450Mhz   225Mhz  60.00C (62.00C)     785   1,025,091       8,743   58M ( 53%)   30.20    5.79   21.10   36.82    0.00    0.00    4.97   63.18  256,432 kB/33.2%
14:11:42   950Mhz   450Mhz   225Mhz  60.00C (62.00C)     771   1,087,010       8,336   58M ( 53%)   27.70    5.00   23.85   36.17    0.00    0.00    5.39   63.83  255,184 kB/33.5%
14:11:44   950Mhz   450Mhz   225Mhz  60.00C (62.00C)     800   1,096,324       8,556   58M ( 53%)   34.67    3.47   17.72   35.44    0.00    0.00    5.01   64.56  254,936 kB/33.6%
14:11:47   950Mhz   450Mhz   225Mhz  61.00C (62.00C)     793   1,060,306       8,042   58M ( 53%)   37.88    5.30   23.48   24.24    0.00    0.00    7.20   75.76  255,292 kB/33.5%
14:11:49   950Mhz   450Mhz   225Mhz  59.00C (62.00C)     776   1,099,383       8,053   58M ( 53%)   37.04    5.61   23.94   26.19    0.00    0.00    3.37   73.81  253,916 kB/33.8%
14:11:52   950Mhz   450Mhz   225Mhz  60.00C (62.00C)     857   1,112,442      10,780   58M ( 53%)   33.02    3.62   28.19   25.77    0.00    0.00    6.84   74.23  253,460 kB/34.0%
14:11:54   950Mhz   450Mhz   225Mhz  60.00C (62.00C)     845   1,069,813      10,638   58M ( 53%)   33.02    4.77   26.66   25.06    0.00    0.00    6.37   74.94  253,232 kB/34.0%
14:11:57   950Mhz   450Mhz   225Mhz  60.00C (62.00C)     772   1,039,437       8,450   58M ( 53%)   29.00    6.13   19.61   37.99    0.00    0.00    5.72   62.01  253,244 kB/34.0%
14:11:59   950Mhz   450Mhz   225Mhz  60.00C (62.00C)     825   1,097,727      10,419   58M ( 53%)   26.42    5.52   22.47   38.25    0.00    0.00    3.55   61.75  252,864 kB/34.1%
14:12:02   950Mhz   450Mhz   225Mhz  60.00C (62.00C)     812   1,098,452      10,162   58M ( 53%)   21.31    6.03   21.71   43.82    0.00    0.00    2.81   56.18  252,848 kB/34.1%
14:12:05   700Mhz   250Mhz   250Mhz  59.00C (62.00C)     820   1,058,266       9,683   58M ( 53%)   19.07    6.48   18.31   47.67    0.00    0.00    4.58   52.33  252,488 kB/34.2%
14:12:07   950Mhz   450Mhz   225Mhz  59.00C (62.00C)     781   1,082,134       8,769   58M ( 53%)   26.04    5.21   19.63   40.06    0.00    0.00    4.81   59.94  252,336 kB/34.2%
14:12:10   700Mhz   250Mhz   250Mhz  59.00C (62.00C)     559     299,496       3,630   58M ( 53%)   19.22    6.41   18.42   49.65    0.40    0.00    1.20   50.35  253,212 kB/34.0%
14:12:12   950Mhz   449Mhz   225Mhz  59.00C (62.00C)     466       2,564         210   58M ( 53%)   24.03    5.61   22.03   45.27    0.00    0.00    0.40   54.73  253,964 kB/33.8%
Again the same very fast burst just before playback begun then settling down to about 1.1MB/sec while the buffer filled, which now took only 15 seconds to reach 10MB instead of 45 seconds, and it reached a full 20MB after around 30 seconds of playback. The clip wasn't long enough to require further downloading after the buffer had reached full size to see where the low water mark was.

So in terms of getting the buffer filled up reasonably quickly without totally saturating the network there is a massive difference between a readbufferfactor of 1.0 and 1.5, and that setting does seem to work as expected. With 1.5 you have a decent 10MB safety margin built up in only 15 seconds in this example, which is going to make playback much more robust in the face of short stalls in the stream or intermittent dips of throughput below the average bitrate. So well worth tweaking readbufferfactor up a bit IMHO. (but not so high that it saturates the network)


RE: Gotham - buffering regression ? - DBMandrake - 2014-03-19

I managed to catch it red handed buffering way more than the cachemembuffersize as I was describing earlier. Here was my advancedsettings.xml (on RPi) when it happened:

Code:
<advancedsettings>
  <network>
    <buffermode>1</buffermode>
    <cachemembuffersize>20971520</cachemembuffersize>
    <readbufferfactor>1.5</readbufferfactor>
  </network>
</advancedsettings>

Here is a screenshot taken from a 35Mbps MKV video shared from a PC using the built in SMB client: (which played fine with no pauses, but could not play without multiple pauses with buffermode=0, so the buffering is certainly working)

https://dl.dropboxusercontent.com/u/7826218/Forum%20attachments/XBMC-large-buffer.png

It steadily climbed all the way up to 42MB and hovered around 40MB by about 3/4 of the way through the clip. Strange...


RE: Gotham - buffering regression ? - allan87 - 2014-03-21

Potentially related to this issue, I have found that using the cmyth (MythTV) add-on on over wireless n, on a Pi, the video pauses frequently to buffer, making it unwatchable. The recordings are 1080i MPEG 2. I have never had a problem using a wired connection.

Somewhat surprisingly, watching the same recordings from the same myth backend OVER WIRELESS work fine in the following scenarios:
- Gotham/cmyth runing on a Macbook;
- using the TVs built in UPnP;
- using the same raspberry pi, using UPnP instead of cmyth.

So, since even the wireless network evidently has sufficient bandwidth to maintain a stable stream, there seems to be a bottleneck elsewhere.


RE: Gotham - buffering regression ? - popcornmix - 2014-03-21

(2014-03-21, 19:05)allan87 Wrote: So, since even the wireless network evidently has sufficient bandwidth to maintain a stable stream, there seems to be a bottleneck elsewhere.

Were you using the same USB dongle on the Pi and the Mac?
Small USB dongles typically have a single, small antenna and a much lower bandwidth than a laptop's wifi (with multiple antennas).


RE: Gotham - buffering regression ? - allan87 - 2014-03-21

Quote:Were you using the same USB dongle on the Pi and the Mac?
No. Built in wifi on the macbook.

However, I didn't use a dongle on the Pi, but a TRENDnet TEW-654TR travel router, in client mode. I used the same TEW-654TR
• on the TV, using UPnP, with no rebuffering,
• on the same raspberry pi, using UPnP, with no rebuffering.

In all cases, watching the same recordings from the same myth backend.


RE: Gotham - buffering regression ? - DBMandrake - 2014-03-21

(2014-03-21, 20:53)allan87 Wrote:
Quote:Were you using the same USB dongle on the Pi and the Mac?
No. Built in wifi on the macbook.

However, I didn't use a dongle on the Pi, but a TRENDnet TEW-654TR travel router, in client mode. I used the same TEW-654TR
• on the TV, using UPnP, with no rebuffering,
• on the same raspberry pi, using UPnP, with no rebuffering.

In all cases, watching the same recordings from the same myth backend.
Built in wifi on any Mac made in the last several years has either two or three spatial streams which is potentially up to 3 times faster than a wireless client with one spatial stream. Looking at the specs for that trend net router it looks like it is 2.4Ghz only - all recent Macs are dual band 2.4Ghz and 5Ghz, generally you'll get MUCH faster more consistent speeds on 5Ghz (as long as you're not through too many walls) so that's another difference.

So comparing it with what you get with the Mac doesn't really prove anything and is a bit of a red herring.

If it works ok on the Pi on a direct Ethernet connection but struggles through your Ethernet connected wireless client then clearly the wireless performance is marginal - in both cases as far as the Pi is concerned its using an Ethernet connection - it doesn't know one is wireless converted to Ethernet and one is real Ethernet from end to end. The difference in performance MUST be the wireless network and that of the wireless client.

Having said that it may be that UPnP in Gotham uses buffering by default whereas local filesystems (including SMB and NFS) do not - does anyone know for sure about UPnP ?

When you try playing using your cmyth addon, bring up codec info (O) and see if cache sits on 0 or whether it increases. If it sits on 0 it means that buffering is not enabled for the transfer method cmyth uses - in that case try using the advanced settings I posted above which enable buffering on all video playback and increases the readbufferfactor. (In fact try it regardless)

If the wireless throughput is marginal enabling buffering and increasing readbufferfactor can easily make the difference between a stream that keeps pausing and one that plays perfectly. (As long as the average throughput is sufficient)