Closed arrmo closed 2 years ago
It's almost like I thought methods for these thing would be useful
It's almost like I thought methods for these thing would be useful
Very cool, makes 100% sense. Nice and clean too - origin object. I like it!
I'm glad you got this working. Since I only was using a single 'client; to access the plugin, I never got it out of sync.
And if you want to present the relationship between Ceton tuner and fHDHR tuner, you could add that to the Ceton status page.
And if you want to present the relationship between Ceton tuner and fHDHR tuner, you could add that to the Ceton status page.
Yep, makes sense - but inside Ceton, we don't know the fhdhr instance ... agreed? At least I don't think we do 😆.
Closing this one - yell if you disagreed! But addressed I believe, #33. Will follow the other issues (vars not being used) in the Testing Talk thread.
Thanks!
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!