Improve reliability of STB channel changing?

[jksmurf]

Apologies for starting a new thread but I think it is worth doing so now that I have a reasonable idea of the blaster utilities and commands required to operate my IPTV STB.

What I didn’t realise was there is a whole industry surrounding IPTV channel zapping (it even has a name!) with lots of research papers etc etc.

Anyway, whilst sub has patiently explained the whole IR Blasting process is SLOW and the technology hasn't changed i.e. it remains a crude simualtiuon of someone pressing a remote, the thing I still don’t understand is that when I just plug the STB to my HDMI Monitor (or TV) the remote presses are reliable.

I have purposely not mentioned instantaneous as sub has explained that the whole NPVR Client->NextPVR Server->IR Blaster (USB or Capture Card based)->STB->Capture Card->PC->Client->TV is slow, as above. I don't really care about the speed of the channel change TBH I don't channel surf (at least not right now).

However as I mostly watch recorded programs, I need to know it is going to be reliable and record the show I need.

I did a couple of trials as follows:

1. STB -> direct to HDMI Monitor, changing channels using STB remote - fastest changes (as expected) but also reliable; even after I did many changes sequentially.
   
2. STB -> [b]direct to HDMI Monitor, changing channels using USBUIRT (manual zap using cmd + a uutx batch) [/b]- reasonably fast changes (as expected) also reliable, even after I did many changes sequentially.
   
3. STB->Colossus in PC, NextPVR changing channels using USBUIRT (uutx-based batch) - slow changes (as explained) but unreliable, especially after I did a number of channel changes sequentially. I tried this with various permutations of "Restart on Live TV Channel Change" and "
   

My STB output is set for a fixed resolution of 1080i.

So my questions are:

• Why is (3) unreliable? See these pictures on another thread for examples of missing channel digits (1st, middle, last...).
  
• How do I improve the reliability of STB channel changing?
  
• What governs it?
  • Would a better / faster capture card (I have a Colossus I (HDPVR) which this thread suggests might be an issue?) take something out of the time needed for the change? I am more than happy to buy a new capture device if this will likely help.
    
  • Do IPTV STBs have some sort of buffer that needs to empty before you can "zap" the next channel
    
• My config.xml shows <HDPVRBufferLonger>false</HDPVRBufferLonger>. Would setting this to true help?
  
• My config.xml shows <WaitLongerDelay>6500</WaitLongerDelay>; would changing this help? Appreciate that referred thread back at 3.3.8 was fixed by sub via a patch for that posters problem.
  

Lots of questions, sorry!

Cheers

k.

[sub]

he thing I still don’t understand is that when I just plug the STB to my HDMI Monitor (or TV) the remote presses are reliable.

Unfortunately there is a lot of differences in the IR signals from different manufacturers. When they build a remote for their STB (or TV), they know obviously know exactly the type of signals the receiver is expecting, and the remote is made to generate exactly those types of signals.

The USBUIRT and other learning blaster don't really know any details about the IR remote you're trying to emulate. It goes through a process of trying to record the IR signals for each button, but will not capture it precisely. There is a lots of things going on even to send a single digit, like modulation rate, in-bit spacing, headers, how many times the code is repeated (somewhere between 1-4 per digit) etc. There is also other things the IR blaster doesn't capture, like how long it needs to wait between digits, before sending the next digital. It's usually close but not exactly the same, and some guess work involved.

There is another type of blaster, like those include with many of the Hauppauge devices, don't use IR learning. Instead, they buy a database of IR signals from someone like OneForAll (who make universal remotes), and that database tells them how to generate the same signals as the original remote. So...as long as your STB one of those in the database, you can end up with pretty good blasting success. Downside - if you STB is not on that list, then you're out of luck.

How do I improve the reliability of STB channel changing?

It'll often come down to things like the repeat count and inter-digit delay. Your blaster software may allow you to tweak these. I know USBUIRTSend.exe allowed for these to be changed in the learned data file. uutx may also have something.

What governs it?
Would a better / faster capture card (I have a Colossus I (HDPVR) which this thread suggests might be an issue?) take something out of the time needed for the change? I am more than happy to buy a new capture device if this will likely help.
Do IPTV STBs have some sort of buffer that needs to empty before you can "zap" the next channel

