[Solved, then turned into a hangout thread] Tune Failed: Could Not Create Socket

[arrmo]

Hi,

OK, this is so cool - really like how this all works together. Thanks!

Just having a bit of an issue with my Ceton card. I try to have Plex tune to a channel, but seeing this error (and Plex complains about it of course),

[2022-01-21 17:55:40,333] INFO - Client has requested stream for ceton channel 4 KDFW FOX KDFW FOX.
[2022-01-21 17:55:40,333] INFO - Selected Stream Parameters: method=direct duration=0 origin_quality=None transcode_quality=None.
[2022-01-21 17:55:40,334] INFO - Attempting to Select an available tuner for this stream.
[2022-01-21 17:55:40,334] INFO - Tuner #0 Acquired.
[2022-01-21 17:55:40,335] INFO - ceton Tuner #0 to be used for stream.
[2022-01-21 17:55:40,361] INFO - Selected Ceton tuner#: 0
[2022-01-21 17:55:40,362] INFO - Ceton tuner 0 to be started
[2022-01-21 17:55:40,579] INFO - Preparing Ceton tuner 0 on port: 43534
[2022-01-21 17:55:41,586] INFO - Initiate streaming channel 4 from Ceton tuner#: 0 
[2022-01-21 17:55:41,587] INFO - Preparing Stream...
[2022-01-21 17:55:41,587] INFO - Attempting to create socket to listen on.
[2022-01-21 17:55:41,588] INFO - Created TCP socket at 192.168.2.64:57467.
[2022-01-21 17:55:41,588] INFO - Created UDP socket at 192.168.2.64:43412.
[2022-01-21 17:55:41,589] INFO - Closing UDP socket at 192.168.2.64:43412.
[2022-01-21 17:55:41,590] INFO - Closing TCP socket at 192.168.2.64:57467.
[2022-01-21 17:55:41,590] ERROR - TunerError: 806 - Tune Failed: Could Not Create Socket: 'username'
[2022-01-21 17:55:41,591] INFO - Tuner #0 Released.
[2022-01-21 17:55:41,595] INFO - 192.168.2.65 - - [2022-01-21 17:55:41] "GET /api/tuners?method=stream&channel=4&origin=ceton&stream_method=direct&accessed=http%3A//192.168.2.64%3A5006/hdhr/ceton/auto/v4 HTTP/1.1" 503 2424 1.265516
{'channel': '4', 'channel_name': 'KDFW FOX', 'channel_callsign': 'KDFW FOX', 'origin': 'ceton', 'method': 'direct', 'duration': 0, 'origin_quality': None, 'transcode_quality': None, 'accessed': 'http://192.168.2.64:5006/hdhr/ceton/auto/v4', 'base_url': 'http://192.168.2.64:5006', 'client': '192.168.2.65', 'client_id': 'e21ddcb0-eae3-4b25-a6a1-c014b2985fb2', 'stream_info': {'url': 'udp://127.0.0.1:43534', 'headers': None}, 'true_content_type': 'video/mpeg', 'content_type': 'video/mpeg'}

Absolutely could be me. I'm not sure that I need to set / define 'username' ... or do I?

And to clarify, this is for an InfiniTV 4, PCIe.

BTW, a bit of fiddling here, I was able to look at the Ceton web interface, manually get a channel to tune, and then right after that stream from the appropriate device to mplayer. Just to let you know, the card is working 🤣. Oh, and this is from Postman - used that to confirm the "API" is working.

Requests, channel change
import requests

url = "http://192.168.200.1/channel_request.cgi"

payload='instance_id=3&channel=593'
headers = {
  'Content-Type': 'application/x-www-form-urlencoded'
}

response = requests.request("POST", url, headers=headers, data=payload)

print(response.text)

Thanks!

[deathbybandaid]

Pinging @DanAustinGH as he's the master of this plugin.

[arrmo]

Thanks! And a bit more digging - to try to help debug ... want to fix this myself if I can (and help out!), but I'm new to the code, wandering my way through 😜. It seems like I have to use ffmpeg for the ceton stream_method? I admit, not sure why. Thinking I want direct => let Plex see the stream directly, handle it there, no?

And not quite following the setting above, vs. stream_method in streaming, there it is set to direct. Again, still digging.

