Can you send me the output from http://192.168.1.98/lineup.json, and what you get back from:
Code: Select all
hdhomerun_config XXXXXXXX get /tunerX/streaminfoPM sentdjp952 wrote: ↑Wed Mar 09, 2022 9:26 pm Hi wazer, I PMed you a link to a test build that I think solves both of your confirmed bugs, I would appreciate it if you can let me know if that's the case. Using the data you provided me, slightly altered so it would match one of my channels, here is what I see now for the UTF-8 channel name concern (only "Tuner 0" is relevant, ignore "Tuner 1" since I didn't change all the program numbers).
I'm sorry I have no insight as to your problem with the Windows language bar. Nothing I do seems to cause that. I'm also still trying to decide about your requested enhancements to actually control the tuners ...
) Anyone is totally free to do whatever they want to this thing and make it their own!Family and Friends owns loads of hdhomerun including my self 3 units, sometimes tuners are locking and not responding, sometimes after a internet loss from the internet provider or dns issues will occur the hdhomeruns to be another a another ip sub like this example taking from the log.djp952 wrote: ↑Thu Mar 10, 2022 9:33 pm I'm still struggling to justify adding things that would modify the device state (unlock, reboot). Technically, of course both requests are possible. Some thoughts:
Neither of these operations are available in HDHomeRun Config GUI, nor from the device webpage (at least not for any of my tuners). You can mess with the tuners a bit in HDHomeRun Config though, admittedly. For what I think are probably the lionshare of people out there these would be dangerous operations to allow, even if made optional to allow. I think most people are going to be using a front-end to the tuners, be it the HDHomeRun app, Kodi, Plex, etc. as well as a DVR/recording solution. Unlocking a tuner manually or rebooting it from an application that doesn't have any insight as to what the tuner stream(s) are being used for feels a bit on the reckless side. In the case of HDHomeRun DVR, the application *could* have insight into it since it somewhat knows what's going on, but HDHomeRun DVR doesn't expose what tuners it's actually using. It is true that one could compare the stream target IP with that of the HDHomeRun DVR and perhaps disallow, but again this is just one of a plethora of possible DVR systems that use HDHomeRun tuners. Once a tuner is unlocked, it's eligible for use by another application/purpose whether the current stream was needed or not. I think that's kind of a bad thing?
I did consider the UI implications and suggestions, however. What I was thinking would be a "lock" glyph adjacent to the target IP address that indicates it's locked, clicking that would unlock it and remove the glyph (NOTE: the glyph font I need to use on Windows 7 doesn't have an "unlock" glyph, just a "lock" one, so ... this). For reboot, have either a "power" glyph or the circular arrow type "refresh" glyph in the footer all the way to the right that would do it. An alternate option I thought of would be adding just a "wrench" glyph in the device footer all the way to the right that would bring up a context menu or something that would provide ways to unlock/reboot/channel scan/etc.
There is also the slippery slope factor to consider. If an application allows SOME device state modifying operations, will it eventually need to support ALL device state modifying operations, like the aforementioned channel scan? Now we're into HDHomeRun Setup turf, especially for legacy tuner devices, and I personally think that's a bridge too far.
I'm still not saying no, and I would like to know what everyone thinks about this. Such things are not hard to do, but still feel very out of place here to me. Maybe I just don't understand why anyone in 2022 is still manually unlocking and rebooting their HDHomeRun tuners? Are there issues with the modern tuners without LEDs that should be brought up to SiliconDust as opposed to having an application that can ease the pain? It's an honest question.
And hey, it's open source with a very permissive "do what you want with it" license (that's how I roll
Hey, the most odd thing is they are all assigned to static ip, and I do not run other subnets at all, so yeah its weird, its not only at me that has this problem, maybe its an issue with the dvb-c eu versions...djp952 wrote: ↑Fri Mar 11, 2022 7:10 pm I feel ya.
Out of curiosity, can't you assign a static DHCP lease to the tuners' MAC addresses, ensuring they always get the same IP address and no other device on the network will? That's how I do it, anyway, and always have. I like having predicable, known, IP addresses for network appliances. The second problem feels more like something SiliconDust should be looking into, you're probably not the only person that has this problem (but if you are maybe it's the router)?
I also use Ubiquiti, love that thing, it's been configure and ignore for YEARS now. I even have a completely separate HIPAA compliant subnet for my wife's work set up with it. I have the EdgeMax Lite, FWIW. You can definitely assign a static DHCP lease, I'd look into that? One thing I never did was bump to the new new new firmware, I stuck with the older baseline. As I understand it, you can't go backwards, but hey maybe the answers to both your concerns lie with the router?
I'll tell ya what, I'll make sure to keep the GitHub Issue open and I'll add a comment along the lines of "if we do this, it will be a secret option that you'd need to go into the .config file and turn on manually". It would be documented, of course, but not accessible from the UI. Sound reasonable?
Nah I already checked with various code and tools including the classic arp -a
Thank you, been tested over the weekend and seems really greatdjp952 wrote: ↑Sat Mar 19, 2022 8:02 pm Yea! Version 1.0.0 is out there! No more vaporware! Still vapordocumentation, and I have to go out of town for a few days so no progress will be made there, but it really seems solid enough to call it "done" until more people see it and complain about it - LOL.
Version 1.0.0.8113
Release Notes: https://github.com/djp952/hdhomeruntray/discussions/63
Downloads: https://github.com/djp952/hdhomeruntray ... /tag/1.0.0
It doesn't have everything everyone wanted, and I'm certain there are many bugs to squash, but as I stated before I despise the "perennial beta" aspect of modern software development.
Have at it, gang. I hope it serves you well and meets your needs. Once the documentation is at least 'respectable', I'll start a new thread about it.
Let me have it when it breaks or just plain sucks by opening a GitHub Issue as opposed to posting here? Please? https://github.com/djp952/hdhomeruntray/issues
Thank you for testing it, sir. I sincerely don't think there is much I can do about that without a ground-up set of changes, what you're experiencing is the high "refresh rate" of the tuner status when the UI is active
This is a semi-Catch-22; if you are using the default UDP broadcast discovery mechanism, the network operations need to time out and fail to complete before the UI can become responsive again. If you're using HTTP discovery, the information is cached by the backend and is essentially "doomed" to also time out and fail.
