OpenDCT: An open source digital cable tuner.

[EnterNoEscape]

To address the issue in the previous post in the stable release, I upped the UDP packet receive buffer size to 65508 bytes. This will allow people with non-standard packet sizes to not need to upgrade to the beta if they don't want to.

[HelenWeathers]

I've had this happen 3 times now since installing ver 4.23 when it was released and I ignored the first time, turned on debug logging after the second time and have logs for the third time.

Recording is triggered to be named xxxx-0.ts but no data seems to get written to drive. After about 1 min 15 sec Sage shows halt detected and trys to restart.

Second recording is named xxxx-1.ts and completes successfully. xxxx-0.ts is not on the drive.

Logs are attached. Any thoughts on anything I should try??

[EnterNoEscape]

The bad thing about what I'm seeing in those logs is that there are absolutely no errors happening while the file is being "written." The FileChannel is supposed to throw an IOException if there are any problems writing and the "bytes written" which is what is sent to SageTV only increments after the FileChannel essentially says it gave the data to the OS to write. I can see that at least 2MB were at least given to the OS. It's very hard to believe that at least an empty file didn't exist at some point. My best guess is SageTV might have deleted it maybe because it did not contain any data. I'll see what I can do to further guarantee that data is hitting the disk.

Update: I did not know this, but it's possible the FileChannel may continue without error even if the file is suddenly deleted. I believe this is the definition of poor design.

[HelenWeathers]

Originally Posted by EnterNoEscape

.....My best guess is SageTV might have deleted it maybe because it did not contain any data. I'll see what I can do to further guarantee that data is hitting the disk.

Update: I did not know this, but it's possible the FileChannel may continue without error even if the file is suddenly deleted. I believe this is the definition of poor design.

Thanks for looking at this. I noticed that Sage checked the filesize twice and reported 0 bytes both times prior to calling for a device reset. It would be great IF you can find a way to verify writes a bit sooner than Sage does (1 min 15 secs+).

With your debug logging, can you create flags to tell you how far along the chain of events the data made it on it's way to the hard drive? Like, it made it into the buffer, did it make it to the next step ie ffmpeg or whatever the next step is? Sorry if what I'm saying/asking doesn't make sense.

[EnterNoEscape]

I just put together some changes that should make a difference. It's unclear how data could be buffered for so long and nothing actually written unless it's not actually being written. I'll post a new beta later in the day.

[EnterNoEscape]

This release addresses the possibility of the file being deleted while recording and takes some additional actions of the file size isn't growing when it should be. It also tells the OS to commit to disk the first 1MB of data, then switches to just flushing the buffer on each commit for the rest of the recording.

It also handles DTS errors little differently. Instead of dropping the packets, it just gives them a monotonic time stamp.

[HelenWeathers]

Sounds good. Will download and install shortly. I'll keep Sage logging turned on in case it happens again.

Thanks.

[EnterNoEscape]

No problem. I guess this was a problem just waiting to happen.

This is unrelated, but if anyone wants to know what's next. I was playing around with FFmpeg transcoding examples and spent a few days translating a good one that supports filters into JavaCPP and added colorspace conversion which is needed. The results were very encouraging, so I'm currently working on live transcoding support mostly for de-interlacing content or converting MPEG-2 to H.264 for better device compatibility.

Not surprisingly this will not be a feature everyone can use. I estimate that on a good quad-core computer you are going to be able to live transcode 4 streams maximum and realistically 1-2 for everyone else. I'm thinking it could have a transcode limit and once that limit is hit, other recordings even if they would have been transcoded will just be remuxed. It's also worth noting that if you just want to de-interlace, MPEG2 is perfectly viable and requires a little over half the resources needed to transcode to H.264. I'm also going to see what we can do with hardware acceleration since FFmpeg can be built with support for it.

[troll5501]

Originally Posted by EnterNoEscape

It also tells the OS to commit to disk the first 1MB of data, then switches to just flushing the buffer on each commit for the rest of the recording.

Adding of the flush seems to have greatly increased the I/O load and overall CPU usage on my Linux system writing to an NFS share as the video storage volume. Each call to flush() appears to have the effect of forcing the NFS client to commit each write the NFS server, even with the volume mounted in async mode. It's also committing to disk an average I/O size of 30K which is quite small.

Would it be possible to have an option to disable this flush, or (maybe better) have a property to set the minimum amount of data in the buffer before issuing a flush to disk so it can be tuned? I'd prefer to see 256K or even 1M writes to disk.

With earlier versions (I was running 0.4.19 until tonight), the NFS client in async mode would cache the writes and commit them based on the Linux kernel "dirty_*" parameters.

I'm not sure what effect this change has on using local disk, but I'm curious if it's causing the same issue or maybe the local filesystem cache is absorbing the excessive IOPS. Either way, I suspect that the CPU usage of OpenDCT may still be higher in this version due to all the flush calls.

[EnterNoEscape]

