Posts by HelmutB

    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

    und in I18nSetLocale() nach dem Aufruf von SetEnvLanguage() die "technischen" Einträge ab diesem Offset einzutragen bzw. zu überschreiben.

    Hat etwas gedauert aber genau so häbe ich es jetzt gemacht. Sieht auf den ersten Blick nicht schlecht aus.

    Neben 'qaa' habe ich auch die 4 speziellen Codes 'mis', 'mul', 'und' und 'zxx' dazu genommen,


    Helmut

    da zu diesem Zeitpunkt die gewählte Sprache ja noch nicht gesetzt is

    Ich habe in i18n.c noch nicht ganz durchschaut wann und wo die Sprache endgütig gesetzt wird. Was macht denSetEnvLanguage(LanguageLocales[CurrentLanguage]);im Locales-Loop davor ?


    Außer 'qaa' gäbe es ja auch ander Language Codes zu denen es keine "echte" Sprache zur Auswahl gibt z.B.

    "mul", "Multiple languages" , "mis", "Uncoded languages" oder auch "nar", "Narration: (audio described)"}


    Die Unterstüzung von 'mis' ist z.B. von ORS (ORF) für DVB-T2 Boxen sogar vorgeschrieben: https://www.ors.at/fileadmin/u…n_Market_Version_1_02.pdf :

    Code
    1. The user shall be able to set storable preferences for the default audio language. The IRD should provide the option to select "MIS" language code as defined in ISO 639-2 [7].

    Veiielicht sollte man diese "technischen" Language Codes gesondert behandeln und dabei mit verständlichen Bezechnungen versehen.

    Ich werde mir die i18n.c einmal genauer ansehen.


    Helmut

    Hallo

    corvy - only this Patch: vdr-2-4-0-verify-cat-crc-2-check-all-patch -this one checks each received CAT-section (which is received normaly every 1 or 2 seconds) and reports if there is an CRC error into the syslog file.


    haraldov : I usually have VDR loglevel set to 3 (no ddci2 debug required), My syslog-file is /var/log/messages (gentoo) in which i see also all "normal" VDR messages . To watch this logfile "live" i use the command tail -F /var/log/messages as root in an seperate xterm window.

    Helmut

    corvy hat hier beschrieben dass bei ihm gelegentlich nach dem Start einer verschlüsselten Aufnahme VDR mit einem "emergency exit" einen Neustart durchführt.

    Eine Ursache dafür könnten fehlerhafte Daten in der CAT section sein, die dann in weiterer Folge zur Ermittlung einer falschen EMM-Pid führen und damit das Programm nicht entschlüsselt wird.

    Der Patch vdr-2.4.0-verify-cat-crc.patch prüft die Gültigkeit der Daten der CAT Section über die CRC32 Prüfsumme und die EMM-Pids werden dann nur bei fehlerfreien Daten ermittelt.


    Da ich mir einerseits nicht ganz sicher bin, ob damit wirklich die Ursache des Problems behoben wird, andererseits der Fehler aber eher selten aufzutreten scheint und damit gar nicht leicht zu finden ist habe ich einen 2. Patch der im Hintergrund laufend alle einlangenden CAT-Sections überprüft und eine entsprechende Fehlermeldung ausgibt.


    Ich selbst konnte bei einem Kurztest noch keinen Fehler feststellen. abe rVielleicht hat noch jemand Anderer Interesse diesen 2. Patch einzuspielen und Auffälligkeiten hier zu posten.


    corvy : The HEXDUMP Macro is now includet in thevdr-2.4.0-verify-cat-crc-2-check-all.patch - manual patching is not required anymore.

    Helmut

    Your manually patch looks OK. I applied it with all vdr-patches up to #34 but didn't think of your HEXDUMP() line.


    I think it will take some time to catch the data/crc error because the CAT is first evaluated on a channel-switch, but after that only if the catversionchanges - but i don't know how often this happens (hours ?, days?).
    And so i think, for test purposes, it would be better to modify the patch and verify the checksum of all CATPID occurences, regardless of catversion.

    I will try this tonight - and open a new thread for it because it has nothing to do with MCD or MTD.


    Helmut

    will this be proposed for the next release in case it is stable?

    I dont know, maybe only if this patch really solves your problem.


    If you can catch the CRC-error ( look for cCaPidReceiver::Receive() : CRC-ERROR - skip invalid CAT section [Ver.... with a following cCaPidReceiver::Receive() : got valid CAT section [Ver....in your logs ) then i think the chances are good.


    Helmut

    So all with 09 0A 0B 00 F3 89

    and today 09 0A 0B 00 89 F3 with the last 2 bytes reversed.

    Can you find more of this wrong CAT-PIDS by greping for '89 f3' in your logs?


    A workaround could be to look for this wrong PID in ci.c / cCaPidReveiver::Receive() and adjust it - but this is more a hack then a fix.

    Helmut


    Edit: corvy - you can try this patch. It compiles, but is completly untested

    You start a recording at 14.58:00 and 30 seconds later VDR initiates the emergency exit. That means usually that the TS-stream for the recording is not decrypted.

    Code
    1. May 19 14:58:00 timeshift changeover: [1747] writes hours id '22 @timeshift 'to /srv/vdr/video/Tid_for_hage_(R)/2019-05-19.14.58.5-0.rec/.timer
    2. May 19 14:58:00 timeshift vdr: [8624] recording thread started (pid = 1747, time = 8624, prio = high)
    3. May 19 14:58:00 timeshift CEO: [1769] VNSI: Ask for clients to reload timers
    4. May 19 14:58:01 time shift VDR: [8622] CAT: 09 0A 0B 00 89 F3 80 04 34 10 EE 54 07 93 05 3C FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
    5. ...
    6. May 19 14:58:31 timeshift vdr: [8624] ERROR: video data stream destroyed
    7. May 19 14:58:31 timeshift changeover: [8624] initiates emergency exit

    The interesting thing is the CAT-dump. In April you sent me this log:

    Code
    1. Apr 1 19:10:18 timeshift vdr: [17502] CAT: 09 0A 0B 00 F3 89 80 04 34 10 EE 54 07 93 05 3C FF FF ...
    2. 0x09 -> marker
    3. 0x0A -> len
    4. 0x0B00 -> caid
    5. (0xF389 & 0x1FFF) = 0x1389 -> your emm-pid
    6. 80 04 34 10 EE 54 -> private data
    7. 07 93 05 3C -> crc32

    Now the 2 bytes for the CAT-PID are reversed, but the CRC32 is unchanged:

    Code
    1. May 19 14:58:01 time shift VDR: [8622] CAT: 09 0A 0B 00 89 F3 80 04 34 10 EE 54 07 93 05 3C FF FF ...
    2. 0x09 -> marker
    3. 0x0A -> len
    4. 0x0B00 -> caid
    5. (0x89F3 & 0x1FFF) = 0x9F3 -> your emm-pid ---> bytes reversed !!!!!
    6. 80 04 34 10 EE 54 -> private data
    7. 07 93 05 3C -> crc32 ---> the same as in April, means wrong CRC32 (or that one in April)

    And so i think your provider sent wrong data and without EMMs your CAM does not decrypt at all.

    Do you have more CAT-dumps from today?


    Helmut

    Der letzte Kartentausch ist sicher schon 3-4 jahre her. Und die Freischaltung lief damals über einen normalen SAT Receiver.

    Ich verwende die Alphacrypt aber nicht im regulären Betrieb sondern nur um hin und wieder im VDR etwas auszuprobieren. Die Smartcard steckt normalerweise in einem anderen Modul.


    Vielleicht hilft ein Factory Reset - und danach Online ein neues Freischaltsignal anfordern.

    Helmut