OpenDCT: An open source digital cable tuner.

[HelenWeathers]

Originally Posted by EnterNoEscape

.....Is the service currently refusing to start?

Service is running fine now and has been running fine since I installed RC9 the day you posted it..

That above segment was from the opendct.log. The segment below is from the wrapper.log file for that same time period. I had shut down the system the previous night to do my backups and restarted it just before 11AM today.

STATUS | wrapper  | 2016/04/09 10:56:35.979 | --> Wrapper Started as Service
STATUS | wrapper  | 2016/04/09 10:56:36.197 | Launching a JVM...
INFO   | wrapper  | 2016/04/09 10:56:36.197 | command: "C:\Windows\system32\java.exe" -Dopendct_log_root=c:/ProgramData/OpenDCT/logs -XX:ErrorFile=c:/ProgramData/OpenDCT/logs/hs_err_pid%p.log -Xms128m -Xmx768m -Djava.library.path="./lib;../lib" -classpath "./lib/wrapper.jar;../lib/opendct-0.4.43.jar;../lib/cling-core-2.1.0-SNAPSHOT.jar;../lib/seamless-http-1.1.0.jar;../lib/seamless-util-1.1.0.jar;../lib/seamless-xml-1.1.0.jar;../lib/log4j-api-2.5.jar;../lib/log4j-core-2.5.jar;../lib/commons-cli-1.3.jar;../lib/jna-4.2.1.jar;../lib/jna-platform-4.2.1.jar;../lib/ffmpeg-2.8.1-1.1.jar;../lib/ffmpeg-2.8.1-1.1-windows-x86.jar;../lib/javacpp-1.1.jar" -Dwrapper.key="sqsN1xlqp8pZnvQs" -Dwrapper.port=32000 -Dwrapper.jvm.port.min=31000 -Dwrapper.jvm.port.max=31999 -Dwrapper.pid=1708 -Dwrapper.version="3.2.3" -Dwrapper.native_library="wrapper" -Dwrapper.service="TRUE" -Dwrapper.cpu.timeout="10" -Dwrapper.jvmid=1 org.tanukisoftware.wrapper.WrapperSimpleApp opendct.Main --daemon --config-dir=c:/ProgramData/OpenDCT/config --log-to-console=false
INFO   | jvm 1    | 2016/04/09 10:56:36.525 | Wrapper (Version 3.2.3) http://wrapper.tanukisoftware.org
INFO   | jvm 1    | 2016/04/09 10:56:36.525 |   Copyright 1999-2006 Tanuki Software, Inc.  All Rights Reserved.
INFO   | jvm 1    | 2016/04/09 10:56:36.525 | 
INFO   | jvm 1    | 2016/04/09 10:56:37.071 | 10:56:36.977 [WrapperSimpleAppMain] INFO  Main - Starting OpenDCT 0.4.43...
INFO   | jvm 1    | 2016/04/09 10:56:37.180 | 10:56:37.118 [WrapperSimpleAppMain] INFO  Main - OpenDCT logging to the directory 'c:/ProgramData/OpenDCT/logs'.
INFO   | jvm 1    | 2016/04/09 10:56:37.180 | 10:56:37.133 [WrapperSimpleAppMain] INFO  UpnpManager - Logging Cling UPnP to 'c:/ProgramData/OpenDCT/logs\opendct_cling.log'.
INFO   | jvm 1    | 2016/04/09 10:56:37.180 | 10:56:37.133 [FFmpegAsyncInit-19] INFO  Main - FFmpeg loading...
INFO   | jvm 1    | 2016/04/09 10:56:37.508 | 
INFO   | jvm 1    | 2016/04/09 10:56:37.508 | WrapperSimpleApp: Encountered an error running main: java.lang.Error: IP Helper Library GetAdaptersAddresses function failed
INFO   | jvm 1    | 2016/04/09 10:56:37.508 | java.lang.Error: IP Helper Library GetAdaptersAddresses function failed
INFO   | jvm 1    | 2016/04/09 10:56:37.508 | 	at java.net.NetworkInterface.getAll(Native Method)
INFO   | jvm 1    | 2016/04/09 10:56:37.508 | 	at java.net.NetworkInterface.getNetworkInterfaces(Unknown Source)
INFO   | jvm 1    | 2016/04/09 10:56:37.508 | 	at opendct.power.NetworkPowerEventManger.getNetworkInterfaces(NetworkPowerEventManger.java:199)
INFO   | jvm 1    | 2016/04/09 10:56:37.508 | 	at opendct.power.NetworkPowerEventManger.<clinit>(NetworkPowerEventManger.java:54)
INFO   | jvm 1    | 2016/04/09 10:56:37.508 | 	at opendct.Main.main(Main.java:159)
INFO   | jvm 1    | 2016/04/09 10:56:37.508 | 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
INFO   | jvm 1    | 2016/04/09 10:56:37.508 | 	at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
INFO   | jvm 1    | 2016/04/09 10:56:37.508 | 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
INFO   | jvm 1    | 2016/04/09 10:56:37.508 | 	at java.lang.reflect.Method.invoke(Unknown Source)
INFO   | jvm 1    | 2016/04/09 10:56:37.508 | 	at org.tanukisoftware.wrapper.WrapperSimpleApp.run(WrapperSimpleApp.java:240)
INFO   | jvm 1    | 2016/04/09 10:56:37.508 | 	at java.lang.Thread.run(Unknown Source)
INFO   | jvm 1    | 2016/04/09 10:56:37.813 | 10:56:37.743 [WindowsPowerMessagePump] INFO  WindowsPowerMessagePump - Message pump started.
INFO   | jvm 1    | 2016/04/09 10:56:42.113 | 10:56:42.083 [Shutdown] INFO  Main - OpenDCT has received a signal to stop.
INFO   | jvm 1    | 2016/04/09 10:56:42.113 | 10:56:42.083 [Shutdown] INFO  Main - Saving current configuration...
INFO   | jvm 1    | 2016/04/09 10:56:42.113 | 10:56:42.083 [PowerMessageManagerShutdown] INFO  Main - Stopping power messages...
INFO   | jvm 1    | 2016/04/09 10:56:42.113 | 10:56:42.083 [PowerMessageManagerShutdown] INFO  WindowsPowerMessagePump - Posting WM_QUIT message and waiting for message pump thread to exit.
INFO   | jvm 1    | 2016/04/09 10:56:42.213 | 10:56:42.113 [WindowsPowerMessagePump] INFO  WindowsPowerMessagePump - Message pump stopped.
INFO   | jvm 1    | 2016/04/09 10:56:42.213 | Exception in thread "FFmpegAsyncInit-19" java.lang.ExceptionInInitializerError
INFO   | jvm 1    | 2016/04/09 10:56:42.213 | 	at java.lang.Class.forName0(Native Method)
INFO   | jvm 1    | 2016/04/09 10:56:42.213 | 	at java.lang.Class.forName(Unknown Source)
INFO   | jvm 1    | 2016/04/09 10:56:42.213 | 	at org.bytedeco.javacpp.Loader.load(Loader.java:413)
INFO   | jvm 1    | 2016/04/09 10:56:42.213 | 	at org.bytedeco.javacpp.Loader.load(Loader.java:381)
INFO   | jvm 1    | 2016/04/09 10:56:42.213 | 	at org.bytedeco.javacpp.avfilter.<clinit>(avfilter.java:17)
INFO   | jvm 1    | 2016/04/09 10:56:42.213 | 	at opendct.video.ffmpeg.FFmpegUtil.initAll(FFmpegUtil.java:67)
INFO   | jvm 1    | 2016/04/09 10:56:42.213 | 	at opendct.Main$2.run(Main.java:120)
INFO   | jvm 1    | 2016/04/09 10:56:42.213 | 	at java.lang.Thread.run(Unknown Source)
INFO   | jvm 1    | 2016/04/09 10:56:42.213 | Caused by: java.lang.IllegalStateException: Shutdown in progress
INFO   | jvm 1    | 2016/04/09 10:56:42.213 | 	at java.io.DeleteOnExitHook.add(Unknown Source)
INFO   | jvm 1    | 2016/04/09 10:56:42.213 | 	at java.io.File.deleteOnExit(Unknown Source)
INFO   | jvm 1    | 2016/04/09 10:56:42.213 | 	at org.bytedeco.javacpp.Loader.loadLibrary(Loader.java:621)
INFO   | jvm 1    | 2016/04/09 10:56:42.213 | 	at org.bytedeco.javacpp.Loader.load(Loader.java:429)
INFO   | jvm 1    | 2016/04/09 10:56:42.213 | 	at org.bytedeco.javacpp.Loader.load(Loader.java:381)
INFO   | jvm 1    | 2016/04/09 10:56:42.213 | 	at org.bytedeco.javacpp.swscale.<clinit>(swscale.java:12)
INFO   | jvm 1    | 2016/04/09 10:56:42.213 | 	... 8 more
STATUS | wrapper  | 2016/04/09 10:56:42.513 | <-- Wrapper Stopped