Direct file writing now uses a tunable property that is set to flush every 1MB instead of every time FFmpeg uses the write callback. The property name is consumer.ffmpeg.min_direct_flush_size.

[troll5501]

Originally Posted by EnterNoEscape

Direct file writing now uses a tunable property that is set to flush every 1MB instead of every time FFmpeg uses the write callback. The property name is consumer.ffmpeg.min_direct_flush_size.

It looks like the variables and property names are mismatched, unless I'm reading it wrong:

    // This is the smallest amount of data that will be transferred to the SageTV server.
    private final int minDirectFlush =
            Math.max(
                    Config.getInteger("consumer.ffmpeg.min_upload_id_transfer_size", 20680),
                    RW_BUFFER_SIZE
            );

    // This is the smallest amount of data that will be flushed to the SageTV server.
    private final int minUploadIDTransfer =
            Math.max(
                    Config.getInteger("consumer.ffmpeg.min_direct_flush_size", 1048576),
                    0
            );

[EnterNoEscape]

You're right; I transposed them. I'll fix that in a minute. I'm glad to see I'm not the only one reviewing the code.

I really do welcome anyone who finds something that looks wrong in the code to bring it up or better yet if it's not a simple fix like this one to create a pull request.

Update: The transposed variables are fixed. I just replaced the 0.4.27 installer with one with the variables correctly assigned. If you downloaded it prior to this post, you'll have to download it again and upgrade. It will still upgrade even though it's the same version number because the product code is different.

[brandypuff]

First i'd like to say that OpenDCT is working great - for the most part and I am happy this product exists. However, I've been having problems with missed recording for some reason and can't figure out what is happening and my wife is blaming me. Go figure...

If a tuner is locked at the time a recording is scheduled, will OpenDCT look for the next prime tuner that's free? Or will it crap out?

Are there any config settings I need to tweak? There's a lot of talk in prior posts about changing some settings but it's all very confusing to me.

I looked through the logs but there is a lot of data in them and I'm not sure what I am looking for. Will the wrapper.log or OpenDCT.log tell me what is wrong?

[nyplayer]

Originally Posted by brandypuff

First i'd like to say that OpenDCT is working great - for the most part and I am happy this product exists. However, I've been having problems with missed recording for some reason and can't figure out what is happening and my wife is blaming me. Go figure...

If a tuner is locked at the time a recording is scheduled, will OpenDCT look for the next prime tuner that's free? Or will it crap out?

Are there any config settings I need to tweak? There's a lot of talk in prior posts about changing some settings but it's all very confusing to me.

I looked through the logs but there is a lot of data in them and I'm not sure what I am looking for. Will the wrapper.log or OpenDCT.log tell me what is wrong?

Do you have pooling enabled? .. Will use tuner that is not in use.
pool.enabled=true

Do you have force unlock enabled?.
always_force_external_unlock=true ... if pooling is enabled and all tuners are in use will force unlock of tuner not being used by sagetv.


If you want tuners exclusively for Sagetv.

Disable pooling and enable always force unlock

[brandypuff]

i don't recall ever setting those settings. What config file do i need to change?

[nyplayer]

Originally Posted by brandypuff

i don't recall ever setting those settings. What config file do i need to change?

properties file. There should be a shortcut to it in your start menu.... or you can look here. C:\ProgramData\OpenDCT\config\opendct.properties
They are both false by default.

Make sure to shutdown "Sagetv OpenDCT" service before editing the properties then restart the service.

[brandypuff]

Thank you. I will give it a go.

[troll5501]

Originally Posted by EnterNoEscape

Update: The transposed variables are fixed. I just replaced the 0.4.27 installer with one with the variables correctly assigned. If you downloaded it prior to this post, you'll have to download it again and upgrade. It will still upgrade even though it's the same version number because the product code is different.

Thanks for adding the new property and for the quick bug fix! With 0.4.27 the I/O and CPU stats are back to normal. I increased the min flush to 8MB and I'm happy with the performance now. There is still an occasional flush that wasn't there before, but it's probably a good idea to have it.

[ThePaladinTech]

Just wanted to say thanks for creating this! With SageTV going open source I have great hopes that I will be able to return to SageTV as my primary PVR solution and installing this on my virtual machine went smooth as butter!

When I exited SageTV I was using SageDCT, while it worked fine I recall it was a bit of work to get it going. I was unable to use PrimeNet Encoder due to some requirement that my virtual server didn't support. But OpenDCT worked, and was EZ.

Again thank you for this!

[brandypuff]

i second that. With the renewed interest in SageTV development and the pretty stable v9 open source beta along with the very useful OpenDCT application, i plan on continuing with Sage for as long as my extender hardware keeps going. It's too bad new extenders aren't being produced anymore. To this day, i don't believe there is a better PVR solution than SageTV.

Thanks for the dedication and hard work to everyone who has put into keeping SageTV alive. Long Live SageTV!