OpenDCT: An open source digital cable tuner.

[sflamm]

Updated script for readability and logging.

Syntax for command: (tune.ps1)

tune TunerNumber=<tunerNumber> ChannelNumber=<channelNumber> EnableDebug=<True | False>


Run from command shell:

powershell.exe -ExecutionPolicy ByPass -File "PATH\tune.ps1" -TunerNumber <tunerNumber> -ChannelNumber <channelNumber>"


tune.ps:

Param([string]$TunerNumber, [string]$ChannelNumber, [ValidateSet("true", "false")]$EnableDebug="false")

switch($EnableDebug.ToLower()) {
    "true" { $EnableDebugBool = $true }
    default { $EnableDebugBool = $false }
}

$ChannelNumberArray = $ChannelNumber.ToCharArray()

$HostName = "10.0.0.25"
$HostPort = 8080
$TuningCommand = "http://" + $HostName + ":" + $HostPort + "/sagex/api/?c=TransmitCommandUsingInfraredTuningPlugin"
$TuningPlugin = "USB-UIRT Transceiver"
$TuningPluginPort = "0"
$BaseRemoteName = "PaceRNG150"
$RemoteName = $BaseRemoteName + "-" + $TunerNumber
$RepeatFactor = "2"

$LogFile = "log.txt"

$Username = "sage"
$Password = "frey"
$Headers = @{ Authorization = "Basic {0}" -f [Convert]::ToBase64String([Text.Encoding]::ASCII.GetBytes(("{0}:{1}" -f $Username,$Password))) }

if ($EnableDebugBool) {
		$ChannelText = "***** Tune " + $ChannelNumber + " *****" 
		Write-Output $ChannelText | Out-File $LogFile -append
}

foreach ($Digit in $ChannelNumberArray) {

	

	$Uri = $TuningCommand + "&1=" + $TuningPlugin + "&2=" + $TuningPluginPort + "&3=" + $RemoteName + "&4=" + $Digit + "&5=" + $RepeatFactor

	if ($EnableDebugBool) {
		Write-Output uri:$Uri | Out-File $LogFile -append
	}

	$Result = Invoke-RestMethod -Uri $Uri -Headers $Headers
	
}

if ($EnableDebugBool) {
		Write-Output "*******************" | Out-File $LogFile -append
}

This can work with any Tuning Plugin.

To find the parameters for your system - here is a sample of the following commands to run in a browser:

/ CAPTURE DEVICE
http://10.0.0.25:8080/sagex/api/?c=G...CaptureDevices
![CDATA[
DCT-HDHomeRun Prime Tuner 131104FC-0 on 127.0.0.1:9000
]]>
</Item>
<Item>
<![CDATA[ STB-2 on 127.0.0.1:9000 ]]>
</Item>
<Item>
<![CDATA[ STB-1 on 127.0.0.1:9000 ]]>


// CAPTURE DEVICE INPUT
http://10.0.0.25:8080/sagex/api/?c=G...127.0.0.1:9000
<Result size="1">
<Item>
<![CDATA[ STB-1 on 127.0.0.1:9000 HDMI ]]>
</Item>
</Result>

// TUNER REMOTE NAME
http://10.0.0.25:8080/sagex/api/?c=G....1:9000%20HDMI
<Result>
<![CDATA[ PaceRNG150-1 ]]>
</Result>

// TUNING PLUGIN
http://10.0.0.25:8080/sagex/api/?c=G....0.0.1:9000%22
<Result>
<![CDATA[ USB-UIRT Transceiver ]]>
</Result>

// TUNING PLUGIN PORT
http://10.0.0.25:8080/sagex/api/?c=G....1:9000%20HDMI
<Result>0</Result>

[sflamm]

Having problem with tuner executable entry in OpenDCT config...

Entered the following line:

sagetv.device.79219558.tuning_executable="C\:ProgramData\OpenDCT\config\tune.bat" 1 %c%

And it gets converted to this when OpenDCT starts:

sagetv.device.79219558.tuning_executable="C\:ProgramDataOpenDCTconfig\tune.bat" 1 %c%

NOTICE THE PATH IS ALL WRONG NOW

And in the OpenDCT log file:

00:59:34.368 [SageTVRequestHandler-102:STB-1] ERROR GenericHttpCaptureDevice - Unable to run tuning executable '"C:ProgramDataOpenDCTconfig une.bat" 1 4' => java.io.IOException: Cannot run program ""C:ProgramDataOpenDCTconfig": CreateProcess error=2, The system cannot find the file specified
at java.lang.ProcessBuilder.start(Unknown Source)
at java.lang.Runtime.exec(Unknown Source)
at java.lang.Runtime.exec(Unknown Source)
at java.lang.Runtime.exec(Unknown Source)
at opendct.capture.GenericHttpCaptureDevice.executeCommand(GenericHttpCaptureDevice.java:156)
at opendct.capture.GenericHttpCaptureDevice.startEncodingSync(GenericHttpCaptureDevice.java:375)
at opendct.capture.GenericHttpCaptureDevice.startEncoding(GenericHttpCaptureDevice.java:265)
at opendct.sagetv.SageTVRequestHandler.run(SageTVRequestHandler.java:301)
at java.lang.Thread.run(Unknown Source)
Caused by: java.io.IOException: CreateProcess error=2, The system cannot find the file specified
at java.lang.ProcessImpl.create(Native Method)
at java.lang.ProcessImpl.<init>(Unknown Source)
at java.lang.ProcessImpl.start(Unknown Source)
... 9 more

00:59:34.368 [SageTVRequestHandler-102:STB-1] ERROR GenericHttpCaptureDevice - Failed to run tuning executable.
00:59:34.368 [SageTVRequestHandler-102:STB-1] ERROR SageTVRequestHandler - SageTV sent: 'BUFFER STB-1 HDMI|2009279711|4|83886080|\\nas\public\RecordedTV\STB1on1000259000HDMI-0.mpgbuf|Great-H.264', Replied: 'ERROR Device Start Failed'
00:59:34.368 [SageTVRequestHandler-102:STB-1] ERROR SageTVRequestHandler - Encoder device is unable to start.

What is the proper syntax for the sagetv.device.<unique_id>.tuning_executable= on Windows?

[EnterNoEscape]

You need to escape the backslashes. \ needs to be \\

[Fuzzy]

Originally Posted by sflamm

Correct - my primary server needs to be different from the secondary (configured as a Network Encoder).

As a general configuration having a Network Encoder with local resources and tuning is VERY helpful... and really the point of a Network Encoder.

Why is it a problem to have a Network Encoder that uses Network Encoders? The Client of the Network Encoder doesnt see how the video sources of the Network Encoder are configured.

It's not that it'd be a 'problem' but I am still not clear on what you are using SageTV for on this remote machine - if you are using OpenDCT to interface with your capture device, why wouldn't you want the main sagetv server to simply connect to that OpenDCT instance directly?

[sflamm]

Nevermind... silly mistake...


Correct path is:

sagetv.device.79219557.tuning_executable=C\:\\ProgramData\\OpenDCT\\config\\tune.bat 1 %c%

[sflamm]

Now I have a different problem...

The OpenDCT log file shows the command executing:

01:52:04.925 [SageTVRequestHandler-101:STB-1] DEBUG GenericHttpCaptureDevice - Executing: 'cmd.exe /c C:\ProgramData\OpenDCT\config\tune.bat 1 551'

But in fact it is NOT executing.

[sflamm]

Success:

sagetv.device.79219557.tuning_executable=C\:\\Windows\\SysWOW64\\WindowsPowerShell\\v1.0\\powershell.exe -ExecutionPolicy ByPass -F C\:\\ProgramData\\OpenDCT\\config\\tune.ps1 -TunerNumber 1 -ChannelNumber %c% -EnableDebug true

[Fuzzy]

