Plugin: DVB Decrypter & Card Client

[routerunner]

Originally Posted by stuckless

I guess, I'd be interested to know more about how this would work, and what would be required to use it.

At the moment this is a DirectShow transformation filter which has two pins (one input and one output). The filter is inserted by STV in the filtergraph that get created for every Digital Capture Device Input STV founds, in particular between the tuner's demodulator output pin and the STV proprietary TS Splitter input pin.

All the TS packet transmitted by the tuner are going through my filter before reaching STV, this way I can descramble the packets without let STV knowing that the packets were actually scrambled

The filter runs in a separated thread environment created by the DirectShow wrapper, however the filter itself spawns four extra threads for each instance (Tuner) which are used during different decryption stages, to talk to the external card server (OSCAM) and to the STV plugin.

Believe it or not I haven't look as the OS code as yet (resisting the temptation until I've got enough free time to commit to any work I might be involved on), so not sure how this approach would fit on Linux, however the most sensible solution to me is to provide a simple wrapper interface to the decryption engine accepting two pointers, one filled with the TS by the agent responsible of capturing the data from the tuner and the other filled by the filter with the result to pass downstream. The buffers must be of the same maximum size and this is normally determined by reading the tuner's capabilities, however the TS packets contained into it can be much less (I normally use this to my advantage, but squeezing more packets into the destination buffer for reasons too long to explain here).

At the moment the filter runs asynchronously, so you can feed the input buffer much quicker and I normally take 1 second of processing before delivering descrambled packet to the output buffer, but that is not a problem in a DirectShow environment, however on Linux we might need to run the filter synchronously.

So far the interest is quite low, I might setup a poll and see if worth the effort, but thanks for your questions.

Cheers
Eddy

[routerunner]

The poll is now open

Eddy

[jamesdisco]

I don't think i'll be moving to linux anytime soon, but i would like a version that works with version 9 on windows.

I think getting a sage client working on one of these would be a nice project for you Eddy

Raspberry pi 3

[routerunner]

Originally Posted by jamesdisco

I don't think i'll be moving to linux anytime soon, but i would like a version that works with version 9 on windows.

Are you saying that the plugin doesn't currently work on STV 9?
I don't see a reason why shouldn't, what I might have said that I didn't want to support it officially in case of issues.

BTW, nice "pi3"...I'll might take a byte at some point

Cheers
Eddy

[stuckless]

Originally Posted by routerunner

All the TS packet transmitted by the tuner are going through my filter before reaching STV, this way I can descramble the packets without let STV knowing that the packets were actually scrambled

The filter runs in a separated thread environment created by the DirectShow wrapper, however the filter itself spawns four extra threads for each instance (Tuner) which are used during different decryption stages, to talk to the external card server (OSCAM) and to the STV plugin.

A few years back, I was running a linux dvb setup (before moving HDPVR), where I was using sasc-ng and a softcam provider. (I was paying twice... once for the legit subscription and again to the softcam provider)

What I thought was cool about this was that sasc-ng exposed the "decrypted" video as standard video4linux devices (/dev/video1), and then any linux video utility could work with it. That being said... While I could tell sagetv to use new video source, sadly, it still didn't work, yet it worked in every other video application on linux

At this point, I'm not sure I'd ever go back to the softcam model, given the HDPVR does work quite well... but, I still think about this from time to time

Originally Posted by jamesdisco

I think getting a sage client working on one of these would be a nice project for you Eddy

Raspberry pi 3

Not sure I ever saw the point in the $35 pi client. It would be possible to create a thin client for it... but by time you add in the extras, like a case, remote, etc, I think the $99 Nexus Player would actually be a better client, for the money, and would likely work better. And the Nexus would uses hardware decoding for h264, h265, and mpeg2.

If you've ever used the sagetv miniclient, on linux, you'll know it's full of glitches. At this point the Android client works much better than the native linux client.

[deanm]

Originally Posted by routerunner

Are you saying that the plugin doesn't currently work on STV 9?
I don't see a reason why shouldn't, what I might have said that I didn't want to support it officially in case of issues.
Eddy

