OpenDCT: An open source digital cable tuner.

[nyplayer]

Originally Posted by brandypuff

I am using OpenDCT and th Jetty Webserver with SageTV V9 for evaluation before I make the move to V9. I have Java 1.8 installed.

The issue is, that the version of Jetty that comes with SageTV webserver plugin does not support Java 1.8. When I try to access guide listings with the mobile browser, I get errors like:

Message: PWC6033: Unable to compile class for JSP PWC6199: Generated servlet error: The type java.util.regex.Pattern cannot be resolved. It is indirectly referenced from required .class files

Message: PWC6033: Unable to compile class for JSP PWC6199: Generated servlet error: The import java.util.Arrays cannot be resolved PWC6197: An error occurred at line: 14 in the jsp file: /WEB-INF/tags/sage/functions/collections/ArrayToList.tag PWC6199: Generated servlet error: Arrays cannot be resolved

SO I downgraded to Java 1.7 and the mobile browser works fine. However, OpenDCT wouldn't work. Said something about requiring Java 1.8, etc.

I downloaded the Jetty 9.3 release that supports Java 1.8 thinking I could update the Jetty that comes with the Sage webserver but it's not straight forward on how to do this.

It appears that Java is not backwards compatible.

Any thoughts on my dilemma?

I am running Java 1.7 with OpenDCT and SageTV9 and it works just fine. Make sure that when you Uninstall and Install Java OpenDCT and SageTV are both stopped completely. I would shutdown SageTv and openDCT uninstall all java versions ... Install Java 1.7 32 bit.

[brandypuff]

great. it works now! Maybe i didn't stop SageOpenDCT last time.

[nyplayer]

Originally Posted by brandypuff

great. it works now! Maybe i didn't stop SageOpenDCT last time.

Yeah I had done the samething the first time.

[nyplayer]

I have always_force_external_unlock=false set to true on all my tuners I was wondering ... if this is how the pooling works with that property set to true.

First it will check if tuner is in use .... If another tuner is available it will not force and unlock even though I have that property set to true. ... If every tuner is in use it will unlock any tuner that is not being used by SageTV.

[EnterNoEscape]

The first thing I will mention is if a device was not locked, then when we go to tune it and it suddenly is locked, with force unlock will for the device to be unlocked even if there are other tuners available. This should be an edge case and not what usually happens because the check and the lock happen in less than a millisecond.

The first pass over the tuners looks for an unlocked tuner in order of merit (higher number, means higher merit). When it finds one, it tries to lock it. If it can't lock it, it moves on to the next one.

The second pass only happens if they are all locked. It will attempt to lock each one of them in order of merit. If the capture device will allow it (most likely because force unlock is true), then that capture device is used. If after this pass, no capture devices are able to be unlocked, it gives up.

Both passes exclude devices already in use by SageTV. OpenDCT has an internally locked state per capture device which is triggered by SageTV sending START, BUFFER or SWITCH. It is released when SageTV sends STOP.

When pooling is enabled, any START, BUFFER or SWITCH command will create a new remapping or if the remapping already exists, it will use the current one. Only STOP will clear a device remapping. This prevents us from ever ending up in a situation where a virtual tuner is requested and cannot be assigned to a physical tuner for logical reasons as opposed to actual availability. If for some reason SageTV never sends STOP, the tuner will remain remapped and could possibly force unlock if that feature is enabled on a future tuning request. Also you would end up with a potentially very large recording; so not receiving STOP would be noticed for other reasons.

[jgsouthard]

Originally Posted by EnterNoEscape

This is not an urgent update unless you're having problems with getting ATSC tuning to work.

This update fixed some legacy ATSC tuning issues.

This update also has some performance optimizations for how FFmpeg reads data. They help the most on channels with very low data throughput like Music Choice. I'll be interested to know if anyone sees anything bad happen as a result. Bad in this case would mean crazy CPU usage or lots of recording errors. Don't let this scare you, the changes have been very stable for me for over a week.

I installed 0.4.24, but I couldn't get it to work at all. SageTV gave "no encoders were found that could tune this station" errors whenever I tried to tune a station (either Live TV or Recording). Since I have some key recordings coming up this evening, I uninstalled 0.4.24 and went back to 0.4.23 and it's working fine now.

I may give it another try if I get a block of time with no recordings coming up.

