OpenDCT: An open source digital cable tuner.

[nyplayer]

Originally Posted by uberpixel

Okay. I'll give it a try. I do have several devices that interact in the DLNA realm. I'll eliminate that variable and see if it improves.

Thanks,
-uberpixel

Once you make that change do not forget to restart the OpenDCT service.

[troll5501]

Originally Posted by EnterNoEscape

Try turning upload id off. Stop the service, then change this property to false consumer.ffmpeg.upload_id_enabled=

I tried testing with upload_id set to false. The first time it failed to start streaming with an exception in the opendct.log, and when it does actually stream to the recording directory without any errors in the OpenDCT or SageTV logs I just get a blank screen with my HD200 extender and it does not play any part of the recording. FF'ing to the current timestamp often causes it to jump back to a previous timestamp on screen. However, the file size keeps increasing and the SageTV GET_FILE_SIZE log entries are showing increasing sizes, and I can play it directly using Windows Media Player although the first few seconds are blank/silent.

The good news is the CPU utilization is lower and I am not getting any ffmpeg errors/warnings like I did with upload_id=true, even with 3 simultaneous recordings.

[troll5501]

Originally Posted by spencerw

I've seen SageTV get into a tight loop talking to network encoders where it requests the recording file size via the GET_FILE_SIZE command over and over again sometimes many times per millisecond especially when SageDCT was used in "dump" capture mode.

Please look for hundreds of the above messages per second when the CPU usage spikes. If you don't see hundreds of them then please post your SageTV log for us to investigate further. If you do see hundreds of them then I'll dig deeper into the SageTV v9 code and if I spot a problem I'll request a fix via the SageTV Open Source forum. Thanks.

I enabled the network encoder debugging, started OpenDCT and SageTV and immediately encountered two issues, the latter is the high CPU issue from my post earlier this week. The logs are attached.

Issue #1: At 18:48:27 tuned to a channel to watch live TV, and it failed to stream any data. There is an exception in the opendct.log at 18:49:29. In the SageTV log, GET_FILE_SIZE showed 0 the entire time.

Issue #2: I started 3 simultaneous recordings, and at 18:57:51 I cancelled one of them. SageTV.exe immediately went to 100% CPU. At 19:03:53 I clicked the close button on the SageTV window on the server. After nearly 15 minutes I killed the process. You can see in the logs that it was not completely hung but something was causing the process to remain at 100% CPU until I killed it.

There was one time in which hundreds of the GET_FILE_SIZE log entries were generated within a few seconds--starting around 18:55:57 but this was several minutes before I cancelled the recording and only when the first recording was active and before the CPU spike.

Also notice in the opendct.log, as the load increases I get more of the "PES packet size mismatch" warnings--these correlate to hiccups/glitches/pixelation in the streams.

[Zalarian]

I have been trying to get sageDCT working on my windows 10 box V9 Sage TV to replace my current windows 7 V7 Sage TV machine and haven't had much luck so I thought I would try and use OpenDCT to see if I can get past the no signal issue.
Unfortunately, I am getting the following error message during install of 0.3.13:

Could not set file security for file 'C:\ProgramData\' Error: 0 Verify that you have sufficient priveleges to modify the security permissions for this file.

I have tried to run the msi using run as administrator but that didn't work at all. I also tried to create a folder called C:\ProgramData\OpenDCT in an attempt to guess what it needs with full permissions to the current user. Finally, I attempted to install with virus scanner and the firewall without any luck. Any other ideas?

[troll5501]

A follow-up to my last two posts:

The playback of recordings using upload_id=false is working now, there was some issue within the HD extender and after rebooting the extender the recordings play fine.

The issue of SageTV.exe going to 100% CPU when cancelling a recording does not occur when upload_id is disabled, and in general the Sage process (and the server overall) uses less CPU this way.

I re-enabled upload_id to do more testing, and again ran into the looping delete failures and eventually the 100% CPU issue after stopping one recording and immediately stopping another one. I have the Sage debug log if anyone is interested in looking at the delete failures.

[EnterNoEscape]

