OpenDCT: An open source digital cable tuner.

[EnterNoEscape]

Originally Posted by Telecore

I've been running 5.6, mostly with no problems. I did what you suggested above, but not all of the earlier stuff you suggested. My config file modifications from the default are:
changed upnp.service.configuration.http_listen_port=8051 to =0
changed error_videos_enabled=false (was true)
added sagetv.device.global.ignore_devices_csv=HDHomeRun HDHR3-6CC-3X2 Tuner 13206485-0,HDHomeRun HDHR3-6CC-3X2 Tuner 13206485-1,HDHomeRun HDHR3-6CC-3X2 Tuner 13206485-2 (to only use the Ceton tuners)
changed consumer.ffmpeg.use_compat_timebase=true (was false)

Another problem happened today at 16:30 (see attached file) while watching a baseball game, the log file says something like "the consumer appears to be stuck". Had to change channels and change back to recover. Just want to give you more info/feedback in case there's an issue here - thanks

Edit: by the way - have not yet seen the problem that occurs when re-tuning at the top of the hour since I made the suggested change

On the plus side, you keep giving me new ideas on what things would be nice to log when abnormal things happen. One thing we can positively say is that data was still coming into the producer, but for some reason it completely stopped going out the consumer end; even when you're not tuned into anything the InfiniTV will actually slowly send null packets as long as RTP is set to stream to a port. The fact that it took over 41 seconds to detect effectively 1 second worth of actual video actually seems to support the idea that the stream might have actually gone effectively dead. I'll put more logging around this situation into the the next version in this regard so hopefully we can weed out what's really going on.

[EnterNoEscape]

Originally Posted by tmiranda

I've got 8 tuners and two recording drives. I haven't done much "real" testing but when the errors occur it's when 6 or more of the tuners are busy.

I thought I had removed the file length checking code from the last stable, but I checked and it looks like it's still there. That might be what you're running up against. To verify this, change consumer.ffmpeg.min_direct_flush_size to -1. That will disable it.

[BobbyDing]

I'm currently running 0.4.35 and want to upgrade to the latest. Is there anything beyond making a backup of the .properties file that I need to do for either the stable or beta versions?

Also, any chance of a Docker version?

Thanks for the great software!!!

[jgsouthard]

Originally Posted by BobbyDing

I'm currently running 0.4.35 and want to upgrade to the latest. Is there anything beyond making a backup of the .properties file that I need to do for either the stable or beta versions?

Also, any chance of a Docker version?

Thanks for the great software!!!

Just stop the OpenDCT service, install the new version, and restart OpenDCT. It's probably a bit cleaner if you delete or rename the previous opendct.properties file so that the update will create a new one with any newly added properties or modified defaults. But if you do that and you've changed any of the defaults, you'll want to note the changes that you made and then add them manually to the new properties file.

[civerson4]

Just wanted to say thanks. I just "upgraded" from PrimeNetEncoder to OpenDCT. Upgrade went perfectly following your instructions (at least as much as I can tell in 24 hours).

What a great forum and community.

[EnterNoEscape]

I'm glad it's working you.

I'm sure it looks like nothing has really happened in about a month, but I'm working on adding a new feature that requires some changes in the SageTV core. Once that feature is committed, the next beta will be released.

[Toddly]

I finally got my system with OpenDCT working well. It was a network issue.

Just noticed yesterday that all of a sudden I received an error that the encoder could not be found so "No Signal". The log said it could not find HDHomerun Prime yet it works well. Scratched my head and uninstalled a recent auto installed Security update and now all is back to normal.

It was KB 3163018 installed on June 20th. Anyone know if there is a way to make it so this will not happen in the future because I know that update is coming back.

Thanks

[nyplayer]

Originally Posted by Toddly

I finally got my system with OpenDCT working well. It was a network issue.

Just noticed yesterday that all of a sudden I received an error that the encoder could not be found so "No Signal". The log said it could not find HDHomerun Prime yet it works well. Scratched my head and uninstalled a recent auto installed Security update and now all is back to normal.

It was KB 3163018 installed on June 20th. Anyone know if there is a way to make it so this will not happen in the future because I know that update is coming back.

Thanks

You can hide the update.

http://www.sevenforums.com/tutorials...n-updates.html

[Toddly]

Originally Posted by nyplayer

You can hide the update.

http://www.sevenforums.com/tutorials...n-updates.html

I can do this in Windows 10? Sorry forgot to mention that was the OS.

[nyplayer]

Originally Posted by Toddly

I can do this in Windows 10? Sorry forgot to mention that was the OS.

