Posts by Fourty2

    Was will mir denn dies sagen:


    vdr: codec: can't allocate HW video codec context err ffffffea


    Ist ein älterer "Intel(R) Celeron(R) CPU J3160 @ 1.60GHz (family: 0x6, model: 0x4c, stepping: 0x4)"



    Stefan

    M-Reimer

    Du meinst also tatsächlich, die Netzwerk-Infrastruktur braucht, unabhängig von der transportierten Datenmenge, immer dieselbe Energie? Egal ob Idle oder Vollast?

    Das wäre schön. Ist aber nicht so. Jedes einzelne Bit, das umgeladen werden muß, fordert Tribut. Und dann wären da noch die USVs, die Klimatisierung und und und...

    Nein. Streaming ist im Vergleich zu einer Sat-Abstrahlung eine "Umweltsauerei" erster Güte.


    Stefan

    Hast Du mal versucht, die Lade-Reihenfolge der Plugins zu ändern?
    Vielleicht schafft das die nötige Zeit, um das Problem zu umschiffen.

    Mit epgsearch vor skinnopacity gibt es hier zumindest keine GPFs, maximal WDT Panics, wenn zwei Aufnahmen laufen (sollen) die alle Karten belegen und ... der VDR auf einem dritten Transponder steht.


    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 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