Inhibit Unnecessary Channel Change

[adi2004]

A bit technical this one. When there are several recordings scheduled to follow on one after the other, it would be nice if GB-PVR did not attempt to change the channel for the next scheduled job when it is the same as the channel number for the current job.

i.e. If Job #1 is recording channel 402 from 18:00 to 19:00 and Job #2 also records channel 402 from 19:00 to 20:00, GB-PVR would not attempt to change the channel at the start of Job #2 - which is what happens now (even when they overlap)

Why? Well, if like me you have an NTL PACE cable box, controlled via a RedEye serial infrared "emulator" you will know that you have a 40% chance of the channel change failing because the cable box's processor is so underpowered that it misses one or more digits (this even happens with the supplied remote control) So, simply put, I like to reduce my risk factor

Also, when you have consecutive programs that run ahead of schedule (as seems to be habitually the case with the Sci-Fi channel) you end up with a 1 or 2 second black gap in the programming while the sloth-like PACE box actions the channel change request - and these muck up attempts to join the end of program 1 to the start of program 2 to get the first few minutes of the show.

[Lucas_24]

I thought about this as well, but GBPVR has no way, if controleld through an IR interface, to know if the commands were seccessful. So in your case, what if the first channel change failed but you were recording 2 consecutive shows on the same channel, you'd miss the second one as well since it would not try to change the channel for the sedond recording. At least this way you have the same odds at a successful recording every time.

[adi2004]

Quote[/b] (Lucas_24 @ Nov. 02 2004,15:12)]I thought about this as well, but GBPVR has no way, if controleld through an IR interface, to know if the commands were seccessful.  So in your case, what if the first channel change failed but you were recording 2 consecutive shows on the same channel, you'd miss the second one as well since it would not try to change the channel for the sedond recording.  At least this way you have the same odds at a successful recording every time.

Believe me, I've messed about with this problem for ages. In fact, I've written my own version of the command line channel changer that fires the channel change code twice because I found that, statistically, the second attempt to change a channel is more successful.

This method used to work quite well because if the PACE didn't receive all three digits it just dropped back to the current channel, so a failed channel change had no effect. Unfortunately, NTL then decided to implement channel 0, so if you have channel 402 and only the 0 gets through (which by Sod's Law it usually does) it changes to the godawful Front Page preview service. Needless to say this is intensely annoying, but that's NTL for you: Interactive buttons that don't do anything, sub optimal bitrates, channels broadcast on the wrong channel number, random anamorphic mode on 4:3 broadcasts - yep, you get it all

Anyway, off the rant, maybe there is an even better way of doing this: How about an option "Inhibit Channel Change" for a recording, then I could either use the built-in diary of cable box to change the channel, or just leave it set on the right one. That way the choice is given to the user instead of impacting people who wouldn't like this function for the reasons you mentioned.

[sub]

I think you're better off fiddling with the repeat count and inter-digit delay until you get it receiving IR channel changes reliably.

I wouldn't be able to add this to the next release, but maybe sometime in the future.

[adi2004]

Quote[/b] (sub @ Nov. 03 2004,11:11)]I think you're better off fiddling with the repeat count and inter-digit delay until you get it receiving IR channel changes reliably.

Unfortunately that isn't the issue. The unreliable communication is not due to a problem with the IR detection; this frequently happens with the supplied remote control.

The fault lies in an underpowered set top box being asked to do too much. Anyone who uses NTL will be familiar with the excrutiatingly slow programme guide which, to all intents and purposes, is unusable. tbh I wouldn't even use an IR channel changer at all if the NTL program guide actually worked (i.e. it didn't take three and a half hours to navigate to the program you want to record, with every keystroke on the remote taking between six and sixty seconds to be actioned) *and* if it held more than two days of data.

Anyway, it's an imperfect world. If you can add that feature at some point it would be appreciated. In the meantime, the easiest way for me to do this is to unplug the RedEye interface when I don't want channel changes sent to the box.

[tkgafs]

Out of interest is anyone using a redeye serial with telewest rather than ntl in uk.

I had considered buying one but this thread has rather put me off.

I have to be honest though I dont have any problems changing channels on my telewest box using the remote in the way adi2004 seems to with NTL.

So it may be be the problem is ntl rather than anything else

any comments folks

tkgafs

[adi2004]

Quote[/b] (tkgafs @ Nov. 04 2004,07:58)]Out of interest is anyone using a redeye serial with telewest rather than ntl in uk.

I had considered buying one but this thread has rather put me off.

I have to be honest though I dont have any problems changing channels on my telewest box using the remote in the way adi2004 seems to with NTL.

So it may be be the problem is ntl rather than anything else

any comments folks

tkgafs

Just to be clear, I believe that the RedEye is a fine product that works well for a lot of people on a lot of different systems. 60% of the time it all works fine for me ... unfortunately, due to Sod's Law, the 40% will always, without fail, affect the most important recordings

If you don't have a problem with dropped digits when changing channels on Telewest, you'll probably be OK. Make sure your box is on the list of those compatible, though.

[eruanion]

Sorry to resurrect an old thread, but I just wanted to say that I'd love if an option to do this was added. I don't have an issue like discussed above, but it would be great to not have to set up manual recordings for consecutive recordings on the same channel.

On a side note, is there anyplace in the forums or elsewhere where the developer(s) give updates on what is being worked on for the next release?

[sub]

On a side note, is there anyplace in the forums or elsewhere where the developer(s) give updates on what is being worked on for the next release?

Sorry, I prefer not to give any public list of things being worked on for the next release. I found if I do, users start trying to reprioritize my work, or trying to force changes they want into the next release, or they get upset if some feature I'd intended to add doesnt appear for the final release (for example, technical problems implementing some change etc).

[eruanion]

Fair enough, I was just curious. I can see how that would be annoying. Thanks for the reply.