I can confirm this plugin works fine with STV 9. Been running this plugin with Windows 10 and STV 9 for a long time.

Dean

[deanm]

Originally Posted by routerunner

I was wondering whether anyone would be interested to see this software working on Linux as well?

Hi Eddy,

I see there is not much interest in this being made available for Linux. I have voted yes to this. At present my STV Server is Windows but in the future I think I would like to move across but this Plugin is a must have feature for me.

Dean

[jamesdisco]

Dean

How would you import the epg into sage in Linux. Is there a way to get the digiguide into sage with Linux.

[deanm]

Originally Posted by jamesdisco

Dean

How would you import the epg into sage in Linux. Is there a way to get the digiguide into sage with Linux.

Yes good point. Never thought about that

Dean

[routerunner]

Originally Posted by syrel

Hi Eddy

I'm strictly Windows-only, so wouldn't be of use to me. Glad to see you're still engaged with the project though!

syrel

Indeed, I've just completed my current contract and whilst awaiting to start a new one in a couple of weeks I am back to the whiteboard for the next exciting feature

Cheers
Eddy

[syrel]

Just a quick note in case anyone has the same problem - I have found that when Oscam is running, I cannot put the system time back in Windows. I could move the time forwards, but not back. Over time, this was causing problems with my recording schedule. I ended up pulling the computer apart assuming a hardware problem, only to find (after several days!) it was Oscam. Eddy, I also tried a non-Rossisoft version of Oscam but it had the same affect, so it's not something you added to the code.

Anyway, this is just in case anyone ends up pulling their hair out over the same problem I did. My solution now is to run a time sync programme at every startup, before Oscam gets loaded.

syrel

[routerunner]

Originally Posted by syrel

Just a quick note in case anyone has the same problem - I have found that when Oscam is running, I cannot put the system time back in Windows. I could move the time forwards, but not back. Over time, this was causing problems with my recording schedule. I ended up pulling the computer apart assuming a hardware problem, only to find (after several days!) it was Oscam. Eddy, I also tried a non-Rossisoft version of Oscam but it had the same affect, so it's not something you added to the code.

Anyway, this is just in case anyone ends up pulling their hair out over the same problem I did. My solution now is to run a time sync programme at every startup, before Oscam gets loaded.

syrel

How bizarre...I never came across this behaviour before. I will look into the OsCAM code at some point to shed some light, in the meantime I'm glad you've found a workaround.

I always run OsCAM on my system using a scheduled task around 10 minutes after the system is up, that's probably why I never seen this happening, also in my configuration I run a very stripped down version of OsCAM on a Linux box where the card reader is connected to which in turn connects to the OsCAM instance running on Windows and found this approach very reliable and fast with ECMs well below the 100msecs, something I could never been able to achieve when the reader was connected to my Windows machine with only one instance of OsCAM running.

cheers
Eddy

[deanm]

Originally Posted by syrel

Just a quick note in case anyone has the same problem - I have found that when Oscam is running, I cannot put the system time back in Windows. I could move the time forwards, but not back. Over time, this was causing problems with my recording schedule. I ended up pulling the computer apart assuming a hardware problem, only to find (after several days!) it was Oscam. Eddy, I also tried a non-Rossisoft version of Oscam but it had the same affect, so it's not something you added to the code.

Anyway, this is just in case anyone ends up pulling their hair out over the same problem I did. My solution now is to run a time sync programme at every startup, before Oscam gets loaded.

syrel

I wish I had known this a few months back. Had this happen on one of my servers and never did find the issue. Changed the BIOS battery reinstalled Windows etc. In the end I changed the mother board as it was in need of being replaced.

Not seen this happen on the new server or my other server. Do think there is something else happening here and not just OSCAM that causes this.

Dean

[syrel]

Originally Posted by deanm

I wish I had known this a few months back. Had this happen on one of my servers and never did find the issue. Changed the BIOS battery reinstalled Windows etc. In the end I changed the mother board as it was in need of being replaced.

Tell me about it. Spent ages on the problem and ended up completely rebuilding my server, only to find the exact same problem

