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-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.
(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.
(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.
(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.
(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