Firewire channel change delay..

[derringer]

Is it just the way I set things up, or does everyone who is using Firewire Channel Changing + Hd-PVR have the same strange delays? As it stands, the HD-PVR retunes itself, *then* the cable box changes the channel via firewire. Couldn't the firewire channel change take place first, reducing the delay to tune the new channel?

I would think that this would be at least several seconds faster.

Anyone have any ideas or is my setup just screwy in that it does it this way?

[derringer]

Just to add some clarification to this post:

I believe that the HDPVR first tuning the signal, and *then* the channel change taking place is what causes most of the issues with the audio and video sync and other HDPVR issues as well.

If the channel change could take place *before* the tuning, it would be a much better and more elegant solution.

Does anyone know if this is possible? I am using exe2multituner, but am open to other suggestions if anyone has them working.

the resolution and audio spec changing in the middle of a recording, which is what happens when the channel change takes place *after* the tuning of the HDPVR, is really not a good method for reliable recording, imo.

[Opus4]

What exactly are you doing when the HD-PVR starts recording before the channel change occurs? I think I've seen this happen in Channel Setup due to the way it works when you preview a channel, but when I start regular recordings, the HD-PVR doesn't start recording until after the channel change occurs. The mmc/encoders/<some #>/delay_to_wait_after_tuning property can extend how long it waits to start recording after tuning the channel.

- Andy

[MacDaddy]

I think I have seen what derringer describes and I'll try to describe it myself as well (derringer - please feel free to correct me if this is nor your experience). When I select a recorded show that was captured with the HD-PVR, I find that many times it will open with the last seconds of capture of the prior channel that was tuned. I can then see the STB UI pop up and the characters for the "to be" recorded show's channel be entered onto the screen. The STB then changes to the appropriate channel, settles down, and the show displays. From my experience, it is at this point of changing channels that most of the sync issues appear to begin.

I believe what derringer may be asking is that the channel change event occur and the STB have time to "settle" before the capture is demanded from the HD-PVR.

Did that capture the problem derringer?

[Opus4]

Originally Posted by MacDaddy

I believe what derringer may be asking is that the channel change event occur and the STB have time to "settle" before the capture is demanded from the HD-PVR.

If so, then I posted the property for that above. It now defaults to something like 4 seconds (4000 milliseconds), but you can increase it while SageTV is not running.

- Andy

[derringer]

Well, you are both close to what I was trying to say, but I will explain how I understand the 4000ms delay and why it isn't quite as elegant a solution as could be implemented, imo:

I believe the delay just delays the tuning for 4 seconds, but it doesn't actually change what is happening in the background, unless I misunderstand it.

Without the delay set, basically, you can get a 3-4 second delay in SageTV with a whirly timer icon, then you see the channel be tuned in by the HD-PVR, then you see the firewire channel change go through on screen, then you see the channel change.

With the delay set to 4000, you get a 7-8 second delay in SageTV with a whirly timer icon, then you see the channel be tuned in by the HD-PVR and you *STILL* sometimes see the tail-end of the firewire channel change sometime around 3000-4000ms. In other words, it appears that the system is doing things in somewhat of a screwy order. I suppose I'm talking about whether this is a exemultituner plugin thing or whether it is a Sage design thing.

My question is why would Sage attempt to tune the channel before the firewire channelchange, or any channel change, for that matter, is effectuated? In the days where we were using coaxial cable boxes, and channel changes were immediate, I can see it not mattering, but when you add extremely long delays in the tuning cycle, it only stands to reason that channel changing, (and as a result, resolution and audio changes,) should be made before the tuning is even attempted.

Having a computer science degree, I know that this is a design thing, and that the channel changing mechanisms would have to return a completion message of some sort so that Sage would know when to tune, but I think you could stop just short of that and just put user-changeable delay variables in the properties file for how long to wait and solve the issue.

In my experience dealing directly with hardware in code (in this case, the HD-PVR,) it would be quite easy to effectuate the channel change before the tuning was even attempted.

If this is what the 4000ms delay does, then I must have not seen it, because it appears to still be doing the firewire channel change very late in the sequence of channel-changing events.

From a purist perspective, if we are going to be tuning the device and letting the capture device deal with resolution and audio output changes itself (and hopefully more gracefully in future capture devices, ) then why don't we adjust the channel-changing plugin code so that it fires immediately upon channel changing, instead of putting at the very tail end of the sequence? It would seem to me that in a perfect world, the capture device could gracefully handle channel, resolution, and audio changes, and then we would want to put the firewire or other channe changing code immediately or concurrently with the tuning code, so as to speed the entire process up 3-4 seconds, but maybe there is a reason I am missing?

I don't mind having a wait for a channel change, but I see no reason for the channel change to be so late in the code sequence is all, I suppose... I mean, realistically, we are dealing with two seperate and disparate pieces of hardware here, and there is no reason for the channel-change to have to 'wait' for the tuning of another device. Does that make sense? Maybe since we are dealing with a capture and channel change on seperate devices and not the same device, that is why we have these issues, but does anyone really think the model of separate capture devices and channel-changing tuning devices is going to go away? A good 3-4 seconds could be saved on every single tuning of an HD-PVR if we just had the channel-changing code fire earlier in the sequence, no?

[Opus4]

As far as I know, SageTV can't know exactly when your STB has completed its channel change, nor does it know how long it takes to complete the firewire channel change command sequence.

As I mentioned in my last post: increase the time for the property I mentioned. I set mine to around 9 seconds to be sure the STB has had time to settle onto the new channel.

- Andy