Feature request?

Want to write your own code to work with a HDHomeRun or work with the HDHomeRun DVR? We are happy to help with concepts, APIs, best practices.
djp952
Posts: 1648
Joined: Wed Oct 01, 2008 8:46 pm
Device ID: 131EB7F7;131ED0E0
Location: Elkridge, MD USA
x 61

Re: Feature request?

Post by djp952 »

wazer wrote: Mon Mar 07, 2022 3:38 am Aaaand found another bug(or not using utf-8 charset?)

ÆØÅ Nordic letters in general show up like this

Image
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/streaminfo
when tuned to that channel?

I'll PM you an e-mail address you can use. The application is Unicode (UTF-16), need to see what it's seeing and make the necessary adjustments. It's very likely a naive conversion by C# that assumes ASCII as you believe it to be.

djp952
Posts: 1648
Joined: Wed Oct 01, 2008 8:46 pm
Device ID: 131EB7F7;131ED0E0
Location: Elkridge, MD USA
x 61

Re: Feature request?

Post by djp952 »

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).

Image

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 ...

wazer
Posts: 91
Joined: Tue May 01, 2018 11:10 am
x 1

Re: Feature request?

Post by wazer »

djp952 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).

Image

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 ...
PM sent :)

Great job and thanks one again :=)

djp952
Posts: 1648
Joined: Wed Oct 01, 2008 8:46 pm
Device ID: 131EB7F7;131ED0E0
Location: Elkridge, MD USA
x 61

Re: Feature request?

Post by djp952 »

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 :mrgreen:) Anyone is totally free to do whatever they want to this thing and make it their own!

JDazell
Posts: 195
Joined: Fri Sep 09, 2011 4:19 pm

Re: Feature request?

Post by JDazell »

I'm with you on this functionality is not needed.

If some task has a Tuner locked, then it would be more appropriate to determine what has it locked and then figure out how to prevent that from happening.

The App is great as is. Thanks again

wazer
Posts: 91
Joined: Tue May 01, 2018 11:10 am
x 1

Re: Feature request?

Post by wazer »

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 :mrgreen:) 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.

https://i.imgur.com/3sQy5eu.png

This is rare but still does happens without getting a refreshed IP from my network, in this example it actually got the correct ip back(as i said its really rare but still occurs), the only way to handle this is, would be to change my PC to another sub manually > reach the tuner and send in command to restart it OR by opening our rack and manually unplug the power..


Now to the other issue.. tuner not responding and stays locked with networkrate 0
https://i.imgur.com/ZnGMWZJ.png

This is where it locks and not responding, will continue to stay this way until I either restart or send unlock/release it. (I was actually the guy who asked for networkrate to be implemented in the status field so we could deal with such issues like this) I'm thankfully for nickk letting it in, because it has saved many issues on our part, just by knowing "oh networkrate is 0", just release it.

I spotted this issue by seeing some tuners being in use 12hours+ in the beginning and I could see on my ubiquity network that there was no network flow between the units

Shutting of the devices who asked for the streams does not help either so really restart unlock/release is the only method.

djp952
Posts: 1648
Joined: Wed Oct 01, 2008 8:46 pm
Device ID: 131EB7F7;131ED0E0
Location: Elkridge, MD USA
x 61

Re: Feature request?

Post by djp952 »

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?

wazer
Posts: 91
Joined: Tue May 01, 2018 11:10 am
x 1

Re: Feature request?

Post by wazer »

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?
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...
I got a edgerouter 12P, and as you say, setup and forget, I love this beast, but was also costly I ended up paying around 450€(500ish $)

For the secret thing I actually thought about asking if you would could do it like that, I love it! Sounds cool and you get to make a little easter egg if you do it :)

jasonl
Silicondust
Posts: 16107
Joined: Sun Oct 28, 2007 9:23 pm
x 41

Re: Feature request?

Post by jasonl »

The only way the HDHomeRun would get an IP address on a different subnet (other than the 169.254.*.* autoIP range) is if something assigned it an IP address on that subnet. You've got a rogue DHCP server on your network somewhere.

wazer
Posts: 91
Joined: Tue May 01, 2018 11:10 am
x 1

Re: Feature request?

Post by wazer »

jasonl wrote: Sat Mar 12, 2022 2:24 pm The only way the HDHomeRun would get an IP address on a different subnet (other than the 169.254.*.* autoIP range) is if something assigned it an IP address on that subnet. You've got a rogue DHCP server on your network somewhere.
Nah I already checked with various code and tools including the classic arp -a

djp952
Posts: 1648
Joined: Wed Oct 01, 2008 8:46 pm
Device ID: 131EB7F7;131ED0E0
Location: Elkridge, MD USA
x 61

Re: Feature request?

Post by djp952 »

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

wazer
Posts: 91
Joined: Tue May 01, 2018 11:10 am
x 1

Re: Feature request?

Post by wazer »

djp952 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, been tested over the weekend and seems really great :)

Only issue I can think of and is a minor? is that when you reboot or release a channel hdhomerunstatusmonitor hangs until job has been successful?

Anyways its a minor and not really an issue for me, keep up the good work, 10/10 :)

djp952
Posts: 1648
Joined: Wed Oct 01, 2008 8:46 pm
Device ID: 131EB7F7;131ED0E0
Location: Elkridge, MD USA
x 61

Re: Feature request?

Post by djp952 »

wazer wrote: Mon Mar 21, 2022 3:23 am Only issue I can think of and is a minor? is that when you reboot or release a channel hdhomerunstatusmonitor hangs until job has been successful?
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.

I also saw this but found it to be "reasonable" for a hidden/secret option. I mean, it doesn't crash, so that's good. It can definitely become unresponsive, but from the hardware I have available it wasn't very painful. I cannot speak to the time it takes the newer ATSC3/4K devices, though.

Based on this, I'd like to call "1.0.0" good but still incomplete. When I get back from Utah I'd like to spend time on documentation as opposed to any "burn-down" of the GitHub Issues list.

djp952
Posts: 1648
Joined: Wed Oct 01, 2008 8:46 pm
Device ID: 131EB7F7;131ED0E0
Location: Elkridge, MD USA
x 61

Re: Feature request?

Post by djp952 »

FYI for anyone watching the thread, there is a new version (1.1.0) out there:

Version 1.1.0.8237
Release Notes: https://github.com/djp952/hdhomeruntray/discussions/67
Downloads: https://github.com/djp952/hdhomeruntray ... /tag/1.1.0

I am lacking free time of late, so really the only impactful thing is that when the popup for an HDHomeRun RECORD device is on-screen, the amount of available storage space will dynamically update instead of being pegged to what it was at the time of the popup opening. Useful when available storage is in the GB (or gasp! get more space! MB range).

Didn't get to anything else of value, sorry.

wazer
Posts: 91
Joined: Tue May 01, 2018 11:10 am
x 1

Re: Feature request?

Post by wazer »

Tested and approved, works like a charm :)

Post Reply