EDIT: It appears to me that it had trouble finding the HDHRPrime for some reason.

[reccitron]

Originally Posted by EnterNoEscape

For a little while I thought we couldn't get the Music Choice type content to work with FFmpeg reliably and I was going to add the ability to use a different consumer based on the channel being tuned, but the reliability started to shape up and I thought that might be a little tedious. OpenDCT does also have a raw consumer, but I haven't really had a good reason to use it in a while. The raw consumer is opendct.consumer.RawSageTVConsumerImpl and would be the equivalent to dump in SageDCT.

I'm also having issues with Comcast music choice channels.

I was using sagedct but installed OpenDct today. I downloaded and installed the latest bet version. All tv channels are working well. The music channels play for about 10 seconds then the sound goes out. It will then come back on after about 2 1/2 minute wait.

I tried switching to the raw consumer listed above by shutting down the services of both sage and OpenDct before I made the configure change. This didn't help at all. When I went back in to change it back it had changed back on its own so I assume it didn't change at all.

Is there a solution to get the Comcast music channels to work reliably with Opendct?

[EnterNoEscape]

Originally Posted by HelenWeathers

Service is running fine now and has been running fine since I installed RC9 the day you posted it..

That above segment was from the opendct.log. The segment below is from the wrapper.log file for that same time period. I had shut down the system the previous night to do my backups and restarted it just before 11AM today.

