PrimeNetEncoder - HDHomeRun Prime Network Encoder

[rlvogel322]

I see few halt detected every day. I'm running in a W7 vm on unRAID 6. I'm doing a few things to get unRAID more stable (converting to xfs from rfs) so I am hoping it clears the halts up.

[nyplayer]

Are you all on the latest Prime firmware there have been a lot of fixes and improvements? I always keep my system up to date especially firmware upgrades. The only thing i haven't upgraded on my server is Java 7 32 bit.(only Because Sage)

[uberpixel]

Originally Posted by nyplayer

Are you all on the latest Prime firmware there have been a lot of fixes and improvements? I always keep my system up to date especially firmware upgrades. The only thing i haven't upgraded on my server is Java 7 32 bit.(only Because Sage)

Well I was going to say that I was running the latest "Production" firmware 20141210 but I just went to the download site and noticed they posted "Production" firmware 20150406 just last week days after I installed the new encoder. I was reluctant to try the beta firmware options not knowing what specific version you guys were using.

I'll upgrade to the 20150406 tonight and see if it helps.

What version are you running?

-uberpixel

[nyplayer]

Originally Posted by uberpixel

Well I was going to say that I was running the latest "Production" firmware 20141210 but I just went to the download site and noticed they posted "Production" firmware 20150406 just last week days after I installed the new encoder. I was reluctant to try the beta firmware options not knowing what specific version you guys were using.

I'll upgrade to the 20150406 tonight and see if it helps.

What version are you running?

-uberpixel

hdhomerun_windows_20150410beta2

[jvl711]

For the users having halts detected, are you running PrimeNetEncoder from the command line or from Sage. If it is being run from inside of Sage it might be worth trying it from the command line.

If you have any scenarios or logs that might help me look into the issue that would be helpful. I might need to add a configurable delay for how long to wait for ffmpeg to launch fully. When the halt is detected I think I am sending the stream to ffmpeg prior to it listening for the connection. As far as I can tell there is no way for me to know when ffmpeg is ready to accept the stream.

Josh

P.S. It has been really stable on my system, but I did however program it for my system

[nyplayer]

Originally Posted by jvl711

For the users having halts detected, are you running PrimeNetEncoder from the command line or from Sage. If it is being run from inside of Sage it might be worth trying it from the command line.

If you have any scenarios or logs that might help me look into the issue that would be helpful. I might need to add a configurable delay for how long to wait for ffmpeg to launch fully. When the halt is detected I think I am sending the stream to ffmpeg prior to it listening for the connection. As far as I can tell there is no way for me to know when ffmpeg is ready to accept the stream.

Josh

P.S. It has been really stable on my system, but I did however program it for my system

I run it from the command line and have had no problems.

[Fuzzy]

I don't usually have a user logged in on my sage server, so I can't really run the console version, so running it within the sage service is my only real option. That said, I haven't had any problems so far (except when I tried the transcoding without the horsepower to do it).

[uberpixel]

I just upgraded to the latest beta firmware.

I'm running from within Sage.

I'll stick with changing only one variable for now to see if there is any improvement. I'll let it run for a few days.

The capture issues I've seen appear fairly random. Most are at the start of a program and others happen part way through. Sage typically recovers quickly and the recording continues.

-uberpixel

[uberpixel]

Well that didn't take long. Had another halt tonight.

Tell me more about running this outside of sage. Is it a service I need to restart every time I reboot? I'm not programming friendly so any implied steps or assumptions surrounding some operations are easily lost on me.

What logs could I produce and how would I go about producing them to help you debug?

-uberpixel

[rlvogel322]

I'm running mine within the sage service. I'll look into the command line option .

[jvl711]

Originally Posted by uberpixel

Well that didn't take long. Had another halt tonight.

Tell me more about running this outside of sage. Is it a service I need to restart every time I reboot? I'm not programming friendly so any implied steps or assumptions surrounding some operations are easily lost on me.

What logs could I produce and how would I go about producing them to help you debug?

-uberpixel

Before you run in command line mode wait for the next beta release I am going to put out in the next few days. I think increasing the delay to wait for FFMPEG to fully start might help you. I added a new property item for this. its default is 500 ms. I think increasing to 1000 ms might fix the issue.

In the mean time if you can send me the following logs and config files from the sagetv directory. (tuner0.log, tuner1.log, tuner2.log, primenetencoder.log and primenetencoder.properties)

Josh

[jvl711]

Originally Posted by rlvogel322

I'm running mine within the sage service. I'll look into the command line option .

