NextPVR Forums

I am having an issue with my LAN and V5 using the Hauppauge DCR-3250 Cable Card Triple Tuner. It is a TCP issue and will take some time to resolve. In the meantime, I am using V4, which uses UDP, as a workaround. I would like to return to V5 but I need to create an "extra" device to access the tuner using UDP. My research into creating an extra device has come from the Wiki snd examples from two other extra sources:

extra-locast.xml:
  <channel name="WCBS" number="2.1" group="locast" tvg-id="16689.locast.org" output="m3u8">
    <command>cmd</command>
    <args>/c "C:\Users\Public\NPVR-data\scripts\locast\locast.bat" 104</args>
    <icon>https://static.locastnet.org/logo/NewYork/WCBS.png</icon>
  </channel>

Locast.bat:
@echo off
python C:\Users\Public\NPVR-data\scripts\locast\locast.py --tune %1 %2

extra-nasa.xml:
  <channel name="NASA TV Media">
    <command>c:/Program Files/NextPVR/Other/ffmpeg.exe</command>
    <args>-user_agent "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:76.0) Gecko/20100101 Firefox/76.0" -referer "https://www.nasa.gov/" -headers "Cookie: domain: nasa-i.akamaihd.net\r\nOrigin: https://www.nasa.gov" -i https://nasa-i.akamaihd.net/hls/live/253..._2000.m3u8 -codec copy -f mpegts -</args>
  </channel>

If added the following channel to extra-nasa.xml for accessing the tuner device:
  <channel name="UDP Source">
<command>cmd</command>
    <args>/c "i:\Nextpvr-capture\curlcap\StartUDPTuner.bat"</args>
  </channel>

StartUDPTuner.bat:
@echo off
:: Clear the tuner
"C:\Program Files\Silicondust\HDHomeRun\hdhomerun_config" 192.168.1.155 set /tuner0/channel none
:: Tune vChannel 504
"C:\Program Files\Silicondust\HDHomeRun\hdhomerun_config" 192.168.1.155 set /tuner0/vchannel 504
:: Direct output to target PC IPaddr and port using UDP and start the stream
"C:\Program Files\Silicondust\HDHomeRun\hdhomerun_config" 192.168.1.155 set /tuner0/target udp://192.168.1.154:5004
:: Receive stream with FFMPEG and re-redirect to stdout.
"C:\Program Files\NextPVR\Other\ffmpeg.exe" -f mpeg -i udp://192.168.1.154:5004 -f mpegts
::"C:\Program Files\Silicondust\HDHomeRun\hdhomerun_config" 192.168.1.155 set /tuner0/channel none

Trying to watch the channel with the desktop app produces no picture or sound though the tuner is sending the stream: Launching VLC specifying port 5004 produces perfect picture and sound. If I tell FFMPEG to save the stream as a .ts file, file playback is flawless.

Attached are the logs from a service restart to cancelling the desktop app's empty screen.

Does anyone have a suggestion about what might be wrong? I'd really appreciate the help.

Thanks.

There is now an Extras sub forum and there is a developers forum so this post is mis-placed.

You would need to start the server before starting the streaming from the HDHR and you need to redirect the ffmpeg output to stdout.

"C:\Program Files\NextPVR\Other\ffmpeg.exe" -v panic -timeout 10000000 -i udp://192.168.1.154:5004 -f mpegts -
"C:\Program Files\Silicondust\HDHomeRun\hdhomerun_config" 192.168.1.155 set /tuner0/target udp://192.168.1.154:5004

Martin

(moved to the extras forum)

Sorry, Martin. Will you move this to the Add-ons:Extras forum?

And thanks for the help. I missed that final hyphen for ffmpeg. Also, what is the -timeout parameter? I can't find it in the ffmpeg documentation and I may need to adjust it.

JohnC

When you start the ffmpeg server listening on the UDP port the -timeout gives you the microseconds it will wait. I figured 10 seconds is safe.

If you want 3 devices you will need 3 extras with different ports.

Martin

Made some progress and the desktop app does present a watchable picture. That's good. On the downside though, the picture is pixelated with very small checkboard squares at full screen. Also, I noticed that Wireshark shows the incoming data protocol as MPEG TS and not the UDP I was expecting. Could these two items be related?

I also checked CPU usage during live TV and saw that ffmpeg was consuming 25% of the CPU. Is that normal or is there transcoding going on? Is there a "passthru" option that can be used? Should I be using the -c:[v|a|s] copy options? Hauppauge told me the device output is normal MPEG2.

I've uploaded a 30-sec NextPVR capture on DropBox that you can view using this link:
https://www.dropbox.com/preview/GeneralE...e=personal

Getting very close...

JohnC

Wireshark is smart, mpegts is fine. I was just using your ffmpeg a/v options, if it was me I would use -codec copy so it wouldn't transcode. Technically sub want extras to produce h264/aac if you want web player support. I don't need that so I often ignore that spec.

Also I don't know who else you are addressing these posts to but I don't plan on providing either general extra or ffmpeg usage support in the future. I expect people creating extras will do their own experimentation and figure it out themselves.

Martin

I went ahead and tried using the options -c:v copy -c:a copy -c:s copy and the picture is now perfect. CPU usage went to 7%.

We're all good, Martin.

Thanks for the help.

JohnC

I have the extra device working beautifully with the DCR-3250. Recordings are clean and complete. I do have one problem and I'd like an opinion on a proposed solution:

The problem occurs when two back-to-back programs are recording on the same channel. Usually, NextPVR will use the same device and simply tell it to change the channel. This also allows recording of overlapped post- and pre-padding times. Unfortunately, the script "PostProcessing.bat" is invoked at the end of the first program but does not indicate that the device is still in use. So...my script turns off the tuner and the second program recording is stopped after the first program's post-padding. I thought about using "ParallelProcessing.bat" but I see a sequencing issue with Parallel... being invoked for the second program before Post... of the first due to padding.

For now I could access the database SCHEDULED_RECORDINGS and test if the device is in use for any entry in the schedule. If not, turn off the stream.

I would like to suggest that a new script be invoked to convey the current state of a device as being either "in-use" or "free" when NextPVR needs it or releases it independent of the program being recorded. This way, the script would stay in the execution context of NextPVR and avoid permission issues.

Any opinion on this?

Thanks.

Don't stop the tuner in your script let it timeout when it is not being used. You aren't locking it so that shouldn't cause any issue.

Martin