USBUIRTSEND not sending newly learnt codes to USB-UIRT?

[jksmurf]

Do you get the crash when you run USBUIRTSend.exe from the command line, or does it only happen when NextPVR runs it?

I think only when NextPVR runs it...
I tried the HD-PVR blaster solution but it took a long time to get it to recongise the remote then it didn't balst it.

I am looking for a new channelchanger exectuable (maybe uutx) if I can work it for 3 digit numbers.
Your USBUIRTSend app is considerably more elegant in that d1 to d4 can be input.

k.

[jksmurf]

I can confirm it is also on the commandline version.

Code:

Faulting application name: USBUIRTSend.exe, version: 0.0.0.0, time stamp: 0x459ec131
Faulting module name: USBUIRTSend.exe, version: 0.0.0.0, time stamp: 0x459ec131
Exception code: 0xc0000005
Fault offset: 0x000011e0
Faulting process ID: 0x33f4
Faulting application start time: 0x01d4d4d37cffa9ca
Faulting application path: C:\Users\Public\NPVR\USBUIRTSend.exe
Faulting module path: C:\Users\Public\NPVR\USBUIRTSend.exe
Report ID: aec22943-bbe2-47f0-b54d-dffca428acdf
Faulting package full name:
Faulting package-relative application ID:

There is an application error followed by a bunch of these "For Information"

Code:

Fault bucket , type 0
Event Name: APPCRASH
Response: Not available
Cab Id: 0

Problem signature:
P1: USBUIRTSend.exe
P2: 0.0.0.0
P3: 459ec131
P4: USBUIRTSend.exe
P5: 0.0.0.0
P6: 459ec131
P7: c0000005
P8: 000011e0
P9:
P10:

Attached files:

These files may be available here:
\\?\C:\ProgramData\Microsoft\Windows\WER\ReportQueue\AppCrash_USBUIRTSend.exe_ecff46b2a3e789b23de220cfebafc4d880e1b4f4_2e54f6e7_289f342d

Analysis symbol:
Rechecking for solution: 0
Report Id: aec22943-bbe2-47f0-b54d-dffca428acdf
Report Status: 528484
Hashed bucket:
Cab Guid: 0

[sub]

Does any blasting happen? ie, do you see any digits sent to your set top box?

[jksmurf]

Does any blasting happen? ie, do you see any digits sent to your set top box?

Odd thing is that before i got these errors it did send them all, and occasionally it would work well and I thought Eureka. Recently it sometimes does often only one or two digits but once it starts failing to change channel it is like there are unfulfilled blasts going on so the next try it might send a digit from the last attempt; then these errors back up and it seems to stop altogether. I’m trying to cobble together a working uutx batch file as a test only (it’s ugly) but there’s not a lot to go on. I’ve contacted the author of the USBUIRT about adding multiple digit arguments to uutx (it’s his blaster exe) and he says he will have a crack at it - not sure when though. This thing makes my system broken though, I have one DTT channel about 20 cable ones via this STB, which can only change channel using a blaster. I thought it was common, was surprised there’s very few IR devices on the market with a simple channel change exe for that purpose.

[jksmurf]

Hi sub,

Well, I'm finally making progress with channel changes, this time I started using uutx.exe (USBUIRTs native exe) and a batch file so I thought I'd report some findings for you and others who might be looking. The batch file (below and attached) is interim while I await Jon Rees (USBUIRT author) udpate to uutx for multi digit channels.

The uutx trial with the IR definition file created by the "USBUIRTSend file learn" syntax was very flaky with uutx, at least for my (Samsung) STB.

• However when I used the IR file that I manually created from PRONTO Codes generated by the USBUIRT lrnhelper.exe utility it worked reasonably well. See Logs_uutx.zip.
  
• Most changes occured as I wanted although I never saw the screen with the number changes being made, unlike with USBUIRTSend; maybe this was because at that precise moment NPVR briefly "stopped responding" as previously discussed. Not sure if this behaviour could be streamlined; be great if yes.
  
• I set repeat to 3 in my lrnhelper trial (you have to set this value in lrnhelper itself, default was 5).
  
• As an aside I found lrnhelper_0.2 did not crash as much as the later lrnhelper_0.5 in doing the learning.
  
• I also learned that Samsung codes can be difficult to capture (esp. TVs), hence possibly why the IR definitions from your USBUIRTSend utility (using learn) and USBUIRTs lrnhelper are different. I attach both but note these apply to my STB only.
  

I then thought OK, just for fun, let's try USBUIRTSend with the lrnhelper IR definition.

• No dice. No channel changes at all; I even tried with d2/d3/d4 and d1/d2/d3.
  
• Reverting to the IR definition created by USBUIRTSend however did work and today, at this time, it worked pretty well, akin to uutx, working it's way through the channels. However as I changed more and more often, it (also) started missing the last one or two digits and eventually would not change - whether this is due to the mounting Windows error I do not know. See Logs_USBUIRTSend.zip.
  
• I have to ask at this point whether the interface of the services provided by Cable Co's through such a box would differ throughout the day as a result of Internet Traffic? Is that how it works, you send a channel change request, the box sends a message home to the Cable Co and if they are busy it might not get through fast enough?
  
• Or is all the work of channel changing done in the box itself?
  
• If so would there be a reason why it differs (markedly) in response times / effective changes throughout the day?
  

In any case what I can confirm is that changes using uutx did NOT cause an Windows Event Viewer Crash whereas those using USBUIRTSend did (like yesterday) - this is repeatable. Maybe you'd like to have a look at that error sometime, as USBUIRTSend is still preferred to the uutx batch file option.

My current uutx Batch file (thanks to Steve232) is:

Code:

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 -f%~dp0%2 %input:~0,1%
if not "%input:~1,1%" == "" C:\Users\Public\NPVR\ChanChg\uutx.exe -r3 -f%~dp0%2 %input:~1,1%
if not "%input:~2,1%" == "" C:\Users\Public\NPVR\ChanChg\uutx.exe -r3 -f%~dp0%2 %input:~2,1%
if not "%input:~3,1%" == "" C:\Users\Public\NPVR\ChanChg\uutx.exe -r3 -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 GXPC4312H.ir contains the IR changer codes

NOTES:

I am not really sure if the Devcon USBUIRT Blaster reset is required each time [note that Devcon.exe (32/64) is not in /windows/system32 by default you have to extract it from a Windows CAB)]

This is the uutx-based batch template I used that works. I changed repeat count from -r1 to -r3.

Others:

1. https://forums.nextpvr.com/showthread.ph...post505196
   
2. https://forums.nextpvr.com/showthread.ph...#post66481
   
3. https://forums.nextpvr.com/showthread.ph...post441296
   

Note also that the uutx syntax (below) allows you to use the -d switch if you have multiple STBs whose channels are being changed by the emitters attached to ONE USBUIRT so in theory you could point channels to various STBs. I am not sure if the -s switch works like subs USBUIRTSend "InterCodeDelay" setting as uutx (current version) sends only ONE code, so whether this is BEFORE or AFTER the Pronto code is issued is unclear.

UUTX Usage:
uutx [-r<repeatCount> ] [-d<deviceNumber> ] [-s<sleepms>] "<IRCode>"
-or-
uutx [-r<repeatCount> ] [-d<deviceNumber> ] [-s<sleepms>] -f<fileName> <IRCodeName>

Cheers, hope that helps someone.

k.