STATUS | wrapper  | 2016/04/09 10:56:35.979 | --> Wrapper Started as Service
STATUS | wrapper  | 2016/04/09 10:56:36.197 | Launching a JVM...
INFO   | wrapper  | 2016/04/09 10:56:36.197 | command: "C:\Windows\system32\java.exe" -Dopendct_log_root=c:/ProgramData/OpenDCT/logs -XX:ErrorFile=c:/ProgramData/OpenDCT/logs/hs_err_pid%p.log -Xms128m -Xmx768m -Djava.library.path="./lib;../lib" -classpath "./lib/wrapper.jar;../lib/opendct-0.4.43.jar;../lib/cling-core-2.1.0-SNAPSHOT.jar;../lib/seamless-http-1.1.0.jar;../lib/seamless-util-1.1.0.jar;../lib/seamless-xml-1.1.0.jar;../lib/log4j-api-2.5.jar;../lib/log4j-core-2.5.jar;../lib/commons-cli-1.3.jar;../lib/jna-4.2.1.jar;../lib/jna-platform-4.2.1.jar;../lib/ffmpeg-2.8.1-1.1.jar;../lib/ffmpeg-2.8.1-1.1-windows-x86.jar;../lib/javacpp-1.1.jar" -Dwrapper.key="sqsN1xlqp8pZnvQs" -Dwrapper.port=32000 -Dwrapper.jvm.port.min=31000 -Dwrapper.jvm.port.max=31999 -Dwrapper.pid=1708 -Dwrapper.version="3.2.3" -Dwrapper.native_library="wrapper" -Dwrapper.service="TRUE" -Dwrapper.cpu.timeout="10" -Dwrapper.jvmid=1 org.tanukisoftware.wrapper.WrapperSimpleApp opendct.Main --daemon --config-dir=c:/ProgramData/OpenDCT/config --log-to-console=false
INFO   | jvm 1    | 2016/04/09 10:56:36.525 | Wrapper (Version 3.2.3) http://wrapper.tanukisoftware.org
INFO   | jvm 1    | 2016/04/09 10:56:36.525 |   Copyright 1999-2006 Tanuki Software, Inc.  All Rights Reserved.
INFO   | jvm 1    | 2016/04/09 10:56:36.525 | 
INFO   | jvm 1    | 2016/04/09 10:56:37.071 | 10:56:36.977 [WrapperSimpleAppMain] INFO  Main - Starting OpenDCT 0.4.43...
INFO   | jvm 1    | 2016/04/09 10:56:37.180 | 10:56:37.118 [WrapperSimpleAppMain] INFO  Main - OpenDCT logging to the directory 'c:/ProgramData/OpenDCT/logs'.
INFO   | jvm 1    | 2016/04/09 10:56:37.180 | 10:56:37.133 [WrapperSimpleAppMain] INFO  UpnpManager - Logging Cling UPnP to 'c:/ProgramData/OpenDCT/logs\opendct_cling.log'.
INFO   | jvm 1    | 2016/04/09 10:56:37.180 | 10:56:37.133 [FFmpegAsyncInit-19] INFO  Main - FFmpeg loading...
INFO   | jvm 1    | 2016/04/09 10:56:37.508 | 
INFO   | jvm 1    | 2016/04/09 10:56:37.508 | WrapperSimpleApp: Encountered an error running main: java.lang.Error: IP Helper Library GetAdaptersAddresses function failed
INFO   | jvm 1    | 2016/04/09 10:56:37.508 | java.lang.Error: IP Helper Library GetAdaptersAddresses function failed
INFO   | jvm 1    | 2016/04/09 10:56:37.508 | 	at java.net.NetworkInterface.getAll(Native Method)
INFO   | jvm 1    | 2016/04/09 10:56:37.508 | 	at java.net.NetworkInterface.getNetworkInterfaces(Unknown Source)
INFO   | jvm 1    | 2016/04/09 10:56:37.508 | 	at opendct.power.NetworkPowerEventManger.getNetworkInterfaces(NetworkPowerEventManger.java:199)
INFO   | jvm 1    | 2016/04/09 10:56:37.508 | 	at opendct.power.NetworkPowerEventManger.<clinit>(NetworkPowerEventManger.java:54)
INFO   | jvm 1    | 2016/04/09 10:56:37.508 | 	at opendct.Main.main(Main.java:159)
INFO   | jvm 1    | 2016/04/09 10:56:37.508 | 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
INFO   | jvm 1    | 2016/04/09 10:56:37.508 | 	at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
INFO   | jvm 1    | 2016/04/09 10:56:37.508 | 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
INFO   | jvm 1    | 2016/04/09 10:56:37.508 | 	at java.lang.reflect.Method.invoke(Unknown Source)
INFO   | jvm 1    | 2016/04/09 10:56:37.508 | 	at org.tanukisoftware.wrapper.WrapperSimpleApp.run(WrapperSimpleApp.java:240)
INFO   | jvm 1    | 2016/04/09 10:56:37.508 | 	at java.lang.Thread.run(Unknown Source)
INFO   | jvm 1    | 2016/04/09 10:56:37.813 | 10:56:37.743 [WindowsPowerMessagePump] INFO  WindowsPowerMessagePump - Message pump started.
INFO   | jvm 1    | 2016/04/09 10:56:42.113 | 10:56:42.083 [Shutdown] INFO  Main - OpenDCT has received a signal to stop.
INFO   | jvm 1    | 2016/04/09 10:56:42.113 | 10:56:42.083 [Shutdown] INFO  Main - Saving current configuration...
INFO   | jvm 1    | 2016/04/09 10:56:42.113 | 10:56:42.083 [PowerMessageManagerShutdown] INFO  Main - Stopping power messages...
INFO   | jvm 1    | 2016/04/09 10:56:42.113 | 10:56:42.083 [PowerMessageManagerShutdown] INFO  WindowsPowerMessagePump - Posting WM_QUIT message and waiting for message pump thread to exit.
INFO   | jvm 1    | 2016/04/09 10:56:42.213 | 10:56:42.113 [WindowsPowerMessagePump] INFO  WindowsPowerMessagePump - Message pump stopped.
INFO   | jvm 1    | 2016/04/09 10:56:42.213 | Exception in thread "FFmpegAsyncInit-19" java.lang.ExceptionInInitializerError
INFO   | jvm 1    | 2016/04/09 10:56:42.213 | 	at java.lang.Class.forName0(Native Method)
INFO   | jvm 1    | 2016/04/09 10:56:42.213 | 	at java.lang.Class.forName(Unknown Source)
INFO   | jvm 1    | 2016/04/09 10:56:42.213 | 	at org.bytedeco.javacpp.Loader.load(Loader.java:413)
INFO   | jvm 1    | 2016/04/09 10:56:42.213 | 	at org.bytedeco.javacpp.Loader.load(Loader.java:381)
INFO   | jvm 1    | 2016/04/09 10:56:42.213 | 	at org.bytedeco.javacpp.avfilter.<clinit>(avfilter.java:17)
INFO   | jvm 1    | 2016/04/09 10:56:42.213 | 	at opendct.video.ffmpeg.FFmpegUtil.initAll(FFmpegUtil.java:67)
INFO   | jvm 1    | 2016/04/09 10:56:42.213 | 	at opendct.Main$2.run(Main.java:120)
INFO   | jvm 1    | 2016/04/09 10:56:42.213 | 	at java.lang.Thread.run(Unknown Source)
INFO   | jvm 1    | 2016/04/09 10:56:42.213 | Caused by: java.lang.IllegalStateException: Shutdown in progress
INFO   | jvm 1    | 2016/04/09 10:56:42.213 | 	at java.io.DeleteOnExitHook.add(Unknown Source)
INFO   | jvm 1    | 2016/04/09 10:56:42.213 | 	at java.io.File.deleteOnExit(Unknown Source)
INFO   | jvm 1    | 2016/04/09 10:56:42.213 | 	at org.bytedeco.javacpp.Loader.loadLibrary(Loader.java:621)
INFO   | jvm 1    | 2016/04/09 10:56:42.213 | 	at org.bytedeco.javacpp.Loader.load(Loader.java:429)
INFO   | jvm 1    | 2016/04/09 10:56:42.213 | 	at org.bytedeco.javacpp.Loader.load(Loader.java:381)
INFO   | jvm 1    | 2016/04/09 10:56:42.213 | 	at org.bytedeco.javacpp.swscale.<clinit>(swscale.java:12)
INFO   | jvm 1    | 2016/04/09 10:56:42.213 | 	... 8 more
STATUS | wrapper  | 2016/04/09 10:56:42.513 | <-- Wrapper Stopped

