[dvbapi 2.0] Sometimes blackscreen while switching channels

[3PO]

Hi,

since the the update to vdr-2.1.4 and dvbapi-2.0 i have a stange behavior.

When i switch to encrypted channel, the channel will in some cases not be decrytetd. :(

The issue in the logfile, in this cases, are not very "verbose".

Feb 02 18:32:46 [vdr] [4491] DVBAPI: Action: Got CA_SET_DESCR request, adapter_index=0 Feb 02 18:32:46 [vdr] [4491] DVBAPI: SetDescr Feb 02 18:32:46 [vdr] [4491] DVBAPI: 0.0: odd key set Feb 02 18:32:46 [vdr] [4407] DVBAPI: 0.0 CA_PMT decoding len=1f lm=5 prg=130 len=19 Feb 02 18:32:46 [vdr] [4407] DVBAPI: ci_cmd(G)=01 Feb 02 18:32:46 [vdr] [4407] DVBAPI: 0.0 got CA pmt ciCmd=1 caLm=5 Feb 02 18:32:46 [vdr] [4407] DVBAPI: 0.0 answer to query surpressed Feb 02 18:32:46 [vdr] [4407] DVBAPI: 0.0 set CAM decrypt (SID 130, caLm 5, HasCaDescriptors 1) Feb 02 18:32:46 [vdr] [4407] DVBAPI: 0.0 CA_PMT decoding len=6 lm=3 prg=0 len=0 Feb 02 18:32:46 [vdr] [4407] DVBAPI: 0.0 got CA pmt ciCmd=-1 caLm=3 Feb 02 18:32:46 [vdr] [4407] DVBAPI: 0.0 answer to query surpressed Feb 02 18:32:46 [vdr] [4407] DVBAPI: 0.0 stop decrypt Feb 02 18:32:46 [vdr] [4407] DVBAPI: 0.0 CA_PMT decoding len=6 lm=3 prg=0 len=0 Feb 02 18:32:46 [vdr] [4407] DVBAPI: 0.0 got CA pmt ciCmd=-1 caLm=3 Feb 02 18:32:46 [vdr] [4407] DVBAPI: 0.0 answer to query surpressed Feb 02 18:32:46 [vdr] [4407] DVBAPI: 0.0 stop decrypt

If i switch, in this case, one channel up and down, all is working as expected.

[manio]

@3PO Ok - my plugin is working ok in both cases, to sum all up: Your first log - as I said the plugin doesn't obtain decrypt request from VDR (don't know the cause but maybe you can ask on VDR forum or the softhddev plugin author). Anyway - if my plugin doesn't got the decrypt request - I obviously cannot do anything.

Your second log: after first switch the oscam got a proper decoding request but just after this it has:

09:16:56   72D480 p vdr_dvbapi_camd3 [cs378x] disconnected: reason rto

I assume it is read timed out - so it's disconnected and cannot provide a keys for the plugin. Then VDR restart the same channel at 09:17:00, and you've got timeout and not found problems from OSCam, finally it started working. Overall: also not a plugin problem - you may report the oscam problem to OSCam developers. But if you have this kind of problems (network and/or card 'timeout'/'not found') please don't expect to have it all working flawless.

[unf]

@manio I'm not using any FF card since 2003 anymore ... ;-)

Here it is a L4M/Cine V6[.2] with an additional Flex Duo Module.

I'll revert DVB drivers back from linux-media-experimental to the kernel ones, this is easy and was one of the changes made before the issue does occur.

[3PO]

OK, but with vdr-2.1.4 and the reverted dvbapi-plugin as described above, this behavior doesnt appear.

[manio]

Guys, Unfortunatelly I'm really out of ideas what could be wrong (especially with @unf problem, as I explained in details my post above what could be wrong on @3PO config). I'm sorry but I don't think it is a problem related with the dvbapi plugin. According to your logs my plugin is decoding properly, so the decoded stream doesn't reach the output plugin for some reason.

Unfortunatelly I don't have similar problems reported from other users. Maybe you can ask/report it on some softhddevice/VDR forums.

