Posts by HelmutB

    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

    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

    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

    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).

    Code: camtweaks.conf
    1. # CAMTWEAK_PACK_MCD 0x10 - pack each CamSlot into a single CA_PMT - for CAMs with limited program slots
    2. # CAMTWEAK_PACK_MTD 0x20 - pack *all* MtdCamSlots into a single CA_PMT - for CAMs with only one program slot
    3. # Example: 0x21,0,<...> tweaks enabled, PACK_MTD (single CA_PMT for MCD+MTD, implicit MCD and unlimited number of programs)

    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

    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