EDIT: It appears to me that it had trouble finding the HDHRPrime for some reason.

Thanks for the additional logging. That clears things up a lot. The crash happened while it was detecting the available network adapters, the JVM returned the very unexpected error "IP Helper Library GetAdaptersAddresses function failed" when it calls the method java.net.NetworkInterface.getAll(Native Method). The result is that the JVM stops and since FFmpeg was initializing still, it crashes along with it.

After a little research, this appears to be an unresolved bug in Java. I'll see if I can code around it in case it happens again to make it less of a complete failure type situation in the future. https://bugs.openjdk.java.net/browse/JDK-8057900

[EnterNoEscape]

Originally Posted by reccitron

I'm also having issues with Comcast music choice channels.

I was using sagedct but installed OpenDct today. I downloaded and installed the latest bet version. All tv channels are working well. The music channels play for about 10 seconds then the sound goes out. It will then come back on after about 2 1/2 minute wait.

I tried switching to the raw consumer listed above by shutting down the services of both sage and OpenDct before I made the configure change. This didn't help at all. When I went back in to change it back it had changed back on its own so I assume it didn't change at all.

Is there a solution to get the Comcast music channels to work reliably with Opendct?

You must always stop the OpenDCT service before making changes to opendct.properties. That's likely why it changed back on you. I would guess that you didn't actually use the raw consumer when you thought you did. There is a solution to allow you to dynamically switch between raw and FFmpeg by channel that will be coming out as soon as we have this current beta reasonably wrapped up.