There is a Microsoft tool for that google hide updates windows 10

[jm9843]

Originally Posted by EnterNoEscape

I'm sure it looks like nothing has really happened in about a month, but I'm working on adding a new feature that requires some changes in the SageTV core. Once that feature is committed, the next beta will be released.

Congrats on getting the new remuxer merged into the SageTV core.

[EnterNoEscape]

Originally Posted by jm9843

Congrats on getting the new remuxer merged into the SageTV core.

Thanks! This makes the remuxer that SageTV uses internally available to all network encoders. As it is configured, it only accepts standard MPEG2-TS containers coming in which should be the vast majority of situations. It could with some modifications support a few less common for streaming TS containers as input. The only other container format it supports going in is MPEG2-PS, but I have yet to see a tuner produce by default.

It will also fully manage the GET_FILE_SIZE and SWITCH network encoder commands for you. This should allow developers to more easily write network encoders in the future.

A new OpenDCT release will soon follow. Just keep in mind that anyone who wants to be an "early adopter" of this feature will need to build their own Sage.jar and JavaRemuxer2.dll or libJavaRemuxer2.so until new releases of SageTV are built.

[EnterNoEscape]

• Fedora 24 is now supported. Fedora 22 support has ended.
• Added a new consumer that supports the new Media Server Remuxer recently added to the SageTV core. To use this consumer you must either compile a copy SageTV from GitHub or install a version of SageTV newer than 9.0.4.252. At this time a new version has not yet been released. The consumer name is opendct.consumer.MediaServerConsumerImpl
• Added a final check to the FFmpeg consumer to ensure that Non-MPEG1/2 video codecs do not get remuxed into MPEG-PS containers.
• Added more logging for FFmpeg initialization.
• Added additional smart detection trigger after startup if a capture device is requested by SageTV, but it doesn't yet exist.
• Further optimized FFmpeg initialization routine.
• Added handling for SageTV sending additional requests to start streaming when it takes too long to return OK.
• Fixed a potential race while switching with the async file writer.
• Fixed a few possible hanging issues with the OpenDCT Media Server implementation.
• Removed CBR option since the timebase compatibility fix seems to be working the best and CBR has some requirements that might have broken switching for some users.
• Added web server on port 9091 to support runtime configuration via JSON calls. This will be utilized at a later date and is listed here for those that notice that OpenDCT is now using port 9091.

[Greg2dot0]

Just wanted to let you know that I loaded 5.7 up this morning and was watching a bunch of live TV and that seems to have improved an issue that I was seeing with 5.6 with lots of "corrections" in the stream. It was so bad that I had to roll back to the stable version. I'm using the "opendct.consumer.FFmpegTransSageTVConsumerImpl" consumer and pooling.


I am curious about the advantage of the work you've been doing with Sage core. I don't think I'm ready to go build the jar file, but it sounds like this will simplify things. What other benefits are there from the new consumer?

[EnterNoEscape]

Originally Posted by Greg2dot0

Just wanted to let you know that I loaded 5.7 up this morning and was watching a bunch of live TV and that seems to have improved an issue that I was seeing with 5.6 with lots of "corrections" in the stream. It was so bad that I had to roll back to the stable version. I'm using the "opendct.consumer.FFmpegTransSageTVConsumerImpl" consumer and pooling.


I am curious about the advantage of the work you've been doing with Sage core. I don't think I'm ready to go build the jar file, but it sounds like this will simplify things. What other benefits are there from the new consumer?

What might be helping you out is the fact that I removed the code needed for CBR TS to work correctly. It didn't look like anyone was using it/needed it and all it did was add complications.

In relation to OpenDCT, one advantage you get with using the SageTV remuxer is that it does a much better job at not breaking things that aren't broken. One thing I personally have been experiencing ever since I started using FFmpeg is my recordings sometimes change to watched if I stop them even just half-way through the show. Since I've been using the the media server remuxer over the past week, I am no longer having this problem. I'm not sure if it's directly related, but it seems to be.

Another advantage is that since the code for finding a transition point between shows is on the server, it's even more responsive and getting a hiccup on the first transition when watching live TV is even more rare than before. The only exception that still lingers is that the SageTV Client doesn't like transitioning on TS containers if you pause the video then resume at a later time. As before it still just hangs. When the container is PS, this issue doesn't seem to happen which is probably why this problem has gone unnoticed for so long.

The SageTV remuxer also does a much better job at fixing discontinuities than OpenDCT likely ever will. This point probably interests you more than anything else.

