HDHomeRun (HDHR) Prime + SageDCT

[KJake]

Originally Posted by babgvant

Does memory use go up while a recording is happening or is it more of an over time thing?

I'm seeing this issue as well. During recordings, the process can use up to 3gB of RAM, and I only have 4gB in the system. I have 8gB arriving tomorrow to swap in for the 4gB to help, but it would be nice if it didn't need to use so much memory.

Current buffers are set to default.

[babgvant]

Originally Posted by KJake

it would be nice if it didn't need to use so much memory.

It shouldn't use that much RAM.

[gplasky]

Check your error log for SageDCT. This usually indicates a misconfiguration and the log file is probably huge also.

Gerry

[phelme]

Originally Posted by KJake

I'm seeing this issue as well. During recordings, the process can use up to 3gB of RAM, and I only have 4gB in the system. I have 8gB arriving tomorrow to swap in for the 4gB to help, but it would be nice if it didn't need to use so much memory.

Current buffers are set to default.

this happens when the SageDCT process gets stressed and can't keep up. once that happens, it never really recovers until the service is restarted.

I get this occasionally too, when all tuners are recording, though less now that I've upped my write buffer to 8192. you might want to try that. a balance needs to be achieved for each unique setup by finding the "right" setting of RTP and write buffer sizes and NIC settings. you may have to experiment.

While I appreciate all Andy has done with SageDCT, the lack of native support for the Ceton and SD Prime tuners is one of, if not the biggest, failing since Google bought SageTV.

[KJake]

Originally Posted by phelme

this happens when the SageDCT process gets stressed and can't keep up. once that happens, it never really recovers until the service is restarted.

I get this occasionally too, when all tuners are recording, though less now that I've upped my write buffer to 8192K. you might want to try that. a balance needs to be achieved for each unique setup by finding the "right" setting of RTP and write buffer sizes and NIC settings. you may have to experiment.

While I appreciate all Andy has done with SageDCT, the lack of native support for the Ceton and SD Prime tuners is one of, if not the biggest, failing since Google bought SageTV.

I think the problem was that I actually reduced my buffers from what I was using back in December with 2.1.8 because I think I read that there were new defaults - so I thought I'd go to them.

I've turned logging on and put my buffers back to what I had in my December post with 2.1.8 - _and_ upgraded the RAM to 8gB. I have no problem upgrading the RAM. It was only $55 and with the plugins that I run with Sage, it will be nice to have some breathing room.

I'll monitor and report back.

[snapdaddy]

Originally Posted by KJake

I'm seeing this issue as well. During recordings, the process can use up to 3gB of RAM, and I only have 4gB in the system. I have 8gB arriving tomorrow to swap in for the 4gB to help, but it would be nice if it didn't need to use so much memory.

Current buffers are set to default.

Might not hold true after more testing, but I've seen the runaway memory problem two times - both just after I changed the log level to verbose and restarted the services. The next recordings after I changed the log level resulted in rapidly climbing memory until it crashed with a .NET OutOfMemory error. I set the log level back to default, and SageDCT has maxed at 87mb, with an avg of about 27mb.

Robb

[zoop]

Originally Posted by KJake

I think the problem was that I actually reduced my buffers from what I was using back in December with 2.1.8 because I think I read that there were new defaults - so I thought I'd go to them.

I've turned logging on and put my buffers back to what I had in my December post with 2.1.8 - _and_ upgraded the RAM to 8gB. I have no problem upgrading the RAM. It was only $55 and with the plugins that I run with Sage, it will be nice to have some breathing room.

I'll monitor and report back.

i also ran into this initially.. i write to UNC paths, and any box with either inadequate network throughput or starved CPU resources would cause DCT to start swelling up like a puffer fish. while sometimes it would come back down to earth and all would be well, other times it would never get the chance to flush that data out properly and some ends of recordings would be lost as it shifted to other, newer recordings. easy to reproduce while trying to get a VM running 3 HD streams thru DCT without something like VT-d to offload the network traffic from the VM's software emulated NIC.

long story short: make sure your output path from DCT, whatever that is, is keeping up with the streams. my DCT process now hovers around 30M or so, with a variance of only a few MB.

/jer

[babgvant]

Originally Posted by zoop

long story short: make sure your output path from DCT, whatever that is, is keeping up with the streams.

+1

[jbuszkie]

It may be something else or just coincidence .. but I'm haven't gotten any halts
recently.. I recently added another 2GB for a total of 4GB on my win7 32bit
system to try to cure some spinning circle of death delays.. and now I haven't noticed any halt detected messages...
hmm...

Jim

[ChePazzo]

I used to get halts at least once show/week and they would come like every 5m. While I was trying to figure out if it was the HDHR or Comcast (recording the same show on Sage and on the Comcast DVR), my wife went down to Best Buy and bitched at the guy that she can't get any of her shows because it kept flicking out. He ran some tests, reset something and I've been halt free ever since.

I imagine that the problem was that Comcast had issues in the line and when Sage detected the LoS, it restarted or reinitialized the tuner, which took a few minutes to come back up, so that even a very short disruption created a huge gap in the recording. Frustrating to be sure, but ultimately it was on Comcast's end and it's been great ever since.