[EnterNoEscape]

Originally Posted by jgsouthard

I installed 0.4.24, but I couldn't get it to work at all. SageTV gave "no encoders were found that could tune this station" errors whenever I tried to tune a station (either Live TV or Recording). Since I have some key recordings coming up this evening, I uninstalled 0.4.24 and went back to 0.4.23 and it's working fine now.

I may give it another try if I get a block of time with no recordings coming up.

I saw that one before a month ago. It freaked me out because I was trying to figure out what I did that broke it. It turns out that if the encoder doesn't respond sometimes the SageTV client will keep showing that error until you reopen it. The client had actually persisted the error even after restarting the SageTV service. Reopening the client was what finally fixed it for me. I hope this helps.

[jgsouthard]

Originally Posted by EnterNoEscape

I saw that one before a month ago. It freaked me out because I was trying to figure out what I did that broke it. It turns out that if the encoder doesn't respond sometimes the SageTV client will keep showing that error until you reopen it. The client had actually persisted the error even after restarting the SageTV service. Reopening the client was what finally fixed it for me. I hope this helps.

I tried installing 0.4.24 again and got the same errors (SageTV lost the tuners), even though I took extra care to make sure that OpenDCT service was running before SageTV started up (and even rebooted and tried a second time).

That's when I checked the wrapper.log file a little more carefully and saw the intro section below just as wrapper was starting up, and it dawned on me what had happened. I accidentally downloaded the 64-bit version of OpenDCT instead of the 32-bit (x86) version.

Now all is well....

INFO   | jvm 1    | 2016/02/13 15:41:27.295 | Wrapper (Version 3.2.3) http://wrapper.tanukisoftware.org
INFO   | jvm 1    | 2016/02/13 15:41:27.295 |   Copyright 1999-2006 Tanuki Software, Inc.  All Rights Reserved.
INFO   | jvm 1    | 2016/02/13 15:41:27.295 | 
INFO   | jvm 1    | 2016/02/13 15:41:27.295 | 
INFO   | jvm 1    | 2016/02/13 15:41:27.295 | WARNING - Unable to load the Wrapper's native library 'wrapper.dll'.
INFO   | jvm 1    | 2016/02/13 15:41:27.295 |           The file is located on the path at the following location but
INFO   | jvm 1    | 2016/02/13 15:41:27.295 |           could not be loaded:
INFO   | jvm 1    | 2016/02/13 15:41:27.295 |             C:\Program Files\OpenDCT Authors\OpenDCT\jsw\.\lib\wrapper.dll
INFO   | jvm 1    | 2016/02/13 15:41:27.295 |           Please verify that the file is readable by the current user
INFO   | jvm 1    | 2016/02/13 15:41:27.295 |           and that the file has not been corrupted in any way.
INFO   | jvm 1    | 2016/02/13 15:41:27.295 |           One common cause of this problem is running a 32-bit version
INFO   | jvm 1    | 2016/02/13 15:41:27.295 |           of the Wrapper with a 64-bit version of Java, or vica versa.
INFO   | jvm 1    | 2016/02/13 15:41:27.295 |           This is a 32-bit JVM.
INFO   | jvm 1    | 2016/02/13 15:41:27.295 |           Reported cause:
INFO   | jvm 1    | 2016/02/13 15:41:27.295 |             C:\Program Files\OpenDCT Authors\OpenDCT\jsw\lib\wrapper.dll: Can't load AMD 64-bit .dll on a IA 32-bit platform
INFO   | jvm 1    | 2016/02/13 15:41:27.295 |           System signals will not be handled correctly.
INFO   | jvm 1    | 2016/02/13 15:41:27.295 | 
INFO   | jvm 1    | 2016/02/13 15:41:27.899 | 15:41:27.823 [WrapperSimpleAppMain] INFO  Main - Starting OpenDCT 0.4.24...
INFO   | jvm 1    | 2016/02/13 15:41:27.899 | 15:41:27.874 [WrapperSimpleAppMain] INFO  Main - OpenDCT logging to the directory 'c:/ProgramData/OpenDCT/logs'.
INFO   | jvm 1    | 2016/02/13 15:41:27.899 | 15:41:27.882 [WrapperSimpleAppMain] INFO  UpnpManager - Logging Cling UPnP to 'c:/ProgramData/OpenDCT/logs\opendct_cling.log'.
INFO   | jvm 1    | 2016/02/13 15:41:27.899 | 15:41:27.882 [FFmpegAsyncInit-19] INFO  Main - FFmpeg loading...

