I haven't done much with Windows 10, but I think you'll need to install some video codecs for playback to work with some content. I believe the LAV Filters are the current choice.

Make sure SageTV is set to use EVR on Windows 10 sometimes it defaults to Overlay.

Thank You for your help but honestly I am not sure where to begin as Sage worked well for a week and then I was back having these issues. I am not sure if it is tied to Win 10 but that doesn't make sense to me but it auto updates and I am not sure if that breaks something in the process. I may go back to Win 7 or 8 to see if it helps.

Once I get OpenDCT installed on the server that SageTV is running on, is there a simple way to test that OpenDCT is functioning properly before making the necessary configuration changes to the SageTV software? My server is pretty stable, and I want to be cautious in introducing change in my environment.

Sorry if this may have already been covered in one of the prior 1000+ posts...

Easiest way for me was to just create a system image before getting underway. You could use Win7's own backup system, or something free like;

http://www.aomeitech.com/aomei-backupper.html

(did I mention that the OpenDCT developer will stick with you until judgement day, helping you to get it running?)

You re not really changing anything in SageTV just 1 property line which can be easily changed back.

My setup currently consists of a dozen or so HD broadcast stations, and roughly 60 analog channels. After installation of OpenDCT, most of the analog channels will have an HD equivalent, and there are many more HD channels available that are not currently available in analog. My channel lineups are going to change pretty dramatically once I move to OpenDCT, but before I go thru all of that, I would like to make sure that OpenDCT itself is working properly.

Start with a clean lineup and only use it for SageDCT. Any changes to it will only be used by SageDCT.

OpenDCT 0.5.5-Beta
 

https://api.bintray.com/packages/ope...s/download.svg

• Re-worked how capture devices determine if the MediaServer will be used or not. This will allow for DynamicConsumerImpl to be more faithful to the individual consumer preference.
• Devices no longer need to be re-detected after standby. They are now re-loaded immediately and detection is only used to verify that the IP addresses have not changed.
• Fixed stopping executable not running as expected for Generic HTTP capture device.
• Added experimental eu-bcast and eu-cable support.
• Internal: Programs are now stored as integers.

OpenDCT 0.5.6-Beta
 

https://api.bintray.com/packages/ope...s/download.svg

This is really only one change, but I think it makes a very positive difference when channel surfing with the WMC tuning addin.

• Added configurable delay in milliseconds for the stop command to be executed for Generic HTTP capture devices. The new property is sagetv.device.<unique_id>.stopping_executable_delay_ms. If the value of this property is 0, the delay is disabled. The default value is 15000.

i've had that periodically over the years.
i have a cable amp right after the entry to the house (and before any splitters) and that has helped a lot

I noticed a potential problem this morning which my wife said has been happening for a while; While running 5.4 and watching TV live, when a show ends at the end of an hour, the next show on the same channel gets a lot of stutter and becomes unwatchable, so we have to tune to a different channel then tune back to fix it. I've attached a log file. Other than that everything has been running well.

Just about every address on a cable loop likely has multiple levels of attenuation in it, so there really is no justification for needing an amp in your home - at worst you might have to pay a service charge to have a tech come out and remove/adjust attenuators at the curb to have your after-split signal at an appropriate level at each tap in the home. You really should makes sure, however, that from home entry to each tap is approximately the same total dB drop.

Ready to move from SageDCT
 

I've been running SageDCT w/ a Prime and Sage 7.1.9 for a long time successfully. Lately more and more channels just won't tune within sage but tune fine using HDHomeRun apps on FireTVs just fine. It seems random...and pisses off the fam missing recordings.

So I'm considering moving to OpenDCT with Sage 7.1.9. Should I jump on the latest Beta 0.5.x on git or latest stable 0.4.x

What device is this happening on? Have you tried just skipping back once while it's stuttering?

I should probably note that if you use the Windows Client, this problem is an almost certainty when the video switches on MPEG-TS (MPEG-PS seems to work better, but you can't use that if you are getting H.264). In other words, if you use the Windows Client, you should just disable switching completely because it will only cause problems.

OpenDCT is cutting the video at a location that is actually designated as an ideal place to stop streaming to the current file and start a new one. FFmpeg is making the transition without issue according to your logs, there are no complications that I can see such as the buffer getting backed up. In fact you will notice that your recordings regularly use SWITCH to start a new recording and they probably have been ok.

Per what I have been told, as long as you can append the new file to the end of the old file and the file will still playback, then you're doing it right. I have done many many many tests on this and I have yet to create a split that when I combine the files causing any kind of abrupt anomaly where the split was made. I believe the real issue is that SageTV isn't dealing with the transition gracefully.

If you want to disable switching, do the following:
1. Stop the SageTV service.
2. Open Sage.properties
3. Change the value of fast_network_encoder_switch to false for all of the network encoders for OpenDCT.
4. Save.
5. Start the SageTV service.

It was happening on an HD300 -I did try skipping back, pausing and then playing, etc but the problem wouldn't go away. I'll keep an eye out for it and test again when I have a chance and if need be try what you've outlined. In the meantime, I have also upgraded to 5.6.

Also something that came to mind is maybe on your content, FFmpeg is reordering things in a strange way. Try setting consumer.ffmpeg.use_compat_timebase to true too. The HD300 shouldn't be having these issues, so I'm a little surprised about that.

I woke up this morning to a bunch of missed recordings. In looking into it a little bit, it looks like my HDHR Prime wasn't getting an IP address and therefore Sage couldn't connect to it.

I really have no idea why that would have happened, but i don't really think it's related to OpenDCT. However, I figure i'd just post my log and see if there is anything that points one way or another.

I'm also posting my DHCP log. Every 60 seconds starting last night there was a DHCPDISCOVER/ DHCPOFFER pair, but the Prime doesn't look like it actually get an address until 7:12AM.

At 7:12, the OpenDCT log also shows that the Prime got sync'd and finally started recording.

As I said, i have no idea what happened, and this may really be a HDHR issue (or other network issue), but i thought i'd start here and see if anything looks suspicious.

thanks
Matt

the relevant portions of the logs are pasted below

Matt, is your Prime firmware all up to date?

Yes, it's Firmware: 20150826, which is the latest that I see on their site. (not sure if there is a newer beta or not.)