OpenDCT: An open source digital cable tuner.

[gordyp]

Originally Posted by EnterNoEscape

That's interesting. You just highlighted an issue I never noticed. The installer is giving write permissions one level higher than expected. I fixed this for the next release candidate. I'm not sure if Windows is preventing this from working or if your have some anti-virus preventing it from working.

I had this exact same problem

https://forums.sagetv.com/forums/sho...postcount=1120

and I ended up switching antivirus vendors because of it - I couldn't disable the AV to get the file installed; I had to completely remove it each time! Are you using McAfee AV by chance?

[EnterNoEscape]

Originally Posted by gordyp

I had this exact same problem

https://forums.sagetv.com/forums/sho...postcount=1120

and I ended up switching antivirus vendors because of it - I couldn't disable the AV to get the file installed; I had to completely remove it each time! Are you using McAfee AV by chance?

The good news is that future releases will not have this problem. So you can switch back if you want.

[waylo]

Originally Posted by jhkoenig

AlphaCrew, I shared your hesitation to upgrade from my "perfectly good" v7 installation. Not touched for 6 years, I think.

Then I upgraded to v( in an attempt to eliminate some stuttering. After some study and preparation, the upgrade took 5 minutes. Also kept a copy of the originial v7 directory, so if things went badly I could have rolled back with trivial effort.

Now I'm prepared for the summer cataclysm of losing the EPG feed as a side benefit.

Can you tell me more about this loss of EPG feed? I'm guessing there's a significant discussion somewhere else on this thread about it?

[jhkoenig]

The EPG feed is going away 7/1/17 per: https://forums.sagetv.com/forums/showthread.php?t=63884 but there is an inexpensive subscription replacement for v9.

[waylo]

Thanks, did some quick searching and there's quite a bit of chatter about it, for obvious reasons. Looks like I now have a new urgently fun project to tackle =)

[Fuzzy]

Originally Posted by waylo

Thanks, did some quick searching and there's quite a bit of chatter about it, for obvious reasons. Looks like I now have a new urgently fun project to tackle =)

I'm not sure I'd call it urgent. with 6 months of lead time.

[SteveW]

Originally Posted by EnterNoEscape

That's interesting. You just highlighted an issue I never noticed. The installer is giving write permissions one level higher than expected. I fixed this for the next release candidate. I'm not sure if Windows is preventing this from working or if your have some anti-virus preventing it from working.

Ya, thought of that. Disabled ESET and tried again and same thing. It's definitely Windows related. I haven't tried playing with UAC. I'll wait for your update to come out first.

Tnx

[AlphaCrew]

Originally Posted by Fuzzy

One of the first improvements made to v9 was in the more robust detection of network encoders like OpenDCT. If a decoder is found to be non-functioning, like may happen right after waking, it will continue checking it until it is found. v7 would essentially forget about it until something asked about it (usually by navigating to the source details screen, where it shows Functioning: True/False).

Also, the 'conflict manager' is not something that runs separate from the rest. SageTV has one scheduler that does all it's work, whether it is scheduling manual recordings, favorites, or even figuring out how to watch a given airing live when selected from the guide. It will always be doing its best with what it has to find the best way to record everything you want it to, and if at any point it finds it cannot, it will notify you of with the conflict icon. Many things will trigger the scheduler to rebuild the schedule: waking, changing the watched/don't like of an airing, watching an airing, an EPG update, time passing, a channel being added or removed or an encoder going on or offline. Upgrading to v9 will likely improve your situation.

So I guess my question is why does the act of opening up a SageTV UI cause the 'conflict manager' to "fix" the schedule. Nothing else will cause it to happen, even rebooting the machine doesn't do it?

Originally Posted by jhkoenig

AlphaCrew, I shared your hesitation to upgrade from my "perfectly good" v7 installation. Not touched for 6 years, I think.

Then I upgraded to v( in an attempt to eliminate some stuttering. After some study and preparation, the upgrade took 5 minutes. Also kept a copy of the originial v7 directory, so if things went badly I could have rolled back with trivial effort.

Now I'm prepared for the summer cataclysm of losing the EPG feed as a side benefit.

I'm extremely hesitant at this point. In my world, (I'm the guy who can open up a can of mixed fruit to only find syrup.) problems typically compound.

I hope you guys are around Saturday...

[Fuzzy]

Originally Posted by AlphaCrew

So I guess my question is why does the act of opening up a SageTV UI cause the 'conflict manager' to "fix" the schedule. Nothing else will cause it to happen, even rebooting the machine doesn't do it?

Without seeing a log, I can't tell you exactly what is going on when you are having these issues (can't necessarily tell what exact issue you are having). The scheduler can run quite often, for a number of reasons (most of which I posted above, but I think a client connecting to the server will cause it to run as well). While the scheduler is running, it is possible to see the conflict icon show up momentarily at the top, depending on what it needs to deal with in the scheduling process.

[BigMac]