[EnterNoEscape]

That's good. I'm glad you figured that one out.

I have figured a few cool things out today and will be posting yet another release soonish. We will finally be able to do a proper channel scan that returns all tunable channels at least on newer HDHomeRun devices. I found a way to have HTTP support with RTP as a fallback for devices that actually support it. This will only apply to non-Prime devices on the first release. Using HTTP, people with the HDHomeRun Extend models can also do hardware transcoding by specifying a global parameter.

If anyone has an Extend that they use for OTA and want to test this, let me know.

[nyplayer]

I appear to have problems with some files that contain H.264 in TS not playing correctly breaking up. I have a log attached look at Beowulf recording.

[EnterNoEscape]

Interesting. I assume the file created doesn't play back in programs like VLC? There's only one thing OpenDCT will do that's not how FFmpeg typically does its remux processing. The program filters out what it determines are duplicate dts frames. Other than that, it's basically taking the frame in and writing the frame out. I have compiled a version without this optimization and will PM you shortly with a link.

[nyplayer]

I am having problems playing them in KODI and The SageTV Miniclient ... I get a lot of lil squares moving all over good sound but picture is unwatchable. I believe these use a form of ffmpeg.

[nyplayer]

Here is a picture of what it looks like using the mini Client this is using OpenDCT_0.4.25_x86. Also In Kodi any type of seeking the Picture freezes and the sound plays fine and sometimes I get the blocks in the image below.

[trk2]

Originally Posted by nyplayer

Here is a picture of what it looks like using the mini Client this is using OpenDCT_0.4.25_x86. Also In Kodi any type of seeking the Picture freezes and the sound plays fine and sometimes I get the blocks in the image below.

That must be the impressionist filter.

[nyplayer]

Originally Posted by trk2

That must be the impressionist filter.

LOL yeah that Comcast conversion to H.264 has me almost about to go to the basement and take a sledge hammer to my Sage Server.

[EnterNoEscape]

It would appear that Comcast is doing something strange because the DTS errors imply we are getting recent frames that are two frames behind what's expected. Any chance you can get me a raw 2-3 minute stream that should have this issue since it looks like it happens every 10-20 seconds? Also just to be clear, you have always had this issue with OpenDCT correct?

The easiest way to get two minutes of raw data will be to download a timed recording by opening the following link in a browser:

http://<prime_ip>:5004/auto/v794?duration=120

It will download for 2 minutes.

[nyplayer]

Originally Posted by EnterNoEscape

It would appear that Comcast is doing something strange because the DTS errors imply we are getting recent frames that are two frames behind what's expected. Any chance you can get me a raw 2-3 minute stream that should have this issue since it looks like it happens every 10-20 seconds? Also just to be clear, you have always had this issue with OpenDCT correct?

The easiest way to get two minutes of raw data will be to download a timed recording by opening the following link in a browser:

http://<prime_ip>:5004/auto/v794?duration=120

It will download for 2 minutes.

File is here.

http://71.193.161.66:9080/testfile/

v794.ts


Edit.

I Only had this issue when they started converting to H.264 ... Most of my recordings are OTA so I might have never noticed it before.

[EnterNoEscape]

Thanks. It might be several days to sort this one out, but I have a feeling it will be worth it for any others who might find themselves in a similar situation. ...so hang in there.

[nyplayer]

Originally Posted by EnterNoEscape

Thanks. It might be several days to sort this one out, but I have a feeling it will be worth it for any others who might find themselves in a similar situation. ...so hang in there.

Thanks no problem my PC Clients using Lav Filters can handle the files.

[gprichardson1]

Hi all,

My setup is Win 7, Sage 7.1.9, Java 1.7 and OpenDCT 0.3.16. I had installed OpenDCT last week (replacing SageDCT) and it was working great until last night. I had a halt detected error. I just tried to tune in the channel in question (809) a few minutes ago and I get a "No Signal".

I looked at the log file that was generated but I don't really know what I"m looking for. I've attached a zip file with the logs from yesterday (the show that didn't record was 2/17 @ 10pm).

Is there anything in them that stick out as a possible problem?

Thanks!

-Gary