TBH, am glad to hear of someone else having the same problem, as was wondering what was specific about my set up to cause it. Clearly it hasn't happened to everyone, or we would have heard something. All I know is that I have had the situation of two PCs - they both have been set up similarly, so it's possible that Oscam + mystery factor is the real culprit, but I didn't have the problem before I installed Oscam, and the moment I stop it the problem goes away...

syrel

[alland]

Eddy

My setup has been running relatively stable for a while. After a blue screen last night I had a nose around the Windows event logs.

I found lots of entries in the security log saying that OSCAM had been changing the system time. Any ideas why ?

Running on Win 10.

Log Name: Security
Source: Microsoft-Windows-Security-Auditing
Date: 15/05/2016 3:49:11 PM
Event ID: 4616
Task Category: Security State Change
Level: Information
Keywords: Audit Success
User: N/A
Computer: XXXXX
Description:
The system time was changed.

Subject:
Security ID: SYSTEM
Account Name: XXXXX
Account Domain: WORKGROUP
Logon ID: 0x3E7

Process Information:
Process ID: 0x34c
Name: C:\Program Files\SageTV\SageTV\CAM\oscam.exe

Previous Time: ‎2016‎-‎05‎-‎15T03:49:11.912217700Z
New Time: ‎2016‎-‎05‎-‎15T03:49:11.912000000Z

This event is generated when the system time is changed. It is normal for the Windows Time Service, which runs with System privilege, to change the system time on a regular basis. Other system time changes may be indicative of attempts to tamper with the computer.
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="Microsoft-Windows-Security-Auditing" Guid="{54849625-5478-4994-A5BA-3E3B0328C30D}" />
<EventID>4616</EventID>
<Version>1</Version>
<Level>0</Level>
<Task>12288</Task>
<Opcode>0</Opcode>
<Keywords>0x8020000000000000</Keywords>
<TimeCreated SystemTime="2016-05-15T03:49:11.911763200Z" />
<EventRecordID>768962</EventRecordID>
<Correlation />
<Execution ProcessID="4" ThreadID="5504" />
<Channel>Security</Channel>
<Computer>XXXXX</Computer>
<Security />
</System>
<EventData>
<Data Name="SubjectUserSid">S-1-5-18</Data>
<Data Name="SubjectUserName">XXXXX$</Data>
<Data Name="SubjectDomainName">WORKGROUP</Data>
<Data Name="SubjectLogonId">0x3e7</Data>
<Data Name="PreviousTime">2016-05-15T03:49:11.912217700Z</Data>
<Data Name="NewTime">2016-05-15T03:49:11.912000000Z</Data>
<Data Name="ProcessId">0x34c</Data>
<Data Name="ProcessName">C:\Program Files\SageTV\SageTV\CAM\oscam.exe</Data>
</EventData>
</Event>

[JREkiwi]

Looks like it was a change that came in here in build 9832

http://www.streamboard.tv/oscam/changeset/9832

Appears the rational is that you don't want the time changing while OsCAM is doing it's stuff as that throws out ECM timing

John

[alland]

John

Thanks, I also noticed that the system times which are changed are truncated to 3 decimal places.For example

Previous Time: ‎2016‎-‎05‎-‎16T05:05:38.506977400Z
New Time: ‎2016‎-‎05‎-‎16T05:05:38.507000000Z

Previous Time: ‎2016‎-‎05‎-‎16T05:05:38.507010300Z
New Time: ‎2016‎-‎05‎-‎16T05:05:38.507000000Z

Previous Time: ‎2016‎-‎05‎-‎16T05:05:38.507078000Z
New Time: ‎2016‎-‎05‎-‎16T05:05:38.507000000Z

Previous Time: ‎2016‎-‎05‎-‎16T05:05:38.507132100Z
New Time: ‎2016‎-‎05‎-‎16T05:05:38.507000000Z

.....

Previous Time: ‎2016‎-‎05‎-‎16T05:02:47.832816100Z
New Time: ‎2016‎-‎05‎-‎16T05:02:47.832000000Z

I will suppress this event ID in the meantime to avoid the overhead of writing log entries.

[routerunner]

Originally Posted by JREkiwi

Looks like it was a change that came in here in build 9832