[CptKirk]

System setup in my signature.

Showing "Halt detected in recording"

Starting at - 11:53
Ending at - 12:23

But the logs are showing problems up to 13:02

Log files attached.

[EnterNoEscape]

Originally Posted by CptKirk

System setup in my signature.

Showing "Halt detected in recording"

Starting at - 11:53
Ending at - 12:23

But the logs are showing problems up to 13:02

Log files attached.

It looks like there's a theme in that log file. SageTV keeps having a hard time maintaining a connection with OpenDCT and OpenDCT frequently can't reach your HDHomeRun devices. I can't definitively say it, but I don't think that OpenDCT is the root cause of this issue.

The reason I say this is that if the HDHomeRun stops responding on the last active connection, a new one is created. If the new connection fails, most of the time it's because something is not working correctly regarding your firewall, computer hardware, network equipment or the HDHomeRun itself. I'm leaning on a network disruption/driver issue because SageTV keeps disconnecting in an unusual way too.

Make sure you didn't have any tasks running on the server at the time this issue happened such as a backup that uses VSS or sends large amounts of data to a remote location. VSS on slower computers without a lot of ram can bring a very active computer to it's knees. Large remote file transfers can also cause intermittent network problems. I'm not telling you to disable your backup process if you have something in place, but I would either change the time so it's less likely to be a problem and just be aware of it if you have issues down the road.

