Posts by HelmutB

Ich habe jetzt nachgelesen:

Ab dem Kernel 5.1.12 und damit auch im Kernel 5.2 wird statt dprintk nun dev_dbg verwendet (der Patch im Link in Pos #2) tund damit sollte diese Meldung ab dieser Kernelversion nicht mehr auftauchen.

Helmut

Es hat sich herausgestellt,, daß der Lock in CamSlot::TsPostProcess() ohne MTD zu einem Deadlock des (Master) CamSlots führen kann.

Das Locken muß richtigerweise in cCiTransportConnection::TsPostProcess() erfolgen.

Helmut

Nachdem der camtweaks-2.1 Patch bei den neuen Funktione immer noch fehlerhaft war, hier nun mit etwas Verzögerung der camtweaks-2.2.patch.

Wie es aussieht lassen sich damit nun auch mit der Sky-CAM 2 Programme gleichzeitig aufnehmen.

Für MTD und CI+ ist (unter anderem) auch noch der vdr-2.4.1-Mtd-LockedTsPostProcess.patch von hier erforderlich.

Und damit das CAM bei SIngle-und MCD sowie MTD immer gleich behandelt wird, kann auch noch vdr-2.4.1-Mtd-StopDecrypting.patch von hier eingespielt werden.

Die Einstellung 0x3 sollte unverändert wie in camtweaks-1 funktionieren.

Mit der Option 0x23 werden alle aktiven Progrmme (auch bei MTD) in einer einzigen CA_PMT an das CAM gesendet ( mit 0x13 eine CA_PMT je Transponder ). Das funktioniert bei einigen CAMs problemlos, bei einer meiner CAMs habe ich allerdings Bildstörungen beim Entfernen von Pids festgestellt. Der Erfolg kann also etwas vom Modul abhängen.

Helmut

Das CamSlot::TsPostProcess() des MasterSlot benötigt einen Lock, damit auch bei Zugriff von mehrern MtdCamSlots die modifizierten Daten immer im richtigen TS-Paket landen.

Helmut

Hi Corvy !

First, the camtweaks-2.1.patch is faulty, Sorry, but I spent the the last weeks to make the Sky CI+ CAM working, so i did not post a better Version.

But today i got a possitive feedback and so i will post a new camtweaks2.2.patch in the next hour or so.

And yes, you can delete EnableCaModuleTweaksin setup.conf (if you stay on version2), i did a reneming and forgot to think on the old name in camtweaks1. And that why you had to enable camtweaks again in setup.

BR

Helmut

BTW: the description in your camtweaks.conf should look a little different in version 2 , as there are 2 more possible options to set.

And if you have troubles, the camtweaks1.patch should stil work with vdr-2.4.1

Laut https://www.linuxtv.org/wiki/i…hp/Hauppauge_WinTV-dualHD wird seit Kernelversion 4.7 ein Tuner und erst ab 4.17 beide Tuner unterstützt.

Ubuntu 18.04 dürfte aber Orignal nur den Kernel 4.15 dabei haben: https://wiki.ubuntu.com/BionicBeaver/ReleaseNotes. Es kann also auch daran liegen.

LG

Helmut

Edit: Falls du überhaupt Ubuntu 18.04 benutzt - habe mich da beim Spoiler verschaut

Edit2: Alles Unsinn -du verwendest ja schon schon Kernel 4.19

Helmut

Ich habe es jetzt erst registriert - du verwendest den grafischen "Systemprotokollbetrachter" und siehst syslog / kernlog.

Wenn es stimmt, dann verwendet Ubuntu schon seit längerem nicht mehr "/var/log/messages" sondern eben syslog. Da werden aber alle möglichen Infos angezeigt, auch Kernelmeldungen. Vermutlich siehst du auch Meldungen, bei der die printk Konfiguartion nicht berücksichtigt wird - so wie in dmesg.

Hier eine Erklärung und mit weiterem Link wie man /var/log/messages bei Ubuntu wieder aktiviert,

https://unix.stackexchange.com…where-is-var-log-messages

(ich habe tail -F /var/log/messages immer in einem Terminalfenster laufen)

Helmut

thba1 wrote:

eine Änderung von kernel.printk hier oder wie oben...

Hätte ich auch so gesehen, sitze aber garade an einem Windoes Rechner und kann es nicht überprüfen.

Ich werde es mir am Abend oder Morgen ansehen.

Helmut

Ich verwende Ubuntu nicht, aber gab/gibt es da nicht auch /etc/sysctl.d/10-console-messages.conf in der man die 4 printk Werte dauerhaft vorgeben kann?

Helmut

dprintk ist in dvb_frontend.c als #define dprintk(fmt, arg...) \ printk(KERN_DEBUG pr_fmt("%s: " fmt), __func__, ##arg) definiert.

Es gibt 8 Loglevels:

#define KERN_EMERG "<0>" /* system is unusable*/

#define KERN_ALERT "<1>" /* action must be taken immediately*/

#define KERN_CRIT "<2>" /* critical conditions*/

#define KERN_ERR "<3>" /* error conditions*/

#define KERN_WARNING "<4>" /* warning conditions*/

#define KERN_NOTICE "<5>" /* normal but significant condition*/

#define KERN_INFO "<6>" /* informational*/

#define KERN_DEBUG "<7>" /* debug-level messages*/

Dein Konsole Loglevel siehst du mit: $ cat /proc/sys/kernel/printk (die erste von 4 Zahlen).

Was steht bei dir in der Ausgabe?

Zum Ändern: - z.B. nach einem $ echo "6" > /proc/sys/kernel/printk werden nur die Levels 0 bis 6 an der Konsole angezeigt. Die Level 7 Meldungen sieht man dann nur mit 'dmesg'.

Man kann das loglevel schon beim booten als Kernel Parameter mitgeben: z.B loglevel=3.

Für Ubuntu: https://wiki.ubuntuusers.de/Bootoptionen/

Helmut

Edit: so in etwa: GRUB_CMDLINE_LINUX="loglevel=3 ....."

Diese Meldung ist eigenlich nur für die Treiber-Entwickler gedacht und zeigt welche Werte im Treiber vorgegeben sind.

Fehlende oder falsche Werte werden dann aber automatisch korrigiert bzw. angepasst. Es ist also keine Fehlermeldung und man kann sie ignorieren.

Seit diesem Commit scheint die Meldung im Kernel auf: https://git.kernel.org/pub/scm…da4f7d00b9e204f9f89287fad

Helmut

Hallo,

das ist eine Debug Meldung von drivers/media/dvb-core/dvb_frontends.c. Dass die Warnung aber permanent angezeigt wird, gibt es erst seit dem Kenel 5.x.

Vielleicht hilft dir dieser Patch: https://patchwork.kernel.org/patch/10953201/

Helmut

cCamSlot::TsPostProcess() ist noch nicht MTD-fähig da die TransportConnections nur der MasterSlot kennt. mtdCamSlots können TsPostProcess() nicht anstossen.

Dieser Patch sollte auch einem Plugin helfen, das bisher im MTD Modus nicht funktioniert hat.

Helmut

cCamSlot::StopDecrypting() leert die ciCaProgramList des CamSlot und und löscht die CA_PMTs aus der CAM.

Im MTD Modus hatte StopDecrypting() aber entweder keine Funktion da sie nur auf den (inaktiven) MasterSlot angewendet wurde, oder sie war nur auf einen mtdCamSlot beschränkt. Das Leeren der CAM fand in keinem Fall statt. Dieser Patch sollte das korrigieren.

Helmut

Das ist eigentlich ein Patch für vdr-2.4.1, ist vom Thema her auch hier richtig.

Mit dem vdr-2.4.0-26-fix-shared-ca-pids.diff werden shared ca-pids derzeit gar nicht mehr entfernt da auch die inaktiven Programme in der caProgramList vorhanden sind und so die shared ca-pids immer wieder gefunden werden.

Es sollte nur gegen die ca-pids der tatsächlich noch aktiven Programme geprüft werden,

Helmut

Ich habe mich letztes Wochenende zu sehr auf dieses packen der CA_PMT konzentriert, dass ich, nach einer letzten kleinen Änderung, den "Normal" Modul nicht aufmerksam getestet habe. Daher ist mir auch nicht aufgefallen, des er mit dem obigen Patch nicht mehr richtig funktioniert.

Auch beim mitzählen der aktven Programme war noch ein Fehler.

Hier nun ein Update in dem diese Fehler behoben sind.

Zusätzlich habe ich noch eine kleine Ergänzung beim Entfernen von Pids eingefügt, da ich auch Pobleme nach mehrmaligem Umschalten bei einer laufenden Aufnahme festgestellt habe. Nun werden die aktuell zu entfernenden Pids einmalig mit "NOT_SELECTED" in die CA_PMT aufgenommen. Das hat bei mir geholfen - ist aber vielleicht auch CAM-abhängig.

kamel5 - ist in etwa wie im der sid9.patch - ich hoffe, es gibt keine Verschlechterung bei dir.

Helmut

Hier eine neue Version des CamTweak Patch, die es ermöglicht, das Programm Limit von Ca-Modulen anzuheben.
Dazu wird nicht wie sonst üblich für jedes Programm eine eigene CA_PMT an das CAM übertragen, sondern alle Programme (Stream- und ECM-Pids) eines CamSlot bzw. bei MTD auch aller MtdCamslots in eine einzelne CA_PMT gepackt.

Das Programm Limit hängt dann nur von der möglichen Anzahl der Pids ab, die das CAM aufnehmen kann.

Es gibt dazu 2 neue Optionen in der camtweaks.conf, die beste und einfachste wäre der Wert 0x21 (MTD) onder 0x25 (nur MCD).

Ich kann nun mit dem SimpiTv-Modul statt 2 nun auch 7 Programme gleichzeitig entschlüsseln.

Jun 24 23:48:27 gentoo64vdr vdr[2942]: [2942] SendCaPmts(MTD) CAM 1: [0] actives in CAM: 7 -> 7 (20 pids)

Es funktioniert grundsätzlcih auch mit der Sky CAM - allerdings mit ein paar Einschränkungen wie sich bei den Tests von kamel5 herausgestellt hat.

- Maximal 2 Programme gleichzeitig - vermutlich eine Beschränkung auf 6 Stream-Pids

- MTD it derzeit noch nicht möglich - nicht einmal die Simulation mit KEEPPIDS in mtd.c

- Beim Hin- und Herzappen auf andere Kanäle während einer laufenden Aufnahme kömmt irgendwann der Punkt wo der 2. Kanal nicht mehr

entschlüsselt wird (das passiert manschmal schon nach 8 oder auch erst nach 50 mal), Es ist aber noch nicht klar warum das so ist und ob es nur bei der SKY CAM Auftritt.

Wenn jemand den Patch testen möchte - ein paar Erfahrungsberichte wären sehr interessant.

Helmut

kls wrote:

Zusätzlich habe ich die DVBSky S952 v3 beigelegt,

Hat DD auch diese Karte mit dem PCie Analyzer getestet? Es wäre interessant zu wissen, ob es damit auch diese unerwarteten "Nak"s gibt.

Helmut

kamel5 wrote:

Mit dem letzten Patch wird es auch noch nicht hell:

Weil ich nicht bemerkt habe, das die ECM-Pids immer nur auf Programm-Ebene in die caPMT eingetragen und damit auf alle EsPids angewendet wurden. Mein Test mit 4 Programmen war nur deshalb erfolgreich, weil sie alle die gleiche ECM-Pid verwenden (shared Pids).

Hier nun ein Patch, der die zur EsPid passende ECM-Pid auf Stream-Ebene in die caPMT einträgt. Läuft so bei mir nun auch mit mehreren Programmen und unterschiedlichen ECM-Pids.

kamel5 : der Plugin-Patch ist nicht erforderlich, die Debug-Ausgaben sind in diesem Patch enthalten

Helmut

I dont know if this is CAM related, At least no CRC-errors in your logfiles.

VNSI: Channel: no data 16 - have you seen this: https://github.com/FernetMenta…ugin-vnsiserver/issues/97 - discussed here too: Kodi18 / VNSI Plugin .

Helmut