OpenDCT: An open source digital cable tuner.

[Fuzzy]

Just to test, try shutting down opendct and sage on the old syatem, then starting up opendct on unraid, wait a bit, then start up sage on the unraid, and try to do a manual record of something. From that, then post the opendct and sagtv logs. This should cover detection, discovery by sage, and recording.

[hb4]

Originally Posted by Fuzzy

Just to test, try shutting down opendct and sage on the old syatem, then starting up opendct on unraid, wait a bit, then start up sage on the unraid, and try to do a manual record of something. From that, then post the opendct and sagtv logs. This should cover detection, discovery by sage, and recording.

I edited my previous post before I saw your latest, reporting the successful results of updating the firmware; I was able to see video, but didn't test recording.

Will it be helpful to you if I do the test anyway? If it doesn't record, I'll post the logs in any event.

*********EDIT: Recording worked great! Playback via Placeshifter and HD200.

[EnterNoEscape]

• Fixed Linux installs to create opendct.properties.default instead of opendct.properties so you don't need to deal with a conflict on upgrades.
• Added saving the configuration if it changed after the first 30 seconds. Then every 5 minutes if anything has changed.
• Added conversion of 0.0.0.0 to 255.255.255.255 when it is returned as a broadcast address.

[willieb]

Originally Posted by EnterNoEscape

That's how the InfiniTV 4 devices show up in Linux. The InfiniTV 6 devices show up as Multimedia video controller. What do you see when you run: ip addr? Do you see anything like ctn0? If you don't you might not have the udev rules installed.

To fix that, you should just need to copy 98-ctn91xx.rules into /etc/udev/rules.d/ and then run: depmod -a

I am showing my Linux/unRAID inexperience here. I definitely saw references to ctn0. I uninstalled the card in favor of my Prime and had to get Verizon to repair my CC but I think I can reinstall it this weekend and I should be able to get some channels without re-pairing it to the Ceton to test.

I don't quite follow the instructions above though. Where is 98-ctn91xx.rules? I can get to a bash prompt through putty but I don't think that is "inside" the docker. Do I need to be in the sage docker to do this? Also on the unRAID forums CHBMB asked me if I passed through the Ceton to the docker. I am sure I did not. So any help there would be good too. Also I am not sure my MB has IOMMU so I might not even be able to pass through so I wanted to make sure I mentioned that. Sorry for the ignorance. I've learned a ton and I'm a pretty quick study when it comes to this. Just a steep curve to deal with. Thanks.

Thanks!

[EnterNoEscape]

Originally Posted by willieb

I am showing my Linux/unRAID inexperience here. I definitely saw references to ctn0. I uninstalled the card in favor of my Prime and had to get Verizon to repair my CC but I think I can reinstall it this weekend and I should be able to get some channels without re-pairing it to the Ceton to test.

I don't quite follow the instructions above though. Where is 98-ctn91xx.rules? I can get to a bash prompt through putty but I don't think that is "inside" the docker. Do I need to be in the sage docker to do this? Also on the unRAID forums CHBMB asked me if I passed through the Ceton to the docker. I am sure I did not. So any help there would be good too. Also I am not sure my MB has IOMMU so I might not even be able to pass through so I wanted to make sure I mentioned that. Sorry for the ignorance. I've learned a ton and I'm a pretty quick study when it comes to this. Just a steep curve to deal with. Thanks.

Thanks!

It's a part of the files you downloaded to compile the kernel module.
https://raw.githubusercontent.com/Ja...-ctn91xx.rules

If you saw the ctn0 adapter, you were 99% of the way there and probably don't actually need the rules. I think those just better define some devices you can stream directly from instead of using RTP. Rules don't actually add anything that's not already there. They usually modify permissions and/or organize things in a more logical way.

I wouldn't be surprised if all that happened was the adapter was just disabled. The OpenDCT Docker runs privileged in host mode, I think it should be able to see the adapter without you needing to change anything about the adapter itself. The adapter just needs to be up. The command to do that is:

ip link set ctn0 up

You can also run 'ip addr' to see if it has an IP address.

Edit: I just wanted to add that we all learn how to do things for the first time, so stop putting yourself down for now knowing things.

[willieb]

Originally Posted by EnterNoEscape

It's a part of the files you downloaded to compile the kernel module.
https://raw.githubusercontent.com/Ja...-ctn91xx.rules

If you saw the ctn0 adapter, you were 99% of the way there and probably don't actually need the rules. I think those just better define some devices you can stream directly from instead of using RTP. Rules don't actually add anything that's not already there. They usually modify permissions and/or organize things in a more logical way.

I wouldn't be surprised if all that happened was the adapter was just disabled. The OpenDCT Docker runs privileged in host mode, I think it should be able to see the adapter without you needing to change anything about the adapter itself. The adapter just needs to be up. The command to do that is:

ip link set ctn0 up

You can also run 'ip addr' to see if it has an IP address.

Edit: I just wanted to add that we all learn how to do things for the first time, so stop putting yourself down for now knowing things.

Thanks. I'll see what I can do this weekend.

[Telecore]

ENE - OpenDCT has been working great for a long time over many updates; after updating to 5.25, I've had difficulty tuning in CBS during basketball games (no signal). I have the latest firmware on my Ceton PCIe6 to avoid the legacy copy flags. My Windows Media Center with the identical card was able to tune the game in question. I performed a channel scan on my HDHomerun Prime and confirmed no DRM on CBS (channel 511). All other channels seem OK. Can you take a brief look at the bottom of the attached files to see if there's an issue and advise? The Dayton-Wichita State game was the one I was unable to see. (This is not an urgent problem for me as I can get the channel other ways, but just want to see if there is some issue with my setup and/or OpenDCT) Thanks in advance-

[EnterNoEscape]

Originally Posted by Telecore

ENE - OpenDCT has been working great for a long time over many updates; after updating to 5.25, I've had difficulty tuning in CBS during basketball games (no signal). I have the latest firmware on my Ceton PCIe6 to avoid the legacy copy flags. My Windows Media Center with the identical card was able to tune the game in question. I performed a channel scan on my HDHomerun Prime and confirmed no DRM on CBS (channel 511). All other channels seem OK. Can you take a brief look at the bottom of the attached files to see if there's an issue and advise? The Dayton-Wichita State game was the one I was unable to see. (This is not an urgent problem for me as I can get the channel other ways, but just want to see if there is some issue with my setup and/or OpenDCT) Thanks in advance-

I've seen something like this before. SageTV is telling OpenDCT to stop every 13 seconds, and then start the same recording over again. I presume because it thinks a halt happened, but OpenDCT clearly shows it was streaming successfully. The more troubling thing to take from this is that SageTV is supposed to wait a full 60 seconds before it makes a halt assumption, so I think this is a problem with SageTV. Do you happen to have the SageTV logs from the same time?

Edit: I just wanted to add that nothing in this area changed between 0.5.24 and 0.5.25.

[Telecore]

Sorry I can't find any .log or .txt files anywhere in the sage folders that were modified today and debug logging was off. I'll try this again tomorrow with debug logging on and if I can repeat the problem I'll post a log file - thanks.

[BobPhoenix]

Originally Posted by Telecore

Sorry I can't find any .log or .txt files anywhere in the sage folders that were modified today and debug logging was off. I'll try this again tomorrow with debug logging on and if I can repeat the problem I'll post a log file - thanks.

Note it shouldn't hurt to leave debug logging on all the time. I do that on all of my servers.

[Fuzzy]

If you are using the latest versions of sage, logging is now forced on all the time.

[Telecore]

I turned on logging and now, of course, I can't reproduce the problem. I'm running Sage V9.0.11.483 - I now see a SageTV_0.txt and SageTV_1.txt file which I believe to be the logs but they were not there until I turned on logging.

[BobPhoenix]

Originally Posted by Telecore

I turned on logging and now, of course, I can't reproduce the problem. I'm running Sage V9.0.11.483 - I now see a SageTV_0.txt and SageTV_1.txt file which I believe to be the logs but they were not there until I turned on logging.

You should upgrade to the latest version. It will give you access to the Schedules Direct EPG service. I don't think your version does but I could certainly be wrong.

[Telecore]

I now see that there is a new version out there and I saw a thread regarding logging always being on - I will upgrade soon - thanks.

[Telecore]

This isn't the proper thread, but I attempted to install 9.0.13.536 and now I get "no encoders can tune the... station" - did a repair install but it didn't fix it. Any idea how to get this working? - prior updates were not problematic.
UPDATE: did an uninstall, then install, then repair install and now it appears to be working...

[realcap]

Originally Posted by EnterNoEscape

I kind of expected this. We have a situation where the built in remuxer can't deal with the stream being provided by a cable company. I would just change the consumer back to FFmpeg and enable upload ID.

I would change opendct.consumer.MediaServerConsumerImpl to opendct.consumer.FFmpegTransSageTVConsumerImpl and consumer.ffmpeg.upload_id_enabled=false to consumer.ffmpeg.upload_id_enabled=true.

I was working on this at one point, but I'm just getting tired of tracking down all of the fun things the cable companies are shooting down the pipes and just because it plays on their boxes doesn't mean they are doing it correctly. I can all but be certain that the PAT and/or PMT packets are messed up.

I made the changes as shown above the the Opendct properties file, but continue to experience frequent "Missed Recordings" and "Halts" due to failure to recognized channels. I've attached the logs and properties files for review. The missed recording and halts today occurred today between 9:02 and 11:30.
Thanks for taking a look and letting me know what further changes I need to make.

[EnterNoEscape]

Originally Posted by realcap

I made the changes as shown above the the Opendct properties file, but continue to experience frequent "Missed Recordings" and "Halts" due to failure to recognized channels. I've attached the logs and properties files for review. The missed recording and halts today occurred today between 9:02 and 11:30.
Thanks for taking a look and letting me know what further changes I need to make.

Something isn't quite adding up. It looks like OpenDCT got hung up on the last thing it was asked to record. Can you post wrapper.log and the last log from yesterday too?

It also looks like something really tied up your network at the start of this problem. Every other packet seems to be getting dropped from the RTP stream for whatever OpenDCT didn't stop recording before.

[realcap]

Originally Posted by EnterNoEscape

Something isn't quite adding up. It looks like OpenDCT got hung up on the last thing it was asked to record. Can you post wrapper.log and the last log from yesterday too?

It also looks like something really tied up your network at the start of this problem. Every other packet seems to be getting dropped from the RTP stream for whatever OpenDCT didn't stop recording before.

Sorry, could not log into forums today due sagetv server problems. Could not locate sagetv log from night of 18th, it was overwritten, but did have halts again last night, 19th at 11:04, partial log file attached. The log files are too large, my zip7 program will not compress below 750 kb, so copied/zipped partial file. Let me know if you need more and I'll do my best to attach or find another way to get it to you. Thanks for taking another look. Mike

[EnterNoEscape]

Originally Posted by realcap

Sorry, could not log into forums today due sagetv server problems. Could not locate sagetv log from night of 18th, it was overwritten, but did have halts again last night, 19th at 11:04, partial log file attached. The log files are too large, my zip7 program will not compress below 750 kb, so copied/zipped partial file. Let me know if you need more and I'll do my best to attach or find another way to get it to you. Thanks for taking another look. Mike

I am a little curious if the problem is thread starvation. Try changing consumer.ffmpeg.thread_priority=8 to consumer.ffmpeg.thread_priority=9. That will give both threads equal priority instead of giving the RTP thread slightly higher priority.

It also looks like you had another pretty good stretch of dropped RTP packets around 2:09pm-2:14pm. This kind of event is usually the computer being unable to keep up with the flow or too much other network traffic causing the UDP traffic to be dropped before the program could even try to get it.

[realcap]

Originally Posted by EnterNoEscape

I am a little curious if the problem is thread starvation. Try changing consumer.ffmpeg.thread_priority=8 to consumer.ffmpeg.thread_priority=9. That will give both threads equal priority instead of giving the RTP thread slightly higher priority.

It also looks like you had another pretty good stretch of dropped RTP packets around 2:09pm-2:14pm. This kind of event is usually the computer being unable to keep up with the flow or too much other network traffic causing the UDP traffic to be dropped before the program could even try to get it.

Thanks, I changed consumer.ffmpeg.thread_priority=9 and update with results. If this is a network issue, my router may be causing the problem and may need to be upgraded (Netgear WNDR3400)? Which router do you recommend?

Appreciate your efforts and support.