PES packet size mismatch errors are usually uncorrectable errors in the stream itself. High network traffic for whatever reason can increase this error in my experience. This has happened to me even with a dedicated NIC. The strangest part to me is that the RTP continuity is fine (UDP packets are not being missed), yet the stream quality gets very bad. Upload id was really able to draw these problems out especially in my development VM.

The upload id thing is interesting. There is a setting called consumer.ffmpeg.min_upload_id_transfer_size and a setting called consumer.ffmpeg.rw_buffer_size. Try bumping those values up to 32768 and see if it improves things at all. Also try dropping them to 10340 and see if it helps or likely makes it worse. When I first used upload_id it would cause really high CPU usage on SageTV.exe when my array was scrubbing. The aggressive network traffic was also somehow effecting the quality of the recording data too. I put in this setting to help smooth out the data transfer. Basically it sets a minimum amount of data to be buffered before allowing it to be transferred to SageTV. For most people the current setting should be ok; I would not change this unless you are actually having problems. Also min_upload_id_transfer_size must always be greater than or equal to rw_buffer_size. If it is not, OpenDCT will adjust it to be valid, but that of course means it may not have done what you intended.

In case anyone is wondering why they are separate settings, rw_buffer_size defines the largest chunk size that FFmpeg will read at one time from the circular buffer. It is also the largest size that will ever be returned in one transfer from FFmpeg to the filesystem/upload_id. As you might guess, if you increase this value too much, tuning times will start to get slower.

[EnterNoEscape]

I am currently looking for someone who is a heavy HDHomeRun Prime user that uses it outside of SageTV a lot to test out the virtual tuner feature in the next minor version of OpenDCT. This feature allows for OpenDCT based on merit and if the tuner is unlocked externally to automatically reassign tuners for SageTV. The feature is stable in my tests, but I don't use any of those features regularly. The feature is also disabled by default since not everyone will want this especially since it will get confusing on the SageTV side of things since the tuner SageTV used to perform the recording is probably not the actual tuner that did the recording. You won't need to be concerned about this feature if you don't want it when the next minor version comes out officially.

A usage case would be, say we have two tuners: Tuner0 and Tuner1. Tuner0 is currently locked by an outside application and Tuner1 is free, even though SageTV asked for Tuner0, Tuner1 will be used instead and SageTV will still think it's using Tuner0. If SageTV then requests Tuner1, since Tuner0 is all that's left, even if Tuner0 is still locked, OpenDCT will then force it to unlock and start the recording. As you can see, the tuners are now crossed, but this was the least disruptive approach since it didn't take the tuner you were using in another application until it had no choice.

OpenDCT will automatically assign tuners to pools based on device type so all capture devices with CableCARDs will be separated from devices without CableCARDs for example. You can also change the pool assignment per capture device if you want to further separate things. I highly do not recommend mixing devices that cannot all tune all of the same channels. This creates problems that I will likely not be addressing that I described in the issue for this feature on GitHub. If SageTV asks for any capture device within that pool, OpenDCT will select the best candidate based on merit and if the tuner is currently locked by another application with a last resort to force unlock if enabled per tuner. Capture devices are assigned on START and BUFFER and unassigned on STOP. The logs do clearly indicate the mapping when pooling is in use. The SageTV side is considered to be a virtual capture device since it represents any capture device from the corresponding pool and is not a direct mapping to a capture device. The OpenDCT side is considered to be a pool capture device and is the actual capture device that gets mapped to the virtual capture device. It gets confusing, but I couldn't think of a better way to separate them. Both sides use the same names. In the future there might be a feature to rename the capture device on the recording after it finishes recording to make it clear what capture device actually did the recording, but that will require some integration with SageTV likely via sagex.

[nyplayer]

Originally Posted by EnterNoEscape

I am currently looking for someone who is a heavy HDHomeRun Prime user that uses it outside of SageTV a lot to test out the virtual tuner feature in the next minor version of OpenDCT. This feature allows for OpenDCT based on merit and if the tuner is unlocked externally to automatically reassign tuners for SageTV. The feature is stable in my tests, but I don't use any of those features regularly. The feature is also disabled by default since not everyone will want this especially since it will get confusing on the SageTV side of things since the tuner SageTV used to perform the recording is probably not the actual tuner that did the recording. You won't need to be concerned about this feature if you don't want it when the next minor version comes out officially.

A usage case would be, say we have two tuners: Tuner0 and Tuner1. Tuner0 is currently locked by an outside application and Tuner1 is free, even though SageTV asked for Tuner0, Tuner1 will be used instead and SageTV will still think it's using Tuner0. If SageTV then requests Tuner1, since Tuner0 is all that's left, even if Tuner0 is still locked, OpenDCT will then force it to unlock and start the recording. As you can see, the tuners are now crossed, but this was the least disruptive approach since it didn't take the tuner you were using in another application until it had no choice.

OpenDCT will automatically assign tuners to pools based on device type so all capture devices with CableCARDs will be separated from devices without CableCARDs for example. You can also change the pool assignment per capture device if you want to further separate things. I highly do not recommend mixing devices that cannot all tune all of the same channels. This creates problems that I will likely not be addressing that I described in the issue for this feature on GitHub. If SageTV asks for any capture device within that pool, OpenDCT will select the best candidate based on merit and if the tuner is currently locked by another application with a last resort to force unlock if enabled per tuner. Capture devices are assigned on START and BUFFER and unassigned on STOP. The logs do clearly indicate the mapping when pooling is in use. The SageTV side is considered to be a virtual capture device since it represents any capture device from the corresponding pool and is not a direct mapping to a capture device. The OpenDCT side is considered to be a pool capture device and is the actual capture device that gets mapped to the virtual capture device. It gets confusing, but I couldn't think of a better way to separate them. Both sides use the same names. In the future there might be a feature to rename the capture device on the recording after it finishes recording to make it clear what capture device actually did the recording, but that will require some integration with SageTV likely via sagex.

I am willing to test for you. I Have HdHomerun DVR and SageTV in the same machine.

[Daweeze]

Hello,

I started playing with the idea of going from SageDCT to OpenDCT and I seem to be hung up somewhere. After modifying the Java path as suggested for my version, the Console seems to run fine. However, I cannot get the service to start. I have Sage 7, Windows 8.1 and 2 Prime Encoders.

Attached is a copy of the wrapper.log

Any help is appreciated!

Thanks,

-Travis

[nyplayer]

Originally Posted by Daweeze

Hello,

I started playing with the idea of going from SageDCT to OpenDCT and I seem to be hung up somewhere. After modifying the Java path as suggested for my version, the Console seems to run fine. However, I cannot get the service to start. I have Sage 7, Windows 8.1 and 2 Prime Encoders.

Attached is a copy of the wrapper.log

Any help is appreciated!

Thanks,

-Travis

your java override is wrong. you have.
"c:\Program Files (x86)\Java\jre1.8.0_66\bin\java"

should be.
"c:\Program Files (x86)\Java\jre1.8.0_66\bin\java.exe"

If you quote something you need to add the exe... Fix it and try running console again start the OPENDCT Service.

[EnterNoEscape]

Originally Posted by nyplayer

I am willing to test for you. I Have HdHomerun DVR and SageTV in the same machine.

Thanks. You are using the 32-bit Windows version correct? I'll PM you with details.

[nyplayer]

Originally Posted by EnterNoEscape

Thanks. You are using the 32-bit Windows version correct? I'll PM you with details.

Yes 32 Bit Version.

[EnterNoEscape]

Originally Posted by Daweeze

Hello,

I started playing with the idea of going from SageDCT to OpenDCT and I seem to be hung up somewhere. After modifying the Java path as suggested for my version, the Console seems to run fine. However, I cannot get the service to start. I have Sage 7, Windows 8.1 and 2 Prime Encoders.

Attached is a copy of the wrapper.log

Any help is appreciated!

Thanks,

-Travis

That's a little strange. You're getting a number format exception when it's taking in a lineup. I'll need to see what's possibly going on there since that's not a normal place to see any errors at all. It looks like it's trying to parse an empty string. While I check that, I would make a copy, then delete opendct.properties and let it rebuild if you made any modifications.

Update: I know what happened. Somehow one of your lineups saved non-numeric data in a numeric field and I missed that possibility. Just delete the lineups folder C:\ProgramData\OpenDCT\config\lineup and you should be ok. It will re-create itself and since it doesn't have a strong purpose yet, so you're not really losing anything.

[EnterNoEscape]

Version 0.3.14-beta is now available.

It fixes the handling issues with importing corrupt lineups. Eventually there will be some logic to detect when a lineup is corrupted and revert to the last backup.

[Daweeze]

Ok, so here's the latest after I uninstalled OpenDCT 0.3.13-beta (Also manually removed folder under C:\ProgramData).

For Reference:

Operating System: Windows 8.1
SageTV Version: 7.1.9.256
Java Version: 1.8.0_66 (32-bit)
Network Tuners: 2x HDHomeRun Prime (CableCard) = 6 Tuners

Installation:

1) Downloaded OpenDCT 0.3.14-beta.
2) Stopped SageDCT Service, Changed Startup Type to Disabled.
3) Stopped SageTV Service.
4) Made Backup Copy of Sage.properties and Wiz.bin.
5) Installed OpenDCT 0.3.14-beta.
6) Ran "OpenDCT Run as Console".
7) CTRL-C on OpenDCT Following Download of Channel Lineups.
8) Ran "OpenDCT Start Service" - Success!
9) Edited and Saved Sage.properties and changed network_encoder_discovery=false to network_encoder_discovery=true.
10) Started SageTV Service.
11) Started SageTV.
12) Setup>Setup Video Sources>Add New Source.
13) Selected New Video Capture Device (Ex. DCT-HDHomeRun Prime Tuner 13113C69-0 on 127.0.0.1:9000).
14) Selected "Digital TV Tuner" (Box Turns Red).
15) Selected "Digital TV Tuner" Again (Message: "The Broadcast Standard is being determined. Please wait...").
16) Selected "Use Tuner on Capture Card to tune Antenna/Cable TV. (To select between Antenna of Cable, use the SageTV installation that is controlling this Network Encoder)".
17) Selected "Use or Copy an Existing Channel Lineup for this Source".
18) Selected the Existing Lineup (Ex. Comcast Digital - Fairfield).
19) Selected "Use the same channel lineup".
20) Repeated Steps 12-19 For Each Remaining OpenDCT Tuner Available.
21) Exited SageTV.
22) Stopped SageTV Service.
23) Edited and Saved Sage.properties and Removed the "mmc/encoders" Entries For Each SageDCT Tuner Identified. (Ex. "mmc/encoders/123456990/video_capture_device_name=SageDCT-HDHomeRun Prime Tuner 13113C69-1" is the Identifying Entry That Ties My SageDCT Tuner to #1234560990, So All "mmc/encoders/1234560990....." Entries Were Deleted As Were 5 Other SageDCT Tuner Entries.
24) Started SageTV Service.
25) Started SageTV.
26) Setup>Setup Video Sources>Add New Source.
27) Confirmed only OpenDCT Tuner Entries Were Present.
28) Tested Recording On All 6 Tuners Simultaneously - Success!

Notes:

1) Default configuration worked fine, no modifications of any file were necessary.
2) OpenDCT Tuners show "DCT-TunerName Etc....." as a Source. I expected "OpenDCT-TunerName Etc....." as a Source. I see no reason why to not do that since SageDCT does it as well.


So far so good, thanks for the hard work by everyone on this project and helping keep SageTV alive. I have high hopes with this release!!

Also, I have attached a copy of the Channel Lineup that was bombing out in the 0.3.13-beta in case it helps clarify what a Lineup might return and why.

Thanks again!

-Travis

[EnterNoEscape]

Thanks. Good to see things are working now. The reason I chose just DCT is because OpenDCT while it has a starting focus on digital cable tuners, it will eventually also support a number of other devices/streaming methods as a network encoder too. DCT is to the point and if we had other new capture devices, I would be prefixing them with whatever makes the most sense. Also you can actually rename the tuners if you really want.

[troll5501]

Originally Posted by EnterNoEscape

