DVBAPI no CAID

[gligi]

Hi.

dvbapi (1.0.6) works with HD+ germany. dvbapi (1843&000000/0000/EF75/89:53B7D07C67AAFDA3D477E755D9C862A5): found (380 ms)

because of new card with CI, i have compiled the latest version dvbapi (2.1.0-GIT-1203c18). Afterwards everything works just CAID 1843 not (HD+). This is from the log:

[22606] CAM 2: system ids: FFFF [22652] detaching receiver - won't decrypt channel S19.2E-1-1017-61301 with CAM 1 [22652] CAM 1: unassigned

but i.e. sky germany works: dvbapi (1702&000000/0000/0082/93:AAB0C982557E14EC5D1A0AFB7C5745AE): found (560 ms)

is this a bug? tnx

[manio]

Why you are creating an issue for a question? This is not a bug (the value 0xFFFF is a special value for a wildcard CAIDs: ee9b786e5). Closing.

[manio]

ps. If you have problems with CAID 1843 the first place to find a problem is the OSCam itself. The plugin is not filtering CAIDs in any way.

[gligi]

So why it works with version 1 and not with version 2?

[manio]

Can you please provide me a debug logs for both versions?

[gligi]

v1 http://pastebin.com/dFjU6zqt v2 http://pastebin.com/febeuEfS

[manio]

Can you schedule a recording from the 1843 CAID using v2? See if it is recording correctly (give it some time to start).

[manio]

Here are my assumptions: You have one real CI slot and one from the plugin. In the old plugin version it is initialized in the following order:

May 22 13:27:30 xbmcubuntu vdr: [24184] CAM 1: system ids: 0500 0648 091F 098C 09AF 09C4 0B00 1702 1830 1833 1843 1860 5601
May 22 13:27:32 xbmcubuntu vdr: [24185] CAM 2: system ids: 1830 1811

CAM1 is the plugin, CAM2 is your hardware CI

In new version it is inverted:

May 22 13:20:47 xbmcubuntu vdr: [23768] CAM 1: system ids: 1830 1811
May 22 13:20:43 xbmcubuntu vdr: [23772] CAM 2: system ids: FFFF

CAM1 is your hardware CI, CAM2 is the plugin

While in both cases your streamdev plugin is trying only the first CAM:

May 22 13:27:47 xbmcubuntu vdr: [24187] CAM 1: assigned to device 1

As a result it is working only in "old" case. The output plugin (streamdev) should stay on channel, detach receiver and reattach, VDR will automatically swap the CAM and it should start working. That is why I am asking for doing a recording - because VDR is handling this CAM switching correctly.

[manio]

Besides in the v2 you probably don't see a request in the OSCam, right?

[gligi]

the difference between two is: v1 oscam working all remote shares work, but CAID from CI+ module does work, respectively it tries to use oscam.

v2 oscam works for all remote shares except 1843, CI+ is working properly. There is no log for in oscam for 1843, but if i switch to 1702 it works instantly and i get log line in oscam for this caid.

well it does not work with vnsiserver plugin too. i will try to start the recording.

[gligi]

recording works as you assumed (therefore at least is not the oscam problem).. so i am doomed.. :( ok after recording i can stream on caid (1843)... the question is why only this caid does not work? I can switch between 1830 (CI+) and 1702 (Sky) as many time i like (with and without recordings).

[manio]

So my assumptions was correct. Please ask the streamdev plugin author to fix his plugin (to constantly reattaching when channel is not decryptable, this is Klaus recommendation btw) or use eg XVDR.

Thank you for your time and logs. This is not a plugin problem. Closing again.

[gligi]

Please read my comment before closing...

[manio]

I readed all your comments. I don't know what vnsi version you're using but IIRC it is fixed there since some version.

[gligi]

last one and also xvdr did not vork (vdr-plugin-xvdr). As said why this switching does not work only with 1843?

[manio]

I don't know - you maybe need to ask Klaus or on VDR forum how the CAM assigning code is working. One thing is sure - if a CAM cannot decode a channel, another one is asked and a streaming plugin cannot give up on the first try. And as you can see VDR internally handles this correctly (when recording).

[gligi]

Ok I think what is problem. Both provider have the same CAID 1830 so first one gets it... You can close the issue. Should I report this to vdr team?

[manio]

It's closed. Sure, please report wherever you think it belongs.