Closed arrmo closed 2 years ago
Fhdhr tuner number doesn't necesarily coordinate with the ceton tuner number. That would have to be handled by the plugin
Also, ceton related issues should go on the repo for that plugin
and github is borked, and won't let me transfer the issue to the other repo
Was just gonna ask if you could ... LOL. Came to the same conclusion as you - just takes me a bit longer, you definitely have a better handle on the code than I do.
Working on a fix now π.
Thanks!
FYI, think I have a fix in place - just testing to confirm
Thanks!
Addresses the tuner status - just want to also update the (Ceton) UI. Hope to have that worked out as well in a day or two ... close this out, or leave it until I have that PR? Whichever you prefer!
FYI π => based on direct, mpeg0_x status. Getting very close!
OK, it hit me today - I am updating the logic to hopefully also catch if some other application is using a tuner (a possibility, as Dan had mentioned), but then ... do you take the tuner number reported from the plugin? Right now that's not the case (I think π).
Thanks!
The plugin is reponsible for giving fHDHR a uri/url to stream
Yes, agreed! Just wanting to make sure you're OK with the plugin saying (for example), "Tuner 1", but fHDHR says "Tuner 0". If so, no issue here π.
Thanks!
the fHDHR tuner isn't even selected until after the plugin provides a stream uri.
that status screencap looks really nice
the fHDHR tuner isn't even selected until after the plugin provides a stream uri.
Yep, understood. Let me get a screen capture here for you, not sure I'm quite explaining this right (or very well).
that status screencap looks really nice
Thanks! Still planning to add in some Ceton data - like you had suggested. Completely agree with you. Will send another update in a bit.
the fHDHR tuner isn't even selected until after the plugin provides a stream uri.
Yep, understood. Let me get a screen capture here for you, not sure I'm quite explaining this right (or very well).
OK, here is what I meant. Another client is accessing Tuner 0, so the first fHDHR client grabs Ceton 1,
But fHDHR, sees this as Tuner 0, not 1 ... you OK with this "disconnect"? That's all I was meaning. It could be aligned, without much trouble ... but your call!
that status screencap looks really nice
As you can see, still working on it π
FYI, this numbering offset is causing some grief => wrong tuners being shut off, retuned, etc.
Thanks!
The plugin needs to keep track of that on it's own
Agreed! And I believe it is - it even returns the instance number (I THINK ... π), but that doesn't seem to be used "upstream". It should be (used), no?
Thanks!
so I'm pretty sure the way I wrote
def get_channel_stream(tuner_number, stream_args):
# get your streamurl somehow
stream_info = {"url": streamurl}
return stream_info
you can in theory pass other things in the stream_info
dictionary, such as ceton_tuner_number
which should be usable in prime_stream
and close_stream
Sorry, you lost me there π. Likely me though.
I do see Ceton selecting Tuner 1 (if 0 is in use), and it should return the instance, from,
def get_channel_stream(self, chandict, stream_args):
found, instance = self.get_ceton_tuner_status(chandict)
But fHDHR is using Tuner 0 => ignoring the instance that is returned? Or are you saying that this instance (value) should be returned in a certain key (inside stream_info), and then it will be used "above"? What is that key (as I assume it's a fixed value, the same for all origins to return)?
Thanks!
I was just saying there's an easy way to track what Ceton tuner you are using
Sorry - do you mean ... in the plugin, track the mapping? So "top level" = 0 aligns to ceton = 1? I was thinking they should be the same, but understand if not ... and the plugin needs to track this?
No panic, but if you would - let me know your thoughts on this. If the mapping needs to be maintained in the plugin ... no issue, I'll work on getting that addressed.
And ... can information be "freely" added to stream_args
? Thinking this may be a way to maintain the mapping.
Thanks!
That's what I was trying to say before. Yes, information can be added back to the stream args
OK, got it - wasn't quite sure that was what you meant. And also if I could freely add something π.
Sometimes I need a π to the side of the head ... LOL.
Thanks!
Well ... LOL. OK, not sure this quite works yet. Here's why I say so,
I started fHDHR, and then through the Ceton UI ... took Tuner 0 into use for another application.
Requested a channel through fHDHR. It works, as below,
[2022-03-09 13:41:37,853] p1124821 {/mnt/ProgSSD/fHDHR/fHDHR/streammanager/__init__.py:115} - DEBUG - Client requested the channel 4c309db8-6bd7-4853-82b1-1730309e4c55
[2022-03-09 13:41:37,854] p1124821 {/mnt/ProgSSD/fHDHR/fHDHR/streammanager/__init__.py:125} - DEBUG - Channel information has been determined as: Channel=593 Origin=ceton
[2022-03-09 13:41:37,855] p1124821 {/mnt/ProgSSD/fHDHR/fHDHR/streammanager/__init__.py:146} - DEBUG - Parsing URL arguments for stream handling.
[2022-03-09 13:41:37,856] p1124821 {/mnt/ProgSSD/fHDHR/fHDHR/streammanager/__init__.py:155} - DEBUG - Client did not select a stream method. Defaulting to origin ceton setting of ffmpeg
[2022-03-09 13:41:37,857] p1124821 {/mnt/ProgSSD/fHDHR/fHDHR/streammanager/__init__.py:165} - DEBUG - Client did not specify a duration to end the stream, stream will run indefinately.
[2022-03-09 13:41:37,858] p1124821 {/mnt/ProgSSD/fHDHR/fHDHR/streammanager/__init__.py:173} - DEBUG - Client did not select a transcode quality. Defaulting to origin ceton setting of custom
[2022-03-09 13:41:37,858] p1124821 {/mnt/ProgSSD/fHDHR/fHDHR/streammanager/__init__.py:181} - DEBUG - Client did not specify a tuner number, automatic selection enabled.
[2022-03-09 13:41:37,859] p1124821 {/mnt/ProgSSD/fHDHR/fHDHR/streammanager/__init__.py:188} - DEBUG - Logging information regarding how the client has accessed the stream.
[2022-03-09 13:41:37,860] p1124821 {/mnt/ProgSSD/fHDHR/fHDHR/streammanager/__init__.py:208} - DEBUG - Pulling default settings for %s regarding stream handling: origin_quality=None bytes_per_read=1152000 buffer_size=3 stream_restore_attempts=3
[2022-03-09 13:41:37,860] p1124821 {/mnt/ProgSSD/fHDHR/fHDHR/streammanager/__init__.py:61} - DEBUG - Instantiating Stream_OBJ Object
[2022-03-09 13:41:37,860] p1124821 {/mnt/ProgSSD/fHDHR/fHDHR/streammanager/stream_obj.py:127} - DEBUG - Attempting to gather stream information for ceton channel 593 Golf HD Golf HD.
[2022-03-09 13:41:38,105] p1124821 {/mnt/ProgSSD/fHDHR/fHDHR/plugins/plugin_logger.py:27} - INFO - [ceton] Selected Ceton tuner#: 1
[2022-03-09 13:41:38,107] p1124821 {/mnt/ProgSSD/fHDHR/fHDHR/plugins/plugin_logger.py:27} - INFO - [ceton] Ceton tuner 1 to be started
[2022-03-09 13:41:38,283] p1124821 {/mnt/ProgSSD/fHDHR/fHDHR/plugins/plugin_logger.py:27} - INFO - [ceton] Preparing Ceton tuner 1 on port: 44285
[2022-03-09 13:41:38,971] p1124821 {/mnt/ProgSSD/fHDHR/fHDHR/plugins/plugin_logger.py:27} - INFO - [ceton] Initiate PCIe direct streaming, channel 593 from Ceton tuner#: 1
[2022-03-09 13:41:38,972] p1124821 {/mnt/ProgSSD/fHDHR/fHDHR/streammanager/stream_obj.py:103} - INFO - Attempting to Select an available tuner for this stream.
[2022-03-09 13:41:38,973] p1124821 {/mnt/ProgSSD/fHDHR/fHDHR/device/tuners/tuner.py:75} - INFO - Tuner #0 Acquired.
[2022-03-09 13:41:38,974] p1124821 {/mnt/ProgSSD/fHDHR/fHDHR/streammanager/stream_obj.py:111} - INFO - ceton Tuner #0 to be used for stream.
[2022-03-09 13:41:38,975] p1124821 {/mnt/ProgSSD/fHDHR/fHDHR/streammanager/stream_obj.py:113} - INFO - Preparing Stream...
[2022-03-09 13:41:38,976] p1124821 {/mnt/ProgSSD/fHDHR/fHDHR/streammanager/stream_obj.py:77} - INFO - Client has requested stream for ceton channel 593 Golf HD Golf HD.
[2022-03-09 13:41:38,976] p1124821 {/mnt/ProgSSD/fHDHR/fHDHR/streammanager/stream_obj.py:83} - INFO - Selected Stream Parameters:method=ffmpeg duration=0 origin_quality=None transcode_quality=custom.
[2022-03-09 13:41:38,977] p1124821 {/mnt/ProgSSD/fHDHR/fHDHR/streammanager/stream/__init__.py:104} - INFO - Tuning Stream...
So, Ceton is Tuner 1, fHDHR sees it as 0. NP, I could try to add a mapping, as fHDHR seems to call get_channel_stream(self, chandict, stream_args)
to start the process ... I could store the needed info in stream_args
, as you mention.
When I try to stop, I don't get stream_args
back π. Rather, it seems to be calling close_stream(self, instance, args)
directly, using the instance
value from fHDHR, not Ceton => I close the wrong tuner ... and I do see that, in the logs (below), and also Ceton UI,
[2022-03-09 13:41:45,814] p1124821 {/mnt/ProgSSD/fHDHR/fHDHR/origins/origin.py:159} - INFO - Running ceton close_stream method.
[2022-03-09 13:41:45,815] p1124821 {/mnt/ProgSSD/fHDHR/fHDHR/plugins/plugin_logger.py:27} - INFO - [ceton] Closing Ceton tuner 0
[2022-03-09 13:41:45,816] p1124821 {/mnt/ProgSSD/fHDHR/fHDHR/plugins/plugin_logger.py:27} - INFO - [ceton] Ceton tuner 0 to be stopped
Make sense? And agreed?
BTW, a few other observations from the logs,
buffer_size = 0
in my config.ini, but it seems to be using, [2022-03-09 13:40:55,190] p1124821 {/mnt/ProgSSD/fHDHR/fHDHR/origins/origin.py:59} - DEBUG - Setting ceton Origin Configuration buffer_size=3
?bytes_per_read = 1152000
, but
[2022-03-09 13:41:42,022] p1124821 {/mnt/ProgSSD/fHDHR/fHDHR/streammanager/stream/__init__.py:197} - DEBUG - Serving Chunk #8: size 65569
[2022-03-09 13:41:42,023] p1124821 {/mnt/ProgSSD/fHDHR/fHDHR/streammanager/stream/__init__.py:202} - DEBUG - Removing chunk #8 from the buffer.
[2022-03-09 13:41:42,024] p1124821 {/mnt/ProgSSD/fHDHR/fHDHR/streammanager/stream/__init__.py:150} - DEBUG - Adding Chunk #11 to the buffer.
[2022-03-09 13:41:42,024] p1124821 {/mnt/ProgSSD/fHDHR/fHDHR/streammanager/stream/__init__.py:189} - DEBUG - Buffer has 3/3 chunks. Allowing buffer reduction due to buffer at capacity. Serving 1 chunk(s).
[2022-03-09 13:41:42,025] p1124821 {/mnt/ProgSSD/fHDHR/fHDHR/streammanager/stream/__init__.py:197} - DEBUG - Serving Chunk #9: size 5449
[2022-03-09 13:41:42,026] p1124821 {/mnt/ProgSSD/fHDHR/fHDHR/streammanager/stream/__init__.py:202} - DEBUG - Removing chunk #9 from the buffer.
[2022-03-09 13:41:42,027] p1124821 {/mnt/ProgSSD/fHDHR/fHDHR/streammanager/stream/__init__.py:150} - DEBUG - Adding Chunk #12 to the buffer.
[2022-03-09 13:41:42,027] p1124821 {/mnt/ProgSSD/fHDHR/fHDHR/streammanager/stream/__init__.py:189} - DEBUG - Buffer has 3/3 chunks. Allowing buffer reduction due to buffer at capacity. Serving 1 chunk(s).
[2022-03-09 13:41:38,105] p1124821 {/mnt/ProgSSD/fHDHR/fHDHR/plugins/plugin_logger.py:27} - INFO - [ceton] Selected Ceton tuner#: 1
[2022-03-09 13:41:38,107] p1124821 {/mnt/ProgSSD/fHDHR/fHDHR/plugins/plugin_logger.py:27} - INFO - [ceton] Ceton tuner 1 to be started
[2022-03-09 13:41:38,283] p1124821 {/mnt/ProgSSD/fHDHR/fHDHR/plugins/plugin_logger.py:27} - INFO - [ceton] Preparing Ceton tuner 1 on port: 44285
[2022-03-09 13:41:38,971] p1124821 {/mnt/ProgSSD/fHDHR/fHDHR/plugins/plugin_logger.py:27} - INFO - [ceton] Initiate PCIe direct streaming, channel 593 from Ceton tuner#: 1
Thanks!
the "instance" variable in the ceton plugin is really the fhdhr tuner number. what you want is within the stream_args dict
Right, that makes sense ... but I just checked, that instance is not in stream_args ... so when setting up the tuner, not sure how to map the fHDHR tuner number to the one ceton selects. Or am I missing it?
Fhdhr doesn't manage that for the plugin, that's up to the plugin to do based on the information given
Agreed! But the stream close calls with an instance number, yet that value is never provided before => how to figure out the mapping then?
Thanks!
By adding that information to the stream args along with the url
Yes, definitely agreed! But I don't see that the fHDHR instance is sent until closing, i.e. the first time it seems to be used is in close_stream
... so no way to figure out that mapping (I think at least). If it were sent in the stream_args, or as a parameter to get_channel_stream
, then NP at all. But it seems like it's only used to close the stream - so I'm not seeing how to store the mapping.
/me shakes head,,, I feel like you're so close to the answer but not reading what I'm typing.....
def get_channel_stream(fhdhr_tuner_number, stream_args):
streamurl = "whatever"
ceton_tuner_number = whatever_number
stream_info = {
"url": streamurl,
"ceton_tuner_number": ceton_tuner_number
}
return stream_info
def prime_stream(self, fhdhr_tuner_number, stream_args):
ceton_tuner_number = stream_args["stream_info"]["ceton_tuner_number"]
self.startstop_ceton_tuner(ceton_tuner_number, 0)
return
def close_stream(self, fhdhr_tuner_number, stream_args:
ceton_tuner_number = stream_args["stream_info"]["ceton_tuner_number"]
self.startstop_ceton_tuner(ceton_tuner_number, 0)
return
it really doesn't matter if the fHDHR tuner number corresponds with the ceton tuner number
but that's a provided method for you to pick the ceton tuner during the initial instantiation of the stream
/me shakes head,,, I feel like you're so close to the answer but not reading what I'm typing.....
I think I am ... π€£. I'm not ignoring, just not quite getting it - sorry!
def get_channel_stream(fhdhr_tuner_number, stream_args):
Yes, this would work! But what is there is get_channel_stream(self, chandict, stream_args)
=> have no idea what the fhdhr_tuner_number
is. But, I think I see where the problem lies now, and it's not really this ... π
close_stream(self, fhdhr_tuner_number, stream_args:
Yep, and that would be fine as well! But, I think I see what got me (mislead). In ceton, it calls out, close_stream(self, instance, args)
... and args is light gray, as not used. I get the feeling it's actually stream_args
(not really "args" ... meaning something different), which I can make work then. Need to check of course, and can't right now (can't restart to debug). But will get back to you.
Thanks for keeping on pushing!
BTW, I do still see the other items noted above - like buffer_size
, and the file name in the log. Just so you know.
Thanks!
Yep, and that would be fine as well! But, I think I see what got me (mislead). In ceton, it calls out,
close_stream(self, instance, args)
... and args is light gray, as not used. I get the feeling it's actuallystream_args
(not really "args" ... meaning something different), which I can make work then. Need to check of course, and can't right now (can't restart to debug). But will get back to you.
Yep, that was it ... that naming (and grayed out) was what confused me. Sorry about that. I think I have this working now ... using stream_args
, and inside that, stream_info
. Let me just test a bit more to make sure, then will push a PR to ceton.
Thanks!
BTW, would it make sense to add the cetun tuner number to the (fHDHR) tuner screen (table)? Just thinking it may be helpful. If you agree, I can use a fixed name inside stream_info (instance?), so it's consistent then between origins.
Just let me know your thoughts.
Thanks!
I'm not putting plugin specific stuff in core. That's why they are plugins
NP, understand. Just thought that mapping may be handy.
Thanks!
OK, PR submitted, #33 - working here, tracks ceton itself.
Close this, or address the other items mentioned above (e.g. buffer_size, etc.)? Whatever you prefer.
Thanks!
And one more quick question, as I'm trying to make use of the output from this API (api/tuners?method=status). Lots of good info in there, but the stream_info is not shown? Any chance it could be?
Thanks!!
I'm trying to decide on moving tuners under origins like I did channels
NP, gotcha - whatever you thinks makes sense. In parallel, I'm looking at adding the stream_info inside the ceton API, another option that may work. I admit - struggling with it a bit, it's not liking me adding a dictionary (or list) inside a dictionary inside ceton (i.e. config.dict["ceton"]["tunerstatus"][]
).
Thanks!
Actually, it's almost like I can't write to config.dict
outside of __init__
. Still digging why, but would that make sense to you?
Thanks!
Because plugins intentionally have a nerfed wrapper around logging, db, config
Also the config dict is not the place to put tuner status
I'm open to suggestions, no issue at all! Just need it to be accessible in the API π.
Thanks!
In __init__
put self.tunerstatus ={}
Will do! Wasn't thinking that would be accessible in the API. Thanks!
Then in your api, use self.plugin_utils.origin_obj.tunerstatus
OK, a bit perplexed here - was sure this was working the other day, but now I'm getting a bit of an odd error. If I set up
direct
with Ceton, the first tuner is fine. For example, tuning to Ch. 593, log info below. And ... tuner status in API is fine / correct. Ceton in the UI not showing quite right, but it wasn't before => longer story there π€£. Perhaps this is being used now, but I'm not sure. In any case, this all looks very normal to me, and working well.But then, with the above running, I try to add a client, to use Ch. 570. All heck breaks loose ... LOL. Log info below.
OK, looking at this a bit more closely => fHDHR is selecting Tuner 1, but Ceton is saying Tuner 0. Hmmm ... and then
direct_hardware_stream
goes with the Ceton (plugin) selection - is that right? Did it used to do that? If it were to use the info from the (fHDHR) API, then the selection would all be correct. I may have this wrong, by all means comment. And - did this logic change recently?Thanks!