It pretty much just comes down to the IR Blaster you're using, and it's software, and how close it is to the signals that come from a real remote.

My config.xml shows <HDPVRBufferLonger>false</HDPVRBufferLonger>. Would setting this to true help?
My config.xml shows <WaitLongerDelay>6500</WaitLongerDelay>; would changing this help? Appreciate that referred thread back at 3.3.8 was fixed by sub via a patch for that posters problem.

These wont make any difference to how reliable your IR blasting is. These are just NextPVR settings that effect smoothness when starting playback of live tv with these types of devices. The actual blasting accuracy is strictly down to the blasting software you're using (USBUIRTSend.exe, uutex.exe etc).

If you're finding your blaster software behaves more badly when other things are happening, it probably means that it's not managing to accurately reproduce the timing that it's trying to. You might be able to look at running a batch file for your blaster, and starting the blaster from there with high priority.

[jksmurf]

Unfortunately there is a lot of differences in the IR signals from different manufacturers. When they build a remote for their STB (or TV), they know obviously know exactly the type of signals the receiver is expecting, and the remote is made to generate exactly those types of signals.

Thanks for your comprehensive response sub, appreciate you taking the time. I've spent some considerable time since your note reading about making IR Codes better and found a site that produces IR Codes for JP1 remotes (and converted those to Pronto HEX) and I also (independently) pulled out my Global Cache devices and learned Codes from those (although goodness knows why the codes change each time they are learnt, might be frequency). For the moment I think I have OK Codes (but feel free to put me right on this). I have not found a way to issue those codes back to the GC Devices but that might be an option to replace the USBUIRT.

The USBUIRT and other learning blaster don't really know any details about the IR remote you're trying to emulate. It goes through a process of trying to record the IR signals for each button, but will not capture it precisely. There is a lots of things going on even to send a single digit, like modulation rate, in-bit spacing, headers, how many times the code is repeated (somewhere between 1-4 per digit) etc. There is also other things the IR blaster doesn't capture, like how long it needs to wait between digits, before sending the next digital. It's usually close but not exactly the same, and some guess work involved.

Understood. I'm never going to know this, although I have been playing around with IrScrutinizer to see if I can make it better.

There is another type of blaster, like those include with many of the Hauppauge devices, don't use IR learning. Instead, they buy a database of IR signals from someone like OneForAll (who make universal remotes), and that database tells them how to generate the same signals as the original remote. So...as long as your STB one of those in the database, you can end up with pretty good blasting success. Downside - if you STB is not on that list, then you're out of luck.

Nope. My STB seems to be very very sparse on the Interwebthingy....

It'll often come down to things like the repeat count and inter-digit delay. Your blaster software may allow you to tweak these. I know USBUIRTSend.exe allowed for these to be changed in the learned data file. uutx may also have something.

Yes, uutx, the native exe for the USBUIRT does, via the -rx and -sx parameters. I have played with these for a while now, even before I sent you logs a few days ago.

It pretty much just comes down to the IR Blaster you're using, and it's software, and how close it is to the signals that come from a real remote.

OK.

These wont make any difference to how reliable your IR blasting is. These are just NextPVR settings that effect smoothness when starting playback of live tv with these types of devices. The actual blasting accuracy is strictly down to the blasting software you're using (USBUIRTSend.exe, uutex.exe etc).

OK. I still seem to have a much slower response when I use the IN-NPVR pop-up Guide (whilst playing a Stream) than when I issue manual uutx channel changes (using the same Batch File and IR Definition). See logs attached. Manually issuing I can see the numbers populating the STB (not always correct but at least I can see it).

If you're finding your blaster software behaves more badly when other things are happening, it probably means that it's not managing to accurately reproduce the timing that it's trying to. You might be able to look at running a batch file for your blaster, and starting the blaster from there with high priority.

OK I need to look into how to do that, I started looking at start "" /realtime etc but I'm struggling with the batch files due to the arguments passed to the batch file.

[macgyver]

