CI-Unterstützung für CineS2, Mystique SaTiX-S2 Dual usw.

Der Patch tut, was er soll, gute Arbeit!

Das harte und das weiche CAM gehen wieder.

Vielen Dank nochmals!

Mit vdr-2.4.0 geht es aber immer noch nicht.

Zitat von jrie

Mit vdr-2.4.0 geht es aber immer noch nicht.

Ich kann mir nicht vorstellen, dass das am ddci2 Plugin liegt.

Vielleicht kann dir Klaus ja beim Debuggen helfen.

Ja, meine ursprüngliche Annahme, es müsse an ddci2 oder am ACL liegen ist offensichtlich falsch. Es liegt am vdr.

Stört das hier? Dann könnte man die Beiträge in einen anderen Thread auslagern.

Mein Verständnis ist nur sehr oberflächlich.

Ich habe ein paar printf‘s in vdr-2.4.0 eingebaut.

Vielleicht blicke ich aber auch nur nicht richtig durch …

Auf dem Transponder sind 4 Sender, die alle die 3 selben ECM Pids haben.

Beim Hinschalten werden diese 12 CaPids hinzugefügt, beim Wegschalten werden diese 12 CaPids gelöscht. Auch wenn sie noch benötigt werden.

Wie werden denn in vdr-2.4.0 shared CaPids geschützt?

hallo,

vdr-2.4.0 macht dass schon richtig - soweit ich den code verstanden habe.

du könntest folgendes testen:
zeile 2504 ci.c
if (GetCaPids(source, transponder, p->programNumber, CaSystemIds, MAXRECEIVEPIDS + 1, CaPids) > 0) {

if (Active)

caPidReceiver->AddPids(CaPids);

else {

++++ FixSharedCaPids(p->programNumber, CaSystemIds, CaPids);

caPidReceiver->DelPids(CaPids);

}

}

falls dies Besserung bringt - bitte unbedingt an klaus melden - der kümmert sich dann.
gruß, onur

Ja, dein Patch hilft auch bei vdr-2.4.0.

Hab Klaus eine PN geschickt.

Bevor ich jetzt das Rad neu erfinde, frage ich lieber erst mal:

Damit der VDR nach den DVB-S2-Karten startet habe ich in /etc/systemd/system/vdr.service.d eine wait-for-devices.conf:

[Unit]
Wants=dev-dvb-adapter0-demux0.device
After=dev-dvb-adapter0-demux0.device
Wants=dev-dvb-adapter0-dvr0.device
After=dev-dvb-adapter0-dvr0.device
Wants=dev-dvb-adapter0-frontend0.device
After=dev-dvb-adapter0-frontend0.device
Wants=dev-dvb-adapter1-demux0.device
After=dev-dvb-adapter1-demux0.device
Wants=dev-dvb-adapter1-dvr0.device
After=dev-dvb-adapter1-dvr0.device
Wants=dev-dvb-adapter1-frontend0.device
After=dev-dvb-adapter1-frontend0.device
Wants=dev-dvb-adapter2-demux0.device
After=dev-dvb-adapter2-demux0.device
Wants=dev-dvb-adapter2-dvr0.device
After=dev-dvb-adapter2-dvr0.device
Wants=dev-dvb-adapter2-frontend0.device
After=dev-dvb-adapter2-frontend0.device

Das CI legt aber ein

/dev/dvb/adapterx/ca0
/dev/dvb/adapterx/sec0

an, wobei adapterx mal adapter0 oder adapter1 oder ... ist.

Wie bekomme ich die sauber getrennt, so dass sich das nicht beisst?

Hi!

Das mit dem ca0 und sec0 in einem getrennten Adapter ist richtig, wenn du das ddci2 Plugin verwenden möchtest.

Wenn du das CI im Kernel fest einen Tuner zuordnen willst (warum auch immer), dann musst du einen Kernel Parameter (adapter_alloc) definieren. Wie das geht, steht irgendwo in diesem Thread.

