Ceton, SageDCT and Halt Detected issues

[crarbo1]

Hello,
I have two Ceton tuners and using SageDCT with great results, mostly. Sometimes I come home and see that I have some halt detected warnings, and sometimes errors on some channels.

Does anyone know what causes this? So far it has only been on shows that I wanted to watch, so the WAF is still good. I'm afraid that if it happens on one of her recordings, I will be in the doghouse. So, if there is anything that I can do to prevent this from happening, it would be greatly appreciated.

Thanks,
Chuck

[zoso]

For me the issue was caused by having my windows swap file on one of my recording drives. As soon as I moved it back to C drive that problem went away for me. I think the CETON cards (or maybe SageDCT) are extremely sensitive to harddrive bandwidth.

[crarbo1]

zoso,
Thanks for the help. I checked my swap file and it was already on the C drive. It is set to be managed by Windows however, is that how you have it set? I have 3, 1TB WD Balck (7200rpm) hard drives and SageTV set to the "Bandwidth" settings, so I think my hard drives are capable of keeping up.

Any other help is appreciated.

Thanks,
Chuck

Originally Posted by zoso

For me the issue was caused by having my windows swap file on one of my recording drives. As soon as I moved it back to C drive that problem went away for me. I think the CETON cards (or maybe SageDCT) are extremely sensitive to harddrive bandwidth.

[tpowell]

I'm afraid that if it happens on one of her recordings, I will be in the doghouse. Chuck

I would recommend a divorce if she is that touchy.


On a more serious note I am also having the same issue. My configuration is as follows:

A relatively new and powerful htpc server
Windows 7
Sage 7.1.9 (latest beta)
SageDCT
Ceton package 1.2.0.8-20110804
Firmware 1.0.9.5
HW version 4884

I tripled the "Write buffer" and "RTP Buffer" and that has helped a little bit, but as the original poster It hasn't eliminated the issue.

I verified that my swap file is not on the system drive.

Any help would be greatly appreciated

[crarbo1]

tpowell,
Where do you change the "Write buffer" and "RTP Buffer"? I haven't done anything like that as you can tell.
Thanks,
Chuck

Originally Posted by tpowell

I tripled the "Write buffer" and "RTP Buffer" and that has helped a little bit, but as the original poster It hasn't eliminated the issue.

[babgvant]

Originally Posted by zoso

I think the CETON cards (or maybe SageDCT) are extremely sensitive to harddrive bandwidth.

It is. Besides some buffering there's no intelligence in the file writing, it just dumps the bits to disk as they arrive.

If you're writing to a UNC path make sure that your NIC drivers are up to date, otherwise it could be a signal strength issue (your sig lists 2x Ceton cards, which means an 8-way split).

[sflamm]

It is. Besides some buffering there's no intelligence in the file writing, it just dumps the bits to disk as they arrive.

Does the Silicondust Prime work more reliably? (also using UNC - have dedicated 'tuner PC' for Ceton card)

Maybe I should upgrade to one instead of Ceton...?

[crarbo1]

babgvant,
I have 3, 1TB WD Balck (7200rpm) hard drives and SageTV set to the "Bandwidth" settings, so I think my hard drives are capable of keeping up.
Those hard drives are local to my sage TV server, so no UNC paths to worry about. I'm only splitting it twice, but I guess your right it technically is getting split into 8. I do have an amp to the line before I split it though.
So far, I see this issues an a couple of channels, so, is it possible that some of those shows on those channels are not marked as copy freely and thus creating the these halt detected errors and thus giving me a blank screen? If I open the file that the halt detected occured on, it appears to have recorded the entire time, but it is just a black screen.

Any futher help is appreciated,
Chuck

Originally Posted by babgvant

It is. Besides some buffering there's no intelligence in the file writing, it just dumps the bits to disk as they arrive.

If you're writing to a UNC path make sure that your NIC drivers are up to date, otherwise it could be a signal strength issue (your sig lists 2x Ceton cards, which means an 8-way split).

[babgvant]

Originally Posted by sflamm

Does the Silicondust Prime work more reliably? (also using UNC - have dedicated 'tuner PC' for Ceton card)

Maybe I should upgrade to one instead of Ceton...?

If your NIC or signal is the issue changing tuners won't solve the problem.

[babgvant]

Originally Posted by crarbo1

babgvant,
I have 3, 1TB WD Balck (7200rpm) hard drives and SageTV set to the "Bandwidth" settings, so I think my hard drives are capable of keeping up.
Those hard drives are local to my sage TV server, so no UNC paths to worry about.

The HD can be local and still write to UNC. Is the path something like "S:\TV" or "\\mysagetvserver\TV" inside of SageTV?

Originally Posted by crarbo1

I'm only splitting it twice, but I guess your right it technically is getting split into 8. I do have an amp to the line before I split it though.

Check the levels on the web page.

Originally Posted by crarbo1

