Beiträge von HelmutB
-
-
dprintk ist in dvb_frontend.c als #define dprintk(fmt, arg...) \ printk(KERN_DEBUG pr_fmt("%s: " fmt), __func__, ##arg) definiert.
Es gibt 8 Loglevels:
#define KERN_EMERG "<0>" /* system is unusable*/
#define KERN_ALERT "<1>" /* action must be taken immediately*/
#define KERN_CRIT "<2>" /* critical conditions*/
#define KERN_ERR "<3>" /* error conditions*/
#define KERN_WARNING "<4>" /* warning conditions*/
#define KERN_NOTICE "<5>" /* normal but significant condition*/
#define KERN_INFO "<6>" /* informational*/
#define KERN_DEBUG "<7>" /* debug-level messages*/
Dein Konsole Loglevel siehst du mit: $ cat /proc/sys/kernel/printk (die erste von 4 Zahlen).
Was steht bei dir in der Ausgabe?
Zum Ändern: - z.B. nach einem $ echo "6" > /proc/sys/kernel/printk werden nur die Levels 0 bis 6 an der Konsole angezeigt. Die Level 7 Meldungen sieht man dann nur mit 'dmesg'.
Man kann das loglevel schon beim booten als Kernel Parameter mitgeben: z.B loglevel=3.
Für Ubuntu: https://wiki.ubuntuusers.de/Bootoptionen/
Helmut
Edit: so in etwa: GRUB_CMDLINE_LINUX="loglevel=3 ....."
-
Diese Meldung ist eigenlich nur für die Treiber-Entwickler gedacht und zeigt welche Werte im Treiber vorgegeben sind.
Fehlende oder falsche Werte werden dann aber automatisch korrigiert bzw. angepasst. Es ist also keine Fehlermeldung und man kann sie ignorieren.
Seit diesem Commit scheint die Meldung im Kernel auf: https://git.kernel.org/pub/scm…da4f7d00b9e204f9f89287fad
Helmut
-
Hallo,
das ist eine Debug Meldung von drivers/media/dvb-core/dvb_frontends.c. Dass die Warnung aber permanent angezeigt wird, gibt es erst seit dem Kenel 5.x.
Vielleicht hilft dir dieser Patch: https://patchwork.kernel.org/patch/10953201/
Helmut
-
cCamSlot::TsPostProcess() ist noch nicht MTD-fähig da die TransportConnections nur der MasterSlot kennt. mtdCamSlots können TsPostProcess() nicht anstossen.
Dieser Patch sollte auch einem Plugin helfen, das bisher im MTD Modus nicht funktioniert hat.
Helmut
-
cCamSlot::StopDecrypting() leert die ciCaProgramList des CamSlot und und löscht die CA_PMTs aus der CAM.
Im MTD Modus hatte StopDecrypting() aber entweder keine Funktion da sie nur auf den (inaktiven) MasterSlot angewendet wurde, oder sie war nur auf einen mtdCamSlot beschränkt. Das Leeren der CAM fand in keinem Fall statt. Dieser Patch sollte das korrigieren.
Helmut
-
Das ist eigentlich ein Patch für vdr-2.4.1, ist vom Thema her auch hier richtig.
Mit dem vdr-2.4.0-26-fix-shared-ca-pids.diff werden shared ca-pids derzeit gar nicht mehr entfernt da auch die inaktiven Programme in der caProgramList vorhanden sind und so die shared ca-pids immer wieder gefunden werden.
Es sollte nur gegen die ca-pids der tatsächlich noch aktiven Programme geprüft werden,
Diff
Alles anzeigen--- a/ci.c.orig 2019-05-28 17:55:44.000000000 +0200 +++ b/ci.c 2019-06-24 20:11:44.130112151 +0200 @@ -2549,7 +2549,7 @@ void cCamSlot::KeepSharedCaPids(int Prog return; int CaPids2[MAXRECEIVEPIDS + 1]; for (cCiCaProgramData *p = caProgramList.First(); p; p = caProgramList.Next(p)) { - if (p->programNumber != ProgramNumber) { + if (p->Active()) { if (GetCaPids(source, transponder, p->programNumber, CaSystemIds, MAXRECEIVEPIDS + 1, CaPids2) > 0) { int *pCaPids2 = CaPids2; while (*pCaPids2) {
Helmut
-
Ich habe mich letztes Wochenende zu sehr auf dieses packen der CA_PMT konzentriert, dass ich, nach einer letzten kleinen Änderung, den "Normal" Modul nicht aufmerksam getestet habe. Daher ist mir auch nicht aufgefallen, des er mit dem obigen Patch nicht mehr richtig funktioniert.
Auch beim mitzählen der aktven Programme war noch ein Fehler.
Hier nun ein Update in dem diese Fehler behoben sind.
Zusätzlich habe ich noch eine kleine Ergänzung beim Entfernen von Pids eingefügt, da ich auch Pobleme nach mehrmaligem Umschalten bei einer laufenden Aufnahme festgestellt habe. Nun werden die aktuell zu entfernenden Pids einmalig mit "NOT_SELECTED" in die CA_PMT aufgenommen. Das hat bei mir geholfen - ist aber vielleicht auch CAM-abhängig.
kamel5 - ist in etwa wie im der sid9.patch - ich hoffe, es gibt keine Verschlechterung bei dir.
Helmut
-
Hier eine neue Version des CamTweak Patch, die es ermöglicht, das Programm Limit von Ca-Modulen anzuheben.
Dazu wird nicht wie sonst üblich für jedes Programm eine eigene CA_PMT an das CAM übertragen, sondern alle Programme (Stream- und ECM-Pids) eines CamSlot bzw. bei MTD auch aller MtdCamslots in eine einzelne CA_PMT gepackt.Das Programm Limit hängt dann nur von der möglichen Anzahl der Pids ab, die das CAM aufnehmen kann.
Es gibt dazu 2 neue Optionen in der camtweaks.conf, die beste und einfachste wäre der Wert 0x21 (MTD) onder 0x25 (nur MCD).
Code: camtweaks.conf# CAMTWEAK_PACK_MCD 0x10 - pack each CamSlot into a single CA_PMT - for CAMs with limited program slots # CAMTWEAK_PACK_MTD 0x20 - pack *all* MtdCamSlots into a single CA_PMT - for CAMs with only one program slot # Example: 0x21,0,<...> tweaks enabled, PACK_MTD (single CA_PMT for MCD+MTD, implicit MCD and unlimited number of programs)
Ich kann nun mit dem SimpiTv-Modul statt 2 nun auch 7 Programme gleichzeitig entschlüsseln.
Jun 24 23:48:27 gentoo64vdr vdr[2942]: [2942] SendCaPmts(MTD) CAM 1: [0] actives in CAM: 7 -> 7 (20 pids)
Es funktioniert grundsätzlcih auch mit der Sky CAM - allerdings mit ein paar Einschränkungen wie sich bei den Tests von kamel5 herausgestellt hat.
- Maximal 2 Programme gleichzeitig - vermutlich eine Beschränkung auf 6 Stream-Pids
- MTD it derzeit noch nicht möglich - nicht einmal die Simulation mit KEEPPIDS in mtd.c
- Beim Hin- und Herzappen auf andere Kanäle während einer laufenden Aufnahme kömmt irgendwann der Punkt wo der 2. Kanal nicht mehr
entschlüsselt wird (das passiert manschmal schon nach 8 oder auch erst nach 50 mal), Es ist aber noch nicht klar warum das so ist und ob es nur bei der SKY CAM Auftritt.
Wenn jemand den Patch testen möchte - ein paar Erfahrungsberichte wären sehr interessant.
Helmut
-
Zusätzlich habe ich die DVBSky S952 v3 beigelegt,
Hat DD auch diese Karte mit dem PCie Analyzer getestet? Es wäre interessant zu wissen, ob es damit auch diese unerwarteten "Nak"s gibt.
Helmut
-
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
-
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 :
CodeThe 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