[barberio]

My normal reaction to Open Source developers that snidely respond to user case issues with "Submit a Patch" is to refuse to do so. Not everyone has time to contribute to every open source project they use and that doesn't quite fit their needs. I would have been more than happy if you said "We'll look into caching strategies for internet content, but probably not by the next version", but instead it becomes an issue of "We only treat people who submit patches with respect".

This is a structural design issue, not something to leave to a single patch that "scratches an itch". Working out the right ways to cache content from all the different media sources XBMC might see shouldn't be pushed off onto the guy who brought up the issue. Even if I had the time to work on what is actually a pretty big problem, I'd need to fit it in with the rest of the system and things other people are working on. And no one seems at all interested in it so that might be a problem. The contradictory statements on first saying that XBMC does what I wanted, then saying that actually it does something different, and that someone is working on disk caching, or they aren't...

The last time I tried to help XBMC with patches to submit, I ended up duplicating work after explicitly asking if anyone else was working on it and getting a 'no', then finding the person who said 'no' had changed their mind without telling anyone and started some alternative and incompatible work on it, so I wasted my time. I note the issue I was trying to help with, getting the build scripts working on OS X 10.7, still appears to have issues. So I wouldn't be able to do development on XBMC because guess what my build environment is... And no, I'm not interested in setting up a new build environment for XBMC.

[DDDamian]

This is a structural design issue

Bollocks

And no one seems at all interested in it so that might be a problem.

No actually ya lost the interest of a key dev who's actually done some coding on the network streaming caching issues. He's a pretty talented guy. But by acting like that, his natural reaction was to go meh, and wander off this thread to do some real work on issues.

[Martijn]

My normal reaction to Open Source developers that snidely respond to user case issues with "Submit a Patch" is to refuse to do so. Not everyone has time to contribute to every open source project they use and that doesn't quite fit their needs. I would have been more than happy if you said "We'll look into caching strategies for internet content, but probably not by the next version", but instead it becomes an issue of "We only treat people who submit patches with respect".

So ONLY we should invest our own valuable free time instead of you come up with something useful on which we can build further?
Wasn't it whole point of open source software that EVERYONE can contribute?

Working out the right ways to cache content from all the different media sources XBMC might see shouldn't be pushed off onto the guy who brought up the issue. Even if I had the time to work on what is actually a pretty big problem,

Like everyone else who that is working as a volunteer on this project

[davilla]

I note the issue I was trying to help with, getting the build scripts working on OS X 10.7, still appears to have issues. So I wouldn't be able to do development on XBMC because guess what my build environment is... And no, I'm not interested in setting up a new build environment for XBMC.

Build on xcode4 under 10.7 is now fixed. If you remember, from the last time. The issues was with us targeting 10.4 sdk. We now target 10.6 sdk. That took a series of careful moves in both main xbmc code and depends code which has happened the past week.

[barberio]

"Submit a Patch" is still the most alienating dismissive way of responding to someone who has not yet indicated they want to assist as a programmer in fixing what they see as a problem. As I said, I would have been perfectly happy if it had been accepted as something to be looked at, but not a priority for immediate work.

I would also have been somewhat more happy if someone had actually ever told me, when I asked multiple times, what the current XBMC caching strategy is. I am still confused over the initially response that "XBMC already does this" when it appears that it does something different, and with a limit on the default maximum cache that limits the utility of what it does do.

[barberio]

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.

[Martijn]

well that closes this case