(2013-09-04, 04:10)krustyreturns Wrote:

(2013-09-04, 03:29)smacrae Wrote: Hi KR....does that mean from the time it one selects a channel to the time it is rendered on the screen will speed up? We're not channel surfers but having it start around 5-7 seconds is acceptable, 12-15 is a bit long.....thanks...

Yeah, well that's the goal.

Details for die-hards:

I have definitely knocked 3 - 5 sec out the delay of the start of a live tv view. I did this by re-writing the wtv parser. One of challenges in active wtv data, is to determine the actual amount of data in the file, since MS creates a giant file, growing in .5 GB chunks, and filling in the data as it goes. My old way of doing it was to detect the length of the actual data by polling a field in the header of the file, that Jeff found to be updated with the actual file length. the problem with this is that this field is updated by the windows service about 3-5 sec after data is written, so we were always late by this amount.

So I found a way to I parse the data as soon as the rec service writes it, eliminating this delay. Immediately after a packet of data is written I start remuxing it to ts for transport to xbmc. I have also made some slight improvements in the remux delay, but really it has never been the problem - ts data is available almost immediately after the wtv data is output from the tuner.

There is still a delay from when the data is available from the tuner. I might be able to improve this a little, but the jury is still out on that.

Then there is the delay that xbmc waits before it starts displaying the ts data I am sending it. I can't do much about this, but some have been reporting that the 'margo' build of frodo reduces this significantly, so I am hoping that will be the case.

There are other possible tricks to try, but that's after the next version.

(2013-09-05, 02:11)hoopsdavis Wrote: I just got things setup again and the positive is I'm changing channels within 6 seconds. (That's satisfactory to me)
what I've noticed on the negative side but not a deal breaker: I have xbmc setup on 2 PC's with one PC as the server everything works great but when watching one channel in the bedroom, I'm unable to tune to that some channel in the living room. (This isn't a problem with mediaportal) But still not a deal killer, I'm sure this is something that'll be worked out soon. Another thing I've noticed, when I have a channel running in the bedroom and another in the living room, I noticed skips of picture and audio at both locations. (Not a major skip but a second or two) Maybe I can tweak a bit and get this right but so far the progress is great. I've gone from 12 seconds to 6 seconds on channel changing, that's serious progress. Good work

(2013-09-05, 01:05)smacrae Wrote:

(2013-09-04, 04:10)krustyreturns Wrote:

(2013-09-04, 03:29)smacrae Wrote: Hi KR....does that mean from the time it one selects a channel to the time it is rendered on the screen will speed up? We're not channel surfers but having it start around 5-7 seconds is acceptable, 12-15 is a bit long.....thanks...

Yeah, well that's the goal.

Details for die-hards:

I have definitely knocked 3 - 5 sec out the delay of the start of a live tv view. I did this by re-writing the wtv parser. One of challenges in active wtv data, is to determine the actual amount of data in the file, since MS creates a giant file, growing in .5 GB chunks, and filling in the data as it goes. My old way of doing it was to detect the length of the actual data by polling a field in the header of the file, that Jeff found to be updated with the actual file length. the problem with this is that this field is updated by the windows service about 3-5 sec after data is written, so we were always late by this amount.

So I found a way to I parse the data as soon as the rec service writes it, eliminating this delay. Immediately after a packet of data is written I start remuxing it to ts for transport to xbmc. I have also made some slight improvements in the remux delay, but really it has never been the problem - ts data is available almost immediately after the wtv data is output from the tuner.

There is still a delay from when the data is available from the tuner. I might be able to improve this a little, but the jury is still out on that.

Then there is the delay that xbmc waits before it starts displaying the ts data I am sending it. I can't do much about this, but some have been reporting that the 'margo' build of frodo reduces this significantly, so I am hoping that will be the case.

There are other possible tricks to try, but that's after the next version.

Great, so that code is in the master for us to all try or yet to be released?

(2013-09-05, 03:52)krustyreturns Wrote:

(2013-09-05, 02:11)hoopsdavis Wrote: I just got things setup again and the positive is I'm changing channels within 6 seconds. (That's satisfactory to me)
what I've noticed on the negative side but not a deal breaker: I have xbmc setup on 2 PC's with one PC as the server everything works great but when watching one channel in the bedroom, I'm unable to tune to that some channel in the living room. (This isn't a problem with mediaportal) But still not a deal killer, I'm sure this is something that'll be worked out soon. Another thing I've noticed, when I have a channel running in the bedroom and another in the living room, I noticed skips of picture and audio at both locations. (Not a major skip but a second or two) Maybe I can tweak a bit and get this right but so far the progress is great. I've gone from 12 seconds to 6 seconds on channel changing, that's serious progress. Good work

I haven't released the new sped up server yet, so whatever you are doing you have accomplished it on your own . Are you doing something special to get a 6 sec channel change?

The problem with some channels not working on a remote client might be addressed on the next release. I did find some problems on the client side that may cause this. Not sure about the skips that happen when the server is running two streams though.

BTW I noticed that genre color coding was not working on the latest release due to the new wix installer. This will be fixed too.

---

(2013-09-05, 01:05)smacrae Wrote:

(2013-09-04, 04:10)krustyreturns Wrote: Yeah, well that's the goal.

Details for die-hards:

I have definitely knocked 3 - 5 sec out the delay of the start of a live tv view. I did this by re-writing the wtv parser. One of challenges in active wtv data, is to determine the actual amount of data in the file, since MS creates a giant file, growing in .5 GB chunks, and filling in the data as it goes. My old way of doing it was to detect the length of the actual data by polling a field in the header of the file, that Jeff found to be updated with the actual file length. the problem with this is that this field is updated by the windows service about 3-5 sec after data is written, so we were always late by this amount.

So I found a way to I parse the data as soon as the rec service writes it, eliminating this delay. Immediately after a packet of data is written I start remuxing it to ts for transport to xbmc. I have also made some slight improvements in the remux delay, but really it has never been the problem - ts data is available almost immediately after the wtv data is output from the tuner.

There is still a delay from when the data is available from the tuner. I might be able to improve this a little, but the jury is still out on that.

Then there is the delay that xbmc waits before it starts displaying the ts data I am sending it. I can't do much about this, but some have been reporting that the 'margo' build of frodo reduces this significantly, so I am hoping that will be the case.

There are other possible tricks to try, but that's after the next version.

Great, so that code is in the master for us to all try or yet to be released?

Yet to be released.

(2013-09-05, 14:36)TheImmortal Wrote: Has anybody tried this using one of the Gotham builds? Do you know if the Margo code made it into Gotham?

(2013-09-06, 00:33)scott967 Wrote:

(2013-09-05, 14:36)TheImmortal Wrote: Has anybody tried this using one of the Gotham builds? Do you know if the Margo code made it into Gotham?

I have 0827 nightly installed and AFAICT, no PVR clients are working. Enabling any causes Gotham to pop up an error window.

scott s.
.

(2013-09-06, 05:07)hoopsdavis Wrote: Krusty, when will you release the next version of wmc_pvr?

(2013-09-06, 06:34)krustyreturns Wrote:

(2013-09-06, 05:07)hoopsdavis Wrote: Krusty, when will you release the next version of wmc_pvr?

Its a big departure from what I was doing, so I want to spend a little more time with it before a general release. I hope I can release it tomorrow, or at least by Saturday.

(2013-09-06, 09:29)asm495 Wrote: Is there any more news on a Linux x64 build please? Thanks!

(2013-09-06, 16:28)Jmhthefirst Wrote: Any chance I missed an iOS or Android/Ouya client by now?