Keep in mind that if you're using Windows, you'll need to install VS2015 and set things up per the directions on the SageTV GitHub to be able to compile JavaRemuxer2.dll. Linux is a little easier. Just make sure if you're running Ubuntu that build-essential is installed and you should be able to make libJavaRemuxer2.so. This would be in addition to compiling a new Sage.jar. If you only compile a new Sage.jar, the new library will not be able to load and you will not be writing anything to disk. Eventually new install packages for Windows and Linux will be released, so if this looks daunting, I would just wait.

[Greg2dot0]

Originally Posted by EnterNoEscape

Keep in mind that if you're using Windows, you'll need to install VS2015 and set things up per the directions on the SageTV GitHub to be able to compile JavaRemuxer2.dll. Linux is a little easier. Just make sure if you're running Ubuntu that build-essential is installed and you should be able to make libJavaRemuxer2.so. This would be in addition to compiling a new Sage.jar. If you only compile a new Sage.jar, the new library will not be able to load and you will not be writing anything to disk. Eventually new install packages for Windows and Linux will be released, so if this looks daunting, I would just wait.

Nope, running Unbuntu 16.04 Server 64-bit. If things weren't so busy these next couple of weeks, I'd take a crack at it on my test VM. Perhaps when things calm down and I can focus I'll give it a shot.

Thanks for the information. Looking forward to this hitting mainstream. Great work!

[EnterNoEscape]

Originally Posted by Greg2dot0

Nope, running Unbuntu 16.04 Server 64-bit. If things weren't so busy these next couple of weeks, I'd take a crack at it on my test VM. Perhaps when things calm down and I can focus I'll give it a shot.

Thanks for the information. Looking forward to this hitting mainstream. Great work!

In case you didn't notice, a new build for Linux was released the other day (9.0.4.287) that includes the new remuxer. That should make it a little easier for you to play with this feature.

[jm9843]

Originally Posted by EnterNoEscape

• Added a new consumer that supports the new Media Server Remuxer recently added to the SageTV core. To use this consumer you must either compile a copy SageTV from GitHub or install a version of SageTV newer than 9.0.4.252. At this time a new version has not yet been released. The consumer name is opendct.consumer.MediaServerConsumerImpl

I've done a bit of testing with the new MediaServer consumer on Windows and things seem to be working well (files here). Although I did notice entries in the log having to do with:

ERROR HDHomeRunDiscoverer - Unable to communicate with HDHomeRun device
WARN  HDHomeRunDiscovery - The capture device does not have any tuners. Assuming 2 => java.net.ConnectException: Connection refused: connect

This occurs even right before it successfully begins streaming the file (e.g. 'INFO MediaServerConsumerImpl - Media Server consumer is now streaming...). Is the above warning/error to be expected for now using the MediaServer?

[EnterNoEscape]

Originally Posted by jm9843

I've done a bit of testing with the new MediaServer consumer on Windows and things seem to be working well (files here). Although I did notice entries in the log having to do with:

ERROR HDHomeRunDiscoverer - Unable to communicate with HDHomeRun device
WARN  HDHomeRunDiscovery - The capture device does not have any tuners. Assuming 2 => java.net.ConnectException: Connection refused: connect

This occurs even right before it successfully begins streaming the file (e.g. 'INFO MediaServerConsumerImpl - Media Server consumer is now streaming...). Is the above warning/error to be expected for now using the MediaServer?

That's unrelated. That looks like something has triggered OpenDCT to kick detection off again. There should be some lines above that that either end in (startup) or (requested). Do you have an HDHomeRun DVR install somewhere on your network? They seem to respond like that error you posted. Basically they reply, but then don't act like a capture device, hence the error.

Edit: From looking at that a little more closely, I think the error is triggering the broadcast to happen over and over. The interval should be somewhere between 4.5 and 58 seconds. It's harmless for it to keep checking for new devices. I'll fix that in the next release.

[jm9843]

Originally Posted by EnterNoEscape

That's unrelated. That looks like something has triggered OpenDCT to kick detection off again. There should be some lines above that that either end in (startup) or (requested). Do you have an HDHomeRun DVR install somewhere on your network? They seem to respond like that error you posted. Basically they reply, but then don't act like a capture device, hence the error.

Edit: From looking at that a little more closely, I think the error is triggering the broadcast to happen over and over. The interval should be somewhere between 4.5 and 58 seconds. It's harmless for it to keep checking for new devices. I'll fix that in the next release.

The error does happen over and over again. And, yes, I do have an instance of the HDHomeRun DVR running so that's likely what's triggering it.

Thanks for all the work you do on this.