SageTV Community
Page 23 of 35 « First 132122 23 242533 Last »
Show 40 post(s) from this thread on one page

SageTV Community (http://forums.sagetv.com/forums/index.php)
-   Hardware Support (http://forums.sagetv.com/forums/forumdisplay.php?f=9)
-   -   PrimeNetEncoder - HDHomeRun Prime Network Encoder (http://forums.sagetv.com/forums/showthread.php?t=62055)

jvl711 10-04-2015 06:46 PM
Quote:
Originally Posted by Eckwell (Post 578290)
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 10-04-2015 07:44 PM
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 10-04-2015 08:21 PM
Quote:
Originally Posted by kchase56 (Post 578326)
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 10-05-2015 01:25 AM
1 Attachment(s)
Here is the properties file.

Fuzzy 10-05-2015 02:47 AM
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:
Code:
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 10-05-2015 03:04 AM
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 10-05-2015 05:46 AM
Quote:
Originally Posted by Fuzzy (Post 578339)
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 10-05-2015 06:16 AM
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 10-05-2015 06:57 AM
Quote:
Originally Posted by jvl711 (Post 578341)
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 10-05-2015 08:45 AM
Quote:
Originally Posted by Fuzzy (Post 578338)
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:
Code:
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 10-05-2015 09:34 AM
Auto Start for PrimeNetEncoder?
 
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 10-05-2015 09:40 AM
Quote:
Originally Posted by Eckwell (Post 578356)
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 10-05-2015 10:02 AM
Quote:
Originally Posted by Fuzzy (Post 578349)
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:
Code:
HDHomeRun(UDP) -> PrimeNetEncoder(SDIN) -> ffmpeg(STDOUT) -> SageTV Media Server(TCP)
Code:
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:
Code:
HDHomeRun(UDP) -> PrimeNetEncoder(STDIN) -> ffmpeg(CIFS/SMB)
The extra piping seems costly.

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

jvl711 10-05-2015 10:03 AM
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 10-05-2015 10:19 AM
Quote:
Originally Posted by jvl711 (Post 578362)
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 10-05-2015 10:21 AM
Quote:
Originally Posted by Fuzzy (Post 578364)
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 10-05-2015 10:40 AM
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 10-05-2015 10:44 AM
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 10-05-2015 11:51 AM
Quote:
Originally Posted by Fuzzy (Post 578361)
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:
Code:
HDHomeRun(UDP) -> PrimeNetEncoder(SDIN) -> ffmpeg(STDOUT) -> SageTV Media Server(TCP)
Code:
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:
Code:
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 10-05-2015 11:56 AM
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.


All times are GMT -6. The time now is 07:35 PM.
Page 23 of 35 « First 132122 23 242533 Last »
Show 40 post(s) from this thread on one page

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2023, vBulletin Solutions Inc.
Copyright 2003-2005 SageTV, LLC. All rights reserved.