Just a quick reply to say I feel your pain - I've been through this not that long ago with similar 'why on earth does that affect it' issues. All I can add is that my changes were near 100% reliable until I upgraded from XP to W10 at which point the chances of all three digits working reduced to about 50%. After a lot of hair-tearing I ended up with a batch file that fired the channel numbers twice with a 10 second pause in between blasts. The first 3-digit blast is still unreliable but the second is 100%. Go figure!

[jksmurf]

Just a quick reply to say I feel your pain - I've been through this not that long ago with similar 'why on earth does that affect it' issues. All I can add is that my changes were near 100% reliable until I upgraded from XP to W10 at which point the chances of all three digits working reduced to about 50%. After a lot of hair-tearing I ended up with a batch file that fired the channel numbers twice with a 10 second pause in between blasts. The first 3-digit blast is still unreliable but the second is 100%. Go figure!

I'm glad I'm not the only one. This really is a very frustrating area of the whole HTPC experience, I cannot fathom why it must be so difficult. I had a (reasonably) well-working system until I got a new STB.

I'm not sure that 10s repeat would work for me, it seems to work OK for 5 or so changes then goes awry, like some buffer fills up and after that it can't take any the numbers.

You wouldn't know how to change the priority of the batch file would you? I tried calling my original batch from a starter batch but the {channel} and IR Defintion arguments don't seem to work.

EDIT: I know how to use start "Name" /realtime command.exe or command.bat --arguments but I am not sure how to get the NextPVR Blaster arguments {channel} and IRDef.ir passed from this starter batch file of the channel changer batch file.

k.

[Graham]

You wouldn't know how to change the priority of the batch file would you? I tried calling my original batch from a starter batch but the {channel} and IR Defintion arguments don't seem to work.

It says ...

In comparison START will instantiate a new CMD.exe shell for the called batch. This will inherit variables from the calling shell, but any variable changes will be discarded when the second script ends.

at ... https://ss64.com/nt/start.html

[jksmurf]

H Graham

Yup I did read that ... but .... doesn't work for me.

My starter Batch

Code:

REM
SET command=GXPC4312H_UUTX.bat
start "" /REALTIME /B %command%
REM

My Working Channel Changing Batch GXPC4312H_UUTX.bat

Code:

@echo off
REM
REM Devcon.exe restart USB\VID_0403*
cd C:\users\public\NPVR\ChanChg\
set "channel=%1"
set "num=-1"
REM by KM
REM timeout 1
REM
:loop
set /a num=num+1
call set "name2=%%channel:~%num%,1%%"
if defined name2 (
REM uutx.exe -r3 -s500 -fGXPC4312H.ir %name2%
uutx.exe -r3 -s10 -fGXPC4312H.ir %name2%
echo %name2%
goto :loop
)
REM timeout 2
REM
REM This is supposed to make the guide go away but I turned it off on NowTV
REM
REM uutx.exe -r3 -s50 -fGXPC4312H_JP_Remote.ir BACK
REM
REM

My Alternative Working Channel Changing Batch GXPC4312H_Changer.bat

Code:

REM
REM Exec: C:\Users\Public\NPVR\ChanChg\GXPC4312H_Changer.bat
REM Arguments: {channel} GXPC4312H.ir
REM
REM GXPC4312H_Changer.bat (THIS FILE)
REM
REM OPTIONS 1,2,3
REM
REM FOR USBUIRT INITIALISE/FIX REMOVE REM FROM "Devcon.exe restart USB\VID_0403*" line
REM
set sleep=0
set loops=5
:WAIT
IF EXIST C:\Users\Public\NPVR\ChanChg\usblock.dat (GOTO PING) ELSE (GOTO CC)
:PING
timeout 1
set /A sleep=%sleep%+1
IF %sleep% EQU %loops% GOTO ERROR
GOTO WAIT
:CC
ECHO wait_lock > C:\Users\Public\NPVR\ChanChg\usblock.dat
REM
REM Devcon.exe restart USB\VID_0403*
REM
set input=%1
REM
REM Timeout 2
REM
if not "%input:~0,1%" == "" C:\Users\Public\NPVR\ChanChg\uutx.exe -r3 -s200 -f%~dp0%2 %input:~0,1%
if not "%input:~1,1%" == "" C:\Users\Public\NPVR\ChanChg\uutx.exe -r3 -s200 -f%~dp0%2 %input:~1,1%
if not "%input:~2,1%" == "" C:\Users\Public\NPVR\ChanChg\uutx.exe -r3 -s200 -f%~dp0%2 %input:~2,1%
if not "%input:~3,1%" == "" C:\Users\Public\NPVR\ChanChg\uutx.exe -r3 -s200 -f%~dp0%2 %input:~3,1%
REM
REM uutx has switches -ra -db -sc -f where a=repeat code, b=device no. [of multiple emitters], c=ms sleeptime f=IRfilename
REM
del C:\Users\Public\NPVR\ChanChg\usblock.dat
exit
:ERROR
ECHO %DATE% %TIME% >> C:\Users\Public\NPVR\ChanChg\changer_error.log
GOTO :CC
REM
REM GXPC4312H.ir contains the IR changer codes
REM

