HD-PVR lockup related to Java heap size?

[troll5501]

I'm a new HD-PVR user, and it's been working fine until last night when I powered up an extra media extender. When the main menu came up, I noticed that the red light went out on my HD-PVR which was busy recording a show.

The debug log showed "SEEKER HAS DETECTED A HALT IN THE ENCODER...TRYING TO RESET IT". I power cycled the HD-PVR and in a few minutes Sage restarted the recording and the red light was back on.

Today I've gotten it to happen a few more times, sometimes while booting an extender, browsing menus, or while watching an SD channel while the HD-PVR is recording something else. And I'm thinking it's related to memory in the JVM.

Each time the HD-PVR stopped during a recording, I noticed a slight hiccup on the extender's Sage interface at the same time and according to the debug logs, the Java memory was nearly at the limit and a moment later it freed up several hundred MB. So the hiccup was probably the JVM garbage collector cleaning up.

So could it be as simple as adding more memory to the JVM? I still want to do more testing on this, but it seems like the HD-PVR is overly sensitive to the low memory situation, and when it happens I have to power off and on the HD-PVR to get it back. The JVM cleanup process doesn't interrupt or hang any of my PVR-500 recorders.

Has anyone else correlated HD-PVR lockups to JVM memory usage? I haven't seen anything like that in this forum. Would this be a Sage or a Hauppauge driver problem?

My setup: Sage 6.6.2.218, WinXP, HD-PVR D2 w/1.5.6 drivers, Java 1.6.0_16

[HelenWeathers]

Each exterder does take extra memory from the java heap on the server. I have had similar issues from bad java installs, not enough java heap and bad memory modules in my SageTV server. With mine, the issue was generally that the HD PVR would not get the message to stop a recording and would continue to record until I caught the problem or until another recording was scheduled to start.

I run mine now at 768 - if you have enough memory you can even try 1024.

[Flash69]

Originally Posted by HelenWeathers

I run mine now at 768 - if you have enough memory you can even try 1024.

I didn't think you could go over 512. Do you mind sharing your setting? I have plenty of memory.

[HelenWeathers]

Originally Posted by Flash69

I didn't think you could go over 512. Do you mind sharing your setting? I have plenty of memory.

I use 768m. Many users use 1g. I use SageTV in service mode with 3 HD200s - but rarely are all three active at the same time.
512m = 200hex
768m = 300hex
1g = 400hex

[hemicuda]

I tried 1024... once. Had to boot into safe mode to get around a persistent BSoD and reset the value to 512. I guess 2gig isn't enough physical to run a heap of that magnitude. I've been toying with the idea of putting in one stick of a spare 2gig I bought for expansion, but not sure if my board will take singles. I was told in another thread that my 350 drivers won't operate w/ 4gig installed.

[Flash69]

Originally Posted by hemicuda

I tried 1024... once. Had to boot into safe mode to get around a persistent BSoD and reset the value to 512. I guess 2gig isn't enough physical to run a heap of that magnitude. I've been toying with the idea of putting in one stick of a spare 2gig I bought for expansion, but not sure if my board will take singles. I was told in another thread that my 350 drivers won't operate w/ 4gig installed.

I just did the 400hex code on my server tonight. I only have 2 GB of Ram and it's fine.

[hemicuda]

Lovely. Guess it's just me and mine then.

[troll5501]

An update...

Last night I reduced the java heap to 256MB, and the HD-PVR lockup was fairly easy to reproduce by running the JVM out of memory and forcing it to do cleanup. Then I increased it to 1024MB, and with only 150MB in use the HD-PVR locked up. So much for my theory.

But the more I watched the problem, each time the HD-PVR would hang there was a CPU spike up to 100%. I ran a CPU-hog program to force the CPU to 100% but that didn't cause any problems. So it seems like a CPU spike within the JVM leads to the hang. And I guess most of the time these spikes were the memory cleanup processes, which explains what I was thinking earlier--until it failed with lots of free memory.

Then I downgraded from 1.5.6 to 1.5.0.301 per some suggestions on other threads. I put the JVM back to 256MB and for 3 or 4 hours I rebooted extenders over and over, started lots of recordings, browsed menus, etc just to exercise the system. The JVM memory was nearly 100% all the time and the interface was really sluggish, and the HD-PVR only locked up once. Several times the CPU was at 100% for a long time and it stopped recording but picked back up as soon as the load came down (no capture errors), and continued writing to the same file although there is a corrupted spot in the data (not surprised by this).

So all I can say is 1.5.0.301 seems much more stable than 1.5.6 on my system. I'll keep testing and let you all know how it goes. My final solution will include a 1024MB JVM since I have 2GB in the box.

[jerryt]

Troll5501, thanks for all your detailed testing.

1.5.6 did appear to lock up more then 1.5.0.301 for me, plus audio problems with 1.5.6

[GollyJer]

Troll5501,
Are you using optical or component audio?

[troll5501]

Originally Posted by GollyJer

Are you using optical or component audio?

Optical. Didn't really spend much time with analog audio although I've read about some people having problems with optical.

[GollyJer]

I switched from digital to analog (even though I didn't want to) and haven't had a lockup since. This is 1.5.6 drivers. With digital they were locking up almost every day.

[troll5501]

Originally Posted by troll5501

But the more I watched the problem, each time the HD-PVR would hang there was a CPU spike up to 100%. I ran a CPU-hog program to force the CPU to 100% but that didn't cause any problems. So it seems like a CPU spike within the JVM leads to the hang.

I've only had two lockups since I posted my previous update. However, both lockups (one this afternoon) occurred when making changes to recording schedules or deleting old recordings.

When doing these operations, I'm getting CPU spikes to 100% that last several seconds. For example, I went into the guide and selected a show and when I clicked "Record this show" I got something like this:



A moment later I looked over and saw that the HD-PVR was no longer recording, and then I got the capture error on the screen.

The previous lock-up happened much the same way. I was away from the TV all day, then turned it on (extender was already running) and went into recordings and deleted a few. Next thing I knew, the HD-PVR that was recording suddenly stopped recording and up came the capture error.

Both cases required power cycling the HD-PVR. Is it possible that something is not getting the CPU it needs (driver, USB, ??) and the resulting delay is somehow causing the lockup? This seems like a driver issue, not a heat-related one like some people are finding.

I'm also wondering if these CPU spikes are normal for these types of actions in SageTV. My server does not do any decoding or transcoding, I use extenders everywhere. My wiz.bin has 3+ years of data and is 23MB...maybe it's parsing all this data each time I do something related to recordings?

CPU is a Pentium Northwood 3.0GHz. I think my CPU supports hyperthreading...should I consider enabling it? I'm using Neilm's Dynamic Menu plugin and I have the SageTV unsupported "extras" enabled, but no other customizations.

[bthurber]

I'm finding that 1GB doesn't do the trick.

Last night, instead of doing a full shutdown, I simply unplugged the USB cable from the back of the HDPVR and plugged it back in after 5 seconds and the lockup was gone (sage was able to record on the HDPVR again). I didn't even restart the sage service. I have to wonder if it is time to find a quality USB card at newegg.

SPECS: Intel DG45ID motherboard, ATI 4670, 3GB RAM, Vista 32-bit, 1561 HDPVR firmware

Brad

[GollyJer]

Originally Posted by troll5501

I've only had two lockups since I posted my previous update. However, both lockups (one this afternoon) occurred when making changes to recording schedules or deleting old recordings.

When doing these operations, I'm getting CPU spikes to 100% that last several seconds....

... Is it possible that something is not getting the CPU it needs (driver, USB, ??) and the resulting delay is somehow causing the lockup? This seems like a driver issue, not a heat-related one like some people are finding.

I think you're on to something. I switched back over to 1.5.6 drivers and optical sound. Lockups started happening when ShowAnalyzer was running (using a majority of the cpu cycles). I'll be testing for the next week or so without ShowAnalyzer to see if lockups are less frequent.