BitTorrent can cause things to randomly disconnect if you have the allowed connections to be higher than the weakest device on your network can handle.

The other side of this could be another computer on your network flooded the network causing effectively a denial of service attack.

I would also consider upgrading your NIC drivers if that's an option.

Troubleshooting random network issues can be very difficult, but my experience has been they usually end up having a very non-random reason. I hope maybe some of this gives you an aha moment.

[CptKirk]

Thanks, I'll look around on my side then.

No big tasks running on the server. No bittorrents on the network.

Edit: Nic drivers were from 2012. Updated to the latest, will see if that helps.

[Cooper]

Originally Posted by EnterNoEscape

That's odd. That's one of the things I test constantly. There will be a move to the transcoding consumer when I move on to 0.5 because I have improved so much and it doesn't make sense to keep them synced up when they effectively do the same thing when remuxing. Try changing all of the values for sagetv.device.<unique_id>.consumer to opendct.consumer.FFmpegTransSageTVConsumerImpl and see if the situation improves. The difference is that it performs SWITCH more accurately on the key frames.

The reason why you would have never seen this in SageDCT is because it didn't support SWITCH which is why you get that brief interruption between recordings when watching live.

We are still getting problems when watching live TV and pausing. 99% of the time if paused and once you skip ahead get the spinning circle and I need to kill Sage and restart. I am using the latest RC9 beta and Sage 7. I have attached the log file. Besides this problem everything else seems to work well.

[EnterNoEscape]

Originally Posted by Cooper

We are still getting problems when watching live TV and pausing. 99% of the time if paused and once you skip ahead get the spinning circle and I need to kill Sage and restart. I am using the latest RC9 beta and Sage 7. I have attached the log file. Besides this problem everything else seems to work well.

What are you using when you're watching live TV? HD200, HD300, Android miniclient, SageTV Windows client, placeshifter? The only one I know sometimes doesn't work well is the SageTV Windows client. OpenDCT in your logs on SWITCH is creating a file for the next recording that if you put it end to end with the previous recording, it will transition without a hiccup. OpenDCT makes sure it's done on a video key frame and resets the file size reported to SageTV which is the extent of the requirements for it to work.

Since the logs just indicate that everything did was it was supposed to do, it sounds like you should turn switching off. You can do this by doing the following:

1) Stop the SageTV service.
2) Stop the OpenDCT service.
3) Open Sage.properties
4) Find all of the OpenDCT entries and change mmc/encoders/<unique_id>/fast_network_encoder_switch to false.
5) Open opendct.properties
6) Change all entries for sagetv.device.<device_id>.fast_network_encoder_switch to false.
7) Save the changes.
8) Start OpenDCT service.
9) Start SageTV service.

[Cooper]

Thanks I will try this. Using Windows Sage Client with service running on same box.

This seemed to resolve the issue so far. Little slower changing from show to show but will take that over failing.

[troll5501]

