PrimeNetEncoder - HDHomeRun Prime Network Encoder

[jvl711]

Originally Posted by Eckwell

I have read through what feels like everything... When i run the Jar file I get the following in the .txt log file:

10/04/2015 10:11:44 - Running PrimeNetEncoder in Console Mode
10/04/2015 10:11:44 - PrimeNetEncoder Version: 1.2.4
10/04/2015 10:11:44 - Starting tunner threads
10/04/2015 10:11:44 - Starting Debug Console
10/04/2015 10:11:44 - Unexpected error reading from the console. The handle is invalid
10/04/2015 10:11:44 - Unexpected error reading from the console. The handle is invalid
10/04/2015 10:11:44 - Unexpected error reading from the console. The handle is invalid

I can't seem to get past this. My remaining thought is that i am running Java 8 and maybe that is the issue?

My PrimeNetEncoder folder is in my main SAGE folder on the server... i am running 64-bit Windows 7. FFMpeg is 64-bit and is placed in the PrimeNetEncoder folder (just the single file)

attached are my files if anyone can please take a look. I have not even gotten to the point where i start sage... i am just trying to get the .txt file from growing exponentially with this error first!

How exactly are you launching the application? It is throwing an error that it can not read from the console. If you are not launching from a console can you please try that.

FYI... I have not tested this with Java 1.8. It might work fine, but I do not know.

[kchase56]

Hi jvl711,

I'm getting the following problem using version 1.2.4 of PrimeNetEncoder when trying to access any of the tuners on my 2nd HDHomerun Prime =>

10/04/2015 19:00:13 - Checking to see if the tuner is locked.
10/04/2015 19:00:13 - Tuner is locked. Force unlocking the tuner.
10/04/2015 19:00:13 - Switch channel: 1027
10/04/2015 19:00:13 - Using Lockkey: 1627678092
10/04/2015 19:00:13 - Command output: ERROR: unknown getset variable
10/04/2015 19:00:13 - Send stream to UDP port: 5003
10/04/2015 19:00:13 - Using Lockkey: 1627678092
10/04/2015 19:00:13 - Command output: ERROR: unknown getset variable

All of the tuners on the first tuner work just fine. What would cause the tuner to report as being locked? Also what is the "ERROR: unknown getset"?

Any information that you could provide regarding this problem would be greatly appreciated.

Thanks for all of your hard work on this driver.

[Fuzzy]

Originally Posted by kchase56

Hi jvl711,

I'm getting the following problem using version 1.2.4 of PrimeNetEncoder when trying to access any of the tuners on my 2nd HDHomerun Prime =>

10/04/2015 19:00:13 - Checking to see if the tuner is locked.
10/04/2015 19:00:13 - Tuner is locked. Force unlocking the tuner.
10/04/2015 19:00:13 - Switch channel: 1027
10/04/2015 19:00:13 - Using Lockkey: 1627678092
10/04/2015 19:00:13 - Command output: ERROR: unknown getset variable
10/04/2015 19:00:13 - Send stream to UDP port: 5003
10/04/2015 19:00:13 - Using Lockkey: 1627678092
10/04/2015 19:00:13 - Command output: ERROR: unknown getset variable

All of the tuners on the first tuner work just fine. What would cause the tuner to report as being locked? Also what is the "ERROR: unknown getset"?

Any information that you could provide regarding this problem would be greatly appreciated.

Thanks for all of your hard work on this driver.

Post up your PrineNetEncoder.properties file

[kchase56]

Here is the properties file.

[Fuzzy]

The problem is your tuner3.number entries (and 4 and 5).

PrimeNetEncoder uses the .id and the .number properties to determine how to locate and interact with a given tuner. What you are doing is telling it that tuner3.id and tuner3.number point to tuner #3 on the device with id 1311C562. There is not tuner 3 on that device, as it only has 0, 1, and 2.

you need the entries to read as follows:

tuner0.id=131142D4
tuner0.number=0
tuner1.id=131142D4
tuner1.number=1
tuner2.id=131142D4
tuner2.number=2
tuner3.id=1311C562
tuner3.number=0
tuner4.id=1311C562
tuner4.number=1
tuner5.id=1311C562
tuner5.number=2

Hope that makes sense.

[Fuzzy]

Finally got around to setting up 1.2.4 yesterday, and today I've noticed a marked increase in stream glitches in all recordings since the change. Have to think it's related, as I've always had pretty good signal quality. Before I roll back, any recommendations on some buffering tweaks to hopefully not lose any bits through the process?

[jvl711]

Originally Posted by Fuzzy

Finally got around to setting up 1.2.4 yesterday, and today I've noticed a marked increase in stream glitches in all recordings since the change. Have to think it's related, as I've always had pretty good signal quality. Before I roll back, any recommendations on some buffering tweaks to hopefully not lose any bits through the process?

I gave nyplayer a one off that had some buffer changes. I have been testing that internally for a while. It seems to be pretty stable. I am going to pull the trigger and release it hopefully today. I hope that will fix your issues.

[Eckwell]

nyplayer - your suggestion of using the batch file, and pointing to the Java 8 Java.exe location in the file worked! the console came up without any complaint, I was able to see and set-up all three tuners in SageTV and things seem to be working fine now.

Thank you Very much for your suggestion!

I am seeing some video glitches which seem to also have been noticed others... Testing continues, but THANK YOU!

[Fuzzy]

Originally Posted by jvl711

I gave nyplayer a one off that had some buffer changes. I have been testing that internally for a while. It seems to be pretty stable. I am going to pull the trigger and release it hopefully today. I hope that will fix your issues.

In the mean time, I am planning on disabling the mediaserver push on it this morning - since it's on my server, it's not really necessary - hopefully it will narrow down where the stream is getting dropped.

[kchase56]

Originally Posted by Fuzzy

The problem is your tuner3.number entries (and 4 and 5).

PrimeNetEncoder uses the .id and the .number properties to determine how to locate and interact with a given tuner. What you are doing is telling it that tuner3.id and tuner3.number point to tuner #3 on the device with id 1311C562. There is not tuner 3 on that device, as it only has 0, 1, and 2.

you need the entries to read as follows:

tuner0.id=131142D4
tuner0.number=0
tuner1.id=131142D4
tuner1.number=1
tuner2.id=131142D4
tuner2.number=2
tuner3.id=1311C562
tuner3.number=0
tuner4.id=1311C562
tuner4.number=1
tuner5.id=1311C562
tuner5.number=2

Hope that makes sense.

That worked perfectly!

Thanks Fuzzy!

[Eckwell]

How are folks running this? Batch file at start up?

And what about timing and not wanting to have more than one running, etc.

What is "best practice" at this point?

thanks again.

[nyplayer]

Originally Posted by Eckwell

How are folks running this? Batch file at start up?

And what about timing and not wanting to have more than one running, etc.

What is "best practice" at this point?

thanks again.

I schedule it through windows task scheduler... to run at Startup with highest privileges... whether I am logged on or not.. also hidden... also I disable the option that says stop this tasks if it is running more than 3 days.

You also have to export it and change the priority from 7 to 4 then delete from task scheduler and re-import it. Windows by default starts every task with priority of 7 that is below normal.
This thread explains priority.
http://forums.sagetv.com/forums/show...2&postcount=55

I chose not to run it as a runnable task because it uses SageTV Java heap.

[Fuzzy]

Originally Posted by Fuzzy

In the mean time, I am planning on disabling the mediaserver push on it this morning - since it's on my server, it's not really necessary - hopefully it will narrow down where the stream is getting dropped.

Well, I switched to direct file writing instead of the MediaServer push, but it looks like this doens't change the process much.
With the MediaServer enabled:

HDHomeRun(UDP) -> PrimeNetEncoder(SDIN) -> ffmpeg(STDOUT) -> SageTV Media Server(TCP)

HDHomeRun(UDP) -> PrimeNetEncoder(STDIN) -> ffmpeg(STDOUT) -> PrimeNetEncoder -> File(CIFS/SMB)