Are you seeing the same issue. Halt detected when starting a recording? If so I would also like you to try the next beta, and to change the ffmpeg delay setting.

Josh

[mechling-burgh]

How fast is your server for the guys not getting halts. I'm wondering if ffmpeg is taking longer to start on slower machines. I know the reinstall of sage helped but I still have one now and then. My server is a old core 2 duo e8400 so that could be my problem. I'm will to try or next beta to see if that fixes the problem.

[nyplayer]

Originally Posted by mechling-burgh

How fast is your server for the guys not getting halts. I'm wondering if ffmpeg is taking longer to start on slower machines. I know the reinstall of sage helped but I still have one now and then. My server is a old core 2 duo e8400 so that could be my problem. I'm will to try or next beta to see if that fixes the problem.

Intel I3 with windows 7.

[jvl711]

New beta posted...

Guys that were seeing the halt detected occasionally please add the new property "ffmpeg.delay=500". Change the value from 500 to 1000. Let me know if this reduces the issue. This value controls how long PrimeNetEncoder waits after starting ffmpeg before sending the stream to it.

nyplayer,

I added the scaling and codec for you. You should be able to use that experimental build of ffmpeg, and change the coded to the proper codec for hardware encoding. There was a different codec for the intel and nvidia techology. I did not have either of those, so I was not able to test that. I did test the scaling, and it seemed to work well.

Let me know if you guys see any issues.

Josh

[KryptoNyte]

The halts sound similar to some of the issues that I was having the Prime and SageDCT:

http://forums.sagetv.com/forums/show...ust#post567064

I got so frustrated with it that I would bring up the tuner status screen for all 6 tuners (2 primes) and downloaded a program that would take a screenshot every second and then coordinate the halted recordings with the screenshots to try and determine if it was a signal problem and/or a problem with the Prime and not Sage.

At this point, the halts that occur are doing so about once every two weeks, and a reboot of the computer and the Primes seems to resolve it. Research has indicated that I am usually losing one Prime (so 3 of the 6 tuners) and that's when the halts begin, with the reboot resolving.

[KryptoNyte]

SageDCT allows for the "dump" method, which basically just brings in the original digital stream and saves it to the hard drive. Sage has problems rendering some of these streams, yet VLC can render them fine.

It seems that the current solution is to use ffmpeg to solve Sage's inability to render. As Sage goes open source, would it be possible to solve Sage's problem with rendering the video, and ditch ffmpeg entirely and just bring down the original stream?

[nyplayer]

Originally Posted by jvl711

New beta posted...

Guys that were seeing the halt detected occasionally please add the new property "ffmpeg.delay=500". Change the value from 500 to 1000. Let me know if this reduces the issue. This value controls how long PrimeNetEncoder waits after starting ffmpeg before sending the stream to it.

nyplayer,

I added the scaling and codec for you. You should be able to use that experimental build of ffmpeg, and change the coded to the proper codec for hardware encoding. There was a different codec for the intel and nvidia techology. I did not have either of those, so I was not able to test that. I did test the scaling, and it seemed to work well.

Let me know if you guys see any issues.

Josh

Scaling works great ... hardware encoding not so much got no signal. I will do some offline testing of ffmpeg with hardware encoding to see if I can get a commandline to work. Other than that everything works fine with this beta. I even scaled down to 320x240 just to see. and it worked.

[uberpixel]

Originally Posted by jvl711

New beta posted...

Guys that were seeing the halt detected occasionally please add the new property "ffmpeg.delay=500". Change the value from 500 to 1000. Let me know if this reduces the issue. This value controls how long PrimeNetEncoder waits after starting ffmpeg before sending the stream to it.

Let me know if you guys see any issues.

Josh

Do we need the new .jar too or can I just add the new property with the old .jar? I ask because I tried the new beta .jar with both the old and new properties files and it broke my tuner setup. I updated the tuner ID in the new properties file... Sage said it wasn't able to encode or something. Do I need to remove and add the tuners with the new beta .jar?

-uberpixel

[nyplayer]

Originally Posted by uberpixel

Do we need the new .jar too or can I just add the new property with the old .jar? I ask because I tried the new beta .jar with both the old and new properties files and it broke my tuner setup. I updated the tuner ID in the new properties file... Sage said it wasn't able to encode or something. Do I need to remove and add the tuners with the new beta .jar?

-uberpixel

The tuners in Sage stay the same you just have to update the new properties file with tuner ids and tuner names from your old property file...copy over ffmpeg and use the new jar.