2012-05-12, 01:12
And I suggest you go look over this thread...
1) First reply, "XBMC already does this." when of course I now know that it doesn't, it does something that may or may not be similar. But it doesn't try to maintain a single constant stream that never quite fills the buffer for the entire content (from what has been posted).
2) Second reply "What are you trying to accomplish?"
3) Third reply, tries to turn it into an argument about "I know the ATV hardware better than you" because I made an error in listing the hardware specs of the models when mentioning that the ATV uses more memory for streaming than XBMC does. Not that this had anything to do with the issue of caching content from a high latency high bandwidth source.
None of that was particularly welcoming, and I feel pretty put upon to be ranted at for trying to get someone to say something definitive about what it is XBMC is doing, could be doing and should be doing.
Now, bobo1on1 is apparently already working on an extended network caching patch. So calls for work on that seem to be duplicating effort and risk conflicting with what's being done there. I've no idea what is being done there, or if it would benefit from having a high/low watermark throttle/release. Or if it could also benefit from include an additional layer of a disk based ring buffer to prevent saturating system memory when streaming a multi-hour 1080P stream.
These are non-trivial things, but it would be absurd to try and patch them in without the devs looking at caching and making some top level design decisions about if a) there should be one caching strategy for everything, b) there should be a disk cache for some content sources and what it's caching strategy should be, c) how much system memory should XBMC try to use for cache and what the minimum cache memory should be...
You can start asking these questions, or ignore them. I don't really care. I've fixed the skipping in and out of buffering problem by forcing XBMC to use 128Mb local memory for it's cache. And will just live with not being able to pause except for brief moments till some better alternative comes along.
1) First reply, "XBMC already does this." when of course I now know that it doesn't, it does something that may or may not be similar. But it doesn't try to maintain a single constant stream that never quite fills the buffer for the entire content (from what has been posted).
2) Second reply "What are you trying to accomplish?"
3) Third reply, tries to turn it into an argument about "I know the ATV hardware better than you" because I made an error in listing the hardware specs of the models when mentioning that the ATV uses more memory for streaming than XBMC does. Not that this had anything to do with the issue of caching content from a high latency high bandwidth source.
None of that was particularly welcoming, and I feel pretty put upon to be ranted at for trying to get someone to say something definitive about what it is XBMC is doing, could be doing and should be doing.
Now, bobo1on1 is apparently already working on an extended network caching patch. So calls for work on that seem to be duplicating effort and risk conflicting with what's being done there. I've no idea what is being done there, or if it would benefit from having a high/low watermark throttle/release. Or if it could also benefit from include an additional layer of a disk based ring buffer to prevent saturating system memory when streaming a multi-hour 1080P stream.
These are non-trivial things, but it would be absurd to try and patch them in without the devs looking at caching and making some top level design decisions about if a) there should be one caching strategy for everything, b) there should be a disk cache for some content sources and what it's caching strategy should be, c) how much system memory should XBMC try to use for cache and what the minimum cache memory should be...
You can start asking these questions, or ignore them. I don't really care. I've fixed the skipping in and out of buffering problem by forcing XBMC to use 128Mb local memory for it's cache. And will just live with not being able to pause except for brief moments till some better alternative comes along.
