That was it.

As it turns out I copied the properties file to the Sage directory and then proceeded to edit the original file in my downloads folder... :blush:

Watching basketball tonight and so far the only glitches I've seen look like they are coming from the satellite truck broadcasting the game. That's a big improvement from what I had been seeing!

I did see some strange behaviour when I added the second and third tuners (channel tuning failure and pixelated video) but a full system restart (server, and Prime) cleared it up.

Thanks guys for all of your help, and thanks to jvl711 for building this encoder! It's nice to know I don't need to live in fear of my Prime no longer working due to a future incompatibility.

-uberpixel

Well, there is something nasty about my system. When I try to test out my setup by doing a 'java -jar PrimeNetEncoder.jar status', I get repeating this:

java.lang.NullPointerException
at jvl.primenetencoder.Tuner.run(Tuner.java:100)

Any clue what is the problem here?

C:\Sagetv\PrimeEncoder>java -version
java version "1.7.0_67"
Java(TM) SE Runtime Environment (build 1.7.0_67-b01)
Java HotSpot(TM) Client VM (build 24.65-b04, mixed mode, sharing)

C:\Sagetv\PrimeEncoder>

I know the tuner works because I was using the HDHomeRun VIEW program to watch a couple of channels.

Are you running a batch file if you are can you post it this is how I am running. I have everything in C:\PrimeNetEncoderv1.0.0

encoder.bat

Nope, no batch file. Just straight Command Line:

C:\Sagetv\PrimeEncoder>java -jar PrimeNetEncoder.jar status
PrimeNetEncoder>java.lang.NullPointerException
at jvl.primenetencoder.Tuner.run(Tuner.java:100)
java.lang.NullPointerException
at jvl.primenetencoder.Tuner.run(Tuner.java:100)
java.lang.NullPointerException
at jvl.primenetencoder.Tuner.run(Tuner.java:100)
java.lang.NullPointerException
at jvl.primenetencoder.Tuner.run(Tuner.java:100)
java.lang.NullPointerException
at jvl.primenetencoder.Tuner.run(Tuner.java:100)
java.lang.NullPointerException
at jvl.primenetencoder.Tuner.run(Tuner.java:100)
java.lang.NullPointerException
at jvl.primenetencoder.Tuner.run(Tuner.java:100)
java.lang.NullPointerException
at jvl.primenetencoder.Tuner.run(Tuner.java:100)
java.lang.NullPointerException
at jvl.primenetencoder.Tuner.run(Tuner.java:100)

Specifying the location of java didn't help either
C:\Sagetv\PrimeEncoder>"c:\Program Files\Java\jre7\bin"\java -version
java version "1.7.0_67"
Java(TM) SE Runtime Environment (build 1.7.0_67-b01)
Java HotSpot(TM) Client VM (build 24.65-b04, mixed mode, sharing)

C:\Sagetv\PrimeEncoder>

Why not just use a batch like the one I posted above I see your "c:\Program Files\Java\jre7\bin"\java -version
java version "1.7.0_67" is wrong quotes are around the directory not the full jave.exe.

you can just create the encoder.bat and drop it in the directory where you have the encoder properties jar and ffmpeg.

I copied your batch file that you posted above, modified the path for java (to remove the (x86) since I'm running 32 bit Win7) and used that. Same result...

You definitely have something wrong maybe you should just zip the whole folder. Could be the properties file.

Dropped you a private message.

Here is the correct batchfile. When you run it you can issue commands such as status etc. at the console window. Everything else is ok. Just replace the one you have.

put your runEncoder.bat file into my PrimeEncoder directory and ran it. Same stinking Exception. I'm thinking we're gonna need to look at that .java file to see where the exception is being thrown and what object is Null.

Thanks for your help so far, but bedtime for bonzo.... Have to pick this up again another evening....

You sure you don't already have 1 running check for a task java.exe
My System ran ok with your stuff must be your Java. Goodnight

04/07/2015 21:32:37 - Setting local IP address to: 192.168.0.104
04/07/2015 21:32:37 - Starting encoder thread: 131B4C09-0

04/07/2015 21:32:37 - Setting local IP address to: 192.168.0.104
04/07/2015 21:32:37 - Starting encoder thread: 131B4C09-1

04/07/2015 21:32:37 - Setting local IP address to: 192.168.0.104
04/07/2015 21:32:37 - Starting encoder thread: 131B4C09-2

Does this eliminate the delay between back to back recordings?

No not network encoder does. The only way to eliminate this is to have SageTV natively support Primes.

Just curious, but you lose the seamless recording transitions with this right?

Yes, there's no mechanism in the current network encoder system to handle directly transitioning a stream to a new file seamlessly. Might be something that could be improved once we're into the code, its just that no real work was done on the network encoder spec for a very long time before seamless recording came to be a thing. It should be noted, that there is NO implementation of the Prime (SageDCT or this) that support the seamless transitions, as both are network encoders.

That said, the HDHR starts and stops streams very quickly, such that it is not a very long gap.

I think that's in the "advanced" network encoder protocol that Sage uses when you setup an Encoding server, but was never documented for the "public" protocol.

Right but I dropped my cablecard and now I just use everything Clear QAM native in Sage, but as noted above, Sage doesn't have the best handling of transport streams, so I'm curious to try this out and see if it solves some of my issues. However the IRPStackSize tweak may have taken care of 90%+ of the errors I was seeing so my motiviation has dropped a bit.

If nothing else, by using this and passing the stream through ffmpeg, it fixes (at at least drops) bad packets in the steram. This can turn an unplayable stream into one that just has a bit of corruption here or there. Being able to record direct to H.264 has other great benefits.

I will say, that the network encoder interface is the first thing I plan on looking at when we get into this thing, hopefully some of the features are there that we need to improve the system and it will just take some documentation to expand those features to these 3rd party encoders. If not, I guess I'll be adding some features as well... I had, early on, talked about wanting to roll this solution (the Prime encoder) into Sage, but I am thinking more and more that a more modular support, where nearly all future encoders are network based, will be more versatile and robust going forward - but the API would have to add in some things like scanning and/or retrieving channels lists and such.

Well... Not sure if it's related to this new encoder but I've started experiencing occasional tuner issues like "Halt Detected" and "Recording Missed Due to Conflict". Worse yet I've seen a few lock-ups and reboots on my server. I'm running a few other things on the server (Blue Iris as well as serving files) so it's possible that the reboots aren't related to Sage.

With the Halt's it typically drops around 5 minutes of the program and then picks it back up again and continues on.

For the tuner conflict, in some cases, it's the only program being recorded so I know I don't have any schedule conflict. I suspect the tuner is dropping out entirely and Sage reports a conflict.

Anyone else seeing this behavior with the new encoder?

-uberpixel

Mine has been rock solid since the beginning no problems at all.

The halt detected I was getting a lot of. I reinstalled sage and that seemed to fix the problem I have only had three halt detected since then. Two of them ere back to back recordings and required a reboot of the prime so that one I don't think was the encoder problem. Maybe try a reinstall of sage not the whole server, if you can find the time to do it.