Improve reliability of STB channel changing?

[jksmurf]

From the looks of things you should skip GXPC4312H_StarterUUTX.bat altogether, it does nothing except cause problems. Using the start command to run another batch file makes no sense for tuning. The first batch file will complete and report back to NRecord that it is finished when it may not have. Running with realtime priority should be avoided too but you probably did this to reduce the chance of the "start" problem.

Martin

Agreed ... uutx.exe is doing something so trivial that it is not likely that it will benefit from the "realtime" (or any other) boost that comes from the START command.

Gents - I'm guessing you're both correct. What I was looking for was (as topic) a reliable channel change without missing keypresses.

Suggestions from here and other forums ranged from:

• Improving the learned STB Codes for the remote - with Samsung (my STB) touted as being particularly sensitive to the correct code. For this I learned them using
  (a) subs USBUIRTSend.exe utility (and even his old USBUIRTlearn.exe one)
  (b) ISBUIRT native lrnhelper.exe utility (I have the 0.01, 0.02 and 0.05 versions)
  © Global Caches iLearn.exe utility (Pronto, GC and GC Compressed Formats; latter two for use in my trials using the device as a Blaster)
  (d) Iscrutinizer using the Global Cache Flex Device (Pronto, GC and GC Compressed Formats; ditto)
  
  
• Trying a different Blaster
  (a) The USB-UIRT (my go-to device); this despite (i) the suggestion that the FTDI FT232R chip in it (it might be any of FTDI FT232RL, FTDI FT232BM) might be responsible for missing keypresses [I wrote to Jon Rhees - he said not bit-bang mode] and (ii) The suggestion that the thing was very susceptible to EMF. Case 1; Case 2. I put ferrite beads on both the main wire and the additional transmitter wire, both ends. The small transmitter is stuck on the STB sensor, the main device is well away from it to prevent doubling up. Yes I could use Zones (Z1, Z2,..) to isolate the transmitter but I like to see the red light flash on the main unit ... I also uncoiled my neat coiled up wiring to ensure I wasn't creating a little amplified magnetic field and re-routed the cables away from transformers etc..
  (b) The Global Cache iTach Flex and iTach IP2IR (worked as well as the USB-UIRT but not better).
  © The Colossus Blaster HD-PVR (wouldn't learn the codes, abandoned).
  
  
• Ensuring the transmitter was directed at the sensor, with the right power; I had the USBUIRT blasting full-tilt but went for the small stick-on transmitter in the end. Some have even put those small emitters on a "wand" i.e a stick, a few cm's away from the actual sensor. Didn't seem to make a difference for me.
  
  
• Trying various blaster executables to get the code-issue timing right so as to not miss keypresses by being too fast or too slow or with issue of too many repeat codes, including (playing each time with Repeat and InterCodeDelay settings):
  (a) USBUIRTSend.exe [caused EventViewer crash so had to give up on it despite being a nice utility]
  (b) uutx.exe, the native app for the usbuirt.
  © The Global Cache (GC) executable for use with a GC IP2IR device such as the iTach Flex. Documented here.
  (d) A similar executable for IP2IR issue, TST10.exe, also documented there.
  
  
• Trying various argument settings {channel}=>{channel_d1}{channel_d2}{channel_d3}=>{channel_d1} {channel_d2} channel_d3}=>{channel_d2} {channel_d3} {channel_d3}. NOTE the SPACES and d2 to d4 not d1 to d3.
  
  
• Trying various Batch Files to change sendcode executable priority See below.
  
  
• Contacting your provider; it might be the STB software, or internet speed as the changed channel needs to be fed back to your device by the IPTV provider once selected. Apparently speed of channel change (zap time) is a whole area of research on its own...
  
  
• Tried to turn off the ECO mode on some LCD TV's to check if the TV's auto-ambient lighting function was interfering - no difference for me
  
  
• I tried putting the STB somewhere else I originally had mine under the desk with a curtain in front of it (pretty dark) but it didn't work there, even in several places under the desk. I am still not sure if it had something to do with absence of light (it should not make a difference, IR is supposed to work in the dark!) or interference from some other source. This solution seemed to have the greatest effect.
  
  

Everything (seems) to be more reliable now. Time will tell.

So, back to your comments - below was my original (working) code and it is actually faster than one batch calling another, then it sending 3 instances of uutx. All I wanted from the "start" batch file parameter was for it to be reliable by having a higher priority; it turned out not to be more reliable, just more complex as you state.

Code:

@echo off
REM
REM Used to reset USB-UIRT in case it hangs - not needed
REM Devcon.exe restart USB\VID_0403*
REM
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 (
uutx.exe -r2 -s10 -fGXPC4312H.ir %name2%
echo %name2%
goto :loop
)

HTH someone.

k.

[Graham]

I am still not sure what worked exactly, maybe a little bit of everything but it (seems) to be more reliable now. Time will tell.

SS64 says this about CALL SET ...

This is undocumented behaviour, in fact whenever CALL is run without a : prefix, it will always search disk for a batch file/executable called command before running the internal command. The effect of this extra disc access is that CALL SET is significantly slower than CALL, its use in loops or with a large number of variables should be avoided.

Is the two file version in Post 28 the currently working version ?

If yes, I (and, probably, Martin) are suggesting that you try the second batch file on its own ... putting GXPC4312H_UUTX_Priority.bat as the "exec" in NextPVR Settings.

[jksmurf]

Is the two file version in Post 28 the currently working version ?

If yes, I (and, probably, Martin) are suggesting that you try the second batch file on its own ... putting GXPC4312H_UUTX_Priority.bat as the "exec" in NextPVR Settings.

Yes; for the purposes of the “ Start” experiment to promote priority it is. If there is no observable benefit in “starting” it with a priority call, yes I could indeed run it as a standalone batch file; albeit it seems slower than the one I posted just above.

k

[mvallevand]

As I wrote I believe your approach is wrong. NextPVR will not change channels on you and real-time won't help the speed of light or tuning times on the stb or Hauppauge driver startup which are the delays not the tuner exe itself.

Martin

[jksmurf]

Ok fair enough; I’d agree with you, I just had to go through the process to satisfy myself as what I observed right in the beginning was lightning fast, correct channel changes without NextPVR and slow unreliable ones with it. Hence the trial and error list above. It was on subs suggestion that I looked at start / priority and it was a suggestion that made sense to my simple brain.

[jksmurf]

Just a further progress update and I think I might have isolated the problem for sure this time.

My STB sits (sat) under my computer desk, next to my PC, a computer bass speaker (although not always on), my internet modem and a wireless router. It is also dark under there, although I understand that IR wavelength (any kind?) is wholly unaffected by dark environments, albeit it is affected by direct sunlight (of which there is none under my desk).

In testing the stick-on emitter, which I was trialling a few cm’s away from the sensor in case it was too strong, I realised that every time I moved the box out from under the desk to test it, hey presto, perfect reliable changes. Under the desk again, failures, totally repeatable, blaster-type independent. I didn’t think IR was affected by EMF but maybe the STB itself is. This is a different ‘upgraded’ HD STB to the old SD one I had under that desk for over 5 years, which never had this issue, which is why I never thought to question it.

It simply did not work reliably, dropping keypresses, even when I moved it around to several places under the desk. I am still not sure if it had something to do with absence of light (it should not make a difference, IR is supposed to work in the dark!) or interference from some other source.

It now resides on my desk, and is working perfectly. Touch wood.

k.

[ACTCMS]

The speaker magnet seems the obvious candidate for the interference...

Alex

[AraldoJanes]

Hi...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.

pcb assembly

[jksmurf]

For me with multiple devices there was simply something under the desk it couldn’t handle dodgy power supply being another possibility (to speaker magnet).

[jksmurf]

The USB-UIRT Author came through with an update:

Code:

There is a new version of uutx on the website ([url]www.usbuirt.com/uutx_0_4.zip[/url]) which allows for multiple commands (digits) to be sent if they are comma-separated.

HTH someone.

I changed my channel changer bat from

Code:

@echo on
REM
CD C:\Users\Public\NPVR\ChanChg\
REM
uutx.exe -r2 -d1 -s1 -fGXPC4312H.ir %1
uutx.exe -r2 -d1 -s1 -fGXPC4312H.ir %2
uutx.exe -r2 -d1 -s1 -fGXPC4312H.ir %3
@echo off
REM EXIT
REM

Code:

@echo on
REM
CD C:\Users\Public\NPVR\ChanChg\
REM
uutx.exe -r2 -d1 -s1 -fGXPC4312H.ir %1,%2,%3
@echo off
REM EXIT
REM

My executable is C:\Users\Public\NPVR\ChanChg\GXPC4312H_UUTX_SIMPLE.bat (the above code) with arguments
{channel_d2} {channel_d3} {channel_d4}

I'm not sure if you could just use uutx.exe with the arguments
C:\Users\Public\NPVR\ChanChg\uutx.exe -r2 -d1 -s1 -fGXPC4312H.ir
{channel_d2} {channel_d3} {channel_d4}

Have not tried as bat works OK.

Cheers

k.