But if I go with ceton set to ffmpeg for now, a bit more progress ... but Plex still complains that it "could not tune channel" (which may not be entirely accurate. Updated info below. Will keep digging here!

[2022-01-22 07:39:20,665] INFO - Client has requested stream for ceton channel 8 WFAA ABC WFAA ABC.
[2022-01-22 07:39:20,665] INFO - Selected Stream Parameters: method=ffmpeg duration=0 origin_quality=None transcode_quality=None.
[2022-01-22 07:39:20,666] INFO - Attempting to Select an available tuner for this stream.
[2022-01-22 07:39:20,666] INFO - Tuner #0 Acquired.
[2022-01-22 07:39:20,667] INFO - ceton Tuner #0 to be used for stream.
[2022-01-22 07:39:20,740] INFO - Selected Ceton tuner#: 0
[2022-01-22 07:39:20,741] INFO - Ceton tuner 0 to be started
[2022-01-22 07:39:20,979] INFO - Preparing Ceton tuner 0 on port: 42262
[2022-01-22 07:39:21,926] INFO - Initiate streaming channel 8 from Ceton tuner#: 0 
[2022-01-22 07:39:21,927] INFO - Preparing Stream...
[2022-01-22 07:39:21,928] INFO - Tuning Stream...
ffmpeg version N-105190-ga2372f904c Copyright (c) 2000-2022 the FFmpeg developers
  built with gcc 11 (Ubuntu 11.2.0-7ubuntu2)
  configuration: --enable-libnpp --enable-nonfree --enable-cuda --enable-libx264 --enable-gpl --enable-nvenc --enable-libx265 --enable-cuda-nvcc --enable-cuvid
  libavutil      57. 18.100 / 57. 18.100
  libavcodec     59. 20.100 / 59. 20.100
  libavformat    59. 17.100 / 59. 17.100
  libavdevice    59.  5.100 / 59.  5.100
  libavfilter     8. 25.100 /  8. 25.100
  libswscale      6.  5.100 /  6.  5.100
  libswresample   4.  4.100 /  4.  4.100
  libpostproc    56.  4.100 / 56.  4.100
[2022-01-22 07:39:25,641] INFO - 192.168.2.65 - - [2022-01-22 07:39:25] "GET /discover.json HTTP/1.1" 200 2693 0.005255
[2022-01-22 07:39:25,645] INFO - 192.168.2.65 - - [2022-01-22 07:39:25] "GET /lineup_status.json HTTP/1.1" 200 2464 0.002953
[2022-01-22 07:39:30,933] INFO - 192.168.2.65 - - [2022-01-22 07:39:30] "GET /discover.json HTTP/1.1" 200 2697 0.004641
[2022-01-22 07:39:30,939] INFO - 192.168.2.65 - - [2022-01-22 07:39:30] "GET /lineup_status.json HTTP/1.1" 200 2462 0.003997
[2022-01-22 07:39:36,237] INFO - 192.168.2.65 - - [2022-01-22 07:39:36] "GET /discover.json HTTP/1.1" 200 2694 0.004186
[2022-01-22 07:39:36,242] INFO - 192.168.2.65 - - [2022-01-22 07:39:36] "GET /lineup_status.json HTTP/1.1" 200 2462 0.003843
[2022-01-22 07:39:41,543] INFO - 192.168.2.65 - - [2022-01-22 07:39:41] "GET /discover.json HTTP/1.1" 200 2694 0.004087
[2022-01-22 07:39:41,548] INFO - 192.168.2.65 - - [2022-01-22 07:39:41] "GET /lineup_status.json HTTP/1.1" 200 2462 0.004081
[2022-01-22 07:39:45,245] INFO - 192.168.2.65 - - [2022-01-22 07:39:45] "GET /discover.json HTTP/1.1" 200 2695 0.004065
[2022-01-22 07:39:45,250] INFO - 192.168.2.65 - - [2022-01-22 07:39:45] "GET /lineup_status.json HTTP/1.1" 200 2465 0.003255

BTW, I did check, using the Ceton web interface - and the channel tune is working! Just the streaming back to Plex is failing? Thanks!

PS: anyone know of a way to access the Ceton web interface remotely? It's a (scope) local link, can't seem to figure out the route commands to get to it from elsewhere on my network. Minor, but just to make debug a bit easier 😆.

[deathbybandaid]

I know this plugin was created for the standalone ceton devices. there may have to be some poking on your end to see if it works the same.

One thing you can try, is from the web interface of fHDHR, grab the m3u file from the channel page, and open that in VLC or something. This should rule out fHDHR or Plex as the issue.

If the above works, remove the "dvr" from Plex, and restart Plex, and re-add.

[arrmo]

Appreciate the suggestion! I tried like you said, no joy. It is interesting ... in tuners, it says it tunes to that channel, using the first available tuner (perfect!) ... but streaming (using cat) from the command line (to mplayer), I can see that the channel is actually not tuned.

Hmmm ... need to figure out how to get this running inside pyCharm - debugging that way would be much easier. Problem is that Flask seems to be multi-threaded, which is causing pyCharm grief. But I haven't given up 🤣.

Thanks again!

[DanAustinGH]

You are the first to report trying with a PCIe card. I suspected it would work from what I saw documented about how it works.

You do need to use the FFMPEG method. The Ceton sends the video in an UDP stream and neither Plex nor Emby currently can consume that.

What OS are you running fHDHR on? This could be selinux related or another OS security feature preventing access to the UDP open to receive the Ceton stream. After tuning a channel you can check to see if you have an ffmpeg process connected to the UDP port list on the log line 'INFO - Preparing Ceton tuner 0 on port:' using netstat -apn | grep ffmpeg .

[DanAustinGH]

And it could also be a host based firewall blocking UDP from the embedded Ceton IP and the host...

[arrmo]

You are the first to report trying with a PCIe card. I suspected it would work from what I saw documented about how it works.

Agreed! It's looking just like a network device, so was thinking the same. I got the driver installed, and all working => can connect to the Ceton web interface, play back from the device directly (i.e. /dev/ceton/ctn91xxmpeg0# ... #=tuner)

You do need to use the FFMPEG method. The Ceton sends the video in an UDP stream and neither Plex nor Emby currently can consume that.

Got it, thanks! BTW, will look at this after the basics working, but it would be nice then to use HW transcoding inside ffmpeg, offload the CPU. Or, is it just copying the data (codec), no transcoding. In any case, will investigate here.

What OS are you running fHDHR on? This could be selinux related or another OS security feature preventing access to the UDP open to receive the Ceton stream. After tuning a channel you can check to see if you have an ffmpeg process connected to the UDP port list on the log line 'INFO - Preparing Ceton tuner 0 on port:' using netstat -apn | grep ffmpeg .

Running on Ubuntu, 21.10. Yep, was thinking the same! And I had already found those processes 😆. Output of the netstat command is,

udp        0      0 0.0.0.0:42617           0.0.0.0:*                           1220165/ffmpeg

Also, from ps -elF | grep ffmpeg

0 S user  1220165 1219768  0  80   0 - 47074 futex_ 17324   9 11:07 pts/0    00:00:00 /usr/local/bin/ffmpeg -i udp://127.0.0.1:42617 -reconnect 1 -reconnect_at_eof 1 -reconnect_streamed 1 -reconnect_delay_max 2 -c copy -f mpegts -loglevel info pipe:stdout

So seems to be running - but if I try vlc, or mplayer 'udp://127.0.0.1:42617' ... no go, I get,

MPlayer 1.4 (Debian), built with gcc-10 (C) 2000-2019 MPlayer Team
do_connect: could not connect to socket
connect: No such file or directory
Failed to open LIRC support. You will not be able to use your remote control.

Playing udp://127.0.0.1:42617.
STREAM_UDP, URL: udp://127.0.0.1:42617
Failed to connect to server
udp_streaming_start failed
No stream found to handle url udp://127.0.0.1:42617

So definitely not able to connect. Thoughts? I may be wrong, but it seems that the udp port there is the input (-i), not the output? Or am I just out to lunch? I may be looking the wrong place for the output.

Thanks!!

PS: minor side note, but makes debugging slower - I need to move the CableCARD back to my old tuner, to keep the family happy ... LOL. I have found folks saying that ClearQAM should work with this card - that would make debug easier (not swapping back and forth all the time, and I do have ClearQAM locals on the cable). Do you happen to know how to do this? Just to be able to work through issues here. No biggie if not, just figured I'd ask. Thanks!

[arrmo]

Actually, it hit me as I walked away for a few minutes - the UDP stream may be "different", for an external vs. internal device. I can see the video by running (for example), cat /dev/ceton/ctn91xx_mpeg0_0 | mplayer -cache 8192 -

So do I need direct after all? From mplayer,

MPlayer 1.4 (Debian), built with gcc-10 (C) 2000-2019 MPlayer Team
do_connect: could not connect to socket
connect: No such file or directory
Failed to open LIRC support. You will not be able to use your remote control.

Playing -.
Reading from stdin...
Cache fill: 18.75% (1572864 bytes)

libavformat version 58.76.100 (external)
Mismatching header version 58.45.100
TS file format detected.
Cache empty, consider increasing -cache and/or -cache-min. [performance issue]
Cache empty, consider increasing -cache and/or -cache-min. [performance issue]
Cache empty, consider increasing -cache and/or -cache-min. [performance issue]
VIDEO MPEG2(pid=3031) AUDIO A52(pid=3032) NO SUBS (yet)!  PROGRAM N. 3303
VIDEO:  MPEG2  720x480  (aspect 2)  29.970 fps  15000.0 kbps (1875.0 kbyte/s)

Will dig into the code, but thinking (perhaps incorrectly!) that I need direct, and input coming from the device. Just not sure where it's supposed to go to ... LOL.

Thanks!

[DanAustinGH]

My cable co does not have an clearqam channels, so I cannot test that, but it should work.

Can you use the web interface to manually start a stream? If you check the tuner status in the web, what do you see for the stream setup details? Do you get a unique device name for each tuner under /dev/ceton ? If you do, the answer might be to add an option to the plugin to treat external and internal differently. External uses 127.0.0.1:port# and internal uses /dev/ceton/#devname

If you start a stream from Plex and then manually run: ffmpeg -i /dev/ceton/{device used} test.ts Do you get a video file that can be played?

[DanAustinGH]

I also want to point out I have not tried mplayer, so I do not know if it can read from an UDP socket and if it can if it will handle the video stream. I was never able to get VLC to work, so I can only recommend ffmpeg for testing. It makes the process a bit clunky since you need to output to a file and then check that file, but it works.

[arrmo]

My cable co does not have an clearqam channels, so I cannot test that, but it should work.

Seems to work ... I can't quite figure out (yet) how to rescan. But not changing channels here, and all is OK for debug 😆.

Can you use the web interface to manually start a stream? If you check the tuner status in the web, what do you see for the stream setup details? Do you get a unique device name for each tuner under /dev/ceton ? If you do, the answer might be to add an option to the plugin to treat external and internal differently. External uses 127.0.0.1:port# and internal uses /dev/ceton/#devname

Sorry, can't check the start / stop right now (CC moved to the old box), but pretty sure that was working before => channels were changing, all looked OK. I think the only real issue is the source - like you say, just an option for internal or external may be the fix.

If you start a stream from Plex and then manually run: ffmpeg -i /dev/ceton/{device used} test.ts Do you get a video file that can be played?

Yep! I also tried piping that device to ffmpeg as stdin, same result - all OK. I added an option to copy (codec), and can see the real bit rate, etc. All good, the .ts output is playable (mplayer, or vlc).

I also want to point out I have not tried mplayer, so I do not know if it can read from an UDP socket and if it can if it will handle the video stream. I was never able to get VLC to work, so I can only recommend ffmpeg for testing. It makes the process a bit clunky since you need to output to a file and then check that file, but it works.

No worries! And I like ffmpeg also - can see bitrate, etc. I do agree, it's a handy tool. And I have my own custom local build, to include HW accel for hevc 😄.

I can try to dig into the code, see where to set the internal or external option if you want? I admit, not real familiar with it yet, but more than happy to. Trying to help out if I can!

Thanks!

[DanAustinGH]

How many devices under /dev/ceton?

In plugins/fHDHR_plugin_origin_ceton/origin/init.py on line 197 you can change streamurl to point to one of the /dev/ceton/devices

That may fail due to core code validation functions that expect one of a few valid URL formats. I can point that code out as well if you need it.

If changing the streamurl works, the code would need an option to indicate if the Ceton is PCIe or not, If it is it needs to build a list of usable local devices, and use those instead of UDP ports. Not too complex, but since I don't have a PCIe device I can only provide suggestions...

[DanAustinGH]

Silly question, but do you have ceton_ip set in your fhdhr.ini? And address set as well in the [fhdhr] section?

[arrmo]

How many devices under /dev/ceton?

Listing here,

lrwxrwxrwx  1 root root   15 Jan 22 06:40 ctn91xx_ctl0 -> ../ctn91xx_ctl0
lrwxrwxrwx  1 root root   20 Jan 22 06:40 ctn91xx_filter0_0 -> ../ctn91xx_filter0_0
lrwxrwxrwx  1 root root   20 Jan 22 06:40 ctn91xx_filter0_1 -> ../ctn91xx_filter0_1
lrwxrwxrwx  1 root root   20 Jan 22 06:40 ctn91xx_filter0_2 -> ../ctn91xx_filter0_2
lrwxrwxrwx  1 root root   20 Jan 22 06:40 ctn91xx_filter0_3 -> ../ctn91xx_filter0_3
lrwxrwxrwx  1 root root   20 Jan 22 06:40 ctn91xx_filter0_4 -> ../ctn91xx_filter0_4
lrwxrwxrwx  1 root root   20 Jan 22 06:40 ctn91xx_filter0_5 -> ../ctn91xx_filter0_5
lrwxrwxrwx  1 root root   18 Jan 22 06:40 ctn91xx_mpeg0_0 -> ../ctn91xx_mpeg0_0
lrwxrwxrwx  1 root root   18 Jan 22 06:40 ctn91xx_mpeg0_1 -> ../ctn91xx_mpeg0_1
lrwxrwxrwx  1 root root   18 Jan 22 06:40 ctn91xx_mpeg0_2 -> ../ctn91xx_mpeg0_2
lrwxrwxrwx  1 root root   18 Jan 22 06:40 ctn91xx_mpeg0_3 -> ../ctn91xx_mpeg0_3
lrwxrwxrwx  1 root root   18 Jan 22 06:40 ctn91xx_mpeg0_4 -> ../ctn91xx_mpeg0_4
lrwxrwxrwx  1 root root   18 Jan 22 06:40 ctn91xx_mpeg0_5 -> ../ctn91xx_mpeg0_5

I think the 6 is hard coded in the driver - will look at that after. For now, I stick to 0-3 (4 tuner version of the card).

In plugins/fHDHR_plugin_origin_ceton/origin/init.py on line 197 you can change streamurl to point to one of the /dev/ceton/devices

Changed just below that block, to force, streamurl = "/dev/ceton/ctn91xx_mpeg0_0". Fails though, with a tuner error? This is likely because of no CC => trying to just skip that step for now 😄.

[2022-01-22 12:55:30,352] INFO - Client has requested stream for ceton channel 4 KDFW FOX KDFW FOX.
[2022-01-22 12:55:30,353] INFO - Selected Stream Parameters: method=ffmpeg duration=0 origin_quality=None transcode_quality=None.
[2022-01-22 12:55:30,353] INFO - Attempting to Select an available tuner for this stream.
[2022-01-22 12:55:30,353] INFO - Tuner #0 Acquired.
[2022-01-22 12:55:30,354] INFO - ceton Tuner #0 to be used for stream.
[2022-01-22 12:55:30,354] DEBUG - Attempting to gather stream information for ceton channel 4 KDFW FOX KDFW FOX.
[2022-01-22 12:55:30,383] INFO - Selected Ceton tuner#: 0
[2022-01-22 12:55:30,384] INFO - Ceton tuner 0 to be started
[2022-01-22 12:55:30,520] INFO - Preparing Ceton tuner 0 on port: 42943
[2022-01-22 12:55:30,621] INFO - A ceton stream request for ffmpeg channel 4 was rejected due to TunerError: 806 - Tune Failed
[2022-01-22 12:55:30,622] ERROR - TunerError: 806 - Tune Failed
[2022-01-22 12:55:30,623] INFO - Tuner #0 Released.
[2022-01-22 12:55:30,624] DEBUG - Client GET requested /api/tuners Closing

If changing the streamurl works, the code would need an option to indicate if the Ceton is PCIe or not, If it is it needs to build a list of usable local devices, and use those instead of UDP ports. Not too complex, but since I don't have a PCIe device I can only provide suggestions...

No worries! And agreed. Trying to "hack" this first, prove it gets working => then clean up, enumerate, etc. I see a PR or two in my future 🤣.

Silly question, but do you have ceton_ip set in your fhdhr.ini? And address set as well in the [fhdhr] section?

Never silly! You know me already ... LOL. Yep, both set,

[ceton]
ceton_ip = 192.168.200.1
stream_method = ffmpeg

[fhdhr]
address = 192.168.2.64
port = 5006
discovery_address = 192.168.2.64
tuner_count = 4

Thanks!

[DanAustinGH]

Silly question 2. Are you running all this on the base host, or using a container (docker/kubernetes)?

The code should have the Ceton start sending an UDP stream to 192.168.2.64:%port% and the streaming code uses localhost to open and connect to the UDP port.

The web tuner status should confirm the destination IP and port are what was configured by fHDHR. I am not seeing a lot of docs, but is appears that the PCIe should be capable of doing both local device and UDP/RTP. If it is not setting up the RTP stream properly, it might be that the current code is not passing a setup argument that the PCIe card needs.

The tune error in the log is related to the core code refusing URLs that do not match an expected pattern. Look in fHDHR/device/tuners/init.py fHDHR/device/tuners/stream/init.py for udp:// and add "/dev/ceton/ctn91" to the tuple list This should allow you get past the 806 error

[DanAustinGH]

And before diving deep in the code, although I think the result might be worth it, do you have firewalld running? If so you might need add a rule that allows all UDP traffic from 192.168.200.1/32

The stream from the Ceton appears to be unsolicited and would be blocked by default if you have any firewall running

[arrmo]

Silly question 2. Are you running all this on the base host, or using a container (docker/kubernetes)?

You know you only get 3, right?!?! LOL! Base host - directly running the code in the OS (Linux).

The tune error in the log is related to the core code refusing URLs that do not match an expected pattern. Look in fHDHR/device/tuners/init.py fHDHR/device/tuners/stream/init.py for udp:// and add "/dev/ceton/ctn91" to the tuple list This should allow you get past the 806 error

OK, a tad scary, like you are watching my screen 😉. I was right in that section of the code, looking for the error. I added to that tuple list (/dev/ceton) ... like you say, let's me past then, and ... video in Plex! I think that addition is valid, agreed? Meaning - playback from a device is also acceptable. If you agree, I'll submit a PR, to get that update in.

Then - just need to handle the internal / external on the ceton side of the code, agreed?

Thanks!!

[DanAustinGH]

I am curious about the firewall if it is in the way, but in general the following would be needed-

The tuple list is in DBD's code so he will have to be OK with it.
In the Ceton plugin code we need an option, say Ceton_PCI=T|F (add to ceton_conf.json default False) If Ceton_PCI = Y then the streamurl is set to /dev/ceton/ctn91xxmpeg{cardnum}{tunernum}

Cardnum can be assumed to be the first(0). Right now I do not think the framework allows for multiple Ceton devices, but double bonus points if you can add the code in a way to handle more than one.

And other than tweaking the logging to reflect local devices instead of IP:port that should be all of it

[arrmo]

More than happy to try to dig into the firewall question - but I'm relatively sure I don't have one running. Then again, I was wrong once before 😜. Any particular things you want checked?

Agreed on the tuple list. And really, thinking /dev would make more sense, not limit to /dev/ceton at the top level?

Will work on the code updates, get you something to look at (will get it working, then submit a PR that we can work through ... OK?). And yes, logging as part of that. I really wish I could get pyCharm working with this, but I think Flask and multi-threading is causing it grief 😞. Just makes debugging more difficult without it.

Thanks!

[DanAustinGH]

Right now the only local device that fHDHR could read from is Ceton, so starting out specific makes sense, but DBD can adjust if he has other local devices he might want to open up access to.

I am not an Ubuntu user, so I had to dig. Looks like for that distro the firewall is ufw and off by default. I figured if it was as simple as a firewall, I could add it to the docs to look for. the code you are looking to add may get more folks interested in the project. I am only aware of 3~4 Ceton plugin users.

I see a few PCI Cetons on ebay. I may order one just to play with...

[arrmo]

Sure, will make it more specific, no issue here!

And yes, agreed - ufw, and off. Just wasn't sure if you knew of something else.

Will code it up, get it to you! And definitley ... eBay - I found a 4 tuner one for $25. Pretty nice for a 4 tuner card 😆

Thanks!

[arrmo]

Hmm ... OK, I have code to "count" (determine) the number of PCIe cards. Allocating between them can come later 😆. And I have it selectively setting the url (internal or external). But a bit stuck - the state never seems to change from STOPPED (using stream_request.cgi). Not quite sure why (yet), but it prevents me from getting past using the first tuner ... it always thinks it's available.

[arrmo]

OK, figured that one out - from the log on the Ceton web UI,

Jan  2 11:38:43 ocur[21]: ocur: ERROR: Unable to open presentation file "/stream_request.cgi" (No such file or directory)
Jan  2 11:38:43 ocur[21]: ocur: ERROR: unknown write handle

So seems that page doesn't exist 😞. I did find the attached - really need to all that complexity? It does set up rtsp, but seems to limit to being on the same machine (Ceton, fHDHR)? Need to look a bit more. I also find it doesn't exit very gracefully, seems to keep the device hung.

Thanks! infinitv_client_1_2.tar.gz

[DanAustinGH]

You do not need that code, although I never found that package, so there might be something interesting in there to review.

In the web interface do you have a top level menu with an entry for each of the tuners? If you do under each is there a status and tuner tab/option? If you have a tuner tab, is there section near the bottom labeled 'Streaming Setup'? If all of the above is true, you can view source in the page to see what the required form data is and the url to submit the API as.

[arrmo]

Too funny - yet again, similar thoughts at the same time 😆. I was looking at that, and at /api/tuners?method=status. That seems to include status I could use to decide which tuner to use (and then don't need to check STOPPED, as it doesn't change for the internal device).

Just trying to figure out how to get that status from the tuner api (in the code I mean).

Thanks!

[arrmo]

In the web interface do you have a top level menu with an entry for each of the tuners? If you do under each is there a status and tuner tab/option? If you have a tuner tab, is there section near the bottom labeled 'Streaming Setup'?

Sorry, didn't answer this one. Nope, no streaming setup. That's one thing I noticed in the Ceton web UI ... no place to enable streaming. Or I may be missing it.

[DanAustinGH]

What firmware is running on that card? I was under the impression that both the PCIe and standalone used an identical web interface. I have 15.1.13.152 on my eth6. If you do have a tuner tab, are there any buttons on it? Some of the code in the plugin is based on what I found using view source in the web interface...

[DanAustinGH]

What is returned if you call this- http://192.168.200.1/get_var?i=0&s=av&v=TransportState (i={tunernum})

[DanAustinGH]

Oh and you really do want to get the cards tuner state. Ideally it should always match the core tuner state, but they can get out of sync.

[arrmo]

What firmware is running on that card?

1.1.8.2. Wow, that's quite a difference. I do find this. Thoughts? Try this? Don't want to bake my card of course.

If you do have a tuner tab, are there any buttons on it? Some of the code in the plugin is based on what I found using view source in the web interface...

Agreed! Was thinking the same thing. And agree - I also looked at that code, as well in the browser devtools.

What is returned if you call this- http://192.168.200.1/get_var?i=0&s=av&v=TransportState (i={tunernum})

STOPPED ... no matter what the state. That's why I was thinking about using the core tuner state. Thoughts?

Thanks!

[arrmo]

Looks like the version numbers are quite different, 4 vs. 6 http://cetoncorp.com/infinitv_support/linux_drivers/

[DanAustinGH]

You need an update. This page has links to various versions. I think you will have to do multiple updates since your version is so old. Further it is documented that older firmware (like yours) does not stream. Getting the latest firmware on your device will likely allow it to work with no code mods (but they might still be worthwhile)

[arrmo]

Perfect! Sorry, which page? Or did I just miss the link?

[DanAustinGH]

Failed to paste it- https://githubhelp.com/craigmox/cetonproxy Folks on that page have that app working with a PCIe 4 tuner. It uses the same http API calls that the plugin uses, so I take that as a positive sign.

[DanAustinGH]

Oh and while all Ceton owned pages are MIA, it appears that they wen from code 1.2. to 13. No idea why but there does not appear to have been a dozen in between releases

[arrmo]

Thanks! Giving it a shot 🥁

[arrmo]

OK, up to 14 so far ... and now those buttons show up. LOL!

Let me get to 15, then will go back to fHDHR, give it a shot.

[arrmo]

Well, firmware is current, no error messages now - but still fails to playback. ffmpeg is running, so very odd. Not sure if I need to reboot, then remove and re-add in Plex perhaps?

Thanks!

[DanAustinGH]

The status page should show 'PLAYING' once a tuner is tuned. The tuner page streaming section should confirm the host IP and the port number that the plugin requested. You can now use the fhdhr web interface and check the tuners view and confirm that the desired channel is tuned and both downloaded and served are increasing. I doubt you need a reboot or changes in Plex, but they won't hurt.

[arrmo]

The status page should show 'PLAYING' once a tuner is tuned.

Yep!

The tuner page streaming section should confirm the host IP and the port number that the plugin requested.

Yes, but ... the destination IP seems to be my Ceton IP (192.168.200.2), and the port is 8000? Not sure that is right, and may be why the video isn't getting to Plex? Otherwise it all seems happy. Will dig more here!

[arrmo]

Hmmm, from the Ceton log - wondering if this is the issue?

Jan  1 00:24:10 ocur[21]: ocur: [0] stream request 192.168.2.64:45673 start:1 prot: 0
Jan  1 00:24:10 ocur[21]: upnp: Event(cm[0]): CurrentConnectionIDs, "0"
Jan  1 00:24:10 ocur[21]: ocur: WARNING: failed to get hwaddr for remote rtp addr

Thanks!!

[deathbybandaid]

@DanAustinGH let's make sure we document tested firmware versions that this plugin works for

[DanAustinGH]

Others have documented the minimum as 13.5.6.132 For my use I just went to the latest.

The streaming page defaults to 192.168.200.X:800X where X is the tuner numbers and the tuner number, so that is not super helpful. If the tuner status is still showing Playing with that error, you could connect to the hardware device to matches that tuner. Another option would be to add a loopback network adapter to your system and assign it to 192.168.200.2.

Can you do a view source on the tuner page, zip it and post it here? It is possible that the PCIe card has more options on the page than the standalone version.

[arrmo]

@DanAustinGH let's make sure we document tested firmware versions that this plugin works for

Agreed! I took a note to myself this morning actually - good info to capture, knowing that a specific (minimum) version is needed. One of the (slight) gotchas here.

Can you do a view source on the tuner page, zip it and post it here? It is possible that the PCIe card has more options on the page than the standalone version.

Sure, NP! Attached - just yell if you need anything else. BTW, this is when not running - but I can update if you want. http _192.168.200.1_Services_1_Tuner.zip

OK, and I tried one thing here ... made this slight (temporary) change to the code, in get_channel_stream()

streamurl = "/dev/ceton/ctn91xx_mpeg0_%s" % instance

Works great, even tried with 3 tuners running, all good! Not saying this is the final answer, but it really all is working except the streaming. And there - wondering if it's me just being stupid. I admit, a bit confused by some of the address settings, perhaps I have one wrong? Here is what I have - noting that my LAN IP is 192.168.2.64, so thinking that's what I need to use for fHDHR also? But perhaps I have misunderstood.

[ceton]
ceton_ip = 192.168.200.1
[fhdhr]
address = 192.168.2.64
port = 5006
discovery_address = 192.168.2.64

Also, what I do note is, from ip route

192.168.200.0/24 dev ctn0 proto kernel scope link src 192.168.200.2 metric 100

Scope is local? FYI, I did try from another machine (after adding a route to 192.168.200.0/24) ... and I can ping 192.168.200.2, but not 192.168.200.1. Expected? And needed? Does it mean that fHDHR needs to be running on the machine where the Ceton card is? It is in my case, but perhaps part of the issue?

Sorry if this is rambling thoughts - trying to figure out the IP config here, as this may be part (or all) of it.

Thanks!

[DanAustinGH]

Your understanding that you want to set the fhdhr address to the LAN IP is correct. The Ceton plugin assumes that the Ceton device will send the stream to that IP.

What I suspect is the issue is that the Ceton internally does not have a default gateway so can only communicate with 192.168.200.X. The IP route line seems to support this. can you run ip addr and confirm that the ctn0 interface is assigned 192.168.200.2 ? If it is, we might be able to use '192.168.200.2' in dest_ip in function startstop_ceton_tuner and keep the streamurl as 127.0.0.1

BUT since the stream is going over the PCI bus in either case, UDP stream or direct device access, it might by very slightly more efficient to get the stream from the hardware device. We will use the http control API to tune channels and start the tuner.

I can think of a few hacky ways to try to run fhdhr on a separate system, but for the PCI card, I think it should be on the same box to keep things simple.

[arrmo]

What I suspect is the issue is that the Ceton internally does not have a default gateway so can only communicate with 192.168.200.X. The IP route line seems to support this. can you run ip addr and confirm that the ctn0 interface is assigned 192.168.200.2 ? If it is, we might be able to use '192.168.200.2' in dest_ip in function startstop_ceton_tuner and keep the streamurl as 127.0.0.1

Yep, confirmed ... ran ip -c addr, result is,

4: ctn0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 1000
    link/ether 00:22:2c:ff:ff:ff brd ff:ff:ff:ff:ff:ff
    inet 192.168.200.2/24 brd 192.168.200.255 scope global dynamic noprefixroute ctn0
       valid_lft 847482sec preferred_lft 847482sec

And I was thinking the same - no default GW. I went to the Ceton GUI, was going to try to manually add it ... but even if not running DHCP, you cannot set the GW. So I'm with you, thinking it's not used / available => limited to that subnet only. And the log output (above) supports that.

BUT since the stream is going over the PCI bus in either case, UDP stream or direct device access, it might by very slightly more efficient to get the stream from the hardware device. We will use the http control API to tune channels and start the tuner.

Agreed! Was thinking exactly the same thing 😄. The tuning is all working, as is PLAYING / STOPPED (i.e. status) ... so like you are saying - don't use the RTP stream, just get it directly from the device. I hacked in the code above, and it does work ... I can go back to adding the variable we talked about (for PCIe True/False), and then set the url based on that. Work for you? And perhaps for now, just limit to 1 PCIe card? I can put back the code I had locally added though also, that does display in the log the number of cards. For later 😜.

I can think of a few hacky ways to try to run fhdhr on a separate system, but for the PCI card, I think it should be on the same box to keep things simple.

Agreed!

[DanAustinGH]

I support everything you propose. Multiple cards would be nice, but would require changing the config system to support at least a list of card IP, or a dict that maps card number to card IP and then tracking which channels are tuned to which card/tuner (we already track tuner).

Since you are the first to use a PCI card, I would guess the demand for multiple is not very high.

You'll end up with one PR for changes inside the Ceton plugin and one for the tuple changes, unless @deathbybandaid wants to make those for you.

[arrmo]

Agreed! And yes, a lot of complexity for multiple cards - could be an addition later, but perhaps not critical right now 😆.

And agreed as well on 2 PR's - was thinking the same. FYI, code already modified here, and it's working - now to beta test on the family 😜. It's not super complex, and I do at least log the number of Ceton PCIe cards.

Just one other minor question, thinking efficiency, and not adding load if not needed. As the stream now is not RTP / UDP, but rather the "direct" tuner traffic ... wondering if it could be moved from ffmpeg to direct? Ya, I tried it, didn't work out of the box - no biggie, but wondering if I should dig more, or if that's just not possible. Also, if it is ffmpeg, wondering about HW accel ... just to offload the CPU. Or both of these - future enhancements?

Thanks for all the help, and putting up with my wandering path - really appreciated! I do like how this works, hope you can find a PCIe card on eBay!

[deathbybandaid]

Whatdo you mean by tuple changes?

If needbe, the ceton plugin can have a custom ffmpeg streaming method.

[DanAustinGH]

The card is using a video stream format based on RTSP over UDP. Emby/Plex and others want to see HLS over TCP or HTTP chunks over TCP. True direct is not going to work. I looked into a few Python projects to convert RTSP to HLS or HTTP chunks. I never got anything to work, and after rethinking it, I just don't see how a Python implementation would be better than FFMPEG. It would eliminate a dependency, but would likely be slower and far less able to handle bad streams.

Earlier you mentioned hardware acceleration. I tried that. Turns out to be not needed. A 10 year old CPU has more than enough power to handle the conversion in realtime with very little CPU.