• 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

All I know is that you need at least Windows 8 because the database doesn't work with anything less. Other than that, I don't think there is anything to stress your PC. The interface is a web page and the recorded data rate is really low in PC terms, even with HD. Simply put, the PC just gives the network tuner instructions and then waits for recording data to arrive from the network. At least, that's what I think happens.

PS. I have a Fitlet (a 12 volt PC that fits in a car's glove box) with vintage Win 8.1. It's old and slow and does the job without any trouble. No, it's not doing it from the car!
I think I'll put Windows 10 on it and see how/if it runs. Thanks.
 
I just received a stock availability email from SiliconDust
Code:
HDHomeRun models are back in stock for the United Kingdom

We are now accepting orders for HDHomeRun tuners. Models may sell out fast, so you will continue to get notified when the next batch is available to order, unless you unsubscribe.
 
After months of watching silly prices on eBay (still dual tuner for £200!) my orders in awaiting delivery . Now to dust off the DVRONTIME software and finally get started.
 
I see there is a thirty quid a year charge for "DVR Software Activation". I assume that if we're using the custom software we do not need this option?
 
A rare event last night a recording failure which then effected subsequent recordings on the same channel. It started with this:-

17/08/2022 19:35:39 Warning => Corrupt packet total 1 (logging of corrupt packets suspended for 1 minute)
17/08/2022 19:35:50 Error System.IndexOutOfRangeException: Index was outside the bounds of the array.
at TransportStream.Table.GetTableInPacket(Packet packet)
at TransportStream.Table.ProcessPacket(Packet packet)
at DvrOnTime.ProgramRecordByEit.Tuner_PacketReceived(Object sender, EventArgs e)
at HdHomeRun.TunerDevice.PacketExtract(Byte[] data)
at HdHomeRun.TunerDevice.TcpReceiver(Object data)

Which killed the recording at that point, however subsequent recordings on the same channel then failed because DVROnTime still thought:-

"The channel is currently being recorded, waiting for that recording to stop before starting this recording"

Eventually it then terminated the recording which started this:-

17/08/2022 22:59:23 Error ScheduledEventProgramId 6851: Terminating the recording as recording has passed maximum recording time

At which point it then started to listen and immediately terminate all the recordings from the earlier scheduled recordings that it had been waiting for.

@lc200 Any ideas what would cause the error and should it not have terminated the recording properly when it failed so at least any following ones could still stand a chance of being recorded? Both the recording PC and the 2 HDHomeRun's are hardwired to a switch. Other recordings from a different channel during this same time period recorded perfectly BTW.
 
"The channel is currently being recorded, waiting for that recording to stop before starting this recording"

This is another example where, when tuners are not in short supply, it would be worth allocating another tuner to the same channel. When padding is in use it would allow each programme to have have full start and end padding when recording back to back programmes
 
This is another example where, when tuners are not in short supply, it would be worth allocating another tuner to the same channel. When padding is in use it would allow each programme to have have full start and end padding when recording back to back programmes
Agreed. It does seem rather crazy that I ended up with 3 failed recordings when I had 6 free tuners sat idle...
 
Why is it necessary to allocate another tuner? All it has to do is sent the same stream to multiple record processes.
 
Why is it necessary to allocate another tuner? All it has to do is sent the same stream to multiple record processes.
Agree that it could be possible and also to record multiple channels on the same plex using a single tuner
My suggestion was intended as a hopefully simple to implement change within the existing dvrontime architecture which would improve its resilience as well as improving handling of padded recordings. There are are likely to continue to be a virtually unlimited supply of potential errors that have could cause a recording to fail that have yet to be identified and recovery implemented. So my idea is to simply remove the check for whether there is an existing recording on the channel and always schedule a new tuner for each recording.

I think changing the processing to handle multiple recordings from the same tuner would be a very much more complex change especially to make it sufficiently bullet proof.
 
So my idea is to simply remove the check for whether there is an existing recording on the channel and always schedule a new tuner for each recording.
Yes, though it might be nice to have a setup instruction to specify how many of the available tuners dvrontime can use (7 of 9, or 2 of 4) for those who want some tuners reserved for the kids to watch something on their tablets.

PS, but maybe HDHomeRun decides which tuners to use, not dvrontime?
 
Finally got a HDHOMERUN box brand new from Silicondust . My experience so far (in case its of any use to anyone else) and a couple of things I’m still struggling with.
It worked straight out off the box, by the time I had loaded the HDHOMERUN app I had Live TV on my laptop.
Next up DVRONTIME software, made sure I had the the pre requisites of
Net Core runtime 3.1.28 and dotnet-sdk-3.1.422
DVRONTIME service failed to start which I tracked down to the SQL service not starting which was down to needing Visual C++ 2015-2019 redistributable .
Service started ok and a few test recordings made.
Next downloaded the trial of ADBREAKER.UK and purely by chance gave it an episode of YOUNG SHELDON on 4EXTRA which it lost the last 5 or 6 mins of. Did a couple more tests (Inspector Morse etc) which were fine. Then another young Sheldon, which lost the end again. Mailed ADBREAKER about it. And got a reply that they knew about this and it was a general problem with American sitcoms with short scenes and they hoped to address it in the next version. (Young Sheldon was just the next program to start and record in the EPG)
All good so far now al that I have a problems with is getting DRVONTIME to save to anything other than a local drive on the PC its running on. Seems to be permission based but I can’t see where.
I’ve put a delayed start on the DRVONTIME service to try to give the SQL service time to start which doesn’t always work after a reboot.

DVRONTIME and ADBREAKER seem to be excellent pieces of software and are recommended.

I get an email most days from eBay that there are new HDHOMERUN’s for sale at silly prices £150 + presumably from people desperate to sell b4 everyone realises Silicon dust have them back in stock at normal prices.
 
This mornings DVRONTIME recording of paddington didnt happen
2/08/2022 08:25:28 Error Error in RecordWatchdog_Elapsed, error is: Stored Procedure [dbo].[up_ScheduledEventProgramSetStatus] reported an error from the database: Connection Timeout Expired. The timeout period elapsed while attempting to consume the pre-login handshake acknowledgement. This could be because the pre-login handshake failed or the server was unable to respond back in time. The duration spent while attempting to connect to this server was - [Pre-Login] initialization=24830; handshake=0;
22/08/2022 08:25:30 Error ScheduledEventProgramId 4225: Terminating the recording for The Adventures of Paddington as recording has passed maximum recording time
22/08/2022 08:25:30 Error Error in RecordWatchdog_Elapsed, error is: Stored Procedure [dbo].[up_ScheduledEventProgramSetStatus] reported an error from the database: Connection Timeout Expired. The timeout period elapsed while attempting to consume the pre-login handshake acknowledgement. This could be because the pre-login handshake failed or the server was unable to respond back in time. The duration spent while attempting to connect to this server was - [Pre-Login] initialization=24830; handshake=0;
22/08/2022 08:25:32 Error ScheduledEventProgramId 4225: Terminating the recording for The Adventures of Paddington as recording has passed maximum recording time
22/08/2022 08:25:35 Information Recording watchdog timer now stopped

subsequent recordings were ok.
 
Back
Top