There is a commandline program on the usbuirt forums to send a command to the USB-UIRT. That could be used with the following batch file to have openDCT directly blast the channel change instead of having sagetv installed on the remote machine (since it seems like the only reason you are using sage on the remote machine is to deal with the blasting):

BLAST.BAT

@echo off
REM *************************************************
REM *         IR Blasting Script                    *
REM *        by Christopher Piper                   *
REM *                                               *
REM *    Set the following blastercmd variable      *
REM *  where //digit// will be the digit to send    *
REM *                                               *
REM *     example:                                  *
REM * SET blastercmd=uutx.exe -firfile.ir //digit// *
REM *                                               *
REM *************************************************

SET blastercmd=

REM *************************************************

if "%blastercmd%"=="" (goto nocmd)
if "%1"=="" (goto syntax) else (set num=%1)
if "%2"=="" (set min=3) else (set min=%2)
if "%3"=="" (set del=250) else (set del=%3)

ECHO Blasting %num%, minimum %min% digits, with %del% msec delay:

REM Get digits from number
SET digit0=%num:~0,1%
SET digit1=%num:~1,1%
SET digit2=%num:~2,1%
SET digit3=%num:~3,1%

REM Zero Pad the digits
:testsize
if "%digit3%"=="" (GOTO padit)
goto testmin

:padit
SET digit3=%digit2%
SET digit2=%digit1%
SET digit1=%digit0%
SET digit0=0
goto testsize

:testmin
if %digit0%==0 (
	if %min%==4 goto blast4
	if %digit1%==0 (
		if %min%==3 goto blast3
		if %digit2%==0 (
			if %min%==2 goto blast2
			if %digit3%==0 (
				if %min%==1 goto blast1
				goto end
			) else goto blast1
		) else goto blast2
	) else goto blast3
) else goto blast4

:nocmd
ECHO.
ECHO ERROR: blastercmd variable is not set.  See note at top of blast.bat for help.
ECHO.

:syntax
ECHO Send an IR blast 
ECHO.
ECHO Usage:  BLAST  n [min] [delay]
ECHO.
ECHO Where:  n     = the channel number to tune to
ECHO         min   = minimum number of digits to send (default 3)
ECHO         delay = inter-digit delay in microseconds (default 250)
goto end

:blast4
CALL :blast %digit0%
CALL :delay %del%
:blast3
CALL :blast %digit1%
CALL :delay %del%
:blast2
CALL :blast %digit2%
CALL :delay %del%
:blast1
CALL :blast %digit3%
GOTO end

:delay
	if not "%1"=="0" PING 1.1.1.1 -n 1 -w %1 >NUL
	GOTO:EOF
:blast
	call set cmd=%%blastercmd://digit//=%1%%
	%cmd%
	GOTO:EOF
:end

Essentially, what the batch file is doing is parsing out the individual digits from the channel number that need to be sent, and calling the configured cmd for each digit. This is pure batch, not powershell, which makes things simpler as well.

[EnterNoEscape]

Originally Posted by Fuzzy

There is a commandline program on the usbuirt forums to send a command to the USB-UIRT. That could be used with the following batch file to have openDCT directly blast the channel change instead of having sagetv installed on the remote machine (since it seems like the only reason you are using sage on the remote machine is to deal with the blasting):

BLAST.BAT

@echo off
REM *************************************************
REM *         IR Blasting Script                    *
REM *        by Christopher Piper                   *
REM *                                               *
REM *    Set the following blastercmd variable      *
REM *  where //digit// will be the digit to send    *
REM *                                               *
REM *     example:                                  *
REM * SET blastercmd=uutx.exe -firfile.ir //digit// *
REM *                                               *
REM *************************************************

SET blastercmd=

REM *************************************************

if "%blastercmd%"=="" (goto nocmd)
if "%1"=="" (goto syntax) else (set num=%1)
if "%2"=="" (set min=3) else (set min=%2)
if "%3"=="" (set del=250) else (set del=%3)

ECHO Blasting %num%, minimum %min% digits, with %del% msec delay:

REM Get digits from number
SET digit0=%num:~0,1%
SET digit1=%num:~1,1%
SET digit2=%num:~2,1%
SET digit3=%num:~3,1%

REM Zero Pad the digits
:testsize
if "%digit3%"=="" (GOTO padit)
goto testmin

:padit
SET digit3=%digit2%
SET digit2=%digit1%
SET digit1=%digit0%
SET digit0=0
goto testsize

:testmin
if %digit0%==0 (
	if %min%==4 goto blast4
	if %digit1%==0 (
		if %min%==3 goto blast3
		if %digit2%==0 (
			if %min%==2 goto blast2
			if %digit3%==0 (
				if %min%==1 goto blast1
				goto end
			) else goto blast1
		) else goto blast2
	) else goto blast3
) else goto blast4

:nocmd
ECHO.
ECHO ERROR: blastercmd variable is not set.  See note at top of blast.bat for help.
ECHO.

:syntax
ECHO Send an IR blast 
ECHO.
ECHO Usage:  BLAST  n [min] [delay]
ECHO.
ECHO Where:  n     = the channel number to tune to
ECHO         min   = minimum number of digits to send (default 3)
ECHO         delay = inter-digit delay in microseconds (default 250)
goto end

:blast4
CALL :blast %digit0%
CALL :delay %del%
:blast3
CALL :blast %digit1%
CALL :delay %del%
:blast2
CALL :blast %digit2%
CALL :delay %del%
:blast1
CALL :blast %digit3%
CALL :delay %del%
GOTO end

:delay
	PING 1.1.1.1 -n 1 -w %1 >NUL
	GOTO:EOF
:blast
	call set cmd=%%blastercmd://digit//=%1%%
	%cmd%
	GOTO:EOF
:end

Essentially, what the batch file is doing is parsing out the individual digits from the channel number that need to be sent, and calling the configured cmd for each digit. This is pure batch, not powershell, which makes things simpler as well.

There is one plus side to using the SageTV server. There's no spin-up time to start communications with the USB-UIRT. uutx.exe has a definite cost for each execution. It takes about 800ms to start and send one command.

[wayner]

Originally Posted by EnterNoEscape

There is one plus side to using the SageTV server. There's no spin-up time to start communications with the USB-UIRT. uutx.exe has a definite cost for each execution. It takes about 800ms to start and send one command.

Then isn't that adding 0.8 seconds to the delay in Fuzzy's script? If you put in much of a delay at all then you may have tuning issues - if you wait too long between button pushes I know that my box assumes that you are done and tunes the channel. So the conclusion would be to make sure that you don't use any additional delay.

For example if you send 5 <delay> 1 <delay> 3 when trying to tune channel 513 you may tune channel 5, then tune channel 1 and finally end up on channel 3.

[Tiki]

Am I missing something? I don't see anything in that BAT file that deals with zones? I think the whole reason he went down this path was to be able to use zones so he could control multiple STBs with one blaster.

[wayner]

I don't think the uutx.exe command line program understands zones. We may need to get Jon Rhees to create a new version of it with a zone as a parameter.

[EnterNoEscape]

Originally Posted by Tiki

Am I missing something? I don't see anything in that BAT file that deals with zones? I think the whole reason he went down this path was to be able to use zones so he could control multiple STBs with one blaster.

Originally Posted by wayner

I don't think the uutx.exe command line program understands zones. We may need to get Jon Rhees to create a new version of it with a zone as a parameter.

It does support zones. You need to define them in the code file you're using. You just prefix the code with Z1, Z2 or Z3. I'm not sure it's well documented, but I have done it before and it does work.

[Fuzzy]

Originally Posted by EnterNoEscape

It does support zones. You need to define them in the code file you're using. You just prefix the code with Z1, Z2 or Z3. I'm not sure it's well documented, but I have done it before and it does work.

Which is the same way you do it for Sage's implementation as well (in fact, you should be able to use the exact same .ir file for uutx as you use for sagetv).

