Posts by HelmutB

kamel5 wrote:

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

I dont know if this is CAM related, At least no CRC-errors in your logfiles.

VNSI: Channel: no data 16 - have you seen this: https://github.com/FernetMenta…ugin-vnsiserver/issues/97 - discussed here too: Kodi18 / VNSI Plugin .

Helmut

Da mir die bisherigen Patches nicht ganz gefallen haben, hier eine kleine Überarbeitung. Anstatt immer eine eigene Liste neu aufzubauen werden nun die Übersetzungen direkt in der LanguageNames Liste geändert. Ist irgendwie logischer und macht den Patch auch etwas kürzer.

Helmut

In i18nInitialize() fehlt die erste initialisierung der CurrentLanguageNames Liste. Diese Liste wird aber bereits für Setup::ParseLanguages() benötigt.

Hier die Korrektur.

Helmut

Hier noch eine Version bei der ich ein paar redundante Codezeilen entfernt habe.

Helmut

kls wrote:

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

kls wrote:

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 :

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

corvy wrote:

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

And here with a little more information when finaly receiving a valid CAT section after previous CRC errors.

Helmut

I think I thought too complicated last night.

It's better to treat it what it is - a plain data error. And data with faulty CRC32 checksum should be simply ignored.

Here is a more general patch fo this problem (and it has nothing to do with your provider - so ignore the patch in post #61).

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

Yes, some of this from the last days.

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.

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

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

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

haraldov wrote:

Do you know if I need the updated ddci2 drivers from ppa:jasmin-jessich/media-build-dkms.

Sorry, i don't know.

To find out if it is the patch or the rebuild-process iitself which causes the kernel-crash, try to rebuild the VDR deb-package and satip + ddci2 - but without the camtweaks-patch applied.

Helmut

Did you rebuild the satip-plugin too ?

I will build my VDR with all official patches and check it.

Helmut

Edit:

VDR with all patches up to #34 and camtweaks-1.patch works normal for me.

But - as i enabled VDR's patchlevel checking - i have to rebuild all plugins.

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

Für die ORF Sender benötigt man kein CI+ Gerät. Mein Alphacrypt Classic mit der letzten verfügbaren Firmware Ver. 3.28 von Mascom läuft im VDR ohne solche Meldungen.

Helmut