OpenDCT: An open source digital cable tuner.

[EnterNoEscape]

You're right. I think I know what happened. It needs to be fixed in the code.

[nyplayer]

Originally Posted by EnterNoEscape

You're right. I think I know what happened. It needs to be fixed in the code.

Ok PM me when you want me to test no hurry ... running on test system.

Fixed works fine.

[SageWizdom]

EnterNoEscape, If you didn't see it, mikejaner found that the init scripts were not updating / running correctly so that opendct was not auto starting at boot via the .deb install. He shared the below command (also linked below)

update-rc.d -f opendct defaults

http://forums.sagetv.com/forums/show...8&postcount=20

[EnterNoEscape]

Thanks! It's easy to add and I tested it as working, so it will be in the next beta release.

I also added this to the uninstall script:

update-rc.d -f opendct remove

[EnterNoEscape]

This update only addresses some scripting issues discovered on Ubuntu. It does not change anything for Windows.

• Ubuntu init.d script was not running on startup for everyone. The install script now runs 'update-rc.d -f opendct defaults'. The uninstall script runs 'update-rc.d -f opendct remove'. Thanks mikejaner.
• Addressed runlevels warning message when enabling the Ubuntu init.d script.

[EnterNoEscape]

In the next release I would like people to migrate over to the newer HDHomeRun capture device implementation and discovery method. I can fully automate this transition in the next version by making some changes to opendct.properties programmatically on first run. Of course a backup will be made before the changes are done.

I wanted to see if anyone has any objections about this being done for them or if they would rather have this done only in the default configuration for new installs.

Also due to the comments in the Sage 9 Web UI thread about using NanoHTTPD instead of Jetty, Java 1.8 may not be a requirement for yet to be released web interface. I was just going with what I figured would be the logical next step for SageTV. Earlier today I was playing around with NanoHTTPD and I think it's much more in line with the actual needs of OpenDCT and a lot lighter than the latest Jetty. I'll need to work with it a little more, but so far it looks very promising.

[HelenWeathers]

Originally Posted by EnterNoEscape

.....I wanted to see if anyone has any objections about this being done for them or if they would rather have this done only in the default configuration for new installs......

I always save copies of my OpenDTC folders and software, uninstall older version, delete old folders and then run fresh install of new version creating new folders etc.

So no objection here.

[jgsouthard]

Originally Posted by EnterNoEscape

In the next release I would like people to migrate over to the newer HDHomeRun capture device implementation and discovery method. I can fully automate this transition in the next version by making some changes to opendct.properties programmatically on first run. Of course a backup will be made before the changes are done.

I wanted to see if anyone has any objections about this being done for them or if they would rather have this done only in the default configuration for new installs.

Also due to the comments in the Sage 9 Web UI thread about using NanoHTTPD instead of Jetty, Java 1.8 may not be a requirement for yet to be released web interface. I was just going with what I figured would be the logical next step for SageTV. Earlier today I was playing around with NanoHTTPD and I think it's much more in line with the actual needs of OpenDCT and a lot lighter than the latest Jetty. I'll need to work with it a little more, but so far it looks very promising.

No objections.

So far everything you've done has demonstrated strong programming and SageTV knowledge, so I'm confident in letting you tell us what you think will work best. Since you are still in Beta, I think it would be better for you to set defaults based on what you think would work best for most, rather than trying to maintain compatibility with those already using OpenDCT. I can adapt as needed.

I'm currently using 0.4.28 and it is ROCK SOLID (no issues at all), so I'm comfortable that if you screw something up I can always go back to 0.4.28 and be happy.

But I am a habitual and compulsive early adopter, so if you release something else I will certainly try it.

[EnterNoEscape]

Originally Posted by jgsouthard

But I am a habitual and compulsive early adopter, so if you release something else I will certainly try it.

I can relate to that.

[mistergq]

Originally Posted by EnterNoEscape

I wanted to see if anyone has any objections about this being done for them or if they would rather have this done only in the default configuration for new installs.

What ever makes it easier for me...I'm all full.

[brandypuff]

No objections here, either. I'm happy (and still amazed) that it works.

[Daweeze]

Originally Posted by EnterNoEscape

In the next release I would like people to migrate over to the newer HDHomeRun capture device implementation and discovery method. I can fully automate this transition in the next version by making some changes to opendct.properties programmatically on first run. Of course a backup will be made before the changes are done.

I wanted to see if anyone has any objections about this being done for them or if they would rather have this done only in the default configuration for new installs.

I'm willing to bite as well. Just know that I am still on v0.3.16 with great success. The only concern I ever have is with the Channel Lineups getting messed up due to all of the custom changes I have made. At this point I haven't typically backed up anything before using OpenDCT for updates. I am only running 2 HDHomeRun Prime units using CableCards, but I do have an HDHRDual for ATSC that I haven't integrated in years still on the network that could be discovered but I don't have in SageTV. I don't know if this an interesting upgrade scenario for you but that's what I have.....

-Travis

[nyplayer]

Go for it has been working great.

[mechling-burgh]

I say go for it also, I have been using 4.28 since it came out and is running great. The way you've been working I thought you would of had it released already. Thanks for all your work on this.

[EnterNoEscape]

The last release on this thread was 0.4.28, so these notes will get everyone completely up to speed. There are some more minor notes that I'm going to skip over. If you're interested, the most complete change log is always on GitHub.

CONFIGURATION UPGRADE: The first time you run this version, it will upgrade your current configuration. What this means is a few properties in opendct.properties will be removed and some properties will be modified so that you are using the best configuration. The HDHomeRun Prime will be switched to being discovered via its native discovery protocol. This upgrade will only happen once. The new configuration is not fully compatible with OpenDCT versions earlier than 0.4.30. As of 0.4.25 the properties are backed up on upgrade, so if this upgrade breaks anything for you and you did not make a copy of your old configuration, you should have a file named opendct.properties.0.4.xx-x containing your old configuration that you can use to undo the changes.