LG,

Jasmin

Es geht darum, dass für ddbridge jedes Mal dasselbe /dev/dvb/adapterN angelegt wird.

Sonst funktioniert die wait-for-devices.conf nicht.

Ich habe mir jetzt damit beholfen, dass ich in /etc/modprobe.d/50-blacklist.conf ddbridge und die Module für meine DVB-Karten geblacklistet habe, und dann in /etc/init.d/boot.local erst die Module für meine DVB-Karten starte und dann ddbridge.

Dadurch ist das CI dann immer in /dev/dvb/adapter3, statt mal in /dev/dvb/adapter0, mal in /dev/dvb/adapter1, mal in /dev/dvb/adapter2 oder mal in /dev/dvb/adapter3.

Noch einfacher:

cat /etc/modprobe.d/99-local.conf
options budget adapter_nr=0,1,2
options ddbridge adapter_nr=3

Hello! I have also the Digital Devices cards with the DuoFlex CI card reader. I have been running fine now for a few days with the patch for enabling dual-channel descramble and MTD with VDR 2.4.0 but my German is not so good and Google translate is not perfect either. Right now I am on Linux Kernel 4.19.2 since I kind-of gathered that I needed a new driver based on what I read in this thread.

Sometimes I get some stuttering, especially if I watch on two clients at one time, or I do recording at the same time as watch another channel. Some very few times the stream freeze. To try and fix this I upgraded to kernel 4.19.2 and I wonder do I need the patch referenced above?

https://www.vdr-portal.de/inde…0-fix-shared-capids-diff/

From before I run the vdr-2-4-0-camtweaks-1.patch and the vdr-2.4.0-06-fix-channel-switch.diff and also the latest EPG fix patch from Klaus.

Would this aditional patch be needed or is the new driver from updated kernel enough? If someone could explain what is the conclusion from the last ~40 posts in this thread I would be very grateful!

That patch helps, if two (or more) TV stations have the same ECM Pids.

The stuttering is another problem.

If you record several encrypted stations at the same time and check the recordings afterwards with checkts, are they ok? If yes, the problem is at replay, if no, the problem is at recording. Than you can investigate further.

Ok grand, thanks for the tips! I will apply the patch and do some more testing. The recordings were also on a NTFS volume, moved that away and over to Btrfs so hopefully that will solve some issues. Chekts is a good tips, thanks!

Was there a good reason to be a new kernel? Was there some patches or updates applied there? I do not quite understand the statements around that.

Seems my files are all OK

timeshift@timeshift:/srv/vdr/video/vdr-recordings$ find -iname *.ts -exec vdr-checkts {} \;
Errors: 0
Errors: 0
Errors: 0
Errors: 0
Errors: 0
Errors: 0
Errors: 0
Errors: 0
Errors: 0
Errors: 0
Errors: 0
Errors: 0
Errors: 0
Errors: 0
Errors: 0
Errors: 0
Errors: 0
Errors: 0
Errors: 0
Errors: 0
Errors: 0
Errors: 0
Errors: 0
Errors: 0
Errors: 0
Errors: 0
Errors: 0
Errors: 0
Errors: 0
Errors: 0
Errors: 0
Errors: 0
Errors: 0
Errors: 0
Errors: 0
Errors: 0
Errors: 0
Errors: 0
Errors: 0
Errors: 0
Errors: 0
Errors: 0
Errors: 0
Errors: 0
Errors: 0
Errors: 0
Errors: 0
Errors: 0
Errors: 0
Errors: 0
Errors: 0
Errors: 0
Errors: 0
Errors: 0
Errors: 0
Errors: 0
Errors: 0
Errors: 0
Errors: 0
Errors: 0
Errors: 0
Errors: 0
Errors: 0
Errors: 0
Errors: 0
Errors: 0
Errors: 0

Zitat von corvy

Was there a good reason to be a new kernel? Was there some patches or updates applied there?

Yes.

Das ist gut! Danke!