Running V7 and migrated to OpenDct 32bit (now on 0.5.13) in Sept 2016 and it was smooth upgrade and no problems. In the last 1 1/2 I've gotten a strange behavior where once a week my tuners disappear, Jave.exe and wrapper.exe are running excessively and the wrapper.log file has exploded to eat ALL the disk space left (80-100 GBytes).

I have Comcast and I've seen an occasional error happen on live TV impacting a number of channels at the same time but when observed (Heisenberg principle) SageTV (and OpenDct) recover with a small outage in the recorded program. Of course when I'm not observing, late into the night, something happens and it tanks the tuners.

I've been able to recover without rebooting by stopping SageTV and OpenDct services and deleting the wrapper.log file and starting everything up again. I wanted to open the wrapper.log file but it's too big.

Not sure if the tuners disappear because of a primary cause or secondary because there is no more disk space.

Any suggestions.

BigMac

[EnterNoEscape]

Originally Posted by BigMac

Running V7 and migrated to OpenDct 32bit (now on 0.5.13) in Sept 2016 and it was smooth upgrade and no problems. In the last 1 1/2 I've gotten a strange behavior where once a week my tuners disappear, Jave.exe and wrapper.exe are running excessively and the wrapper.log file has exploded to eat ALL the disk space left (80-100 GBytes).

I have Comcast and I've seen an occasional error happen on live TV impacting a number of channels at the same time but when observed (Heisenberg principle) SageTV (and OpenDct) recover with a small outage in the recorded program. Of course when I'm not observing, late into the night, something happens and it tanks the tuners.

I've been able to recover without rebooting by stopping SageTV and OpenDct services and deleting the wrapper.log file and starting everything up again. I wanted to open the wrapper.log file but it's too big.

Not sure if the tuners disappear because of a primary cause or secondary because there is no more disk space.

Any suggestions.

BigMac

Do you have opendct.log? If the log doesn't have any relevant dates, you can check the archive directory for one from the date and time when this happened. My best guess is that wrapper.log was trying to rotate and for some reason it was being locked by the OS, so it couldn't rotate and it might have been logging the fact that it couldn't rotate over and over. OpenDCT also tracks it's overall filesystem usage and will start deleting old logs if it realizes the overall space used by logging is getting ridiculous.

[EnterNoEscape]

• Added check for valid modulation for InfiniTV ClearQAM tuning.
• Added some InfiniTV detection between QAM64 and QAM256 when it is not clear what needs to be used.
• Adjusted default timeout for detection of network interfaces after standby to 4 minutes.
• Relaxed timing on detection of network interfaces after standby.
• Fixed some issues with the JSON web interface.
• Fixed the Windows installer adding write permissions to the wrong folder.

[KarylFStein]

I tried installing RC3 and was having trouble with it working. I uninstalled and wiped the ProgramData files and reinstalled. When running the as console it kept saying that InfinitTV interface #2 was detected and extending wait, then it said that there was no IP for the interface (log snippit below). This repeated until I hit CTRL-C and the tuners were not populated in my properties file. I uninstalled, cleaned up the ProgramData files and installed 0.5.18. This time running as console found everything fine. After checking that everything was working I tried installing RC3 again this time on top of the existing install keeping the properties file. But I still get the error in the logs and SageTV sees the device and not working. Uninstalled, cleaned up and installed 0.5.18, which is working fine.

Hardware is an InfiniTV 6 PCIe card.

INFO   | jvm 1    | 2017/01/19 09:56:49.000 | 09:56:48.953 [WrapperSimpleAppMain] INFO  NetworkPowerEventManger - InfiniTV network interface 'Ceton InfiniTV Network Device #2' detected. Extending wait...
INFO   | jvm 1    | 2017/01/19 09:56:57.094 | 09:56:57.016 [WrapperSimpleAppMain] INFO  NetworkPowerEventManger - InfiniTV network interface 'Ceton InfiniTV Network Device' detected without IP address. Extending wait...
INFO   | jvm 1    | 2017/01/19 09:57:08.137 | 09:57:08.090 [WrapperSimpleAppMain] INFO  NetworkPowerEventManger - InfiniTV network interface 'Ceton InfiniTV Network Device #2' detected. Extending wait...
INFO   | jvm 1    | 2017/01/19 09:57:16.231 | 09:57:16.122 [WrapperSimpleAppMain] INFO  NetworkPowerEventManger - InfiniTV network interface 'Ceton InfiniTV Network Device' detected without IP address. Extending wait...
INFO   | jvm 1    | 2017/01/19 09:57:27.169 | 09:57:27.153 [WrapperSimpleAppMain] INFO  NetworkPowerEventManger - InfiniTV network interface 'Ceton InfiniTV Network Device #2' detected. Extending wait...
INFO   | jvm 1    | 2017/01/19 09:57:35.262 | 09:57:35.215 [WrapperSimpleAppMain] INFO  NetworkPowerEventManger - InfiniTV network interface 'Ceton InfiniTV Network Device' detected without IP address. Extending wait...
INFO   | jvm 1    | 2017/01/19 09:57:46.309 | 09:57:46.262 [WrapperSimpleAppMain] INFO  NetworkPowerEventManger - InfiniTV network interface 'Ceton InfiniTV Network Device #2' detected. Extending wait...
INFO   | jvm 1    | 2017/01/19 09:57:54.403 | 09:57:54.294 [WrapperSimpleAppMain] INFO  NetworkPowerEventManger - InfiniTV network interface 'Ceton InfiniTV Network Device' detected without IP address. Extending wait...