The first one spits out endless garbage ad infinitum.
Too scared to try the second.
Suffice to say I didn't write either :-)

EDIT - I did try start "" /realtime "PATH GXPC4312H_UUTX.bat" in NextPVR but it wouldn't accept that as an executable. It works from the command line.

k.

[Graham]

Yup I did read that ... but .... doesn't work for me.

This worked for me

bat1.cmd ...

Code:

set hiya=hello
set earth=world
start bat2.cmd

bat2.cmd ...

Code:

echo %hiya% %earth%

[sub]

These wont make any difference to how reliable your IR blasting is. These are just NextPVR settings that effect smoothness when starting playback of live tv with these types of devices. The actual blasting accuracy is strictly down to the blasting software you're using (USBUIRTSend.exe, uutex.exe etc).

OK. I still seem to have a much slower response when I use the IN-NPVR pop-up Guide (whilst playing a Stream) than when I issue manual uutx channel changes (using the same Batch File and IR Definition). See logs attached. Manually issuing I can see the numbers populating the STB (not always correct but at least I can see it).

NextPVR doesn't have control over whether your blaster is 'slower'. All it does is run your specified blaster, passing in the channel number required, and waits for the software to finish doing it's thing. NextPVR has no idea how long it will take, or what it is doing, and just waits.

For example, in this case it's run your preferred blaster, passing in channel number 113, then it has waited until the blaster completed, then it continues. In this case your blaster took 2.3 seconds (which seems pretty quick)

2019-03-11 10:18:10.400 [INFO][74] Running blaster: C:\Users\Public\NPVR\ChanChg\GXPC4312H_UUTX.bat 113
2019-03-11 10:18:12.713 [DEBUG][74] About to tune graph

FYI, the main reason NextPVR doesn't have any built in IR blaster device, even though GBPVR did, is because I could see what a support nightmare this type of thing is. It's next to impossible to make it reliable. I decided it was better to just provide hooks, so you could use other peoples blaster software, so they could take care of this. I was working on the assumption there would be other coders beavering away, spending hundreds of hours making the perfect IR blaster software

[jksmurf]

NextPVR doesn't have control over whether your blaster is 'slower'. All it does is run your specified blaster, passing in the channel number required, and waits for the software to finish doing it's thing. NextPVR has no idea how long it will take, or what it is doing, and just waits.

I believe you, just saying what I observe when NextPVR does it vs manually. Maybe it's a placebo effect :-).

FYI, the main reason NextPVR doesn't have any built in IR blaster device, even though GBPVR did, is because I could see what a support nightmare this type of thing is. It's next to impossible to make it reliable. I decided it was better to just provide hooks, so you could use other peoples blaster software, so they could take care of this. I was working on the assumption there would be other coders beavering away, spending hundreds of hours making the perfect IR blaster software

There aren't as far as I can tell....to be fair some folks are trying to help, albeit GlobalCache seems to be alarmed that I am wholly underutilising their device and don't supply a simple command line for blasting :-). Seems like most of the hundreds of hours are by users, but you're a smart guy sub, stay way away from all this (although if I had a wish it would be you could find a few hundred hours to fix that pesky USBUIRTSend.exe, the idea is good with multiple channel digits and intercode delays)...

k.