The only tips which comes to my mind: Both of you guys have a Cine S2, and both of you are using softhddevice. Maybe this is a tip? Maybe you can check it without softhddevice and see if it is better. The problem occur not always and not on the same channels - this only prooves that my plugin is generally able to provide decrypted stream as the same channel is working one time, while not on another zap. The new VDR's CAM interface which my plugin is using is currently not managing the encrypted and decrypted TS stream, as it did before - in previous approach (v1.0.6); but only decoding TS packet which VDR is providing. I think it may be related with some timing problems in VDR or maybe buggy drivers. Example: I already discovered a problem with buggy poll() in the TBS driver when one user switched from v1.0.6 to v2.0.0 plugin version (current code is simplier and has much less overhead thus working faster - this trigger his timing problem in the driver poll() function).

It may be even problem which Klaus is now trying to solve (http://www.vdr-portal.de/board17-developer/board97-vdr-core/122361-fixed-detecting-broken-video-data-streams-when-recording).

Overall: I still don't think it's a plugin problem. If you're really convinced that it is, please reopen/create another issue and provide a log.

[manio]

OK, last resort: Try this patch: http://pastebin.com/EZ5RVDjA

[artlov]

For the clarity. I have budget card (not Cine S2, but TT-Budget S2-3200) and using softhddevice. With the last versions of VDR, plugin and oscam no black screen occured anymore.

[manio]

@artlov Thank you for your info. At least we know that softhddevice is working fine for you. @3PO Sorry - I closed this issue before I read your comment - reopening as I'd like to know if my patch (http://pastebin.com/EZ5RVDjA) is solving your problem (it should work the same as reverting described above).

[3PO]

[...] I'd like to know if my patch (http://pastebin.com/EZ5RVDjA) is solving your problem (it should work the same as reverting described above).

I'am not sure, if i understand, i think this patch is only for a extended log issue, or i'am wrong??

[3PO]

Here is an other "black screen" with included patch:

--> http://bpaste.net/show/yG25NW7RTma0M16JbRE3/

[manio]

I'am not sure, if i understand, i think this patch is only for a extended log issue, or i'am wrong??

No - it is working the same as reverting those two commits + additional debug

Here is an other "black screen" with included patch

The problem is exactly the same as http://bpaste.net/show/9CEue2mXdLHIxg7cJAZM/, which you provided today. VDR is not requesting channel decode, but stopped it instead. Maybe I'll ask Klaus what could be the cause of this...

[manio]

And if you have applied http://pastebin.com/EZ5RVDjA, then it was the same as my plugin version with reverted the two commits. You also wrote that with VDR 2.1.4 you don't have it - maybe you could go back and retest on this version?

[3PO]

Going back to vdr-2.1.4?

[manio]

Yes, please.

[3PO]

Hmm, going back to vdr-2.1.4 is not really a problem, but i think this is not a solution for the future.

BTW: This behavior is only, when the vdr is running some hours.

[manio]

@3PO I think I cannot do nothing if you don't help me to track the problem down. I know it is not a solution - it is only to be sure if the problem exists in older version. By running 2.1.4 we will see if it is a VDR regression.

You told:

OK, but with vdr-2.1.4 and the reverted dvbapi-plugin as described above, this behavior doesn't appear.

Now you're using 2.1.5 and my master plugin, so the steps to confirm that it was working before are:

1. Revert my plugin version (we did it with the patch)
2. Revert to VDR 2.1.4

I think you now know what I mean. It is the standard way of debugging such bad cases - If it was working before - then revert and step by step trying to confirm facts.

I think we are still trying to find the problem that VDR doesn't try to switch to the channel, so we are talking about this logs: http://bpaste.net/show/9CEue2mXdLHIxg7cJAZM/ http://bpaste.net/show/yG25NW7RTma0M16JbRE3/

because that one was because OSCam disconnects: http://bpaste.net/show/S2FrUKiYDv0xv4BPfh6e/

[manio]

@3PO Despite my efforts I can see no input and little interest in debugging this problem (I can see you're using some version of VDR which is working and updating OSCam, but I can see no logs about the problem you reported and also no responses to my requests). Besides the two subject logs shows that VDR is not asking a CAM for decrypting, so please report it to VDR maillist/forum. Closing.