[EnterNoEscape]

Originally Posted by KarylFStein

I tried installing RC3 and was having trouble with it working. I uninstalled and wiped the ProgramData files and reinstalled. When running the as console it kept saying that InfinitTV interface #2 was detected and extending wait, then it said that there was no IP for the interface (log snippit below). This repeated until I hit CTRL-C and the tuners were not populated in my properties file. I uninstalled, cleaned up the ProgramData files and installed 0.5.18. This time running as console found everything fine. After checking that everything was working I tried installing RC3 again this time on top of the existing install keeping the properties file. But I still get the error in the logs and SageTV sees the device and not working. Uninstalled, cleaned up and installed 0.5.18, which is working fine.

Hardware is an InfiniTV 6 PCIe card.

INFO   | jvm 1    | 2017/01/19 09:56:49.000 | 09:56:48.953 [WrapperSimpleAppMain] INFO  NetworkPowerEventManger - InfiniTV network interface 'Ceton InfiniTV Network Device #2' detected. Extending wait...
INFO   | jvm 1    | 2017/01/19 09:56:57.094 | 09:56:57.016 [WrapperSimpleAppMain] INFO  NetworkPowerEventManger - InfiniTV network interface 'Ceton InfiniTV Network Device' detected without IP address. Extending wait...
INFO   | jvm 1    | 2017/01/19 09:57:08.137 | 09:57:08.090 [WrapperSimpleAppMain] INFO  NetworkPowerEventManger - InfiniTV network interface 'Ceton InfiniTV Network Device #2' detected. Extending wait...
INFO   | jvm 1    | 2017/01/19 09:57:16.231 | 09:57:16.122 [WrapperSimpleAppMain] INFO  NetworkPowerEventManger - InfiniTV network interface 'Ceton InfiniTV Network Device' detected without IP address. Extending wait...
INFO   | jvm 1    | 2017/01/19 09:57:27.169 | 09:57:27.153 [WrapperSimpleAppMain] INFO  NetworkPowerEventManger - InfiniTV network interface 'Ceton InfiniTV Network Device #2' detected. Extending wait...
INFO   | jvm 1    | 2017/01/19 09:57:35.262 | 09:57:35.215 [WrapperSimpleAppMain] INFO  NetworkPowerEventManger - InfiniTV network interface 'Ceton InfiniTV Network Device' detected without IP address. Extending wait...
INFO   | jvm 1    | 2017/01/19 09:57:46.309 | 09:57:46.262 [WrapperSimpleAppMain] INFO  NetworkPowerEventManger - InfiniTV network interface 'Ceton InfiniTV Network Device #2' detected. Extending wait...
INFO   | jvm 1    | 2017/01/19 09:57:54.403 | 09:57:54.294 [WrapperSimpleAppMain] INFO  NetworkPowerEventManger - InfiniTV network interface 'Ceton InfiniTV Network Device' detected without IP address. Extending wait...

After 119 attempts, it would have just gone ahead anyway, but I can see the problem here. This was a fix for people with seriously latent InfiniTV cards and was tested against my own InfiniTV 6 and InfiniTV 4 plus at least one other user that was having the problem this fixed. I have an idea on how to address it. I might get that out later today.

[EnterNoEscape]

I was also thinking that if it was bridged, this detection logic might fail. Perhaps it was a bad idea. I'll need to do some thinking.

[nyplayer]

I had to change back to opendct.consumer.FFmpegTransSageTVConsumerImpl from opendct.consumer.MediaServerConsumerImpl because I could not tune some channels and was getting channel halts.

log Attached at the bottom I was trying to tune ESPN2... 736

[EnterNoEscape]

Originally Posted by nyplayer

I had to change back to opendct.consumer.FFmpegTransSageTVConsumerImpl from opendct.consumer.MediaServerConsumerImpl because I could not tune some channels and was getting channel halts.

log Attached at the bottom I was trying to tune ESPN2... 736

The logs from the SageTV side of things might shed more light on what happened. You're not the only person who isn't able to use the remuxer built into SageTV for all of your channels. Those issues have been getting looked at, but some of them don't have easy fixes.

[nyplayer]

Here are the Sage logs.

https://drive.google.com/open?id=0B3...G1lQmZSUF9kNjA

[waylo]

Originally Posted by EnterNoEscape

The logs from the SageTV side of things might shed more light on what happened. You're not the only person who isn't able to use the remuxer built into SageTV for all of your channels. Those issues have been getting looked at, but some of them don't have easy fixes.

Can you remind those of us who just upgraded to v9 the benefits of the built-in remuxer vs. ffmpeg?

[EnterNoEscape]

The times aren't quite lining up in those files. The SageTV log is just after the OpenDCT log time-wise.