Where I had hoped that if the mediaserver was disabled, it would simply have ffmpeg write the file directly, as such:

HDHomeRun(UDP) -> PrimeNetEncoder(STDIN) -> ffmpeg(CIFS/SMB)

The extra piping seems costly.

In any case, the data is still getting damaged somewhere.

[jvl711]

Hi,

Released RC1 of PrimeNetEncoder. Please provide feedback positive or negative. I would like to release a stable version and I want to make sure there is as little issues as possible.

Josh

[Fuzzy]

Originally Posted by jvl711

Hi,

Released RC1 of PrimeNetEncoder. Please provide feedback positive or negative. I would like to release a stable version and I want to make sure there is as little issues as possible.

Josh

Well, I dropped in the 1.2.5, started it up, and had similar results. I then added the java parameters you put in the batch file and it seems markedly better. not sure which parameter makes the biggest fix, but it is recording great right now (on the first stream I tried). I'll load it up here for a bit and see if it keeps up.

[nyplayer]

Originally Posted by Fuzzy

Well, I dropped in the 1.2.5, started it up, and had similar results. I then added the java parameters you put in the batch file and it seems markedly better. not sure which parameter makes the biggest fix, but it is recording great right now (on the first stream I tried). I'll load it up here for a bit and see if it keeps up.

I too have it running with the Java parameters appears fine so far.

[jvl711]

Fuzzy and nyplayer,

Thanks for the quick responses. I decided on those parameters after a large amount of tracing of what the JVM was doing while running my app. That has been mainly what I was looking at over the past few weeks. I think it is really running well with these parameters. Garabage collection is very low, which is going to reduce the number of pauses.

Let me know if you guys think I should make those parameters part of a normal PrimeNetEncoder install?

Josh

[Fuzzy]

Well, i put all 3 on high bitrate local channels, and along with comskipping and plex transcoding to max the cpu, they seem to be playing back flawlessly. (I went back to using the MediaServer method).

This is using your java parameters in the batch file (actually inserted into my .cmd file that handles setting the current directory and points to the specific java.exe directly), launched as a high privilege service at priority 4.

[jvl711]

Originally Posted by Fuzzy

Well, I switched to direct file writing instead of the MediaServer push, but it looks like this doens't change the process much.
With the MediaServer enabled:

HDHomeRun(UDP) -> PrimeNetEncoder(SDIN) -> ffmpeg(STDOUT) -> SageTV Media Server(TCP)

HDHomeRun(UDP) -> PrimeNetEncoder(STDIN) -> ffmpeg(STDOUT) -> PrimeNetEncoder -> File(CIFS/SMB)

Where I had hoped that if the mediaserver was disabled, it would simply have ffmpeg write the file directly, as such:

HDHomeRun(UDP) -> PrimeNetEncoder(STDIN) -> ffmpeg(CIFS/SMB)

The extra piping seems costly.

In any case, the data is still getting damaged somewhere.

Fuzzy,

You are correct. The new methodology is a little more costly, but I think the benefits out way the extra processing. Below are the reasons for the changes.

1. I hope to move the remuxing to Sage in the future. Doing so requires reading from the HDHomeRun directly, so that I can pass the stream unaltered to the MediaServer.

2. Reading the stream directly from the HDHomeRun allows me to monitor the data being generated from the HDHomeRun. I have on occasion seen the HDHomeRun not properly respond to request. If I see that data is not being sent I can quickly reset the tuner without disrupting any other part of the streaming process.

Josh

[Fuzzy]

I wasn't really discussing the UDP from the HDHR to PNE, or even the STDIN pipe into ffmpeg. I was discussing the unneeded step of having ffmpeg pipe back to PNE, for it just to write to a file. I understand the need if using the MediaServer to bring it back to PNE, since ffmpeg doesn't know about sage MediaServer protocols. I was just expecting it to skip that step and just pass an output filepath to ffmpeg if MediaServer is disabled.