OpenDCT: An open source digital cable tuner.

[KryptoNyte]

Originally Posted by bnh

On first startup, the local_ip_override was populated with 192.168.200.2, and not the local NIC address which i was getting before.

However, still No Signal.

Looks like you're coming from Comcast/SageDCT ... just to backtrack for a moment, there's nothing strange in your Ceton diagnostics?

[bnh]

Originally Posted by KryptoNyte

Looks like you're coming from Comcast/SageDCT ... just to backtrack for a moment, there's nothing strange in your Ceton diagnostics?

yeah, i've always thought this was strange, but it's been this way since day one, after calling comcast to activate the cablecard.

CableCARD has not received Validation signal.
Please ask your cable company to send a 'CCV' signal to your CableCARD

but otherwise, i dont see anything. SageDCT has been working fine. FWIW, the hardware version is 4884.

[ThePaladinTech]

Originally Posted by EnterNoEscape

I have been doing all of the development with the exception of a few suspend tests on a VM, so yes, it should be working OK on virtual machines. Just keep in mind that the virtual network adapters need to be able to keep up with/not mangle the UDP traffic. This is a problem people commonly run into when using PXE in a VM environment and I will not be surprised if someone reports it when using OpenDCT in a VM.

Thanks for that response - looks like I might be doing playing with SageTV over the holidays

Originally Posted by jvl711

FYI... PrimeNetEncoder does work on Virtual Machines. You just need to install the HDHomeRun software on the virtual machine. My development machine is virtual.