0.4.45 has been running great for the past 5 days. No issues to report, and I haven't noticed any glitches in any recordings and haven't had any failed recordings...just the typical/expected PES packet size mismatch errors at commercial transitions. The only changes from default settings that I am using are UDP (http disabled) and a few minor java GC tweaks leftover from my previous testing efforts.

[EnterNoEscape]

Originally Posted by troll5501

0.4.45 has been running great for the past 5 days. No issues to report, and I haven't noticed any glitches in any recordings and haven't had any failed recordings...just the typical/expected PES packet size mismatch errors at commercial transitions. The only changes from default settings that I am using are UDP (http disabled) and a few minor java GC tweaks leftover from my previous testing efforts.

Good to hear. I've been getting more acquainted with JavaCPP over the past week and have discovered many ways to avoid constant object creation while streaming. In some cases I was able to cut object creation down to 1/4 what it was before. In a few cases, things got so much faster object creation got out of control because it was trying to read more data and hardly anything was available yet. That made it return very small bits of data at a time, so I fixed that too. I'm not against object creation and I'm trying not to over optimize, but tight loops like remuxing in my opinion should try to keep it to a minimum.

I also wrote my own http implementation that allows OpenDCT to download using a direct byte buffer. I'll be interested to see if that design works a lot better for you since the one built into Java does does not.

[EnterNoEscape]

• Features indicated as experimental in 0.4 may still have issues that might only be addressed in 0.5+. 0.4 changes after this release will only address major issues that do not require significant changes.
• Fixed HDHomeRun devices not being re-detected after standby.
• Added a small performance optimization to reduce the number reads performed by the transcoding FFmpeg consumer.
• Added handling for a rare native error when getting all currently available network interfaces.
• Removed some tuning code that never executes anymore due to the delays already in place to support MPEG-PS.
• Handled initial file creation failure so it returns ERROR instead of pointlessly pushing through.
• Fixed issue with upload id that would cause the file be overwritten from the beginning if there was a disconnection.

[troll5501]

Originally Posted by waylo

I was wondering if you had any thoughts on why the music stations have had glitches with DCT tuning? On comcast.

These are the stations which stream music with slideshow-like pics/text/ads on the screen.

Specifically, they are slow to tune initially (no signal for maybe 10 seconds), but then play for the first 15 second or so. Inevitably they start skipping and eventually stop playing after these 15 seconds or so.

So I hadn't thought to test music channels until now, but I am seeing the same issue in 0.4.45 as waylo reported back in March--I'm also using Comcast. When I tune a music channel it takes awhile to tune (understandably due to the low data volume) but then as soon as it tunes, the dts corrections start happening immediately. I get audio for 10-15 seconds then the audio stops but the video continues. If I let it go, eventually I get audio again and it often cuts out a few more times but becomes steady as times goes on. During the entire time, the dts corrections keep happening enough to continue incrementing the tolerance. As I was typing this (and after about 10 minutes of recording) the audio completely stopped and I noticed that it got into a loop of "discarding packet stream 0" however the video continued because the on-screen ads and music info was still changing. After a few minutes the audio came back again and then there were no more dts corrections happening at all and everything was fine.

Let me know if you want to see the logs or want a resulting recording. Or if this is just a known issue and you already have the information that you need to work on it in 0.5 then I will wait. Thanks!

[EnterNoEscape]

Originally Posted by troll5501

So I hadn't thought to test music channels until now, but I am seeing the same issue in 0.4.45 as waylo reported back in March--I'm also using Comcast. When I tune a music channel it takes awhile to tune (understandably due to the low data volume) but then as soon as it tunes, the dts corrections start happening immediately. I get audio for 10-15 seconds then the audio stops but the video continues. If I let it go, eventually I get audio again and it often cuts out a few more times but becomes steady as times goes on. During the entire time, the dts corrections keep happening enough to continue incrementing the tolerance. As I was typing this (and after about 10 minutes of recording) the audio completely stopped and I noticed that it got into a loop of "discarding packet stream 0" however the video continued because the on-screen ads and music info was still changing. After a few minutes the audio came back again and then there were no more dts corrections happening at all and everything was fine.

Let me know if you want to see the logs or want a resulting recording. Or if this is just a known issue and you already have the information that you need to work on it in 0.5 then I will wait. Thanks!

