Page 1 of 4 123 ... LastLast
Results 1 to 10 of 39

Thread: Improve reliability of STB channel changing?

Hybrid View

Previous Post Previous Post   Next Post Next Post
  1. #1
    Join Date
    Jul 2005
    Location
    HK - Pal I
    Posts
    3,437

    Improve reliability of STB channel changing?

    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 -> direct to HDMI Monitor, changing channels using USBUIRT (manual zap using cmd + a uutx batch) - 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 resoution 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.


    Lost of questions, sorry!

    Cheers

    k.
    ASUS STRIX X470-F AMD 2700x 4GHz | Win10Prox64 | 32GB | NVIDIA GEforce GT1030 Fanless | WinTV DMB-TH | WinTV HVR-1280 | Hauppauge Colossus | Various HD's | AC86U | USB-UIRT | PCH-A110 | RPi2 | Sony Bravia LCD X9000F Android TV |. Frustrated that NextPVR is not working? Take a moment and consider this and this and this and this and this and this. Credit where credit's due; for one guy (with a wife and two kids), most problems are solved outrageously quickly. Patience.

  2. #2
    Join Date
    Nov 2003
    Location
    NextPVR HQ, Wellington, New Zealand
    Posts
    89,201
    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.

  3. #3
    Join Date
    Jul 2005
    Location
    HK - Pal I
    Posts
    3,437
    Quote Originally Posted by sub View Post
    You might be able to look at running a batch file for your blaster, and starting the blaster from there with high priority.
    Right after several more (hundreds of ) hours of testing, and asking on stackoverflow about batch files and priorities, I have a batch file which appears to work (reasonably well) from the command line, but alas, not in NextPVR. Still occasionally misses a number but at least it does priority; I hope.

    GXPC4312H_StarterUUTX.bat calls GXPC4312H_UUTX.bat
    GXPC4312H_StarterUUTX.bat sets the priority for GXPC4312H_UUTX.bat

    As I said it works from the command line but it doesn't do anything in NextPVR? Seems odd?

    Executable: C:\Users\Public\NPVR\ChanChg\GXPC4312H_StarterUUTX .bat
    Arguments {channel}

    GXPC4312H_StarterUUTX.bat
    Code:
    REM
    SET command=GXPC4312H_UUTX.bat
    start "" /REALTIME /B %command% %*
    REM
    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 ORIG SETTINGS 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
    Anything noticeable in the logs?

    btw I also for the Pronto and irsend Codes for my Global Cache blaster but the GC people don't really have a blaster exectuable (too low tech for that device) as they rely on many other vendors to write horribly complex software for it. After some pestering they provided me an exe that will send codes via the IP Address of the GC but I would have to write ANOTHER batch file to send the codes seperately as their executable doesn't "do" {Channel_d1} or read off an IR Def as arguments.

    They gave me this as a starter ...

    Code:
    @echo off
    
    set ip="192.168.0.203"
    
    :loop
    if "%1"=="" goto :done
    
    if "%1"=="1" goto :IR1
    if "%1"=="2" goto :IR2
    if "%1"=="2" goto :IR3
    :: Continue if statements for as many digits/commands as necessary
    
    :return
    shift
    goto :loop
    
    ::Make function for each IRn if statement above
    :IR1
    ::Hard code IR code for 'IR1' case
    .\main.exe %ip% 4998 sendir,1:1,1,38000,1,1,500,500
    goto :return
    
    :IR2
    ::Hard code IR code for 'IR2' case
    .\main.exe %ip% 4998 sendir,1:1,1,38000,1,1,250,500
    goto :return
    
    :IR3
    ::Hard code IR code for 'IR3' case
    .\main.exe %ip% 4998 sendir,1:1,1,38000,1,1,250,500
    goto :return
    
    :done
    echo Complete
    
    REM This will loop through the arguments and if they're a match to one of the predefined values it'll send the code in the matching "IRn" function. Then you would just call the batch file like this myBatch.bat 1 2 1 or with as many parameters as needed. Note: the batch file would need to be in the same directory as main.exe
    I have also been experimenting with TST10.exe to do a similar thing... don't change that dial...

    Meanwhile, on the plus side, I'm not actually watching any TV at all, as all my evenings are spent chasing blaster commands....

    k.
    Attached Images Attached Images  
    ASUS STRIX X470-F AMD 2700x 4GHz | Win10Prox64 | 32GB | NVIDIA GEforce GT1030 Fanless | WinTV DMB-TH | WinTV HVR-1280 | Hauppauge Colossus | Various HD's | AC86U | USB-UIRT | PCH-A110 | RPi2 | Sony Bravia LCD X9000F Android TV |. Frustrated that NextPVR is not working? Take a moment and consider this and this and this and this and this and this. Credit where credit's due; for one guy (with a wife and two kids), most problems are solved outrageously quickly. Patience.

  4. #4
    Join Date
    Dec 2005
    Location
    UK
    Posts
    3,125
    Does something a bit more simple help ...

    bat1.cmd
    set channel=%1
    start /realtime /b c:\foldera\folderb\bat2.cmd
    bat2.cmd

    c:\folderx\folderz\uutx.exe blah blah %channel% blah
    Plus NextPVR is able to provide the three digits as separate values. This would allow you to run uutx three times and send one digit each time that you run uutx. Might be more reliable.
    i5 750 2.67 GHz, 6 Gig, 1000 Gig, Nvidia N710
    2 x Hauppauge WinTV QuadHD DVB-T2

  5. #5
    Join Date
    Jul 2005
    Location
    HK - Pal I
    Posts
    3,437
    Quote Originally Posted by Graham View Post
    Does something a bit more simple help ...

    bat1.cmd

    bat2.cmd

    Plus NextPVR is able to provide the three digits as separate values. This would allow you to run uutx three times and send one digit each time that you run uutx. Might be more reliable.
    Hiya,

    It seems I'm terrible with batch files. This is what I am trying but it does not quite work.
    The echo is just so I can see what is going on.

    Bat1.bat
    Code:
    REM
    echo %1 
    echo %2 
    echo %3
    SET ChDigit1=%1
    SET ChDigit2=%2
    SET ChDigit3=%3
    echo %ChDigit1%
    echo %ChDigit2%
    echo %ChDigit3%
    REM
    start "" /REALTIME /B C:\Users\Public\NPVR\ChanChg\GXPC4312H_UUTX.bat %ChDigit1% %ChDigit2% %ChDigit3%
    REM
    Bat2.bat
    Code:
    @echo on
    REM
    echo %ChDigit1%
    echo %ChDigit2%
    echo %ChDigit3%
    C:\Users\Public\NPVR\ChanChg\uutx.exe -r3 -s50 -fGXPC4312H.ir %ChDigit1%
    C:\Users\Public\NPVR\ChanChg\uutx.exe -r3 -s50 -fGXPC4312H.ir %ChDigit2%
    C:\Users\Public\NPVR\ChanChg\uutx.exe -r3 -s50 -fGXPC4312H.ir %ChDigit3%
    @echo off
    REM
    If I run the batch from the command line with GXPC4312H_StarterUUTX 325 it just says (3 times)

    Code:
    Error: missing IRCodeName.
    
    UUTX Usage:
            uutx [-r<repeatCount> ] [-d<deviceNumber> ] [-s<sleepms>] "<IRCode>"
                    -or-
            uutx [-r<repeatCount> ] [-d<deviceNumber> ] [-s<sleepms>] -f<fileName> <IRCodeName>
    However if I run it from the command line with GXPC4312H_StarterUUTX 3 2 5 it works (i.e. with spaces between the numbers). It works but sometimes misses digits, although that is a separate problem. It also spawns a new command window each time i.e. it doesn't go away?

    So I thought OK I will now try incorporating {channel_d1}{channel_d2}{channel_d3} in the calling batch In NextPVR) as the channel arguments. That doesn't work for me, no numbers come up at all.

    Code:
    019-03-17 15:09:02.602	[INFO][40]	Running blaster: C:\Users\Public\NPVR\ChanChg\GXPC4312H_StarterUUTX.bat 0 5 2
    2019-03-17 15:09:02.676	[DEBUG][40]	About to tune graph to: 
    <tuning>
      <type>HDPVR</type>
      <locator>
        <channel>523</channel>
        <input>3</input>
        <audio_input>HDMI Audio Input</audio_input>
        <blaster_executable>C:\Users\Public\NPVR\ChanChg\GXPC4312H_StarterUUTX.bat</blaster_executable>
        <blaster_args>{channel_d1} {channel_d2} {channel_d3}</blaster_args>
      </locator>
    </tuning>
    2019-03-17 15:09:02.676	[DEBUG][40]	About to switch HDPVR/Colossus to target: 
    LIVE&D:\GBPVRLiveTVBuffer\live-FOXCRIME-31669.ts
    2019-03-17 15:09:02.698	[INFO][40]	HDPVRRecorder.StartStream() allocated handle: 0x3E
    2019-03-17 15:09:02.698	[DEBUG][40]	stopping previous handle
    2019-03-17 15:09:02.698	[INFO][40]	HDPVRRecorder.StopStream(61)
    2019-03-17 15:09:04.838	[INFO][40]	HDPVRRecorder.StopStream(62)
    2019-03-17 15:09:04.847	[INFO][40]	No more streams active. Stopping device.
    2019-03-17 15:09:04.848	[DEBUG][40]	Graph stopping...
    If I just have ONE argument {channel} that does not work either.

    Any other suggestions please?

    k.
    Attached Images Attached Images  
    ASUS STRIX X470-F AMD 2700x 4GHz | Win10Prox64 | 32GB | NVIDIA GEforce GT1030 Fanless | WinTV DMB-TH | WinTV HVR-1280 | Hauppauge Colossus | Various HD's | AC86U | USB-UIRT | PCH-A110 | RPi2 | Sony Bravia LCD X9000F Android TV |. Frustrated that NextPVR is not working? Take a moment and consider this and this and this and this and this and this. Credit where credit's due; for one guy (with a wife and two kids), most problems are solved outrageously quickly. Patience.

  6. #6
    Join Date
    Dec 2005
    Location
    UK
    Posts
    3,125
    Quote Originally Posted by jksmurf View Post
    This is what I am trying but it does not quite work.
    I'm not sure what you are doing with batch file names ... You give examples of files called bat1.bat and bat2.bat but the batch file "start"ed by bat1.bat is called GXPC4312H_UUTX.bat

    You can put an EXIT command at the end of a batch file to force the batch file to end.

    There is a SLEEP N command that cause a batch file to wait for N seconds ... This might help if you pause for a second between each of the three executions of uutx.

    Also, I would experiment with and without the /B in the START command.

    Also, I would try the three digit version without the bat1 and bat2 malarkey ... Set NextPVR to run the three digit version (with three executes of uutx) ... If it misses digits, try adding a SLEEP 1 between each execute.
    Last edited by Graham; 2019-03-17 at 12:21 PM.
    i5 750 2.67 GHz, 6 Gig, 1000 Gig, Nvidia N710
    2 x Hauppauge WinTV QuadHD DVB-T2

  7. #7
    Join Date
    Nov 2003
    Location
    NextPVR HQ, Wellington, New Zealand
    Posts
    89,201
    Quote Originally Posted by jksmurf View Post
    Meanwhile, on the plus side, I'm not actually watching any TV at all, as all my evenings are spent chasing blaster commands....
    lol

  8. #8
    Join Date
    Jun 2007
    Location
    St. Paul, MN, USA
    Posts
    1,243
    Quote Originally Posted by jksmurf View Post
    GXPC4312H_StarterUUTX.bat
    Code:
    REM
    SET command=GXPC4312H_UUTX.bat
    start "" /REALTIME /B %command% %*
    REM
    I'd say make sure to use a the full path to GXPC4312H_UUTX.bat in the SET command line. When the batch file is run from NextPVR, the current directory is typically different from what it is when run from a command prompt.

  9. #9
    Join Date
    Jul 2005
    Location
    HK - Pal I
    Posts
    3,437
    Quote Originally Posted by sub View Post
    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.

    Quote Originally Posted by sub View Post
    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.

    Quote Originally Posted by sub View Post
    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....

    Quote Originally Posted by sub View Post
    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.

    Quote Originally Posted by sub View Post
    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.

    Quote Originally Posted by sub View Post
    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).

    Quote Originally Posted by sub View Post
    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.
    Last edited by jksmurf; 2019-03-11 at 09:37 AM.
    ASUS STRIX X470-F AMD 2700x 4GHz | Win10Prox64 | 32GB | NVIDIA GEforce GT1030 Fanless | WinTV DMB-TH | WinTV HVR-1280 | Hauppauge Colossus | Various HD's | AC86U | USB-UIRT | PCH-A110 | RPi2 | Sony Bravia LCD X9000F Android TV |. Frustrated that NextPVR is not working? Take a moment and consider this and this and this and this and this and this. Credit where credit's due; for one guy (with a wife and two kids), most problems are solved outrageously quickly. Patience.

  10. #10
    Join Date
    Jun 2005
    Location
    Cambridge, UK
    Posts
    181
    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!
    Dual Pentium 1.8GHz, 4GB, 5TB, Colossus, NOVA-T, NOVA-HD-S2, W10 NPVR 4.2.4, 3 PCH A100, 2 PCH A110

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •