HDR-FOX T2 to HDHomeRun, my journey

If you are using the mini PC specifically for PVR purposes, how about installing an old Windows which doesn't force updates, ie Win7?

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.
 
I'd just be concerned about how safe Win 7 is, with all of the exploits found over the years.
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.
 
2 weeks later and still going strong, no corrupt packets or failed recordings. I'm going to slowly introduce changes over the next few weeks to see if one triggers the issues again. The 3 main changes are: driver updates, OS updates and setting Windows memory integrity to on. Apart from the last one, I don't have a lot of choice in getting those updates at some point because Windows forces driver and OS updates on me over time.

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.
 
2 weeks later and still going strong, no corrupt packets or failed recordings. I'm going to slowly introduce changes over the next few weeks to see if one triggers the issues again. The 3 main changes are: driver updates, OS updates and setting Windows memory integrity to on. Apart from the last one, I don't have a lot of choice in getting those updates at some point because Windows forces driver and OS updates on me over time.
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.
 
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.

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.
 

Attachments

  • eventlog 21st.txt
    60.4 KB · Views: 0
  • eventlog 22nd.txt
    92.8 KB · Views: 0
  • eventlog 23rd.txt
    73.5 KB · Views: 0
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. <link removed>
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.

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

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......
Updates.png
 
Last edited:
@mike, welcome on board. I should be on commission with Silicondust :) The 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:
  • 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.
* you could use any existing user of course, but maybe best to set a new one with a password not to expire.

Let me know how your get on.
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.
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.
 
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.
 

Attachments

  • eventlog(2).txt
    3.4 KB · Views: 2
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 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.
 
you could try bypassing the tuning by copying the databases from a previuously working setup
but it would probably then start failing with a similar error when attempting to read the epg and/or recording stream
 
Back
Top