Now I just need to get my HDHR Prime to run! I can watch CableCard shows (USA, Food, Etc) with VLC (yeah, I'm on Linux everywhere) but so far only the clearQAM channels are listed after a channel scan in SageTV. Gonna try a new server install on a new machine to get a clean initial scan for the lineup and see if that does the trick.

[gplasky]

If you're using the Prime and a cablecard you don't do channels scans. You have to use SageDCT and copy and paste the tuner settings in the .properties file. Then you just add your EPG to the tuner. Your Prime doesn't work with SageTV without SageDCT.

Gerry

[freewheeling]

Originally Posted by gplasky

Check your error log for SageDCT. This usually indicates a misconfiguration and the log file is probably huge also.

Gerry

What sort of misconfiguration. I'm still getting flaky behavior from SageDCT and am considering going back to WMC. There's no way to troubleshoot SageDCT because the verbose logs are enormous. Also, none of these problems ever show up with WMC so I figure there's some sort of bug in DCT that probably won't ever get corrected.

BTW, right after the failure I get an "actively refused" error in the SageDCT configuration if I test it, but only on that tuner that was being used. As soon as I restart the service the problem goes away until the next time, but there's no log file to look at because I don't have any text programs that can open that big a file.

Update: I reset the log level to "error" because there's not much sense in creating an unusable verbose log, and I figured the logging might actually be causing the problems.

[freewheeling]

Originally Posted by jbuszkie

It may be something else or just coincidence .. but I'm haven't gotten any halts
recently.. I recently added another 2GB for a total of 4GB on my win7 32bit
system to try to cure some spinning circle of death delays.. and now I haven't noticed any halt detected messages...
hmm...

Jim

I've got 12GB of RAM and I still get halts.

[sTVb]

Had my first real issue since the first weekend that I got the PRIME up and running. I noticed my free space dropped by several hundred GB and thought maybe a HD went out.

Turns out, I had a couple of recordings on Wednesday night that were corrupted. CSI was over 250 GB and Royal Pains went over 80 GB! Not sure what that about, but luckily I had enough free space that Sage didn't delete a bunch of stuff.

I think I may have been ripping a couple of DVD's while 2 tuners wre recording. Have to watch out in the future.

[flavius]

Yesterday I noticed a bunch of halts, dozens actually, the first in almost eight weeks. I did a hardware reset and all's fine again.

[freewheeling]

I get a halt every day about 3/4ths of the way through recording FOX&Friends. It's a 3 hour show and it halts usually in the last half hour or 40 minutes and then I get a message that a partial recording was saved because of "recordings on other tuners." Nothing else was recording at the time, and a configuration test will always fail on the tuner that was being used and I'll get substandard jerky recordings until I reset the SageDCT service. No idea what's causing it but it probably has to do with a buildup after over 2 hours recording on 1 tuner.

If there were some text editor when I could delete all but the relevant part of the verbose log it could probably be tracked down, but I don't have anything that can do that. Everything I have chokes on a file that big.

[KJake]

Originally Posted by freewheeling

If there were some text editor when I could delete all but the relevant part of the verbose log it could probably be tracked down, but I don't have anything that can do that. Everything I have chokes on a file that big.

Try Notepad++? http://notepad-plus-plus.org/

[jbuszkie]

Originally Posted by jbuszkie

It may be something else or just coincidence .. but I'm haven't gotten any halts
recently.. I recently added another 2GB for a total of 4GB on my win7 32bit
system to try to cure some spinning circle of death delays.. and now I haven't noticed any halt detected messages...
hmm...

Jim

Almost two weeks since this post and I have to say that I still have not had any halts. So I think my extra 2GB fixed the issue... Or is related in some way.

Guess I should by that extra 2GB so I can return the 4GB back to my other computer who keeps asking when it's going to get it's full memory back!

[jlmdxtv]

I wish I was halt free with the Prime, but one in every 8 recordings or so is shot. Sometimes I end up losing 2 of the 3 Prime sources when it goes completely south; at that point I reboot and everything comes back.

- I've tried dozens of variations of buffer sizes both in SageDCT and the NICs based on other's successes here
- Tried adding a 1GB Intel nic and setting it up as recommended here
- I'm running the latest Prime beta firmware and SageDCT
- Signal rates on the cable are 100%
- Disabled Comskip - and the computer is doing nothing else taxing.
- I ending up putting the Prime on the Intel nic by itself, then turned off the firewall servicing that NIC
- Turned off virus scanning for TS files, the appropriate Sage and SageDCT services, and anything going to the recording drives
- Tried using another 7200rpm hard drive and then pooling the drives which are locally attached
- Upped my Java heap to 768mb
- The processor load (8% or so) and SageDCT memory usage (20MB) all seem normal even during the failures.
- Like others here, when the recordings fail the SageDCT error log ends up hundreds of MB even on the "Errors only" setting, so I turned logging off.

I have an I3 with 4GB ram running XP SP3, 32bit. I'm about out of solutions outside of waiting for Andy and/or Silicon Dust to come out with an update that might fix this.

I'm also thinking of buying a Centon card and see if that works any better. I don't see a lot of issues here with the Centon.

Are there people here using the Centon in XP without the issues the Prime seems to be having?

Has anyone else here gone from Prime to Centon? Experiences?

Thanks, john

[freewheeling]

Originally Posted by KJake

Try Notepad++? http://notepad-plus-plus.org/

"The file is too big to be opened by Notepad++"

So, what's the point in having a verbose log that's too big to open?