Yes, that's an interesting idea. I'd just be concerned about how safe Win 7 is, with all of the exploits found over the years. One to think about if the OS update is the issue, I've done the driver updates and so far so good.
-
The forum software that supports hummy.tv has been upgraded to XenForo 2.3!
Please bear with us as we continue to tweak things, and feel free to post any questions, issues or suggestions in the upgrade thread.
HDR-FOX T2 to HDHomeRun, my journey
- Thread starter lc200
- Start date
Yes, that's an interesting idea. I'd just be concerned about how safe Win 7 is, with all of the exploits found over the years. One to think about if the OS update is the issue, I've done the driver updates and so far so good.
Black Hole
May contain traces of nut
First of all any exploit has to make it past your router. There's no reason for Win7 to be particularly unsafe unless you open the door. I'm still running it.
Hi, good to hear you've finally made some progress. Sounds like it is something related to the windows network stack or windows drivers for the network card that has been updated at some point then. It's an evil thing auto updates, so if you can use an older Windows version that doesn't get updates that would stop shifting sands. Also might be worth taking some screen shots of the network adapter settings and then comparing them when it does get updated to see if some settings have changed that you can simply revert back.
bottletop
Active Member
Why not try to limit the automatic updates?
I've not tried it myself, but I like the idea of marking a connection as metered to reduce the auto updates. https://www.tenforums.com/tutorials...e-automatic-updates-windows-10-a.html#option5
There are other suggestions, but I think option 5 is fairly safe as you'll be able to manually install updates and probably see the effects.
prpr
Well-Known Member
No "back".
I've continued to have perfect recordings until last night, when I had my first failure. In checking, Windows update had indeed done its thing on 22nd August with 2 updates - 1 was '
2024-08 Cumulative Update for .NET Framework 3.5 and 4.8.1 for Windows 11, version 22H2 for x64 (KB5042099)' and the other was a large feature update 'Windows 11, version 23H2'. So one of those 2 broke things again. I've attached the logs, it shows the 21st all clear, 22nd with 2 corrupt packets and then 23rd with many many corrupt packet, numbering in the thousands. I did try to put off windows updates as long as it allowed (although I'd not known about the metering trick from above).
I've got to put my OS install back to its previous install and set everything back up again. Whilst I'd like to experiement and try to work out which update caused it, the Paralympics are starting this week and I really dont want to miss out on recording any episodes so Im to just get things working again, put it in metered mode and once the Paralympics are over, I'll try to narrow down the cause more, including taking photos of the network settings.
Thank you bottletop, I will try that.
The .NET frameworks will not be causing any issues as I'm always on the most up to date with my install.
What would have been an idea was to check your network drivers and network adapter settings (from Device Manager) on the working version, then see what they had changed to on the new version. Has the network adapter driver been updated? Have some of the properties changed, for example energy saving settings turned on when they were off before. It would also be worth monitoring the network when the computer should be idle to see if its busy moving a lot of traffic, is it trying to share the update to other computers on your network or the whole world. Also after updates Windows can take hours or days sometimes in optimising new code. What is the CPU showing for usage? Is something stuck taking up a lot of resources on the CPU?
What would have been an idea was to check your network drivers and network adapter settings (from Device Manager) on the working version, then see what they had changed to on the new version. Has the network adapter driver been updated? Have some of the properties changed, for example energy saving settings turned on when they were off before. It would also be worth monitoring the network when the computer should be idle to see if its busy moving a lot of traffic, is it trying to share the update to other computers on your network or the whole world. Also after updates Windows can take hours or days sometimes in optimising new code. What is the CPU showing for usage? Is something stuck taking up a lot of resources on the CPU?
Thanks lc200, good to know it wasn't the .NET framework updates.
I won't be reverting everything back until this evening so I'll make sure to take photos of both network adapter settings, then do the revert, and then compare.
I've been monitoring the PC for 30 mins and there's no traffic being moved, no updates shared (I always have that off), CPU load is 8-12%, ram is below 50%.
Black Hole
May contain traces of nut
Can you do something in the network settings so that the PC in question has access to the local network but can't get onto the Internet? Gateway address seems like a possibility, but you would have to make sure it can't get the correct values by DHCP.
Nice idea, but I connect to DvrOnTime remotely a lot, especially on holiday, to log in and set up new recordings so its something I don't want to lose ideally.
I've restored the PC back before the Windows update, restored DvrOnTime, and now its a waiting game to see if corrupt packets have gone again, which I'm sure they will have.
I also took about 50 screenshots before I restored my OS, of the network adapter settings and drivers and then I've been through them again after the restore, and not a single setting was different in either.
I've also put off Windows Update for 5 weeks, and the only 2 updates pending are the same 2 that installed 2 days ago.
I tried setting the connection to metered, but it made no difference, Windows updates continued to be downloaded until I set them to paused. So I've got a few weeks now to try to find a way to stop Windows updating itself, I know there were a few other suggestions in bottletops link to try and, if I have to, I'll just pull the network cable
edit: I tried an alternative from bottletops list 'StopUpdates10' and hopefully I'm sorted until 2035......
Last edited:
MymsMan
Ad detector
Could this useful information be included in the pdf instructions and a link to the download page be added to post 1 of this thread. please.@mike, welcome on board. I should be on commission with SilicondustThe frequency to use for the guide data should default to one of the HD Muxes, but the option is available to change to a different frequency, for example if you are on the margins of reception and can't get the HD muxes too well you might want to go for a different frequency. All muxes carry the same guide data. Enjoy.
@Black Cloud @tonylon
I've been playing about with the network share, and have been successfully able to get it working for me, so hopefully this will help.
So give this a try:
* you could use any existing user of course, but maybe best to set a new one with a password not to expire.
- Stop the DvrOnTime service
- Change the permissions for the database to allow users to access it. Go to C:\Program Files\DvrOnTime, right click DvrOnTime.mdf and click Properties, then Security, then Edit… give the Users group Full Control, OK to save and repeat for DvrOnTime_log.ldf
- Now set up a new user* in Windows (e.g. a user called DvrOnTime), set a password, make sure the password is set not to expire and also not to need changing at log-in, add the Administrators and User groups to the new user Members Of.
- Now log in as this new User, navigate to the shared drive, i.e. \\NasBox\DvrOnTime, if a password is required, enter a password and make sure to tick the Remember option. This new user should now be able to access the shared folder, if they can't, then this problem needs to be fixed first.
- Log back in as your normal Administrator user, find the DvrOnTime service, right click it and go to the Log On tab, set to Log on as: This account and enter the new DvrOnTime user name and password, click OK.
- Start the DvrOnTime service, it should start normally but now using this special user. In the DvrOnTime settings, set the shared drive and click Save, this should hopefully succeed and the text file is written to confirm read and write access. Test a recording out.
Let me know how your get on.
Also suggest disabling Sleep on PC and changing to restart service on failure setting in Window Service properties.
Due to the demise of the PC previously used I needed to reinstall on a different PC and it was quite difficult to find all the relevant information in such a long thread and I knew roughly what I was looking for
a ptoential new user would not know where to look.
Black Hole
May contain traces of nut
Perhaps this deserves a sub-forum of its own. I mean, this is hardly a DIY PVR!
Ian Manning
Member
Bit of a strange problem...I've just migrated my virtual environments from ESXi to Proxmox. I've created a Windows 10 VM and installed DVROntime, just as I did on ESXi (where DVROntime was running fine). While it installed without any issues, whenever I try to tune channels the DVROntime service crashes and no channels are stored. I've tried tuning just one channel at a time and it doesn't help. The HDHomeRun app seems to run fine on the VM, so there is no problem with basic connectivity to the HDHomeRun.
The new Proxmox host is using the same ethernet connection as the old ESXi machine (and is in the same physical location). If I install DVROntime on a "real" Windows 10 PC on the same LAN it has no trouble tuning the channels.
Any idea why DVROntime might struggle to access the tuner when it's running on Proxmox vs ESXI??? I've attached the log, in case it's of any use.
The new Proxmox host is using the same ethernet connection as the old ESXi machine (and is in the same physical location). If I install DVROntime on a "real" Windows 10 PC on the same LAN it has no trouble tuning the channels.
Any idea why DVROntime might struggle to access the tuner when it's running on Proxmox vs ESXI??? I've attached the log, in case it's of any use.
The logs show the HDHomeRun is found okay and an attempt is made to connect to it and request a video stream, however it is reporting back an error saying No Video Data. So the HDHomeRun is found and is responding, but refusing to return a data stream. Have you tried rebooting the HDHomeRun (just off and on again)? The Silicondust app may be using a different connection method that is working okay, but the tuner streaming interface over HTTP has a problem which might be fixed by a reboot.
Ian Manning
Member
I've just tried turning the HDHomeRun off then on again. It slightly improved things - I can now get tune channels from 2 of the 6 available multiplexes. If I try to add any of the other 4 the DVROntime service crashes.
I wonder if the TTLs (Time to live) on the connection is causing a problem? The HDHomeRun has very short time to live settings, the idea is to prevent the devices streaming outside of a local area network. If you have the software running in a VM you might be just borderline on the TTL, so it's not reliable. I think you said you had changed the VM software so maybe the software you are using now is just a bit slower in forwarding packets between the virtual machine and the physical network card?
Ian Manning
Member
Hmmm...that's sounds interesting, and would certainly explain the problem. If it's true then I guess there is no obvious solution if I continue with Proxmox :0(