http://www.streamboard.tv/oscam/changeset/9832

Appears the rational is that you don't want the time changing while OsCAM is doing it's stuff as that throws out ECM timing

John

Thank you John for finding this. Don't have much time to look into issues these days

Eddy

[routerunner]

Originally Posted by alland

John

Thanks, I also noticed that the system times which are changed are truncated to 3 decimal places.For example

Previous Time: ‎2016‎-‎05‎-‎16T05:05:38.506977400Z
New Time: ‎2016‎-‎05‎-‎16T05:05:38.507000000Z

Previous Time: ‎2016‎-‎05‎-‎16T05:05:38.507010300Z
New Time: ‎2016‎-‎05‎-‎16T05:05:38.507000000Z

Previous Time: ‎2016‎-‎05‎-‎16T05:05:38.507078000Z
New Time: ‎2016‎-‎05‎-‎16T05:05:38.507000000Z

Previous Time: ‎2016‎-‎05‎-‎16T05:05:38.507132100Z
New Time: ‎2016‎-‎05‎-‎16T05:05:38.507000000Z

.....

Previous Time: ‎2016‎-‎05‎-‎16T05:02:47.832816100Z
New Time: ‎2016‎-‎05‎-‎16T05:02:47.832000000Z

I will suppress this event ID in the meantime to avoid the overhead of writing log entries.

Linux and Windows have different time resolution. When compiling for Windows is Cygwin runtime that does its best to match the two environment...

Eddy

[routerunner]

Originally Posted by alland

Eddy

My setup has been running relatively stable for a while. After a blue screen last night I had a nose around the Windows event logs.

I found lots of entries in the security log saying that OSCAM had been changing the system time. Any ideas why ?

Running on Win 10.

Log Name: Security
Source: Microsoft-Windows-Security-Auditing
Date: 15/05/2016 3:49:11 PM
Event ID: 4616
Task Category: Security State Change
Level: Information
Keywords: Audit Success
User: N/A
Computer: XXXXX
Description:
The system time was changed.

Subject:
Security ID: SYSTEM
Account Name: XXXXX
Account Domain: WORKGROUP
Logon ID: 0x3E7

Process Information:
Process ID: 0x34c
Name: C:\Program Files\SageTV\SageTV\CAM\oscam.exe

Previous Time: ‎2016‎-‎05‎-‎15T03:49:11.912217700Z
New Time: ‎2016‎-‎05‎-‎15T03:49:11.912000000Z

This event is generated when the system time is changed. It is normal for the Windows Time Service, which runs with System privilege, to change the system time on a regular basis. Other system time changes may be indicative of attempts to tamper with the computer.
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="Microsoft-Windows-Security-Auditing" Guid="{54849625-5478-4994-A5BA-3E3B0328C30D}" />
<EventID>4616</EventID>
<Version>1</Version>
<Level>0</Level>
<Task>12288</Task>
<Opcode>0</Opcode>
<Keywords>0x8020000000000000</Keywords>
<TimeCreated SystemTime="2016-05-15T03:49:11.911763200Z" />
<EventRecordID>768962</EventRecordID>
<Correlation />
<Execution ProcessID="4" ThreadID="5504" />
<Channel>Security</Channel>
<Computer>XXXXX</Computer>
<Security />
</System>
<EventData>
<Data Name="SubjectUserSid">S-1-5-18</Data>
<Data Name="SubjectUserName">XXXXX$</Data>
<Data Name="SubjectDomainName">WORKGROUP</Data>
<Data Name="SubjectLogonId">0x3e7</Data>
<Data Name="PreviousTime">2016-05-15T03:49:11.912217700Z</Data>
<Data Name="NewTime">2016-05-15T03:49:11.912000000Z</Data>
<Data Name="ProcessId">0x34c</Data>
<Data Name="ProcessName">C:\Program Files\SageTV\SageTV\CAM\oscam.exe</Data>
</EventData>
</Event>

As a workaround you could possibly try to run the OsCAM instance that deals with the card reader on a Linux box if you have one available like an RPi and the second instance running on Windows as normal.

I run a similar setup and don't have this issue...

Eddy