I hate to pile on with problems, but I just upgraded to 1.2.5 and I've run into a couple of issues.

First, when I go to add source in SageTV Setup it lists the Prime Tuners with the appropriate tuner names and another set of Prime tuners with FFFFFFFF names. I can add the appropriately named tuners and view the signal fine, just can't figure out why I'm getting the FFFFFFFF tuners as well. Has anyone else seen this? Is it another Gemstone anomaly? I can post my properties files if necessary.

Also, after an hour or so of running tonight I started noticing some artifacts while watching Gold Rush and then noticed a halt on one of the other tuners. Gold rush is set to record until 11:00 plus 5 minutes extra padding, but it only recorded to 11:00. Then near 11:05 is when the NBA game on the other channel halted. See the attached logs. Looks like it fails just after confirming tuner lock.

Any ideas? Maybe this is just what I should expect for recording pre-season NBA basketball. :D

-uberpixel

You guys having all these problems need to post more than what you are posting like the primenetencoder properties and the sage properties ... just posting the logs is just not enough or a snippet of the error is just not enough.

Also post the batch file you are running with as there were some parameters that JVL added to the batch file.

these are the parameters.

java -XX:-UseBiasedLocking -XX:NewSize=50M -Xms128m -Xmx256m -jar PrimeNetEncoder.jar

Sample batch file.

Here is a my properties that works. I let Sage auto discover the tuners so there is no mistakes made. Make sure this property is set to true. In sage.properties.
network_encoder_discovery=true

When setting up tuners make sure PrimeNetEncoder is running before you start sage.

Do we need to run the batch file deliberately or is it run automatically without additional input?

I cleared up the FFFFFFFF tuners. I accidentally ran PrimeNetEncoder from a different PC while I was remoting into my Server. :blush: With fresh eyes this morning I noticed that the IP address was different on these FFFFFFFF tuners as compared to the machine that's supposed to be associated with them and a quick check told me which PC on my network they were coming from. A restart of the offending PC and then the server that's supposed to be running PrimeNetEncoder cleared that up.

I've also power cycled the HDHR Prime and so far so good.

Hopefully my halt issues were tied to this Tuner/PC confusion... I'm running a test with every tuner recording to stress test the system. I'll report back with my results and I'll make sure to post my properties if I continue to have issues. :)

-uberpixel

You need to run the batch file with the new parameters to avoid artifacts.

Okay, do I need to run it just once after initially installing or does it need to run at startup every time I reboot, or every time I view a recording, or...?

I think there's an assumed level of competency for a lot of this set up that I unfortunately do not possess.

If it's every reboot should I just add it to scheduled tasks like the batch file that starts the .JAR or does this replace the previous batch file? Otherwise what triggers it to run?

Thanks for your help!

-uberpixel

You need to add the parameters to your existing batch file that you now run at startup.

Well, went back through the thread, and noted others talking about SageDCT and realized that I hadn't disabled the SageDCT service. So, I stopped the SageDCT service and set it to start manually. Hopefully that was my conflict.

Yeah that would do it If you are not running SAGEDCT at all it is best to disable it.

Got it.

Back up and running with your sample batch file. So far so good!

-uberpixel

Hi... I recently moved my Sage server system to a different (more powerful) server. It runs as a VMWare guest, so I didn't have to make configuration changes in the system or reinstall anything.

I am now seeing stuttering during recording, even though I have the guest set to operate with maximum disk priority. The recordings are all to a ZFS based NAS system that I can easily get full gigabit linerate writes to.

I made the mistake of upgrading to the latest RC1 of 1.2.5 before bringing the system back with 1.0.1 which is what I was running before. I was wondering what exactly the parameters on the batch file for this new image mean, so I could help understand where the issue is. This corruption usually means the system isn't processing things and writing to the disk at fast enough rates, so I am trying to figure out where the bottleneck is.

Thanks!
Mike

To be clear, are you using the new java parameters in the batch file?

Yes. Cut and paste from your earlier post. What do those parameters mean?

Any ideas as to what could be the issue?

Thx
Mike

I also recently upgraded to 1.2.5. Definitely some challenges getting it running with the task scheduler but have it all working now. Needed to get all the service timings correct on startup.

I see some artifacts when initially tuning channels. Those go away quickly and it seems stable. This is true for all channels except for our CBSHD. It has severe pixelation and is basically unwatchable. OTA for that channel is a little difficult to get consistently so that is why we use the prime for it.

I am running the encoder with the supplied bat file. Would love some ideas or tips on what those parameters do so I can dial this in even better.

what if we're using PrimeNetEncoder as a runnable class from within SageTV? can we change the parameters for that method somehow? (I'm seeing artifacts from time to time as it is).

I don't believe that's a realistic option with 1.2.5. Due to the changes in how it pipes the data around, it needs to run in it's own process to get the right memory management environment to avoid losing data.

Well I think I've solved my pixelation issues. Upgraded my UnRaid to the latest and converted my W7 VM from Xen to KVM and everything is working great. Must have been some sort of networking issue with the XEN network adapter drivers.

I would occasionally get halts and CBS was severe pixelation. Now everything seems rock solid.

cool. I'll just change it to stand alone later today.

Been running for a few days now with 1.2.5 in standalone mode. THings look like they are much cleaner. Except for this:

10/19/2015 19:33:05 - -------------------------------------------------------------------------------
10/19/2015 19:33:05 - Switching Channel for Tuner: 131B4C09 0
10/19/2015 19:33:05 - -------------------------------------------------------------------------------
10/19/2015 19:33:05 - Channel: 711
10/19/2015 19:33:05 - File: LifeinPieces-S01E05-BabeSecretPhoneGerms-22964335-1.ts
10/19/2015 19:33:05 - UploadID: 933124796
10/19/2015 19:33:05 - Quality: Great
10/19/2015 19:33:05 - Local IP: 192.168.0.10
10/19/2015 19:33:05 - Listening Port: 7000
10/19/2015 19:33:05 - Stream listening Port: 5000
10/19/2015 19:33:05 - Checking to see if the tuner is locked.
10/19/2015 19:33:05 - Switch channel: 711
10/19/2015 19:33:05 - Using Lockkey: 782463775
10/19/2015 19:33:05 - Command output: null
10/19/2015 19:33:05 - Send stream to UDP port: 5000
10/19/2015 19:33:05 - Using Lockkey: 782463775
10/19/2015 19:33:05 - Command output: null
10/19/2015 19:33:05 - Passing stream to SageTV unaltered (ffmpeg stream copy)
10/19/2015 19:33:05 - Starting TunerOutput thread for stdin to ffmpeg then stdout to SageTV MediaServer
10/19/2015 19:33:05 - Tuner output thread constructed for UploadID: 933124796
10/19/2015 19:33:05 - Tuner output thread HDHomeRun(UDP) -> PrimeNetEncoder(SDIN) -> ffmpeg(STDOUT) -> SageTV Media Server(TCP)
10/19/2015 19:33:05 - Sleeping to allow ffmpeg to fully launch: 1000
10/19/2015 19:33:05 - TunerBridge thread started udpPort: 5000
10/19/2015 19:33:05 - Tuner bridge has transfered: 0
10/19/2015 19:33:05 - Sending write open command
10/19/2015 19:33:05 - Write open sent successfully
10/19/2015 19:33:05 - Tuner bridge has transfered: 0
10/19/2015 19:33:06 - Tuner bridge has transfered: 3000
10/19/2015 19:33:06 - Tuner bridge has transfered: 10500
10/19/2015 19:33:06 - Tuner bridge has transfered: 18000
10/19/2015 19:33:06 - Tuner bridge has transfered: 24000
10/19/2015 19:33:07 - Tuner bridge has transfered: 31500
10/19/2015 19:33:07 - Tuner bridge has transfered: 39000
10/19/2015 19:33:07 - Tuner bridge has transfered: 46500
10/19/2015 19:33:07 - Tuner bridge has transfered: 54000
10/19/2015 19:33:08 - Tuner bridge has transfered: 61500
10/19/2015 19:33:08 - Tuner bridge has transfered: 69000
10/19/2015 19:33:08 - Tuner bridge has transfered: 76500
10/19/2015 19:33:08 - Tuner bridge has transfered: 84000
10/19/2015 19:33:09 - Tuner bridge has transfered: 91500
10/19/2015 19:33:09 - Tuner bridge has transfered: 99000
10/19/2015 19:33:09 - Tuner bridge has transfered: 106500
10/19/2015 19:33:09 - Tuner bridge has transfered: 114000
10/19/2015 19:33:10 - Tuner bridge has transfered: 120000
10/19/2015 19:33:10 - Tuner bridge has transfered: 127500
10/19/2015 19:33:10 - Tuner bridge has transfered: 135000
10/19/2015 19:33:10 - No data transfered in 6000ms. Reseting tuner channel and stream.
10/19/2015 19:33:10 - Switch channel: 711
10/19/2015 19:33:10 - Using Lockkey: 782463775
10/19/2015 19:33:10 - Command output: null
10/19/2015 19:33:10 - Send stream to UDP port: 5000
10/19/2015 19:33:10 - Using Lockkey: 782463775
10/19/2015 19:33:10 - Command output: null
10/19/2015 19:33:10 - Tuner bridge has transfered: 622472
10/19/2015 19:33:11 - Tuner bridge has transfered: 1044908
10/19/2015 19:33:11 - Tuner bridge has transfered: 1531828

The recording that was created wasn't playable on my HD300. Anyway, just curious as to what kind of things might cause the output to stop in the middle of a recording (ok, it was at the beginning, but it was during a successful transfer), so I can see what I need to check my system for.

Thanks,

Batch file to start PrimeNetEncoder:
java -XX:-UseBiasedLocking -XX:NewSize=50M -Xms128m -Xmx256m -jar PrimeNetEncoder.jar

PrimeNetEncoder.properties:
$ cat PrimeNetEncoder.properties

ffmpeg.delay=1000
ffmpeg.probesize=5000000
ffmpeg.analyzeduration=5000000
ffmpeg.path=c:\sagetv\sagetv\ffmpeg.exe
#HDHomeRunConfig.path="C\:\\Program Files\\Silicondust\\HDHomeRun\\hdhomerun_config.exe"
HDHomeRunConfig.path=C:\Program Files\Silicondust\HDHomeRun\hdhomerun_config.exe

tuners.count=3
discovery.port=8271
discovery.enabled=true
mediaserver.transfer=true
ffmpeg.outputbuffersize=32768
ffmpeg.inputbuffersize=32768
mediaserver.outputbuffersize=32768
tuner0.name=PrimeNetEncoder 131B4C09-0
tuner0.id=131B4C09

tuner0.number=0
tuner0.port=7000
tuner0.transcoder.port=5000
tuner0.enabled=true
tuner0.transcode.enabled=false
tuner0.transcode.deinterlace=true
tuner0.transcode.bitrate=4000
tuner0.transcode.scaling=
tuner0.transcode.preset=veryfast
tuner0.transcode.codec=libx264
tuner1.name=PrimeNetEncoder 131B4C09-1
tuner1.id=131B4C09

tuner1.number=1
tuner1.port=7001
tuner1.transcoder.port=5010
tuner1.enabled=true
tuner1.transcode.enabled=false
tuner1.transcode.deinterlace=true
tuner1.transcode.bitrate=4000
tuner1.transcode.scaling=
tuner1.transcode.preset=veryfast
tuner1.transcode.codec=libx264
tuner2.name=PrimeNetEncoder 131B4C09-2
tuner2.id=131B4C09

tuner2.number=2
tuner2.port=7002
tuner2.transcoder.port=5020
tuner2.enabled=true
tuner2.transcode.enabled=false
tuner2.transcode.deinterlace=true
tuner2.transcode.bitrate=4000
tuner2.transcode.scaling=
tuner2.transcode.preset=veryfast
tuner2.transcode.codec=libx264

I think, but I am not sure that this is one of two potential issues.

1. The program has the copy protection enabled, and ffmpeg is unable to process the stream. Hence the no data transferred. I know that this is how the log looks when this happens. I have tuned to an copy protected channel and viewed the log.

2. ffmpeg has crashed, or did open properly. I do not believe my resetting the tuner would help.


P.S.

I think you can safely change the following settings. I think you will like the channel change speedup.

ffmpeg.delay=0
ffmpeg.probesize=2500000
ffmpeg.analyzeduration=2500000

It's most likely a copy protection issue. Speaking of which, I'm thinking it would probably be worth it on stream start (or restart) to read the status and vstatus of the tuner and write it out to the debug log. This would show right away whether it's a flagging issue or not.