Posts by onur


    für alle jene die eine specherleck suchen, und die valgrind ausgabe etwas verringern wollen, die müssen den vdr mit so einem sleep bauen.
    aber auch 200ms ist nicht verlässlich, leider ist das ganze stark cpu (anzahl und auslastung) abhängig.
    echt frustrierend.

    zumindest liefert valgrind (auch ohne patches) nach dem beenden das richtige ergebnis.
    die ausgabe zur laufzeit ist falsch.

    LEAK SUMMARY:

    ==29891== definitely lost: 0 bytes in 0 blocks

    ==29891== indirectly lost: 0 bytes in 0 blocks

    ==29891== possibly lost: 0 bytes in 0 blocks

    ich habe alle varianten durchgetestet - damit es schnell geht - mit einem TestThread.

    verlässlich ist keine der varianten - alles ziemlich sinnlos.

    am verlässlichsten funktioniert valgrind, wenn man in cThread::StartThread vor dem Aufruf von Action, ein sleep mit 200ms macht.

    dann meckert valgrind nicht mehr.

    pthread_attr_destroy kann man direkt nach thread create machen.

    if (attrp) pthread_attr_destroy(attrp);


    Solution 3 - signalisert valgrind das der thread detached läuft.
    ansonsten weiß das valgrind ja nicht sofort (valgrind meckert wenn zwischen pthread_create und pthread_detach ein malloc/new gemacht wird).


    ich habe das ganze so verstanden:

    pthread_detach bewirkt das nach thread ende, alle thread ressourcen freigegeben werden.


    vereinfachtes Beispiel:

    pthread_create = erstellt ein globales handle mit nummer 1 (unser childTid).

    wenn der thread beendet wird exisitert dieses handle weiter, damit childTid vom aufrufenden thread weiter gültig bleibt.


    pthread_detach (egal woher es aufgerufen wird) bewirkt:

    alle thread ressourcen (childTid) bitte nach thread ende freigeben.

    die variable childTid ist ab diesem zeitpunkt unsicher.

    es könnte sogar passieren das inzwischen ein anderes pthread_create die selbe id vergeben hat.


    im vdr code wird das durch die variable Thread->threadrunning = false geprüft.

    hier könnte man zusätzlich ein Thread->childTid=0 machen (falls man pthread_detach in den thread verschiebt - Solution 2).

    @mini73
    ich habe folgendes beobachtet:
    valgrind bemerkt dass ein thread gestartet wird, und regsitriert malloc/new aus diesem thread.
    Wenn nun vor thread ende ein pthread_detach gemacht wird, denkt vargrind das der thread speichlecks hat.
    Wenn pthread_detach gemacht wird, bevor im thread ein malloc/new gemacht wird (zufall), dann meckert valgrind nicht.


    speicher-leck suche ist dadurch schwierig.

    kls

    Thread->childTid habe ich korrigiert.


    damit childTid auch gültig ist sollte man nach einem erfolgreichem pthread_create() - auf den thread warten.

    z.B mit Funktion WaitForThreadStart und Variable bThreadStarted (bThreadStarted muss natürlich im konstruktor mit false initialisert werden)

    Hallo, hätte einen Verbesserungsvorschlag:

    ich prüfe mittels valgrind auf Speicherlecks.

    bei den vdr threads läuft aber etwas schief (ausgabe unschön).
    falls innerhalb des threads ein malloc gemacht wird - gibt es einen fehler von valgrind.

    valgrind denkt wohl das der thread direkt nach dem start zerstört wurde.

    wenn man "pthread_detach(childTid)" nach cThread::StartThread(ans ende, vor return true;) verschiebt, dann klappt es besser.


    gruß, 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