[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!

[arrmo]

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.

Makes sense ... it's just copy, no transcoding (at least if set that way), right?

NP, this is the easier solution 😉.

OK, about to put it to the test ... but missing some channels (that show up in the Ceton GUI). Hmmm ... forced a channel update, still missing. Let me have the Ceton clear, reload the channels, see if that does it.

Thanks!

[DanAustinGH]

I wish this forum numbered posts. The core only allows stream URLs to start with rtp, rtsp and udp. We want to also allow direct device input into ffmpeg.

[DanAustinGH]

For missing channels, make sure you have not set favorites or disabled them in the fhdr web.

[arrmo]

Right! This is my update,

        if stream_args["stream_info"]["url"].startswith(tuple(["rtp://", "rtsp://", "udp://", "/dev/ceton"])):

OK with you @deathbybandaid?

[deathbybandaid]

I think if /dev/ would be more universal for potential other hardware devices.

I try to keep the core code so it doesn't have anything plugin specific.

[DanAustinGH]

Yup. We discussed that above and I thought you might want to consider other devices, but did not want to make that call, so I suggested more specific.

[deathbybandaid]

I'll do they change for core myself

[deathbybandaid]

This is the update I pushed to core

https://github.com/fHDHR/fHDHR/pull/212

I've also opened up the idea of possibly coding in some handling for the built-in method of reading the hardware device directly without ffmpeg.

[arrmo]

Thanks! Will pull it in here. FYI, I missed this in the logs, but my channel issue is due to,

  File "fHDHR/plugins/fHDHR_plugin_origin_ceton/origin/__init__.py", line 136, in get_channels
    count = int(count.group(0))
AttributeError: 'NoneType' object has no attribute 'group'

Will fix it, PR for it.

[arrmo]

OK, I take that back 😆. I rescanned (after card remove + insert), I see this ... huh? Odd - the different counts (687 vs. 832).

[2022-01-23 12:15:33,323] INFO - Tuner #1 Performing Channel Scan for ceton origin.
[2022-01-23 12:15:33,326] INFO - Performing Channel Scan for ceton.
[2022-01-23 12:15:33,330] INFO - 192.168.2.66 - - [2022-01-23 12:15:33] "GET /api/tuners?method=scan&origin=ceton&redirect=/channels?origin=ceton HTTP/1.1" 302 2835 0.009086
[2022-01-23 12:15:33,451] INFO - 192.168.2.66 - - [2022-01-23 12:15:33] "GET /channels?origin=ceton&retmessage=scan%20Success HTTP/1.1" 200 423311 0.116107
[2022-01-23 12:15:33,544] INFO - 192.168.2.66 - - [2022-01-23 12:15:33] "GET /style.css HTTP/1.1" 200 5364 0.004337
[2022-01-23 12:15:33,553] INFO - 192.168.2.66 - - [2022-01-23 12:15:33] "GET /brython.js HTTP/1.1" 304 2447 0.003119
[2022-01-23 12:15:33,557] INFO - 192.168.2.66 - - [2022-01-23 12:15:33] "GET /brython_stdlib.js HTTP/1.1" 304 2454 0.002996
[2022-01-23 12:15:33,593] INFO - 192.168.2.66 - - [2022-01-23 12:15:33] "GET /favicon.ico HTTP/1.1" 200 17955 0.004499
[2022-01-23 12:15:34,599] INFO - 192.168.2.66 - - [2022-01-23 12:15:34] "GET /brython.bry?1642961734572 HTTP/1.1" 200 8477 0.004601
[2022-01-23 12:15:34,618] INFO - 192.168.2.66 - - [2022-01-23 12:15:34] "GET /favicon.ico HTTP/1.1" 200 17953 0.004419
[2022-01-23 12:15:35,893] INFO - Found 687 channels for ceton.
[2022-01-23 12:15:35,894] INFO - Performing ceton Channel Import, This can take some time, Please wait.
[2022-01-23 12:15:36,934] INFO - ceton Channel Import took 1 seconds
[2022-01-23 12:15:36,934] INFO - Found no NEW channels for ceton.
[2022-01-23 12:15:36,935] INFO - Total ceton Channel Count: 832
[2022-01-23 12:15:36,946] INFO - Requested Channel Scan for ceton origin Complete.
[2022-01-23 12:15:36,946] INFO - Tuner #1 Released.

[deathbybandaid]

Another thought, does the Ceton webpage (in fhdhr) function correctly?

If so, is there any additional information to pull fromthe ceton api that would be useful for others?

Maybe pull hardware type and firmware version to display here?

[arrmo]

I like that idea! Would be good to pull that in - at least IMHO.

[arrmo]

And BTW, a bit of hacking around, but if I set page=0 when getting channels ... I get them all at once, no need to page through them. Do you want me to try to make that change? Simplifies the code a bit I think.

Thanks!

[arrmo]

OK, this one is odd ... LMAO. I checked, import is correct (number, count, etc.). But the channel list then in the fHDHR web interface is not. Weird.

Digging into it!

Oh, and I have it running here on a single page - we can include or not, your call!

[DanAustinGH]

The Ceton will only deliver 1026 channels in one go. The page code was to get additional channels above that. Will review to see if something got reverted during a merge. if you go to http://192.168.200.1/view_channel_map.cgi? is there a line that looks like 1 to 50 of 832 ?

There is quite a bit of extra details that we could pull. Most stuck me as uninteresting from an fhdhr point of view and could be retrieved directly from the device. BUT my case has the device web interface is available from any system on my network.

@deathbybandaid thanks for those changes.

[arrmo]

Yep, I do see 1 of 50 - didn't know about the 1026 limit. Thanks!

And agreed, thanks @deathbybandaid - much appreciated!!

[arrmo]

Also agree on the items to fHDHR - as I can only see the Ceton details on a single machine 😞

[DanAustinGH]

It looks like the code is failing to get the total count. In the while block I start with page 0 and if there are more than 1024 entries, I jump to page 21 and collect the rest. One possibility is your local channel list was damaged, which can happen if you stop fhdhr during a channel import. You might try renaming data/cache/fhdhr.db with the app stopped and then restart without the page=0 changes to see if you get a clean import

[deathbybandaid]

I think plex also has a limit for channel count

[DanAustinGH]

I see a better way to get the channel count if you want to try it. In get_channels replace count_url = 'http://%s/view_channel_map.cgi?page=1' % self.ceton_ip with count_url = 'http://%s/get_var?i=0&s=diag&v=NumChannels' % self.ceton_ip

then replace: count = re.search('(?<=1 to 50 of )\w+', countReq.text) with: count = re.search(r'\d+(?=<)', countReq.text)

[arrmo]

One possibility is your local channel list was damaged, which can happen if you stop fhdhr during a channel import. You might try renaming data/cache/fhdhr.db with the app stopped and then restart without the page=0 changes to see if you get a clean import

That did it, thanks!

Will give that code try a change, get back to you!

[arrmo]

BTW, looking at the output (log), should this one be changed to DEBUG level?

[2022-01-23 16:03:24,604] INFO - Serving Chunk #12734: size 1152033
frame=217716 fps= 30 q=-1.0 size=14328328kB time=02:01:05.02 bitrate=16156.5kbits/s speed=   1x    
[2022-01-23 16:03:25,189] INFO - Serving Chunk #12735: size 1152033
frame=217731 fps= 30 q=-1.0 size=14329450kB time=02:01:05.52 bitrate=16156.7kbits/s speed=   1x    
[2022-01-23 16:03:25,565] INFO - Serving Chunk #12736: size 1152033
frame=217748 fps= 30 q=-1.0 size=14330361kB time=02:01:06.09 bitrate=16156.5kbits/s speed=   1x    
[2022-01-23 16:03:26,128] INFO - Serving Chunk #12737: size 1152033
frame=217765 fps= 30 q=-1.0 size=14331451kB time=02:01:06.66 bitrate=16156.4kbits/s speed=   1x    
[2022-01-23 16:03:26,724] INFO - Serving Chunk #12738: size 1152033
frame=217781 fps= 30 q=-1.0 size=14332537kB time=02:01:07.19 bitrate=16156.5kbits/s speed=   1x    
frame=217794 fps= 30 q=-1.0 size=14333459kB time=02:01:07.62 bitrate=16156.5kbits/s speed=   1x    

[deathbybandaid]

How's this?

https://github.com/fHDHR/fHDHR/pull/213

[DanAustinGH]

I like it!

[arrmo]

Agreed, and dang that was quick. Thanks!!

[arrmo]

Please check this out, let me know your thoughts. Thanks! https://github.com/fHDHR/fHDHR_plugin_origin_ceton/pull/17

[arrmo]

And let me apologize, as I'm not trying to turn this item into a bunch of other things ... rather the opposite, that's why I'd like your thoughts. We discussed above about trying to stream from HW directly, and I know I'd like to set the script up to run as a service on my Linux box (for that I also need to dump all the console output to a file). All things that aren't critical or gating, but also that I don't want to forget. Thoughts on how to capture them?

My initial thought was to capture them as Issues - they aren't bugs or problems, not at all, rather potential enhancements. But just looking for a good, organized, way to capture items, and work through them. Heck, assign the service to me, I'll get it worked out😄. But really, want to know your thoughts on it. If you don't like it - NP! I'm not trying to redirect, not at all. I think what is here really is awesome. But also thinking a couple of the things I'd like to add to my setup - well, if I can share to help repay in a small part for all the work here, I'd like to.

Thanks again!

[DanAustinGH]

I do not have much I plan to add, so if you want to open an issue for the items you would like to add, I can help with them. I do have a systemd unit file for fhdhr, which I never thought about adding to the package, but it would be worth it I think.

[deathbybandaid]

@arrmo once #17 is merged, we'll close this thread. Feel free to open additional threads for each individual idea you might have, to open them for discussion.

If you have ideas you'd like to attempt to tackle for more origin plugins, you can open those in the fHDHR/fHDHR repo.

[arrmo]

Sorry, catching up - work getting in the way of fun 😆

I do not have much I plan to add, so if you want to open an issue for the items you would like to add, I can help with them. I do have a systemd unit file for fhdhr, which I never thought about adding to the package, but it would be worth it I think.

Yes, was thinking to capture the info for folks - and it's handy in general. Was going to do exactly the same thing ... systemd.

@arrmo once #17 is merged, we'll close this thread. Feel free to open additional threads for each individual idea you might have, to open them for discussion.

Will do, thanks! Some folks / projects don't like "Issues" raised, if not bugs - but seems like you're OK with it. Just wanted to make sure first.

[deathbybandaid]

I've always felt that github should copy what they do with the issues tab and make a feature requests tab

[arrmo]

Agreed! And that's why I asked - don't want it looking like bugs exist, but I also know that for me at least writing things down (and then working through them) is handy, things not forgotten.

[arrmo]

Just a thought, but ... add Labels? Could be for bug states also (confirmed, working, etc.) ... and "Feature Request"? Just a thought.

[deathbybandaid]

whenever I open feature requests on repos, I usually do "[Feature Request] blahblah"

I do add labels to stuff sometimes

[deathbybandaid]

I spent the morning playing with the creation of "Direct" methods for Hardware and a seperated UDP script.

These are completely untested, and In theory, we could also implement a method for reading URLs with file:// for directly streaming video files (if somebody wanted that).

If either of you have time to poke at a completely pythonic way of making the RTP stream better (without depending on importing stuff like cv2 or other odd video modules), go for it

https://github.com/fHDHR/fHDHR/blob/main/fHDHR/device/tuners/stream/direct_hardware_stream.py

https://github.com/fHDHR/fHDHR/blob/main/fHDHR/device/tuners/stream/direct_rtp_stream.py

https://github.com/fHDHR/fHDHR/blob/main/fHDHR/device/tuners/stream/direct_udp_stream.py

[arrmo]

Awesome, thanks! Will take a look. And my apologies, I'll be a bit slower during the week. Dang work! 🤣

[deathbybandaid]

Went ahead and made a method for file://

https://github.com/fHDHR/fHDHR/pull/218

[arrmo]

Will take a look, thanks! Need to understand it yet of course 😆. Thinking the intention is to send the "raw" packets from /dev to the Plex client ... do I have that right?

[deathbybandaid]

yes, and preferably I'd find a way to determine the content type properly instead of assuming mpegts

[arrmo]

Thinking out loud, and complete unproven 😜 ... but, use ffprobe on that (file) stream, to get the content type? Just a thought.

[DanAustinGH]

Just a thought, tune a channel using Plex then do a cat /dev/ceton/ctn91xx_mpeg{tuner} > test.raw then ffprobe test.raw

If we are lucky the direct device read is not using the UDP/RTP packet structure, and in a format that does not need converting before streaming.

@arrmo I put this in the PR, but can you check what this call outputs on your card- http://192.168.200.1/get_var?i=0&s=diag&v=Host_Connection

That might be the easiest call to use to figure out if it is PCI or standalone.

[DanAustinGH]

You posted in the PR as I posted here. Instead of the config option, we can use that call to detect device type. and switch input methods.

[deathbybandaid]

Any potential "direct" python method in core can't rely on external dependencies like ffmpeg/ffprobe

[DanAustinGH]

I'm suggesting using ffprode to document the packaging/format that we get from reading directly from the tuner device. It is unlikely that changes, but we can check an SD channel and bot a 720 and 1080 HD channel. If the packaging/stream format is consistent, we can then determine if it can easily be direct streamed or converted without VLC or ffpmeg to be direct streamable.

[arrmo]

You posted in the PR as I posted here. Instead of the config option, we can use that call to detect device type. and switch input methods.

I like it! Will remove the variable, auto-detect. To confirm ... in your case, is it "Ethernet" (including case, so not ethernet), right?

[DanAustinGH]

Nope, just lowercase ethernet. You might just check to see if PCI or pci are in the string...

[deathbybandaid]

if "pci" in returned_string.lower()

[arrmo]

if "pci" in returned_string.lower()

Yep, that's my plan - agreed! 😄

[arrmo]

FYI, did a very quick check here (not near the machines right now), and looks like the video is (always?) mpeg2video, .ts ... so do we assume that?

[deathbybandaid]

mpegts is the format that Plex would expect to see from a real HDHR device. However, fHDHR is able to tell Plex what kind of video to expect.

https://github.com/fHDHR/fHDHR/blob/e04e0b0d5ff63fa904160cc6490308b51c7e4648/fHDHR_web/api/tuners.py#L200