Extra Device v. IPTV Device for a Network Based Encoder

[pkscout]

I've been poking around at other posts trying to figure out what the best option is to add my network based encoder as a device.

The network encoder currently produces an H265 stream with AC3 (stereo) audio at http://172.16.1.4/0.ts.  I use a custom python script to change channels, and I've confirmed that is working in the Docker container.  To change channels you do python3 /config/scripts/iguana-blaster/execute.py -c {channel}.  This combination works as an IPTV device in NPVR4, and I thought about just leaving it that way.  But the IPTV device in NPVR5 only imports mu3 files, not the XML file I can export from NPVR4.  So that leaves me 2 options:

1- Figure out the format of the mu3 import file so I can import the channels and, ideally, the channel changer script.  I think this might not quite work, as I saw a post indicating that to add channel changing to NPVR5's IPTV device I would have to modify the database directly (which I can do if I have to, but is not my first choice).

2- Figure out the Extras format.  This feels like it should be easier since the encoder already provides a valid stream, but I can't figure out the format.  Other posts about Extra devices seem to be based on having to do a bunch of stuff to get a file that vlc or ffmpeg can convert into a transport stream, and I'm hoping I don't have to do that here.

Thanks.

[mvallevand]

For this Extras device you would put this file in /config/extras-uray.xml

Code:

<extras>
  <channel name="{channel-name}">
    <command>bash</command>
    <args>-c "/config/scripts/uray.sh {channel}"</args>
  </channel>
</extras>

and this in /config/scripts/uray.sh (making sure it is executable)

Code:

#irblasting code
curl  http://172.16.1.4/0.ts
wait
exit $?

After that it acts just like an HDPVR in Windows v5

Why are you considering docker it could make blasting difficult?

Martin

[pkscout]

For this Extras device you would put this file in  /config/extras-uray.xml

Code:

<extras>
  <channel name="{channel-name}">
    <command>bash</command>
    <args>-c "/config/scripts/uray.sh {channel}"</args>
  </channel>
</extras>

and this in /config/scripts/uray.sh (making sure it is executable)

Code:

#irblasting code
curl  http://172.16.1.4/0.ts
wait
exit $?

After that it acts just like an HDPVR in Windows v5

Why are you considering docker it could make blasting difficult?

Martin

It's one part stubbornness and one part plans for new hardware.  I'm going to get a Synology NAS and would really like to run NPVR5 on it.  I could also build a Linux based NPVR5 box, but I'm trying to reduce the clutter some (and not spend extra on hardware for the NPVR5 box).  Thus the Docker image.  Today I wrote a websocket wrapper around my blaster script so it can run in client/server mode.  The Docker image runs the client and sends the channel request to the websocket server running on the machine that has the USB device in it.  For now that's on Windows, but I'll eventually move the blaster to a RPi I have laying around.  I basically now have a network based IR blaster to go with my network based encoder.

As it happens, this option let's me run Docker on my Mac and get NPVR completely configured before I transfer everything to the NAS (whenever I get it).  But really it became a programming problem to solve.  This probably isn't a solution anyone else would do or use, but it gave me something interesting to work on.

[pkscout]

And just to followup, that worked perfectly. Thanks. Running the Docker image on my Mac and Kodi on the same machine, I was able to change channels and watch the stream with absolutely no problem. Through the web browser the video struggled to keep up, but I expected that given the transcoding that happens to get it into the web browser. I will never use NPVR that way, so I don't really care.

[sub]

And just to followup, that worked perfectly.  Thanks.  Running the Docker image on my Mac and Kodi on the same machine, I was able to change channels and watch the stream with absolutely no problem.

Great!

Through the web browser the video struggled to keep up, but I expected that given the transcoding that happens to get it into the web browser.  I will never use NPVR that way, so I don't really care.

Is your encoder producing H.264 + AAC? If so, there is some logic in there where it'll try to avoid re-encoding to get the video into a format that can be played in the browser. I've mainly tested that with an IPTV source, but it should also work with an Extra source (if not the first time you watch a channel, then hopefully from the second watch of the channel ... where it knows a little bit more about the channel from that first attempt). This allows my Synology NAS to be able to stream video to my browser.

[pkscout]

And just to followup, that worked perfectly.  Thanks.  Running the Docker image on my Mac and Kodi on the same machine, I was able to change channels and watch the stream with absolutely no problem.

Great!

Through the web browser the video struggled to keep up, but I expected that given the transcoding that happens to get it into the web browser.  I will never use NPVR that way, so I don't really care.

Is your encoder producing H.264 + AAC? If so, there is some logic in there where it'll try to avoid re-encoding to get the video into a format that can be played in the browser. I've mainly tested that with an IPTV source, but it should also work with an Extra source (if not the first time you watch a channel, then hopefully from the second watch of the channel ... where it knows a little bit more about the channel from that first attempt). This allows my Synology NAS to be able to stream video to my browser.

It can produce that, but I'm having it do H265 AC3 because that solves a problem I was having with one of my client devices (a Vero 4K+ running OSMC/Kodi). that device stutters with interlaced content (1080i) content that comes in H264 for some reason (they're trying to track it down), so I had to downscale the cable box to 720p to fix that.  With the new encoder H265 is fine at 1080i, so that's what I did.  And it's AC3 because my old soundbar doesn't know what to do with AAC in a video track apparently.  It's really not a big deal. I only even tried it as part of the testing to make sure NPVR was doing the video before I added Kodi to the mix.

[mvallevand]

I'm trying to convince sub that we need an option to support mp3 in transcoding for sound bars.

Martin

[sub]

It can produce that, but I'm having it do H265 AC3 because that solves a problem I was having with one of my client devices (a Vero 4K+ running OSMC/Kodi). that device stutters with interlaced content (1080i) content that comes in H264 for some reason (they're trying to track it down), so I had to downscale the cable box to 720p to fix that. 

Ah, ok - that'd explain it.