That is also good to know as well, I saw the requirement for HDhomerun view ... which will not run (at least it won't show video) on my VMs .. and was told(in their thread) it wouldn't work with a vm.

[KryptoNyte]

Originally Posted by bnh

yeah, i've always thought this was strange, but it's been this way since day one, after calling comcast to activate the cablecard.

CableCARD has not received Validation signal.
Please ask your cable company to send a 'CCV' signal to your CableCARD

but otherwise, i dont see anything. SageDCT has been working fine. FWIW, the hardware version is 4884.

But you were successfully using this for a few years at least with SageDCT in a cablecard tuning capacity? (i.e. - you weren't just tuning unrestricted QAM television ignoring the cablecard)

[bnh]

Originally Posted by KryptoNyte

But you were successfully using this for a few years at least with SageDCT in a cablecard tuning capacity? (i.e. - you weren't just tuning unrestricted QAM television ignoring the cablecard)

i assume so, because i have to use comcast supplied adapters to tune any channels on non-Sage tv's. my assumption is clear QAM is unavailable in my region.

[EnterNoEscape]

Originally Posted by bnh

On first startup, the local_ip_override was populated with 192.168.200.2, and not the local NIC address which i was getting before.

However, still No Signal.

If I didn't already ask you to before, try changing http_tune to false. The firmware version on mine is 1.2.2.6. I suspect the web interface is not the same as the newer versions. Your tuning speed will be slower, but it will be tuned like SageDCT tunes.

[EnterNoEscape]

Originally Posted by KryptoNyte

But you were successfully using this for a few years at least with SageDCT in a cablecard tuning capacity? (i.e. - you weren't just tuning unrestricted QAM television ignoring the cablecard)

My observations are without the validation signal, you can't record copy restricted channels. In other words as long as it says Copy Freely you should be good even without it. If it says Copy Once, not only do you need to have software that supports the DRM, but the validation signal must be received. I learned this when I was recording HBO from an Xbox 360 using an HD-PVR. Also worth noting is if it remains None, it usually means you don't actually need the CableCARD at all. That means it's coming in unencrypted.

[bnh]

Originally Posted by EnterNoEscape

If I didn't already ask you to before, try changing http_tune to false. The firmware version on mine is 1.2.2.6. I suspect the web interface is not the same as the newer versions. Your tuning speed will be slower, but it will be tuned like SageDCT tunes.

i assumed you meant: upnp.dct.http_tuning=false

same result anyway.

just curious what your hardware version is?

[EnterNoEscape]

My hardware revision is 6829. I believe my firmware is the last beta firmware. I had to upgrade it for something else a while ago. I think it was MythTV.

I can see from the logs that it used the correct tuning method, but trails off in some unexpected places also the source protocol is rtsp-rtp-udp:*:DRI-MP2T:* all current devices use the same thing, but it's all lowercase rtsp-rtp-udp:*:dri-mp2t:*. I don't know if that makes a difference. I noticed that the RTSP configuration is trailing off at DESCRIBE. That's abnormal and without generating an exception. That's also very abnormal. I was looking at the code for this section and we certainly should have seen an actual error message if things were not working as expected.

Under C:\Program Files (x86)\OpenDCT Authors\OpenDCT\lib, there is a file called log4j2.xml. Open it up and make the following changes:
<Loggers>
<Root level="DEBUG">
<AppenderRef level="INFO" ref="Console"/>
<AppenderRef level="DEBUG" ref="RollingFile"/>
</Root>

to

<Loggers>
<Root level="TRACE">
<AppenderRef level="INFO" ref="Console"/>
<AppenderRef level="TRACE" ref="RollingFile"/>
</Root>

Then try again. The log will then include a lot more data, but maybe it will give me a better clue about what's really happening. I recommend reverting this file back for actual production use since it can waste a lot of disk space.

[bnh]

Originally Posted by EnterNoEscape

Then try again. The log will then include a lot more data, but maybe it will give me a better clue about what's really happening. I recommend reverting this file back for actual production use since it can waste a lot of disk space.

zip attached

[spencerw]

Originally Posted by troll5501

2) If I start all 3 Prime tuners recording shows, watch one of them for a bit, then go into the Guide or Recording Schedule and cancel one of the other 2 recordings, sagetv.exe immediately goes to 100% CPU and becomes essentially unresponsive. I've reproduced this issue several times on-demand and each time I had to kill the sagetv.exe process. This also does not happen when using natively supported tuners.

Not sure if these are OpenDCT or SageTV issues.

I've seen SageTV get into a tight loop talking to network encoders where it requests the recording file size via the GET_FILE_SIZE command over and over again sometimes many times per millisecond especially when SageDCT was used in "dump" capture mode. It has nothing to do with SageDCT but may have to do with the fact that Windows doesn't know how to generate a thumbnail for raw capture files when SageTV asks for one. When this happened I would very often get a red segment in my recording timeline. We don't log GET_FILE_SIZE requests and responses specifically because of this strange behavior in SageTV. I'd be surprised if you're running into this issue but it is the only time I've seen CPU spikes. Since we don't log GET_FILE_SIZE commands we can't tell if this is happening though. Would you be open to trying to narrow this down for us? Since you already have:

debug_logging=true

in Sage.properties could you also enable logging of network encoder activity by stopping the SageTV service, adding the following property and restarting the service:

network_encoder_debug=true

Both properties need to be true to get text like this in your SageTV log:

Tue 11/17 22:47:09.095 MMC sent request to dvr:8040 of GET_FILE_SIZE E:\Recorded TV\CaptainAmericaTheWinterSoldier-16172825-0.ts

Tue 11/17 22:47:09.096 MMC received response from dvr:8040 of 1518288

Please look for hundreds of the above messages per second when the CPU usage spikes. If you don't see hundreds of them then please post your SageTV log for us to investigate further. If you do see hundreds of them then I'll dig deeper into the SageTV v9 code and if I spot a problem I'll request a fix via the SageTV Open Source forum. Thanks.

-Bill

[EnterNoEscape]

Originally Posted by bnh

zip attached

Ok. I think I see what's happening, but I'll need to re-write some of the RTSP code to support your firmware version.

Update: Try version 0.3.13 I just uploaded to Bintray. It hopefully contains the fixes needed to get you working. If it works well, I'll leave it up. If it doesn't fix anything, hopefully I'll get better details from your log this time.

[bnh]

Originally Posted by EnterNoEscape

Update: Try version 0.3.13 I just uploaded to Bintray. It hopefully contains the fixes needed to get you working. If it works well, I'll leave it up. If it doesn't fix anything, hopefully I'll get better details from your log this time.

i don't see 0.3.13 in the Files section. Is there a different place i should be going?

[nyplayer]

Originally Posted by bnh

i don't see 0.3.13 in the Files section. Is there a different place i should be going?

https://bintray.com/opendct/Releases...eleases/0.3.13

[bnh]

Originally Posted by nyplayer

https://bintray.com/opendct/Releases...eleases/0.3.13

No change, although it seemed to take a second longer to try to tune before displaying No Signal.

[EnterNoEscape]

Can you get me wrapper.log too? I'm not even seeing it fail which makes me think the thread is completely crashing in a manner that isn't being logged correctly.

[bnh]

Originally Posted by EnterNoEscape

Can you get me wrapper.log too? I'm not even seeing it fail which makes me think the thread is completely crashing in a manner that isn't being logged correctly.

yep, attached

[EnterNoEscape]

bnh,

It's so hard to sift through what's going on in the trace logs. Anyhow, after looking at wrapper.log, it made things a little more clear. You tried to use the tuner literally one second before it was actually loaded. That's why I'm not seeing the feedback that I was expecting. I also found one tuning around 6:48 PM today that actually went through the entire process and the stream was correctly detected by FFmpeg, but FFmpeg was not happy with the quality of the stream.

It looks like you only have 4 tuners. If you set sagetv.device.global.required_devices_loaded_count= to 4, OpenDCT will actually hang onto SageTV's tuning request until the tuner count is reached instead of just returning an error to SageTV.

- Joe

[bnh]

Originally Posted by EnterNoEscape

It looks like you only have 4 tuners. If you set sagetv.device.global.required_devices_loaded_count= to 4, OpenDCT will actually hang onto SageTV's tuning request until the tuner count is reached instead of just returning an error to SageTV.

I set that value and attached the trace logs. With an older hardware/firmware version, I'm not sure how much more time you want to expend or adding special case code... i'm likely an outlier here.

My objective was to see if the implementation of FFMEG would allow me to avoid having to remux the final file. Intermittently, some files could not be played back in sage without doing a remux. Unless you see some other leads in these logs, I will likely continue to use SageDCT, but not remux and see if that problem still exists. maybe it's a non issue now.

[EnterNoEscape]

Originally Posted by bnh

I set that value and attached the trace logs. With an older hardware/firmware version, I'm not sure how much more time you want to expend or adding special case code... i'm likely an outlier here.

My objective was to see if the implementation of FFMEG would allow me to avoid having to remux the final file. Intermittently, some files could not be played back in sage without doing a remux. Unless you see some other leads in these logs, I will likely continue to use SageDCT, but not remux and see if that problem still exists. maybe it's a non issue now.

Have you tried the latest FFmpeg implementation in SageDCT? It was working a lot better for me than previous versions, but OpenDCT is working even better. I wasn't even remuxing prior because SageDCT's implementation was constantly causing problems. I can see in the logs that FFmpeg is still very unhappy, but you're technically streaming; just not much. It's also possible that FFmpeg will never agree with your providers streams. Are you remuxing with FFmpeg or VideoRedo? You can switch over to raw with OpenDCT if you want to go that route. Just change sagetv.device.parent.<unique_id>.consumer=opendct.consumer.FFmpegSageTVConsumerImpl to opendct.consumer.RawSageTVConsumerImpl.

I don't see anything new. We will be making small improvements to FFmpeg. If Bill sees something of interest in your logs, I'm sure he'll make some changes too. At some point I'll probably want one of your raw streams just for testing to see if we can ever fix it. I appreciate your willingness to try everything. I'm not a fan of unresolved issues, so when you have time, please try out new builds and check in with your results if you want.