Posts by onur

    Ich habe fälschlicherweise angenommen das dies seit 2.3.3 nicht mehr benötigt wird.
    Da ORF wohl keine shared ca pids mehr hat, habe ich einen falschen Schluss gezogen.

    hallo, leider gibt es das problem derzeit auf orf nicht (ich habe auch keine kombi gefunden).

    eventuell aber von 19:00-19:15, da laufen die regional Programme (teste ich heute).

    SRF kann ich derzeit auch nicht empfangen/entschlüsseln.


    ich habe immer mit diesen 2 Kanälen getestet.

    ORF2V HD;ORF:11273:HC23M5O35P0S1:S19.2E:22000:3000:0;3001=deu,3002=mis:3005:D98,650,D95,648,6E2,98C,9C4,500:13307:1:1005:0
    ORF SPORT+ HD;ORF:11273:HC23M5O35P0S1:S19.2E:22000:3090:0;3091=deu,3092=mis:3095:D98,650,D95,648,6E2,98C,9C4,500:13309:1:1005:0

    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

    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

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

    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

    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:

    nach langem testen hab ich das problem gefunden.

    /var/lib/ntp/ntp.drift und-oder /etc/adjtime

    nachdem ich die 2 dateien gelöscht habe, funkionierte adjtime.
    bei mir stand in ntp.drift -500 (500 ist der max. korrektur wert).
    adjtime bzw. die Geschwindigkeits-Korrektur scheint wohl nicht zu funktionieren wenn ntp diese dateien vermüllt hat.

    die 2 dateien werden bei bedarf von ntp neu angelegt (dauert aber).
    ntp berechnet über einen längeren zeitraum den drift der hardwareuhr.
    falls mal kein inet vorhanden, bzw. ntp nicht läuft, wird anhand dieser daten die zeit angepasst, somit wird quasi die hardwareuhr gepatcht.

    gruß, onur

    danke klaus, welchen kernel nutzt du?

    bei mir macht adjtime leider nix.


    waren gleich mehrere fehler im post oben, sind nun korrigiert (kernel 4.12 also neu und /var/log/syslog).

    eleganter ist natürlich klaus seine grep variante.

    noch eleganter wäre sekunden diff in der logausgabe.


    @min73

    ntp will ich nicht. Es muß, und soll die DVB-S Zeit sein.

    mit der DVB Zeit ist VPS und der ganze kram einfach viel genauer.


    info am rande:

    der böse cardserver verhindert ein backwards stellen der systemzeit (bis inklusive version 11233 gibt es keine probleme).

    hab das vor einem jahr schon mal gemeldet, die wollen aber aus unerklärlichen Gründen keine Monotonic Clock verwenden.


    gruß, onur

    die funktion adjtime funktioniert bei mir nicht (kernel 4.12).

    die funktion wird ohne Fehler ausgeführt, aber die System Zeit wird nicht verändert.

    ich weiß dass die funktion die interne uhr beschleunigt bzw. verlangsamt und die zeit quasi smooth angepasst wird.

    aber auch nach 12 Stunden bleibt die Differnz unverändert.

    der vdr ruft im 5 Minuten Takt die Funkton auf falls differnez kleiner 10 Sekunden.


    test Szenario:

    vdr starten.

    date --set 09:40:00

    zeit sollte ca. 5 sekunden vor aktueller DVB-S zeit sein, damit die vdr funktion greift.

    30 minuten warten...

    prüfen:

    cat /var/log/syslog | grep "system time"


    gruß, onur

    hi, problem gefunden, neurdings geht dvbsky frontend erst ab kernel 4.7
    DVB_M88DS3103: Requires at least kernel 4.7.0
    schöne sch... - gibt es eine möglichkeit einen alten stand zu verwenden (im nov ging es noch?).
    ich habs mit git checkout 50dcb6cdb70281d76b28d1564f8e076bb08f2c60 versucht - aber nicht hinbekommen.
    danke für deine mühe, gruss, onur

    @nst - funktioniert leider nicht - meine dvbsky karte geht mit git clone https://github.com/herrnst/media_build.git
    leider nicht?
    mache ich etwas falsch??
    ich mache folgendes:



    mkdir -p /usr/src/dvbdev
    cd /usr/src/dvbdev
    git clone https://github.com/herrnst/media_build.git
    git clone https://github.com/herrnst/dddvb-linux-kernel.git



    cd /usr/src/dvbdev/dddvb-linux-kernel
    git checkout mediatree/master-ddbridge


    cd ../media_build/linux/
    make tar DIR=../../dddvb-linux-kernel
    make untar
    cd ..
    make stagingconfig


    make install



    danke, gruss, onur

    hi,
    kann mir jemand helfen?
    bekomme diesen fehler beim kompilieren (debian jessie kernel 3.16.0-4-amd64)


    ddbridge.c:104:3: error: implicit declaration of function 'pci_alloc_irq_vectors' [-Werror=implicit-function-declaration]
    stat = pci_alloc_irq_vectors(dev->pdev, 1, nr, PCI_IRQ_MSI);
    error: 'PCI_IRQ_MSI' undeclared
    ...


    die rep von //linuxtv.org/media_build.git kompiliert ohne probleme?


    danke, gruss, onur

    hallo,


    Ich würde gerne dem decoder mitteilen Pakete (eigentlich ganze Frames) bei der wiedergabe zu verwerfen (nicht darstellen).
    Die Pakete sollten aber trotzdem beim decoder ankommen.
    Falls so etwas möglich wäre könnte man einen frame-genauen schnitt (zumindest bei der wiedergabe) bewerkstelligen.


    wurde so etwas schon mal diskutiert?


    gruss, onur