So far, I see this issues an a couple of channels, so, is it possible that some of those shows on those channels are not marked as copy freely and thus creating the these halt detected errors and thus giving me a blank screen? If I open the file that the halt detected occured on, it appears to have recorded the entire time, but it is just a black screen.

Is is consistent per channel? You can see if a channel is copy-freely (or not) on the card's webpage.

[crarbo1]

babgvant,
The drives are using the"S:\TV" format.
I may have stumbled onto what is causing this however just a few minutes ago. After I read your reply, I went into SageTV to to make sure of the recording path and I had two more "halt detected" issues. I noticed the newest one just occured at 4pm. Since that recording was still going on, I was able to go to the tuners website to get the info you asked about.
Here that is:
Signal Level: -4.8 dBmV
Signal to Noise Level: 35.6 dB
Channel: 728
Copy Protection: Copy Free
Temp of the tuner: 45.4 C
So, based on all that info, I think it should be in good shape. However, when I got out of the webpage, I decided to go into the Cable Card setup screen using Ceton's Diagnostic too. Once there, I noticed that the OOB was not locked. This is probably the problem, but what is it? A bad cable card, a bad Ceton Tuner? I had similar issue with the first cable card but a new one got me going. The second card on my second Ceton, which is the one giving me this error, worked right away without any issues. Well, with the exception of this "Halt" error every once in a while. It doesn't happen all the time.
I have attached a screenshot of the diagnostic screen to show you what I am talking about.

Any help is greatly appreciated.

Thanks,
Chuck

Originally Posted by babgvant

The HD can be local and still write to UNC. Is the path something like "S:\TV" or "\\mysagetvserver\TV" inside of SageTV?

Check the levels on the web page.

Is is consistent per channel? You can see if a channel is copy-freely (or not) on the card's webpage.

[babgvant]

Originally Posted by crarbo1

So, based on all that info, I think it should be in good shape. However, when I got out of the webpage, I decided to go into the Cable Card setup screen using Ceton's Diagnostic too. Once there, I noticed that the OOB was not locked. This is probably the problem, but what is it? A bad cable card, a bad Ceton Tuner? I had similar issue with the first cable card but a new one got me going. The second card on my second Ceton, which is the one giving me this error, worked right away without any issues. Well, with the exception of this "Halt" error every once in a while. It doesn't happen all the time.
I have attached a screenshot of the diagnostic screen to show you what I am talking about.

Any help is greatly appreciated.

Thanks,
Chuck

If you have the latest drivers/device firmware installed I'd contact their support. That's not something I can fix.

[crarbo1]

I didn't think it was something on your end, I was hoping it was something that you had seen before I had some insight how to resolve it.

Thanks though!

Originally Posted by babgvant

If you have the latest drivers/device firmware installed I'd contact their support. That's not something I can fix.

[babgvant]

Originally Posted by crarbo1

I didn't think it was something on your end, I was hoping it was something that you had seen before I had some insight how to resolve it.

Thanks though!

Yeah, I should have been clearer - that's not something I'd even know where to start fixing

[crarbo1]

I have just submited a suport ticket, so I hope to hear rom them soon.

Thanks,
Chuck

Originally Posted by babgvant

Yeah, I should have been clearer - that's not something I'd even know where to start fixing

[willieb]

Chuck,

Any resolution to this?

[sflamm]

I used to occasionally get errors from my networked Ceton - but since I did the following the errors have dramatically decreased:

1. increased the read/write buffers on the NIC the errors have dramatically dropped (look up the max values of read/write buffers that your NIC supports and adjust accordingly.)

2. disable windows 7 autotuning

1. Open elevated command prompt with administrator’s privileges.
2. Type the following command and press Enter:
netsh interface tcp set global autotuning=disabled

[sflamm]

Also:

3. Turn off Interrupt Moderation on your NIC

Turning this off will increase your CPU usage, but it will also prevent packets from sitting there waiting for an interrupt to be proccessed.

[crarbo1]

Originally Posted by willieb

Chuck,

Any resolution to this?

willieb,
No I haven't. However, they occur infrequently. I have a trouble ticket open with Ceton but they want the data when it occurs. 99.9% of the time, these occur when I'm not around to see them happening, so getting them the info they want is very difficult.

[crarbo1]

Originally Posted by sflamm

I used to occasionally get errors from my networked Ceton - but since I did the following the errors have dramatically decreased:

1. increased the read/write buffers on the NIC the errors have dramatically dropped (look up the max values of read/write buffers that your NIC supports and adjust accordingly.)

2. disable windows 7 autotuning

1. Open elevated command prompt with administrator’s privileges.
2. Type the following command and press Enter:
netsh interface tcp set global autotuning=disabled

sflamm,
I will look into your 3 changes. I'm not sure if I will change anything or not since I am getting these very infrequently. Just a question about #2, what does that do?

Thanks,
Chuck