Ja, geht halt nicht ... schade, aber, als ich damals die Ursache selbst gesucht habe, schien mir das Arbeit/Nutzen-Verhältnis arg ungünstig.
Hab daher das VPS im VDR deaktiviert. Die ein/zwei Aufnahmen im Jahr, bei denen VPS möglich wäre, werden dann halt auch mit + 15 Min aufgenommen.
Stefan
Ich hab das spezielle Problem mal vor einiger Zeit so gelöst:
Eintrag in reccomands zur Anzeige:
TS-Errors: f() { /bin/cat $1/TS-Errors.log; }; f
Recording hooks Script, prüft auf TS-Fehler nach Schnitt und sorgt dafür, daß "alles" bei der Aufnahme bleibt:
HTH,
Stefan
Hab das schon seit VDR... 1.2(?) (also, seit ausreichend Speicher da war) so gepatched, sonst klemmte immer irgendwas - Parallelaufnahmen, Netzwerk-I/O oder Markad/Noad...
Stefan
Sobald ich versuche Timeshift oder eine Aufnahme zu starten, gibt es eine Fehlermeldung, das der Pay-TV Anbieter das gesperrt hat. Versucht habe ich das auf verschiedenen Kanälen, immer das Gleiche.
Dachte ich mir. Dem CAM mit ARM7TDMI CPU auf eCos 2.2.0 geht dabei jedenfalls nicht die Puste aus. Das ACL hat auch keine großartig andere Hardware.
Bleibt nur die minimal benötigten Streams verschlüsselt zu speichern und anschließend zu entschlüsseln. Das wäre ja "nur" ein etwas ausladender Cache, sozusagen. Und es wären auch sicher keine irgendwie illegalen CW Logs nötig - bleibt ja alles im Modul.
Aber schade, daß das CI+ derart zugenagelt ist.
42.
Das ist genau der Punkt, die Entschlüsselung müsste zeitnah geschehen.
Nein. Denke nicht.
Soweit ich weiß, entschlüsselt die Karte auch "alte" ECM Streams (die passende ECM Pid muß man natürlich mitspeichern). Der Original-Receiver legt die Dateien auch "verschlüsselt" ab und jagt sie bei Wiedergabe jedesmal erneut durch das Smartkärtchen.
Was nicht geht ist ECMs mit Datum > Ablaufdatum zu dekodieren. Logisch... 
Wenn die 90 Minuten Begrenzung bei der Vue greifen würde ... würde man das als Einschränkung sicher irgendwo lesen.
42
Das wird wohl der Grund sein, warum neuere Vue-Boxen den TS-Stream aufnehmen und "offline", also wenn das Modul gerade nicht live gebraucht wird, entschlüsseln können.
Könnte man dem VDR natürlich auch beibringen - wäre aber, denke ich, eine größere Umbauaktion.
Das ist das offizielle Sky Modul, was man für EUR 99,- "Leihgebühr" ... lassen wir das.
Technisch könnte das Modul, wenn es dürfte. Dann ist es wohl seitens Sky geblockt.
Zum Thema Timeshift:
Müßte Kamel5 mal in ein CI+ TV stecken und testen. Könnte mir aber vorstellen, daß man nur "Pause" drücken darf. Man soll ja den zahlenden Kunden nicht zuviel Freiheiten lassen.
Grüße,
42
Nein. Nein...
Das Ausschalten der CW-CRC Prüfung hilft nur den Wenigen mit "ohne Hardwarezuordnung".
Gleiches gilt für den (i==12) Freezer-Fix.
Da er statt einem CI+ Modul, das zumindest mit dem VDR verwendbar wäre, eine Kuh hat, ist die Karte (jetzt) sicher verheiratet. Da ist ohne den allgemeinen oder besonderen CW-Schlüssel (erstmal) Ende Gelände für die Software-Lösung.
Hardware-CAMs, die die CRCs prüfen, oder einfach neu berechnen und überschreiben, funktionieren jetzt halt ebenso nicht mehr, bis das ein Firmware-Update ggf. richtet.
Also besser das CI+ nehmen, wenn man VDR und Himmels-Nutzer bleiben will und nicht zu den Turings dieser Welt gehört.
Stefan
PS: Hoffe, das war jetzt noch auf erlaubten Seite...
Hallo Marcus,
wenn, geht es vermutlich nur per epgd / epg2vdr, indem Du die Channel-ID des IP-TVs halt zu den jeweiligen Sat-Channel IDs schreibst.
Grüße,
Stefan
Die Prüfsumme der CWs kann nicht mehr per (CW[Byte 0] + [CW[Byte 1] + CW[Byte 2]) & 0xFF = CW[Byte 3] geprüft werden. Damit fällt alles auf die Nase, was die CRC/Prüfsumme prüft und Falsche verwirft.
Stefan
Hallo Klaus,
naja, wenn die Meldung des I²C Timeouts stimmt, hält irgendein Stück der Hardware die I²C CLK und/oder DTA auf Masse und ist in diesem Zustand abgestürzt.
D.h. die I²C Takt- und/oder Datenleitung ist vom (abgestürzten) I²C-Slave auf Masse gezogen worden (Clockstretch / ACK) und noch immer dort.
Falls ein ACK-Hänger (Data = Lo) vorliegt, helfen eventuell manuelle CLK-Pulse. Ist die CLK auf Masse (Clock-Stretch), ist Ende-Gelände bis zum Hardware-Reset (oder Power-Off).
Stefan
Hallo zusammen,
seit einem Update der MariaDB in debian buster bekommen ich beim epg2vdr compilieren folgenden Fehler:
Einfach mit "suggested alternative" ersetzen, oder ist da Nacharbeit erforderlich?
Stefan
Hallo zusammen,
hab da noch einen Segfault im epg2vdr, wenn man beim Starten ein paar Tasten zuviel drückt:
Ideen?
Stefan
Ja stimmt, der Patch ist kaputt. Hab mal wieder aus dem Nano kopiert, ohne vorher ESC+$ zu drücken... Arrgh.
Also fehlt, was rechts nicht im Fenster war.
Anbei der komplette Patch (mit entferntem Alt-Code)
Stefan
Wenn ich das richtig verstehe, bleibt nach einem Erase lediglich das Start-Element der Iteration gültig.
Ein for() Loop ist demnach eher ungünstig, wenn man alle Elemente löscht.
Hab das jetzt mal so gepachted - so läuft es erstmal und scheint noch zu funktionieren.
Stefan
Hab noch einen neuen Segfault (nach Auskommentieren des letzten Fehlers oben):
Backtrace vom "laufenden Betrieb" der plötzlich (Re-)Startenden Kiste...
Log endet da:
Stefan
Wir schreiben 2019:
Hochskaliert... autsch.
Ja, war definitiv das udev, was wohl im "noch nicht so ganz bereiten" Zustand angesprochen wurde.
Downgrade auf 239 oder ein Delay im Init-Script behebt das Problem (bei mir).
Kernel kann ich ausschließen ... wird hier selbst aus dem GIT gebacken und aus eigenem Repository installiert.
Dies hier halt:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=917247
System ist ein Intel J3160 mit TT-budget S2-4200 Twin - also alles im Kernel 4.19.13.
Und als aplay -lL "keine Audio Geräte" mehr meldete, war klar, was schief lief.
Die hätte man sonst vorher aus dem Chipsatz meißeln müssen.
VDR-Log:
Stefan
Hallo zusammen,
irgendwann lerne ich es noch, das VDR-System nicht mehr zu aktualisieren ... ;-/
Das Update auf udev 2.40 hat wohl das System zerlegt. In /dev fehlt eigentlich seit Neustart alles, was ein VDR so braucht. Ganz toll.
Weiß jemand, wo ich mal suchen und reparieren könnte?
Stefan
Edit:
Nach etwas suchen:
- Das udev startet (bei sysv-init) jetzt per start-stop-manager (aber viel zu früh)
- Patch gibt es da: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908796