I had not realized that the packets were spaced so far apart that was the real reason the channel was actually triggering a dts repair. It's an easy fix, would you mind getting me a raw clip of one of those channels so I can make sure I get it right the first time.

http://<device_ip>:5004/auto/v<music_choice_channel>?duration=120

[CptKirk]

Thought I'd supply a file as well. I'm on Comcast and I see/hear pretty much the same when tuning a music channel.

I sent you a pm with a link to my two minute clip.

It's strange but when I tune into the music channel from within SageTV I see/hear the same problems mentioned by troll5501.

But the two minute clip is flawless the whole way through.

BTW: Once I updated my nic driver to the latest I haven't had a single 'halt detected in recording' happen. Thanks for the debug and suggestion.

[EnterNoEscape]

Originally Posted by CptKirk

Thought I'd supply a file as well. I'm on Comcast and I see/hear pretty much the same when tuning a music channel.

I sent you a pm with a link to my two minute clip.

It's strange but when I tune into the music channel from within SageTV I see/hear the same problems mentioned by troll5501.

But the two minute clip is flawless the whole way through.

BTW: Once I updated my nic driver to the latest I haven't had a single 'halt detected in recording' happen. Thanks for the debug and suggestion.

I spotted the problem fairly quickly in the clip you sent me. I wish I had actually asked for a log file from one of you sooner. I just assumed it was what I thought it was. Interestingly enough your Music Choice streams are not a whole lot different from the ones I get from FiOS. They are both MPEG2. The Comcast ones are missing all of the video frames between each I frame. Whereas in the FiOS content, even though they don't do much, all of the frames in between are present.

I'll post an new release later today. The change needed was very trivial as expected. Also in 0.5 you will be able to use the raw consumer for Music Choice channels if you so choose. I'm still verifying that CCExtractor works in all supported installation scenarios in case you're wondering why the 0.5 beta isn't available yet.

[waylo]

Originally Posted by EnterNoEscape

I spotted the problem fairly quickly in the clip you sent me. I wish I had actually asked for a log file from one of you sooner. I just assumed it was what I thought it was. Interestingly enough your Music Choice streams are not a whole lot different from the ones I get from FiOS. They are both MPEG2. The Comcast ones are missing all of the video frames between each I frame. Whereas in the FiOS content, even though they don't do much, all of the frames in between are present.

I'll post an new release later today. The change needed was very trivial as expected. Also in 0.5 you will be able to use the raw consumer for Music Choice channels if you so choose. I'm still verifying that CCExtractor works in all supported installation scenarios in case you're wondering why the 0.5 beta isn't available yet.

Fantastic update. Your dedication to making this *THE* DCT utility for the ages is much appreciated!

[troll5501]

Originally Posted by EnterNoEscape

I had not realized that the packets were spaced so far apart that was the real reason the channel was actually triggering a dts repair. It's an easy fix, would you mind getting me a raw clip of one of those channels so I can make sure I get it right the first time.

I'll PM you with a link to several raw clips also, just in case my scenario is different than the others. Last night the tolerance incremented as high as 14400000 before it stopped making adjustments. And I'll give you last night's logfile in case it has any helpful information.

[cat6man]

Originally Posted by EnterNoEscape

• Features indicated as experimental in 0.4 may still have issues that might only be addressed in 0.5+. 0.4 changes after this release will only address major issues that do not require significant changes.
• Fixed HDHomeRun devices not being re-detected after standby.
• Added a small performance optimization to reduce the number reads performed by the transcoding FFmpeg consumer.
• Added handling for a rare native error when getting all currently available network interfaces.
• Removed some tuning code that never executes anymore due to the delays already in place to support MPEG-PS.
• Handled initial file creation failure so it returns ERROR instead of pointlessly pushing through.
• Fixed issue with upload id that would cause the file be overwritten from the beginning if there was a disconnection.

hi there........and thanks for the great work on openDCT.

i moved my old v7 server on windows xp to v9 on ubuntu and it is working very nicely. when i update openDCT, do i just stop the sage and openDCT services, run the installer, and re-start the services? (i.e. i don't have to re-do the console-only procedure or re-configure tuners, correct?)