PES packet size mismatch errors are usually uncorrectable errors in the stream itself. High network traffic for whatever reason can increase this error in my experience. This has happened to me even with a dedicated NIC. The strangest part to me is that the RTP continuity is fine (UDP packets are not being missed), yet the stream quality gets very bad. Upload id was really able to draw these problems out especially in my development VM.

What I noticed is that any CPU spike during recording is when these warnings occur. For example, if I mark something to record in the future and the SageTV scheduler kicks off and spikes the CPU briefly in sagetv.exe, I will get a few of the PES packet size mismatch errors in OpenDCT for an active recording, or occasionally when a new show starts playing on live TV. It's also more frequent with higher stream rates such as high-action sports and when multiple recordings are running. Maybe different ffmpeg buffer sizes will help? I will probably need to add more CPUs into the VM but I would prefer to get everything optmized as best as possible first. Currently I have 2 cores allocated (X5570 2.93GHz).

The upload id thing is interesting. There is a setting called consumer.ffmpeg.min_upload_id_transfer_size and a setting called consumer.ffmpeg.rw_buffer_size. Try bumping those values up to 32768 and see if it improves things at all. Also try dropping them to 10340 and see if it helps or likely makes it worse. When I first used upload_id it would cause really high CPU usage on SageTV.exe when my array was scrubbing.

I will experiment with the buffer sizes. I'm guessing the reason the warnings are more frequent with upload_id is because of the higher CPU usage.

Bill seemed interested in looking into the 100% CPU events and hangs in sagetv.exe when upload_id is enabled, so I attached my logs in a previous post. For now I have upload_id disabled because it's the only way I can keep everything stable.

[EnterNoEscape]

It looks like your VM should have more than enough resources to do this. I'm running my primary test SageTV server VM on a i7-4790k (4GHz) with two virtual processors and 4GB of ram. It's worth noting that even though upload id is enabled by default, it's not really required in most cases since when we are writing directly to the disk we are doing it using a direct byte buffer just like SageTV. The best usage case would be if filesystem access is a problem. It's enabled because it can in some cases speed up live tuning. If you look at the internals of SageTV other than checking to make sure you have been "authorized" to write the file, SageTV on the playback side of things is very much blind to what and how much is being written and relies on querying the network encoder to know that data is being streamed. If upload id doesn't interest you, leave it off. I was just curious.

[nyplayer]

Just an FYI ... The files created using OpenDCT play great on the android SageTV app. I wish there was a way to mux OTA channels using OPENdct ... because it appears that the SageTV created OTA files do no play well in the android devices.

PS Is there a way to use the HDHomerun OTA Connects with OpenDCT as I am able to use them with using the PrimeNetEncoder.

[EnterNoEscape]

Originally Posted by nyplayer

PS Is there a way to use the HDHomerun OTA Connects with OpenDCT as I am able to use them with using the PrimeNetEncoder.

The discovery and communication abilities are there and have been tested, but I have not created a capture device implementation specifically for the HDHomeRun protocol. I'm currently working on the web interface which involves a few capture device implementation modifications meaning I likely will not add any new devices until the current version is the version with a web interface. It might be a while before I get around to adding that unless several people express interest in having OTA capabilities over a web interface. I have the original HDHomeRun dual tuner device and I've only used it for QAM. In fact I don't think I have ever used SageTV with OTA. I see from my local lineup that SageTV uses a hyphen and the Connect appears to use a period between the channel and sub-channel.


Speaking of the web interface, I'm a little torn between having the latest and having the most compatible. Does anyone have any opinions on a Java 1.8 requirement knowing that this might break some currently in use SageTV plugins? I ask because the latest Jetty as has been discussed already in other threads requires 1.8. In my current implementation, you can choose to not use the web interface and continue to just use 1.7 with all of the latest features.

What I think I'll be doing for simplicity sake on my own setup if I have issues with 1.8 32-bit and SageTV plugins, is install 1.8 64-bit, run the 64-bit version of OpenDCT and retain a 1.7 32-bit version of Java for SageTV. That way I'll know positively what version SageTV is using. If anyone knows a way to tell SageTV exactly what binary to use, I think that would help most people out.

Update: Just to give people an idea of where I'm going with the interface, attached is a screenshot of a nearly complete page. Almost everything you see currently works.