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

  • Du solltest optimalerweise nochmal aus "mediatree/master" compilen und installieren, es ist mittlerweile alles im Upstream, und es gab noch ein paar Changes am Code. Sollte sich mit Deinem 4.14 oder 4.15 eigentlich derzeit sauber compilen lassen (ich compile selber gegen 4.15). EDIT: Achso, den ci_tsfix Modulparameter kannst Du dann auch streichen, das ist jetzt "Default an".


    Danke für Dein Feedback!

    Hallo nst,


    ich habe nochmal mit mediatree/master kompiliert und funktioniert ohne Modulparameter. Danke. Ich nutze aktuell den im master enthaltenen 4.16.


    Allerdings klappt es mit Kernel 4.14 noch nicht. Hier hat es Probleme bei "apply_patches" gegeben, was ich aber noch nicht genauer analysiert habe.

    ASRock J3455M | 8GB Ram | CineS2 v5.5 | Libreelec 9 | MLD4 als chroot in Libreelec

  • ich habe nochmal mit mediatree/master kompiliert und funktioniert ohne Modulparameter. Danke. Ich nutze aktuell den im master enthaltenen 4.16.

    Super, danke Dir fürs Gegentesten (und viel Spass mit 'nem funktionierenden CI an der ngene-Karte :P). D.h. Du hast jetzt direkt aus media_tree ein Kernel Image compiled und in Verwendung?

    Allerdings klappt es mit Kernel 4.14 noch nicht. Hier hat es Probleme bei "apply_patches" gegeben, was ich aber noch nicht genauer analysiert habe.

    Ja, in media_build ist derzeit ein bisschen was im Argen, bedingt durch die ganzen neuen Dinge, die im media Linux Tree gelandet sind.


    EDIT: Nebenbei, das Problem mit der Pufferverschiebung ist wohl schon seit 2011(!) bekannt, siehe https://www.mail-archive.com/l….kernel.org/msg31736.html - ich finde es Bemerkenswert, dass sich da bislang niemand drum gekümmert hat, vor allem zu einer Zeit, als die Karten populärer waren...

    Server: Gigabyte P35-DS4, Intel Core2Duo E6850, 4GB DDR2-RAM (Headless), Gentoo Linux x86_64 / Kernel 4.16.7 / DD CineCTv6+DuoFlex C/T/T2+DuoFlex C/C2/T/T2 w/Kernel Stock Drivers / TVHeadend-GIT-3356759d8

    HTPC: ASRock J5005-ITX (Intel Pentium Silver J5005, 1.5GHz), 8GB SO-DDR4, Intel UHD Graphics 605 in Antec Fusion Remote Black+SoundGraph iMON LCD ( 0038 ), Kodi v18 Leia
    SW: Kodi Krypton+Leia auf allerlei Gerätchen (HTPC: VAAPI+HD-Audio+LCDproc addon / Ubuntu Bionic 18.04 (x86_64), RPi2, NVIDIA Shield Android TV, Wetek Play 1@LibreELEC/NAND, Tablets, Smartphones, Win/Mac/Linux Desktops)

  • Allerdings klappt es mit Kernel 4.14 noch nicht. Hier hat es Probleme bei "apply_patches" gegeben, was ich aber noch nicht genauer analysiert habe.

    Ich habe ja das Warten des media-builds geerbt, nachdem Hans keine Zeit mehr hat.
    Gestern Abend hatte es eigentlich für Kernel 3.8 funktioniert ...

    Hab mir das jetzt angesehen und ... Asche auf mein Haupt ... ich repariere es gleich. Melde mich dann wieder hier.

  • ... ich repariere es gleich. Melde mich dann wieder hier.

    Sollte wieder gehen. Ich habe aber noch was gesehen, was ich fixen sollte.


    EDIT:

    Die Warning "__noretpoline" redefined" ist für Kernel 4.14 / 4.15 nicht im media-build lösbar (zumindest weiß ich noch nicht wie).

    The post was edited 1 time, last by jasminj ().

  • Super, danke Dir fürs Gegentesten (und viel Spass mit 'nem funktionierenden CI an der ngene-Karte :P). D.h. Du hast jetzt direkt aus media_tree ein Kernel Image compiled und in Verwendung?

    Ja, in media_build ist derzeit ein bisschen was im Argen, bedingt durch die ganzen neuen Dinge, die im media Linux Tree gelandet sind.

    Ja, habe nur die alte .config kopiert und direkt Kernel und Module kompiliert. Alles andere hatte nicht geklappt. Eilt für mich aber auch nicht, da es so ja bestens funktioniert für mich. Einzig das Modul i915 hat jetzt das Problem, dass es im Suspend to ram abraucht. Das ist aber eine andere Baustelle und hat nichts mit den Anpassungen hier zu tun, da es auch schon in neueren 4.14er Versionen auftauchte.

    EDIT: Nebenbei, das Problem mit der Pufferverschiebung ist wohl schon seit 2011(!) bekannt, siehe https://www.mail-archive.com/l….kernel.org/msg31736.html - ich finde es Bemerkenswert, dass sich da bislang niemand drum gekümmert hat, vor allem zu einer Zeit, als die Karten populärer waren...

    Ich denke, dass viele damals eine andere, softere Lösung nutzten, wie ich auch. Als diese durch Verheiratung nicht mehr ging, mussten andere Wege gefunden werden. Ich hatte die Cine S2 v5.5 schon lange und hab mir für die Umstellung auf Alphacrypt extra das passende CI-Modul bei eBay besorgt, wodurch dieses Problem erst aufploppte.


    Vielen Dank nochmal für Deinen und Jasmins Einsatz, dass diese Lösung jetzt stabil funktioniert. Ich hoffe, dass das lange so bleiben wird uns sich die Anbieter nicht wieder alles unbrauchbar machen.


    Sollte wieder gehen. Ich habe aber noch was gesehen, was ich fixen sollte.


    EDIT:

    Die Warning "__noretpoline" redefined" ist für Kernel 4.14 / 4.15 nicht im media-build lösbar (zumindest weiß ich noch nicht wie).

    Wenn ich noch was testen kann, gerne her damit. Musst mir nur sagen, von wo ich das laden kann.


    Grüße

    Andreas

    ASRock J3455M | 8GB Ram | CineS2 v5.5 | Libreelec 9 | MLD4 als chroot in Libreelec

  • Wenn Du media_build von meinem GitHub Account geklont hast (https//github.com/herrnst/media_build.git), dann einfach nochmal frisch klonen, es ist alles rebased und alle Fixes von Jasmin, die den Tag über so reingewandert sind, sind da jetzt drin, sollte also alles klappen.

    Server: Gigabyte P35-DS4, Intel Core2Duo E6850, 4GB DDR2-RAM (Headless), Gentoo Linux x86_64 / Kernel 4.16.7 / DD CineCTv6+DuoFlex C/T/T2+DuoFlex C/C2/T/T2 w/Kernel Stock Drivers / TVHeadend-GIT-3356759d8

    HTPC: ASRock J5005-ITX (Intel Pentium Silver J5005, 1.5GHz), 8GB SO-DDR4, Intel UHD Graphics 605 in Antec Fusion Remote Black+SoundGraph iMON LCD ( 0038 ), Kodi v18 Leia
    SW: Kodi Krypton+Leia auf allerlei Gerätchen (HTPC: VAAPI+HD-Audio+LCDproc addon / Ubuntu Bionic 18.04 (x86_64), RPi2, NVIDIA Shield Android TV, Wetek Play 1@LibreELEC/NAND, Tablets, Smartphones, Win/Mac/Linux Desktops)

  • Problem: VNSI Plugin und TsIsScrambled()

    mir ist folgendes aufgefallen:

    bei RTL2 HD(und eventuell andere) werden manche pakete nicht entschlüsselt,

    diese paket haben alle ein AdaptationField - im grunde also keine mpeg daten, nur PCR usw...

    eventuell ist es ein HW (alphacrypt) problem - kann ich wegen fehlender hardware aber nicht testen.

    wer hat zeit und lust das zu debuggen.

    man müsste folgendes testen: gibt es das problem nur mit one4all, nur mit hdplus?

    ist es eventuell ein treiber problem.


    möglicher patch:

  • Danke onur für diesen Hinweis!

    Vielleicht könnte einer der Betroffen das ausprobieren, damit wir das Problem debuggen können.

    Ich bin nach wie vor nicht begeistert, dass VNSI einen CAM Reset einleitet.

    Solche Workarrounds sollte man mit einer Option abschaltbar machen. Dann können sich die User selbst helfen.


    LG,

    Jasmin

  • Ich habe gerade den Hinweis bekommen, dass es sich um einen Bug im Alpha Crypt CAM handeln könnte.

    Das hängt aber vom Stream ab und ob Frames mit einem Adaptation Field (ohne Inhalt) aufgefüllt werden.

    Man könnte das zwar im VDR mit einfügen eines Null Paketes lösen, aber ich halte das schon für eine sehr spezifische AC Anpassung und die sollte nicht in den VDR. Mal warten was Klaus dazu sagt.


    Ich stehe nach wie vor auf dem Standpunkt das VNSI Plugin sollte einen Schalter bekommen, der den CAM Reset verhindert. Oder besser die Logik umkehren und den Reset nur dann auslösen, wenn die Option aktiviert wurde.


    LG,

    Jasmin

  • Ja, besser ins VNSI Plugin, falls die Aufnahmen nicht davon betroffen sind.
    Info: VNSI macht keinen CAM Reset, sondern nur StopDecrypting und RETUNE.
    Frage: mein Cam benötigt ab und zu einen Reset(alle 2 Wochen??), ist das bei euch auch so?

    Eventuell den Patch auf AlphaCrypt CAM beschränken - dann muss aber in folgenden Codeabschnitten Device übergeben werden.

    m_Demuxer.Read(m_Device,&pkt_data, &pkt_side_data);

    int cVNSIDemuxer::Read(cDevice *Device,sStreamPacket *packet, sStreamPacket *packet_side_data)

    int error = stream->ProcessTSPacket(Device,buf, packet, packet_side_data, m_WaitIFrame);

    int cTSStream::ProcessTSPacket(cDevice *Device,uint8_t *data, sStreamPacket *pkt, sStreamPacket *pkt_side_data, bool iframe)

    m_pesParser->ParsePacketHeader(Device,data);

    int cParser::ParsePacketHeader(cDevice *Device,uint8_t *data)


    Onur

  • Wenn Du media_build von meinem GitHub Account geklont hast (https//github.com/herrnst/media_build.git), dann einfach nochmal frisch klonen, es ist alles rebased und alle Fixes von Jasmin, die den Tag über so reingewandert sind, sind da jetzt drin, sollte also alles klappen.

    Hallo nst,


    entschuldige bitte die späte Antwort, Reallife hat es leider nicht eher zugelassen.


    Ja ich nutze das media_build aus deinem Git.

    Das kompilieren mit 4.14.12 habe ich leider nicht hinbekommen. Es scheiterte immer an apply_patches. Es läuft aber mit dem im Git mitgeliefertem Kernel 4.16 bisher absolut störungsfrei, weshalb ich erst mal auf diesem bleiben werde.

    ASRock J3455M | 8GB Ram | CineS2 v5.5 | Libreelec 9 | MLD4 als chroot in Libreelec

  • Hallo,

    ich habe auf Kernel 4.15 geupdatet (arch mit vdr4arch). Seitdem beschwert sich ddci2 mit:
    DDCI-Inf: no DD CI adapter found


    bei modprobe ddqbridge (redirect wurde noch nie durchgeführt):

    Pakete:


    vdr 2.3.3-1

    vdr-ddci2 1.0.1-2

    vdr-streamdev-server 0.6.1.r33.gb84b7d8-3

    vdr-vnsiserver 2:1.5.2-3

    vdr-xineliboutput 1.1.0.119.g2889fd9-5


    Wäre für Hilfe dankbar.

  • ich habe auf Kernel 4.15 geupdatet (arch mit vdr4arch). Seitdem beschwert sich ddci2 mit:
    DDCI-Inf: no DD CI adapter found

    [...]

    vdr-ddci2 1.0.1-2

    Auch wenns hier um die alten ngene-Karten geht: ddci2 >= 1.0.4 installieren, ältere Versionen erkennen das vom Kernel-Treiber verwendete secX Devicenode nicht.

    Server: Gigabyte P35-DS4, Intel Core2Duo E6850, 4GB DDR2-RAM (Headless), Gentoo Linux x86_64 / Kernel 4.16.7 / DD CineCTv6+DuoFlex C/T/T2+DuoFlex C/C2/T/T2 w/Kernel Stock Drivers / TVHeadend-GIT-3356759d8

    HTPC: ASRock J5005-ITX (Intel Pentium Silver J5005, 1.5GHz), 8GB SO-DDR4, Intel UHD Graphics 605 in Antec Fusion Remote Black+SoundGraph iMON LCD ( 0038 ), Kodi v18 Leia
    SW: Kodi Krypton+Leia auf allerlei Gerätchen (HTPC: VAAPI+HD-Audio+LCDproc addon / Ubuntu Bionic 18.04 (x86_64), RPi2, NVIDIA Shield Android TV, Wetek Play 1@LibreELEC/NAND, Tablets, Smartphones, Win/Mac/Linux Desktops)

  • Hi,

    Der aktuelle VDR wäre sicher auch hilfreich (zumindest 2.3.8).

    MfG Stefan

    Test-VDR1: HP rp5700 Fertigsystem, Core2Duo E6400, 2GB RAM, FF-SD C-2300, nvidia Slim-GT218 x1 | easyVDR 2.0 64Bit
    VDR3: in Rente

    VDR4: MSI G31M2 v2, Digitainer2-Geh., t6963c 6" gLCD, E5200, 2GB, 3TB WD Red, GT730, 2x TT S2-3200; easyVDR 3.5 64bit
    VDR5: Gigabyte
    GA-G31M-S2L, Intel E2140, Zotac GT730 passiv, Digitainer2-Geh., t6963c 6 " gLCD, 2 TB WD Red, 2x TT S2-3200 (an 1 Kabel) easyVDR 3.5 64bit
    VDR6:
    Intel E5200, GT630 passiv, F1 750 GB, t6963c gLCD, 2x TT S2-3200 | easyVDR 3.5 64bit
    VDR-User #1068
    www.easy-vdr.de

  • Problem mit MCD und gleichen ECM Pids


    Problem: Ich gucke auf Sender 2, eine Aufnahme startet auf Sender 1 und stoppt wieder. Wenige Sekunden danach friert das Bild (auf Sender 2) ein.

    Dasselbe passiert auch, wenn es zwei Aufnahmen sind und in allen möglichen anderen Varianten.

    Gemeinsamer Nenner: von Sender 1 wird weggeschaltet, und das blockiert Sender 2. Dabei sind beide Sender auf demselben Transponder und haben dieselbe ECM Pid (SRF1 und SRF2 auf 13°E).

    Besonders bei zwei Aufnahmen ist das ärgerlich, weil dann eine abbricht.

    Was hilft: Einstellungen → CAM → Aktivieren oder neu auf Sender 2 schalten (Kanalnummer eingeben).

    Hardware: Oktopus LE mit Single Flex CI und ACL R2.6.

    Software: vdr-2.2.0 mit allen Patchen, vdr-2.4.0 mit allen vdr-2.4.0-Patchen.

    Kernel 4.14.59

    ACL Firmware: 1.19, 1.23, 1.25, 1.27 und 1.28.


    Unter vdr-2.2.0 habe ich auch weiche CAMs probiert, das eine hatte das Problem auch, das andere nicht. Allerdings kompiliert das funktionierende weiche CAM nicht mehr nach Update auf openSuse 15 und statt Debug-Orgien habe ich lieber in DD Hardware investiert. Nun weiß ich nicht, ob es am ddci2 Plugin liegt oder am ACL.


    Wie kann ich das debuggen?

    Wie könnte man einen workaround machen, indem man z.B. automatisch nach Wegschalten das CAM resettet oder neu tunet?

    Hat jemand eine ähnliche Konstellation die funktioniert?


    Ansonsten funktioniert ddci2 und vdr-2.4.0 super, ich kann 4 verschlüsselte Sender gleichzeitig aufnehmen und während dessen zwischen den Sendern hin- und herschalten.

  • @jrie

    shared CaPids sollte seit vdr 2.3.3 funktionieren.

    mir ist dass mit ORF2 HD Vlbg und orf sport+ aufgefallen.


    in vdr 2.3.3 wurde folgende neue funktion eingeführt.

    cCamSlot::BuildCaPmts
    seitdem sollte es keine probleme mit shared ECM pids geben.

    falls du bei vdr-2.2.0 bleiben willst versuch folgendes - hat damals bei mir funktioniert.

  • Danke für den Patch, den werde ich ausprobieren.


    Es bleibt aber die Frage, warum es nicht funktioniert (obwohl es sollte).

  • hallo,

    ab vdr 2.3.3 funktioniert der patch nicht - bzw. ist nicht notwendig.

    ab version 2.3.3 funktionieren shared CaPids.
    ist niemand aufgefallen, und klaus ging nicht davon aus dass es so etwas gibt.


    da wird quasi srf2 mit dem key von srf1 entschlüsselt.

    wenn einer der sender beendet wird, dann wurden die pids gelöscht, und der verbliebene sender nicht mehr entschlüsselt.
    der neue vdr macht das besser.
    mein patch löscht pids nur wenn CaPid nicht mehr gebraucht wird.
    gruss, onur