2013-06-17, 01:41
Other situations I see include lots of wifi networks that are fast enough but have the occasional interference that will knock speed down for a few seconds, or sometimes the whole connection.
2013-06-17, 10:09
I had the issues on gigabit ethernet... but you're correct, its a minor issue and this PR is still a huge improvement for WAN (I also test it streaming over 100mbps internet connection to another city).
I'd love to get the subtitle-switch thing fixed though, since it points to a deeper issue (it might occur on other files as well, maybe). I've been unable to figure it out though... not familiar enough with the XBMC codebase
I'd love to get the subtitle-switch thing fixed though, since it points to a deeper issue (it might occur on other files as well, maybe). I've been unable to figure it out though... not familiar enough with the XBMC codebase
2013-06-20, 17:00
rar allocates a uhm 40mb iirc memory buffer for some gawd aweful stupid reason. i originally hacked this down to 512kb back in the xbox days due to memory pressure. that always works for stuff that is stored but it breaks certain compression schemes. that buffer was reinstated when we moved to less constrained platforms. it is likely what bites the pi.
2013-06-20, 17:30
(2013-06-20, 17:00)spiff Wrote: rar allocates a uhm 40mb iirc memory buffer for some gawd aweful stupid reason. i originally hacked this down to 512kb back in the xbox days due to memory pressure. that always works for stuff that is stored but it breaks certain compression schemes. that buffer was reinstated when we moved to less constrained platforms. it is likely what bites the pi.
This may be a raspbmc thing. They make /tmp a small ramfs. rar files extract to /tmp and give an error when it's full. xbmc doesn't handle this error well and aborts.
2013-06-21, 03:44
I've added another PR2901 , which makes the buffer behavior more consistent. Based on some of the comments on the original PR thread this may be more of an uphill battle to get this in ... All I can say, my experience had been much better since adding it in.
Also, I've noticed that cache objects seem to be created even when the movies aren't being played (like, when scrolling through the list and the file is opened -- to generate a thumb, I guess). So one of the things I want to do next, is to limit the cache usage to the actual playback (e.g., not subtitles, thumbs, etc). At least, worth exploring.
P.S. I can generate another PR with the stats logging that I've used to track the buffer performance, if anyone's interested.
Also, I've noticed that cache objects seem to be created even when the movies aren't being played (like, when scrolling through the list and the file is opened -- to generate a thumb, I guess). So one of the things I want to do next, is to limit the cache usage to the actual playback (e.g., not subtitles, thumbs, etc). At least, worth exploring.
P.S. I can generate another PR with the stats logging that I've used to track the buffer performance, if anyone's interested.
2013-06-23, 04:05
Rate limiting should also avoid buffer over-run[1], but XBMC's rate limiter seems to incorrectly estimate the bandwidth requirements, or completely fail in several situations. I think it's actually trying to be too clever, by working at the level of the unpacked media frames. This fails to correctly buffer things like MythTV recordings, because it can't work out the correct rate at which to limit and limits far too slowly. (Observed on gigabit ethernet!) It's obviously a flawed idea for variable frame rate streams, or where the stream contains data that XBMC discards. (From the MythTV example, EIT records, MHP, Null packing...)
It really should just be media agnostic, and gauge by measuring how quickly the buffer is emptying. The media player should provide hints to the caching, but trying to micro-manage it by frame-rate is causing problems.
[1] Buffer over-run is bad, because it means that even when you have bandwidth capable of more than real-time streaming, the stream gets stopped because there's nowhere to store what's downloaded. Do this a lot, and a stream you should be entirely capable of streaming becomes choppy and slow over-all.
It really should just be media agnostic, and gauge by measuring how quickly the buffer is emptying. The media player should provide hints to the caching, but trying to micro-manage it by frame-rate is causing problems.
[1] Buffer over-run is bad, because it means that even when you have bandwidth capable of more than real-time streaming, the stream gets stopped because there's nowhere to store what's downloaded. Do this a lot, and a stream you should be entirely capable of streaming becomes choppy and slow over-all.
2013-06-23, 04:16
(2013-06-23, 04:05)barberio Wrote: Rate limiting should also avoid buffer over-run[1], but XBMC's rate limiter seems to incorrectly estimate the bandwidth requirements, or completely fail in several situations. I think it's actually trying to be too clever, by working at the level of the unpacked media frames. This fails to correctly buffer things like MythTV recordings, because it can't work out the correct rate at which to limit and limits far too slowly. (Observed on gigabit ethernet!) It's obviously a flawed idea for variable frame rate streams, or where the stream contains data that XBMC discards. (From the MythTV example, EIT records, MHP, Null packing...)
It really should just be media agnostic, and gauge by measuring how quickly the buffer is emptying. The media player should provide hints to the caching, but trying to micro-manage it by frame-rate is causing problems.
[1] Buffer over-run is bad, because it means that even when you have bandwidth capable of more than real-time streaming, the stream gets stopped because there's nowhere to store what's downloaded. Do this a lot, and a stream you should be entirely capable of streaming becomes choppy and slow over-all.
I don't think buffer overrun is a problem in the current implementation. There's two separate threads, one reading from the buffer, one filling it up. When there's no space to write to, the writer sleeps for 5ms, pretty much just polling for free space from there on. So, as long as buffer is capable of storing more than a reasonable factor of 5ms worth of data, this shouldn't cause any problems.
But I do agree about the interaction of rate limiter in the cache and the player being too clever. I think there's a certain miscalculation, which lets the buffer dip too low at times, causing underruns. But, I haven't gotton to the bottom of it; disabling the limiter in the cache seemed more practical.
BTW, I've been testing with Intel NUC w/4GB of RAM, and setting the cache to 150MB seemed to do the trick on a moderately fast wireless N network. Obviously, this was too much for the 512MB RPi, but 50MB seems to do the trick there *when using Ethernet port*. Using a very fast USB wireless dongle kept causing issues, but once I've switched to an Ethernet bridge (Trendnet TEW-680MB) it has become rock solid. Amusingly enough, the router shows lower speeds for the bridge, then it did for the Asus dongle.
2013-07-03, 14:23
Just thought I'd poke this.
As mentioned on PR2901
Adding an adv setting for setting the throttle amount is more likely to go up.
The issue with that however is the current method of automatically calculating it based on bitrate.
That said, if we default to using the calculated value, unless we have an adv setting (which you can set arbitrarily high) then that would be a good solution?
As mentioned on PR2901
Adding an adv setting for setting the throttle amount is more likely to go up.
The issue with that however is the current method of automatically calculating it based on bitrate.
That said, if we default to using the calculated value, unless we have an adv setting (which you can set arbitrarily high) then that would be a good solution?
2013-07-05, 07:20
Sorry to double post, but any thoughts on this approach instead?
https://github.com/Psykar/xbmc/compare/cache-limiter
Zero will disable the cache limiting, 1 is default and identical to current method, >1 will multiple the cache fill limiter.
Would use a float, but then it can't compare to zero for the disable.
https://github.com/Psykar/xbmc/compare/cache-limiter
Zero will disable the cache limiting, 1 is default and identical to current method, >1 will multiple the cache fill limiter.
Would use a float, but then it can't compare to zero for the disable.
2013-07-05, 08:22
(2013-07-05, 07:20)Psykar Wrote: Sorry to double post, but any thoughts on this approach instead?
https://github.com/Psykar/xbmc/compare/cache-limiter
Zero will disable the cache limiting, 1 is default and identical to current method, >1 will multiple the cache fill limiter.
Would use a float, but then it can't compare to zero for the disable.
i don't like adding a new setting.
better look into integrating it without any setting
2013-07-05, 08:27
Just setting it to zero the way you presented didn't work for me. It's similar to disabling the limiter's while loop, but I found that the problem actually came at various times due to what was being returned in response to IOCTRL_CACHE_STATUS ioctl.
2013-07-05, 08:35
(2013-07-05, 08:27)alex_a Wrote: Just setting it to zero the way you presented didn't work for me. It's similar to disabling the limiter's while loop, but I found that the problem actually came at various times due to what was being returned in response to IOCTRL_CACHE_STATUS ioctl.
Ah right, hense the -1 in the actual PR:2901
Could still add that change, but using the different config setting.
edit: added to my branch - https://github.com/Psykar/xbmc/compare/cache-limiter
(2013-07-05, 08:22)Martijn Wrote:Fair enough, but unfortunately it seems that people object to removing the cache write limiter entirely...(2013-07-05, 07:20)Psykar Wrote: Sorry to double post, but any thoughts on this approach instead?
https://github.com/Psykar/xbmc/compare/cache-limiter
Zero will disable the cache limiting, 1 is default and identical to current method, >1 will multiple the cache fill limiter.
Would use a float, but then it can't compare to zero for the disable.
i don't like adding a new setting.
better look into integrating it without any setting
If we are just going to bump up the rate, what's a reasonable value? Double the current? (add a *2 instead of using the multiplier setting I suggested)
2013-07-06, 16:10
It would be best if XBMC disabled the throttle on it's own when either of the following are true, (Please note, Buffer, not cache. Cache is something different than what we're discussing.)
A) Buffer is less than 75% full. Throttling should only be done to prevent over-run, not all the time.
B) XBMC's bitrate calculations are going to be wrong. (TS streams, variable bit rate content, non media packing in the transport...)
Really, I don't see *why* XBMC uses media bit-rate to throttle, as opposed to a 'token pool consumption' model. Trying to be too clever by using the media bitrate is a lot of effort that results in a problematic rate limiter that is no better than content agnostic rate limiting. No having to estimate bit-rate, no having to work out container overhead, no problems if there's padding or extra data in the container stream...
Start with seven 'tokens' in the pool, add seven[1] tokens for every period then subtract one to ten tokens from the pool based on the percentage the buffer is full. Download blocks when there are no tokens in the pool. You could change the buffer pool. to add eight, or six tokens per period, depending where you want the high tide mark of the buffer to be. A maximum number of tokens should also be present, so that bursty-traffic doesn't flood, but that's harder to identify what it should be.
A) Buffer is less than 75% full. Throttling should only be done to prevent over-run, not all the time.
B) XBMC's bitrate calculations are going to be wrong. (TS streams, variable bit rate content, non media packing in the transport...)
Really, I don't see *why* XBMC uses media bit-rate to throttle, as opposed to a 'token pool consumption' model. Trying to be too clever by using the media bitrate is a lot of effort that results in a problematic rate limiter that is no better than content agnostic rate limiting. No having to estimate bit-rate, no having to work out container overhead, no problems if there's padding or extra data in the container stream...
Start with seven 'tokens' in the pool, add seven[1] tokens for every period then subtract one to ten tokens from the pool based on the percentage the buffer is full. Download blocks when there are no tokens in the pool. You could change the buffer pool. to add eight, or six tokens per period, depending where you want the high tide mark of the buffer to be. A maximum number of tokens should also be present, so that bursty-traffic doesn't flood, but that's harder to identify what it should be.
2013-08-20, 09:29
For those that might have missed it, we now have a buffer limiter setting: https://github.com/xbmc/xbmc/pull/3104
Also made a new guide for using the three AS.xml settings: HOW-TO:Modify the cache (wiki)
Also made a new guide for using the three AS.xml settings: HOW-TO:Modify the cache (wiki)