Regarding the time delay, I've never used it, so I can't say for sure if that's true in all cases. I just knew the utility was out there, so wrote up a (generalized) script to break a channel into digits.

[Fuzzy]

I did just tweak the script a bit to completely skip the delay step if you set the delay to 0, so if the uuirtdrv.dll does take 0.8 seconds to spool up, the interdigit delay should still end up being less than a second, and channel changes should still get off properly (like I said, I've not tried it, and am not even at home to give it a shot on a test rig yet).

[Fuzzy]

Okay, so I was got home and was able to throw a spare USB-UIRT on my win10 desktop and throw some codes at it.

TESTTIME.BAT

@echo off
echo Start: %time%
call blast.bat 1234 4 0
echo Stop:  %time%

This will test the time it takes to execute uutx.exe and send a pronto based code from the txt file.

Output:

Start:  8:43:25.43
Blasting 1234, minimum 4 digits, with 0 msec delay:
Stop:   8:43:27.13

Start:  8:45:17.19
Blasting 1234, minimum 4 digits, with 250 msec delay:
Stop:   8:45:19.19

This is consistent across many attempts. This is taking 1.7 seconds to transmit 4 digits, putting the max speed (delay = 0msec) at about 2.35 digits/second. With my default 250 msec delay, this stretches the 4 digit blast out to 2.10 seconds, or about 1.9 digits/second. This is still plenty fast enough to avoid the box cancelling out and likely faster than a typical thumb on a remote is going to be pressing buttons.

[EnterNoEscape]

Originally Posted by Fuzzy

This is consistent across many attempts. This is taking 1.7 seconds to transmit 4 digits, putting the max speed (delay = 0msec) at about 2.35 digits/second. With my default 250 msec delay, this stretches the 4 digit blast out to 2.10 seconds, or about 1.9 digits/second. This is still plenty fast enough to avoid the box cancelling out and likely faster than a typical thumb on a remote is going to be pressing buttons.

I am so spoiled with my digital tuners. 2 seconds feels like an eternity to get on the right channel. Fortunately this will be less of an issue once I get the new splitter into the SageTV core and you can overlap padding as much as you need.

[Fuzzy]

Originally Posted by EnterNoEscape

I am so spoiled with my digital tuners. 2 seconds feels like an eternity to get on the right channel. Fortunately this will be less of an issue once I get the new splitter into the SageTV core and you can overlap padding as much as you need.

I so rarely have things recording from encrypted channels, and almost never three back to back to cause a need to miss the tuning time, that I've never really noticed an issue with the "slow" channel changes using IR, almost all my recordings are coming via cablecard or OTA these days. (I actually haven't had either HD-PVR online for a couple weeks now, and no-one in the house has said anything).

[tmiranda]

Originally Posted by EnterNoEscape

I am so spoiled with my digital tuners. 2 seconds feels like an eternity to get on the right channel. Fortunately this will be less of an issue once I get the new splitter into the SageTV core and you can overlap padding as much as you need.

If you are updating the splitter please save me some time and make it 64 bit friendly (I think there are Windows native pieces).

[sflamm]

but I am still not clear on what you are using SageTV for on this remote machine - if you are using OpenDCT to interface with your capture device

The motivation is:

1. Setup a SageTV Server that serves local tuners
- this allows any other SageTV Server to use this shared resource
- allows any program (not just SageTV) to use this shared resource
- also important when the hardware itself must be plugged in local (USB-UIRT)
- especially useful when the common resource can tune ALL channels (including protected) such as the BM3000-HDMIs (amazing)


2. Ability to upgrade / configure one without the other - split the dependency
- Updates to the main SageTV Server can be independent of the SageTV Server acting as a Network Encoder
- the Network Encoders are completely backward compatible, works with any SageTV version
- Can migrate configurations easily without reconfiguring tuners

3. Speed of changing channels for IR. (latest script attached)
- the script is very fast since it leverages the in-memory REST
- support multiple zones natively