"Trickle Caching" for HD Content Streaming

Whatever, you brought it up "Remember that the ATV3 upgraded their system memory from 128mb to 256mb to be able to handle 1080p streaming", ATVs never had 128MBs of ram, so your example is bogus as an ATV2 is perfectly capable of handling 1080p streaming as is. It's the greater memory bandwidth from A4 to A5 that has allowed Apple to enable 1080p decode on the ATV3.

3-4mbps streams. Thats not quite high bitrate. Even XBMC on the PI can handle 10mit streams with his 100MBit usb networkdevice. It smells like a networkproblem in your setup. Against a bad setup we can't do anything.

And as I said, I typed the wrong memory sizes for the models by accident. Now look, at the moment you're just in this thread now to pick a fight, and disrupt a discussion on cache streaming sizing. If you have anything to contribute to what the default memory size, low-watermark and high-watermark should be, please do so.

Having toyed around, I think that with the amount of 1080p streamed content now available, 64mb with a low-watermark of 30% and a high watermark of 60% would be better than the current apparent default of 5mb and an unknown low/high-watermark. If the cache is too small, trickle-feed when over the high-watermark does nothing to help. I'd even consider 128mb as the default if on a suitable system.

Is it feasible to have a default that depends on identifying the available system memory?

---

(2012-05-07 22:57)gimli Wrote:  3-4mbps streams. Thats not quite high bitrate. Even XBMC on the PI can handle 10mit streams with his 100MBit usb networkdevice. It smells like a networkproblem in your setup. Against a bad setup we can't do anything.

That's local network low-latency traffic, which isn't a problem because the delay added from a buffer overflow is insignificant. It becomes a problem when you're getting the stream from a higher-latency WAN source.

---

Also, just run some tests. Sourcing video from 'Crunchyroll' (Using the Crunchyroll Takeout plugin) that I know comes from a source that has the bandwidth to deliver to me but if from a different continent so has high latency. With default caching, the 1080p stream keeps bouncing into 'caching' every twenty seconds or so. With caching increased to 128mb (or what ever the hard coded limit is), I can play back the from the same source without a 'caching' pause during playback for the entire 24 minute episode.

So no, not a problem with my networking. A problem with XBMC's caching defaults.

we understand that our current caching policy does not fit all users, we welcome patches to resolve this but to be fair, just increasing the amount of caching will not resolve the issues for all users. We have been there, done that already. See advancedsettings.xml and there are settings there to alter the caching.

Right, so you acknowledge XBMC isn't going to be able to cope with 1080p internet streaming services very well. What do you intend to do about it?

(2012-05-07 23:07)barberio Wrote:  Right, so you acknowledge XBMC isn't going to be able to cope with 1080p internet streaming services very well. What do you intend to do about it?

With that attitude you are no getting any further. That remark looks a bit pushy like you are forcing to take action

Like Davilla said: "patches are welcome"

Right... So, we go from "There is no problem here." "I am going to nitpick an unrelated mistake about hardware models in your post and go on about unrelated stuff to berate you." to "We have been there, done that already." to "Patches are welcome".

Right now my suggestion was "Increase default cache size", but that's apparently not something that's interested in, so a patch won't do much will it. So what should be done if not a default cache size increase?

(2012-05-07 23:07)barberio Wrote:  Right, so you acknowledge XBMC isn't going to be able to cope with 1080p internet streaming services very well. What do you intend to do about it?

Not a damm thing with your attitude.

Again, what do you think would fix the problem, if not increasing the default cache size which you've already rejected?

Silly rabbit, if I knew what would fix the problem, the problem would be fixed.

AdvancedSettings.xml has setting to alter the cache, it's there because we do not believe it is the proper way to fix this issue, yet it seems to help some users so we expose those settings there. You can also make the value zero and it changes to a file based caching method that will suck down the entire file.

Now if you really want to contribute to solving this issue, then come up with a better way than a hammer approach of increasing the caching size, that just solves the problem by hiding it.