Sorry to hear you've had a few issues. The EPG update is halted if the tuner is required so it should work all okay even if the EPG is being updated and that tuner is then needed. I will take a look at the logs and see if I can discover anything. There should be a watchdog timer that will restart a recording if it halts before it should, so I will see if I can work out why that isn't happening. It doesn't stop a broken recording, but it should restart again as a separate file so you shouldn't miss more than 10 or 20 seconds.
-
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
Sorry to hear you've had a few issues. The EPG update is halted if the tuner is required so it should work all okay even if the EPG is being updated and that tuner is then needed. I will take a look at the logs and see if I can discover anything. There should be a watchdog timer that will restart a recording if it halts before it should, so I will see if I can work out why that isn't happening. It doesn't stop a broken recording, but it should restart again as a separate file so you shouldn't miss more than 10 or 20 seconds.
Corrupt packet in this case is reported if the CRC (Cyclic redundancy check) fails on any packet, this could have happened in the tuner from some reception problem or introduced across the network, unfortunately the software can't know where it happened, just that it has happened. A constant stream of CRC failures typically indicates synchronisation has been lost, so the software doesn't know where a packet starts and ends anymore, so to get back to normal operation the software will stop the recording and then restart it by closing the tuner and restarting the stream again. Corrupt packets I seldom if ever see on my home setup.
I will have a look at the logs and see if there is something I can handle better in the software.
I did something sensible/silly last night, depending on your perspective. More programmes had failed to record, in fact the fail ratio for this week is above 50%. So this is what I did in order:
1. Added impedence to the coaxial, this reduced the signal strengh from 100%+ to between 80% and 92%, depending on the mux. That made no difference to failed recordings.
2. Retuned all the channels within DvrOnTime - this is where it went strange - some of the muxes returned 0 channels! When I retried, different muxes failed. I either got 4 of 6 to find channels or 1 of 6, but never the same combination of muxes. So I was left with many channels missing.
3. Retuned all the channels within HDHomeRun - it found them all first time, so I browsed through, watching and checking as many as possible and all seemed fine.
4. Rebooted the PC and HDHomeRun and retested tuning in DvrOnTime, but it still failed to find all the channels.
5. Stopped the DvrOnTimeService, backed up the whole of the folder including the database, and then uninstalled both DvrOnTime and SQL Lite.
6. Rebooted, and then reinstalled DvrOnTime like it was new software with a fresh database, following the instructions and making sure I'm on 1.0.7, like before.
7. Scanned for channels in DvrOnTime and it found all 6 muxes and all channels first time.
8. Finally I added in some of the recordings I'd planned for today to see how it copes now. I'll report back if I get any failures.
I did the above to try to narrow down what the causes could be, I was most concerned at my HDHomeRun being broken and would need RMAing.
So from the above I think the fault could be in my PC (Windows updates, etc), or, the installation of DvrOnTime or the running of DvrOnTime via the existing database. I'm not sure what outside of those 3 it could be now.
Regarding the database, it had grown to around 80mb. It might have been corrupt ? or too large ? I don't know, but I'll report back once I've left the device to record for a couple of days because its been 3 days now since I've not seen a failed recording.
1. Added impedence to the coaxial, this reduced the signal strengh from 100%+ to between 80% and 92%, depending on the mux. That made no difference to failed recordings.
2. Retuned all the channels within DvrOnTime - this is where it went strange - some of the muxes returned 0 channels! When I retried, different muxes failed. I either got 4 of 6 to find channels or 1 of 6, but never the same combination of muxes. So I was left with many channels missing.
3. Retuned all the channels within HDHomeRun - it found them all first time, so I browsed through, watching and checking as many as possible and all seemed fine.
4. Rebooted the PC and HDHomeRun and retested tuning in DvrOnTime, but it still failed to find all the channels.
5. Stopped the DvrOnTimeService, backed up the whole of the folder including the database, and then uninstalled both DvrOnTime and SQL Lite.
6. Rebooted, and then reinstalled DvrOnTime like it was new software with a fresh database, following the instructions and making sure I'm on 1.0.7, like before.
7. Scanned for channels in DvrOnTime and it found all 6 muxes and all channels first time.
8. Finally I added in some of the recordings I'd planned for today to see how it copes now. I'll report back if I get any failures.
I did the above to try to narrow down what the causes could be, I was most concerned at my HDHomeRun being broken and would need RMAing.
So from the above I think the fault could be in my PC (Windows updates, etc), or, the installation of DvrOnTime or the running of DvrOnTime via the existing database. I'm not sure what outside of those 3 it could be now.
Regarding the database, it had grown to around 80mb. It might have been corrupt ? or too large ? I don't know, but I'll report back once I've left the device to record for a couple of days because its been 3 days now since I've not seen a failed recording.
Thanks for the update. Is the PC connected to a wired network? It sounds to me like a network problem. When you ask the HD Tuner to tune itself, it does that without any data travelling over the network, when DvrOnTime needs to tune in, it does that by asking for data from the HDHomeRun box to the PC. With most network traffic there is an element of correction for corrupt packets, so you may not notice an issue with most things, but the HDHomeRun being real-time doesn't have any ability to resend data, so if it is corrupted, its lost. For the tuning of channels no data can be lost, it all has to be received 100% okay, if corrupt packets arrive, it has to start again collecting a table of data, one corrupt packet puts it back to the start, and eventually if it can't receive a whole table of data without error it times out trying to 'tune that channel'. It can also be other things on the PC that have messed with network settings or corrupted the network stack some how. It might be helpful to reset the Windows network stack. Windows 10/11 typing "network reset" on the start menu should find the setting.
The database size is perfectly fine, most of it will be empty space from where the EPG has had old entries cleared out, and a maintenance task runs every now and again to remove the empty space.
The log of the tuning issues may be helpful, is it reporting corrupt packets?
I did check a few days of my own logs and I've never seen a corrupt packet logged, they are that infrequent.
Let us know how you get on.
The database size is perfectly fine, most of it will be empty space from where the EPG has had old entries cleared out, and a maintenance task runs every now and again to remove the empty space.
The log of the tuning issues may be helpful, is it reporting corrupt packets?
I did check a few days of my own logs and I've never seen a corrupt packet logged, they are that infrequent.
Let us know how you get on.
Yes, it both the PC and HDHomeRun are wired to the same network switch. The mini PC's dedicated job is to record TV through DvrOnTime, I don't install other software on it. I'll do the reset of the network stack, just in case.
Sadly there is no log of the tuning issues, as soon as that started to happen I uninstalled everything and reinstalled from scratch. I do however still have the original ldf file archived, I assume the logs will be in that file but I'm reluctant to reinstate any of the old install, yet. I'm losing too many programmes currently to justify going backwards.
Thanks for your help and pointers. I'm at a loss when it worked so well for the last 7 months.
Sadly there is no log of the tuning issues, as soon as that started to happen I uninstalled everything and reinstalled from scratch. I do however still have the original ldf file archived, I assume the logs will be in that file but I'm reluctant to reinstate any of the old install, yet. I'm losing too many programmes currently to justify going backwards.
Thanks for your help and pointers. I'm at a loss when it worked so well for the last 7 months.
I would not try to restore any of the database files, the ldf file isn't the same as the log file, so very much keep it as it is. There is no mechanism in the code or anything in the database that I can reason that would cause corrupt packets to be logged, meaning it would be fixed by reinstalling and using a clean database. So whilst it seems like a fix, my thoughts are the problems will return. If it does remain fixed for a while, I would suggest maybe a memory problem? The act of uninstalling and reinstalling and smaller databases can mean the memory is mapped differently and the network buffers used are now allocated a different place in memory free from errors, but could end up finding themselves back where they were before and it runs over a some faulty memory. Perhaps try running a windows memory test for a while just to check.
Thanks lc200 - network stack reset and a full windows memory diagnostic with 2 passes and no fails. I've also moved to a different network switch. I've got a couple more things to try if things fail again - replace network cables and run DvrOnTime from a completely different PC. I'll feedback once I have more info but its going to be a few days before any changes are tried, I want to see how the latest changes have affected anything.
More failed recordings today, 2/5 failed. I replaced all of the network cables yesterday, ready for today's recordings but it made no difference. I've also installed the software on a completely different PC as well, to take that out of the equation. And bad news, it can't get as far as tuning the channels, good news is I've kept the log and its attached, more corrupt packets.
I'm at a complete loss now, there's no pattern. The corrupt packets come and a recording fails, but its on different channels and muxes, where recordings work later. I can't RMA the HDHomeRun because I can't prove its not working, but I'm seriously considering purchasing the HDHomeRun DVR software, just to prove its the hardware that's the problem. Other than that, I'm so frustrated. I had 5 months of the perfect DVR - thank you lc200 - but something's gone wrong, I don't consider myself stupid or incapable of working through the problems, but I simply cannot find what is causing the corrupt packets
I'm at a complete loss now, there's no pattern. The corrupt packets come and a recording fails, but its on different channels and muxes, where recordings work later. I can't RMA the HDHomeRun because I can't prove its not working, but I'm seriously considering purchasing the HDHomeRun DVR software, just to prove its the hardware that's the problem. Other than that, I'm so frustrated. I had 5 months of the perfect DVR - thank you lc200 - but something's gone wrong, I don't consider myself stupid or incapable of working through the problems, but I simply cannot find what is causing the corrupt packets
I would recommend the HDHomeRun DVR software, and am well into my second year of using it.
bottletop
Active Member
Maybe try isolating it. Minimise the systems and connections.
Eg the recording pc directly connected to HDHomerun if possible, or with only a switch and nothing else. See how it copes without other network traffic or devices. How it behaves may give you ideas for what to check next.
Last edited:
Thanks bottletop, that's an excellent idea, The mini PC has 2 network connections and I've wired the HDHomeRun directly to it and DvrOnTime finds it! A test recording of 10 minutes worked as well. So I'll set up a few throwaway recordings to see how it copes over the next few days, and if it helps.
I would recommend the software, yes I've had a couple of problems, but almost immediately they have been sorted out and it's free.
It's like anything else, if it's working, you just forget it's there
After connecting the HDHomeRun directly to my PC, I've run DvrOnTime for 2 days, recording over 60 programmes over many different channels. All worked well until 14.10 today when failures began, in the end I had 6 failures. Corrupt packets once again. I've attached the log file (its pretty big so I zipped it up). I also checked CPU, ram and network usage and I never saw DvrOnTime use more than 5% cpu, 200mb ram and 8mb of network - all well within the capabilities of the resources.
@lc200 is it possible to log more details for a corrupt packet ? maybe identifying why its corrupt, i.e. is it really unreadable, or is it offset from the expected position ? I'd be more than happy to test out a version of your amazing software to try to identify the cause. I don't think there's much more I can do this end without more information why it's failing.
@lc200 is it possible to log more details for a corrupt packet ? maybe identifying why its corrupt, i.e. is it really unreadable, or is it offset from the expected position ? I'd be more than happy to test out a version of your amazing software to try to identify the cause. I don't think there's much more I can do this end without more information why it's failing.
An interesting development: I started to install Channels DVR to shadow DvrOnTime, to see if it has the same issues - and the very first thing that it came up was a warning that my network adaptor has 'flow control' enabled and that could affect capturing, would I like it disabled? yes please! So that's a setting I'd never heard of or knew about, will be interesting to see if that is my problem.
Black Hole
May contain traces of nut
IIRC "flow control" stops incoming data overflowing the input buffer (rather than just throttling it willy-nilly). With real-time data, interrupting it will cause problems, but overflowing the buffer will also cause problems.
That flow control flag didn't help either.
So, I did something drastic - I restored my windows from a backup I'd taken with Paragon Hard Disk Manager soon after setting up DvrOnTime in January. And so far 2.5 days later, the words "Corrupt packet" have not appeared in any logs! So I've had good recordings once again, no failures.
I've deliberately put off any Windows updates for a week, and once they are installed I'll report back if it fails again or if rolling my OS back has sorted things.
So, I did something drastic - I restored my windows from a backup I'd taken with Paragon Hard Disk Manager soon after setting up DvrOnTime in January. And so far 2.5 days later, the words "Corrupt packet" have not appeared in any logs! So I've had good recordings once again, no failures.
I've deliberately put off any Windows updates for a week, and once they are installed I'll report back if it fails again or if rolling my OS back has sorted things.
Last edited:
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.
Black Hole
May contain traces of nut
If you are using the mini PC specifically for PVR purposes, how about installing an old Windows which doesn't force updates, ie Win7?