Configuration changes:

• The following properties no longer do anything, will confuse people and will be removed:

  hdhr.always_force_lockkey

  sagetv.device.parent.<parent_id>.consumer

  sagetv.device.parent.<parent_id>.channel_scan_consumer

• 'schemas-dkeystone-com' will be removed from 'upnp.new.device.schema_filter_strings_csv'

• 'HDHR3-CC' will be removed from 'hdhr.exp_ignore_models'

• 'discovery.exp_enabled' will be set to 'true'

• Now all HDHomeRun devices available on the network will be discovered and monitored by OpenDCT by default.

General improvements:

• The FFmpeg read/write transfer buffer size (consumer.ffmpeg.rw_buffer_size) is now 262144 bytes by default with a minimum size of 65536.

• The consumer (MPEG-TS processing and streaming) is now set per capture device. After running OpenDCT for about 30 seconds and then stopping it. Change sagetv.device.<unique_id>.consumer to opendct.consumer.FFmpegTransSageTVConsumerImpl on the capture devices that you want to use the new software transcoding feature for that capture device.

• HDHomeRun ongoing discovery only sends one packet per interval after the first 3 in a row. This helps prevent UDP traffic from being dropped because of all of the responses.

• Changed periodic recording flushing to disk so it only happens if it looks like the file isn't growing.

• Changed automatic lineup creation for ATSC HDHomeRun capture devices so they create a new lineup per parent device instead of per tuning type. Automatic pooling also separates ATSC capture devices by parent device. This is required because some people have completely different lineups between their devices of the same type.

• Added HDHomeRun QAM HTTP streaming. HDHomeRun ClearQAM tuning maps to arbitrary virtual channels starting at 5000 that could change between channel scans. Since we can't reliably tell what we are going to get, we need to scan every single virtual channel until we find the one with the frequency and program we are looking for. OpenDCT updates the lineup with everything it discovers along the way, so we can reduce the possibility of needing to scan again in the future. It is safe to run a new scan on the capture device itself since OpenDCT always verifies that the frequency and program have not changed before it uses the URL associated with the virtual channel.

• Added feature that can make 720p content more compatible with H.264 decoders that do not play nicely with out of order presentation time stamps. Set consumer.ffmpeg.h264_pts_hack to true in opendct.properties to enable the compatibility hack. This feature only works when using FFmpegTransSageTVConsumer. If it just makes things worse, don't forget that this is a hack and positively not the right way to remove frames which is why it's not enabled by default.

• Audio and video stream metadata such as language is now copied when available into the FFmpeg output stream when using FFmpegTransSageTVConsumer.

• ATSC HDHomeRun support is now a fully supported configuration. It is no longer experimental.

• The channel map can now be set for HDHomeRun devices via the property sagetv.device.parent.<parent_id>.channel_map if desired. Leave this property blank if you do not want OpenDCT to change your channel map for you. This is mostly a convenience for legacy devices. Valid values right now are us-cable and usbcast. This setting has no effect on CableCARD devices.

• HDHomeRun discovery port can be set to a specific port by changing the property hdhr.broadcast_port. If the value is less than 1024, the port will be chosen automatically. The default is 64998. The static port makes it easier to do port-based firewall rules.

• Ubuntu init.d script was not running on startup for everyone. The install script now runs 'update-rc.d -f opendct defaults'. The uninstall script runs 'update-rc.d -f opendct remove'. Thanks mikejaner.

• Addressed runlevels warning message when enabling the Ubuntu init.d script.

Software Transcoding:

• Software transcoding is now available as an experimental feature. Change sagetv.device.<unique_id>.consumer to opendct.consumer.FFmpegTransSageTVConsumerImpl to enable it. The transcoding profiles are per capture device and are not set by default. When no transcoding profile is set (the default), the stream is only remuxed.

• Set the software transcoding profile by changing sagetv.device.<unique_id>.transcode_profile to one of the available profiles are stored under C:\ProgramData\OpenDCT\config\transcode on Windows and /etc/opendct/conf/transcode on Linux. See profile_example.properties for help on how you can create your own. Do not include the .properties extension when setting the profile.

• Software transcoding will limit by weight the number of live transcodes at one time. The value of consumer.ffmpeg.transcode_limit is by default your ((total CPU core count) - 1) * 2. In all packaged profiles content that does not have a height of 480 has a weight of 2. This might need to be adjusted on computers with HyperThreading enabled.

[nyplayer]

Is it Possible that a future release of OPENDCT be able to extract CC from H.264 recordings? Right now CC does not work in SageTV on recordings that contain H.264.

[EnterNoEscape]

Originally Posted by nyplayer

Is it Possible that a future release of OPENDCT be able to extract CC from H.264 recordings? Right now CC does not work in SageTV on recordings that contain H.264.

It's on the roadmap. Have you tried CCExtractor to create .srt files? I understand that it can be run on live TV.

[HelenWeathers]

Up and running on my Sage 7 Win 7 machine. Seems to be working just fine. I'll report any issues.

I did a clean install and left properties at default settings for now.

[nyplayer]

Originally Posted by EnterNoEscape

It's on the roadmap. Have you tried CCExtractor to create .srt files? I understand that it can be run on live TV.

I will try it out.

[HelenWeathers]

I did get a halt error tonight with the new release. (I had been running 4.28 for 10 days or so with no halts)

Logs are attached. I'll report if it happens again.