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

Thread: Improve reliability of STB channel changing?

  1. #1
    Join Date
    Jul 2005
    Location
    HK - Pal I
    Posts
    3,440

    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
    90,413
    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,440
    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.

  4. #4
    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

  5. #5
    Join Date
    Jul 2005
    Location
    HK - Pal I
    Posts
    3,440
    Quote Originally Posted by macgyver View Post
    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.
    Last edited by jksmurf; 2019-03-11 at 10:00 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.

  6. #6
    Join Date
    Dec 2005
    Location
    UK
    Posts
    3,125
    Quote Originally Posted by jksmurf View Post
    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
    i5 750 2.67 GHz, 6 Gig, 1000 Gig, Nvidia N710
    2 x Hauppauge WinTV QuadHD DVB-T2

  7. #7
    Join Date
    Jul 2005
    Location
    HK - Pal I
    Posts
    3,440
    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.
    Last edited by jksmurf; 2019-03-11 at 09:33 PM.
    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.

  8. #8
    Join Date
    Dec 2005
    Location
    UK
    Posts
    3,125
    Quote Originally Posted by jksmurf View Post
    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%
    i5 750 2.67 GHz, 6 Gig, 1000 Gig, Nvidia N710
    2 x Hauppauge WinTV QuadHD DVB-T2

  9. #9
    Join Date
    Nov 2003
    Location
    NextPVR HQ, Wellington, New Zealand
    Posts
    90,413
    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).
    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

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

    Quote Originally Posted by sub View Post
    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.
    Last edited by jksmurf; 2019-03-12 at 12: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.

Posting Permissions

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