The magro build has a 1 line "fix" in it to tell XBMC not to wait too long when attempting to identify the stream that is sent to it when using live TV. Otherwise the stock XBMC waits several seconds. All of this happens after the WMC backend has recorded the live stream, remuxed to TS and then sent it to XBMC as a stream. So krusty can do as much as he can on the backend/remuxing side, but we really need that XBMC fix to really get the channel change down. Hopefully this fix is included in Gotham but I havent looked as yet. Most likely these Magro builds have other changes in them which we dont really want. I suppose one of us might be able to take the official XBMC frodo build and add just this one change to it and build a version that is identical to the Frodo release, save for just that one channel change speedup. That is assuming of course that this isnt already what magro did (im not sure whether his builds have just this 1 fix or whether they include an assortment of other fixes (some of which may be causing the video issues people talk about). It's also possible that this fix itself causes the issues (eg if it couldnt identify the stream in time but gives up because of the shorter timeout specified). It isnt really a fix as much as it's a hack anyhow. I think another guy did have some actual fixes in the ffmpeg code but it gets confusing trying to follow that discussion and the commits on github etc. What seems to have happened is that a pull request got accepted into XBMC frodo but it turned out to not include all of the required changes, then Frodo got locked down and no more changes could be made.
Anyway the next version should contain krusty's speed ups on the backend so even with XBMC still taking longer than ideal to process the stream, it should still be an improvement for everybody.
I did some considerable refactoring of the ServerWMC code to get it more modular and better equiped for future development, but as with all refactoring this introduces the chance for regressions/bugs. Im hoping that krusy approves my refactoring changes so that when the next build comes out all of our testers will be able to not just check the channel change improvements and other bug fixes but also help identify any problems from my refactoring
hoops. im pretty sure I can see why the 2 clients playing the same channel isnt working at the moment, when the 2nd client wants to watch that live channel. the backend cant record and remux it, because it is already recording and remuxing that channel for client 1. Ideally we could just direct client 2 at the existing remuxed TS file but that would have issues since that stream started from when client 1 started watching that channel. If its possible to send the stream to XBMC as well as an offset of where to play from (and have the frontend client skip to that offset) that would be good. Otherwise perhaps the backend could remux a new TS file for client 2, from the existing wtv live stream that is going. We will file it as a bug request so it doesnt get lost. I imagine that everyone would be keener to get a build with the bugfixes and channel change speedups that have alrady been coded and are just being tested by us, rather than wait even longer for more fixes, so I think we will log this bug but not hold up any release for it at this stage