Posts by FireFly

    Ich habe gerade eine Aufnahme geschnitten und da lief die Platte voll. Es gab auch eine rote Meldung "Bearbeitung gescheitert", aber die Aufnahme wurde nicht gelöscht. Früher (tm) wurde die unvollständige Kopie immer entfernt...

    Mir war das schon vor längerer Zeit mal aufgefallen, das ist also nicht erst seit 2.4.7. so, hatte es aber verdrängt.

    Der skindesigner nutzt Imagemagick nicht (zumindest hat er keine direkten Abhängigkeiten dazu) - wie es mit dem zu Magick-aborts kommen soll, ist mir gerade nicht klar.

    Imagemagick regisrtiert einen Signal Handler und der fängt dann alle Segfaults ab, die innerhalb des VDR-Prozesses passieren. Der Segfault muss also nicht zwingend in dem Plugin passieren, das Imagemagick benutzt sondern kann in einem anderen Plugin oder VDR selbst passieren.

    Es sieht so aus, als wäre /usr/lib/rpm/suse/macros aus rpm-config-SUSE-1-3.61.noarch momentan "broken" :( Da werden die nötigen Variablen momentan nicht gesetzt.

    Wenn sie das korrigiert haben, müsste das bisherige RPM auch wieder bauen, da dort auf >= 15.2 geprüft wird

    :D:D:D Da ich das rpmbuild nicht auf Suse Linux Enterprise (SLE) testen konnte (wofür auch) habe ich das im RPM ausgeschlossen. Da 15.3 nun aber auf SLE aufsetzt, greift der Test. ^^

    Du kannst erstmal das

    Code
    1. %else
    2. %error SLE is not supported

    aus dem Spec-File löschen (müsste Zeile 21+22 sein) - wenn sonst nichts/nicht viel geändert wurde müsste es wieder kompilieren, weil es ja noch Kernel 5.3 ist. Ich werde das später auch mal probieren.

    Wenn es beim Schneiden dazu kommen kann, dass die Fehler weniger werden. Liegt das daran, das fehlerhafte Teile im Schnitt nicht mehr vorhanden sind

    Genau. Die Fehler in den herausgeschnittenen Abschnitten sind zwar noch im Error-Zähler enthalten, aber nicht mehr in der geschnittenen Aufnahme. Die Fehler in den kopierten Abschnitten bleiben erhalten.

    'int' kann maximal ca. 2 Milliarden sein. 2 Mrd. x 188 (wenn man mal nur die TS-Fehler rechnet) entspricht 376 GB - so eine große Aufnahme, bei der jedes TS-Paket fehlerhaft ist, ist doch eher unwahrscheinlich ;-).

    Ok, das sollte für ein TV-Heimgerät reichen ;-)


    Ja, das wäre mir auf jeden Fall lieber, dann würde man zumindest sehen, das das ungeprüft ist.

    mir auch, aber müsste in dem Patch aus Post #57 in Zeile 9 nicht ">= 0" stehen?

    Edit: Nein, es funktioniert mit >0

    in recordings.h fehlt noch ein "const"

    Code
    1. int Errors(void) const { return errors; } // returns -1 if undefined

    dann compiliert es und es werden nur für neue Aufnahmen die Fehler angezeigt.


    Wenn man eine neue (fehlerfreie) Aufnahme schneidet, wird auch die Kopie mit 0 errors angezeigt. Ich habe dann testweise mal das Tag "O 10" gesetzt und VDR neu gestartet. Die Aufnahme zeigt dann 10 Fehler an,, aber nach dem Schneiden steht in der Kopie "O 0", also keine Fehler (was ja eigentlich auch korrekt ist).

    Wird beim Schneiden noch mal der TScontinuity Check gemacht? Dann würde das ja stimmen.

    Ist errors nach oben begrenzt? Wenn das int überläuft wird es ja negativ und irgendwann sogar wieder Null...

    Mich würde interessieren wie der TSCheck für Endanwender nutzbar ist, bzw, wie Skins mit dem O Tag in der info Dateien umgehen?

    Verstehe ich das richtig, dass errors auch für alle Aufnahmen, die mit früheren VDR-Versionen gemacht wurden, mit 0 initialisiert wird? Dann würden die automatisch alle als "fehlerfrei" angezeigt. Kann man errors nicht mit -1 initialisieren, dann würde Errors() nur für neue Aufnahmen einen validen Wert anzeigen.


    MegaV0lt : Im Skin-Plugin kann man dann den Wert abfragen und bei >=0 z.B. in den Aufnahme-Infos anzeigen, genauso wie z.B. die Altersfreigabe oder den Stream-Content

    Was sollte ich genau in der Datei 'vdr.service' eintragen, damit der Start des vdr auf den fertig geladenen Treiber wartet?

    Oha, Du nutzt noch die runvdr ..... Ich denke, dann erkennt systemd gar keine Abhängigkeiten und startet einfach runvdr.

    Mit systemd ist es IMHO besser, den VDR die ganzen Konfigurationen aus /etc/vdr/conf.d holen zu lassen (für jedes Plugin eine Datei alla

    50-dvbhddevice.conf) und in Service-File den VDR ohne Parameter zu starten. Eine mögliche vdr.service im Anhang.


    Sörens Hinweis trifft übrigens nur zu, wenn Du den IR-Empfänger der S2-6400 nutzt, dann müssen seine angegebenen Requires und After im Service-File noch ergänzt werden. Bei mir ist dagegen lirc.service drin.

    Files

    Hallo thinokoe,

    schön, dass mein zweiter Schuss ins Blaue ein Treffer war :-)

    Ich hatte die Sourcen meines RPMs mit denen von Kernel 5.12 verglichen und dann die Änderungen in das tgz übernommen (ich dachte, Du wärst schon bei Kernel 5.12 weil Du oben von dem Update gesprochen hast). Inwieweit das auch mit anderen Kernel läuft wäre auszuprobieren (bzw. Änderungen in Sörens Repo zu suchen), aber ich vermute, dass entweder die Version im RPM oder das tgz laufen müsste. Änderungen gab's nur in saa716x_ff_phi.c und saa716x_pci.c

    Abgesehen davon können wie oben schon erwähnt auch mit dem Kernel 5.3 von der neuen OpenSuse 15.3 wieder Anpassungen nötigt werden wenn der Media-Tree eines neueren Kernel übernommen wird.


    Zu Frage 1: Schau mal in das syslog (journalctl) warum der Start misslingt und baue dann eine entsprechende Abhängigkeit in das VDR-service FIle ein. Falls Netzwerk benötigt wird nutze "network-online.target", bei den anderen network Targets steht das Netzwerk noch nicht zur Verfügung.

    Ich habe da z.B. After=network-online.target syslog.target lirc.service


    Gruß

    FireFly

    Schau mal, ob's mit der angehängten Datei (anstatt der zip-Datei) geht,also wieder hinter Source den Dateinamen auf das neue tgz in SOURCES ändern. Der erste Schuss ins Blaue konnte nicht gehen, da das der komplette Tree war, aber auch das habe ich mangels Tumbleweed-Installation nicht ausprobiert.

    Die neue openSUSE_Leap_15.3 wird wohl auch, so habe ich es verstanden, mit Kernelversion 5.3.x erscheinen.

    Ja, aber sie bauen immer z.B. einen neueren Mediatree etc ein, um neuere HW zu unterstützen. Das bringt aber immer dann Probleme mit sich, wenn von der Kernel-Version auf die Treiber geschlossen wird, deshalb kompiliert z.B. VirtualBox regelmäßig nicht mit neueren Versionen bis das angepasst ist

    Hier der Link zu Sörens 5.11er Tree: https://github.com/s-moch/linu…fs/heads/saa716x-5.11.zip

    Das File musst Du in das SOURCES Verzeichnis legen

    im SPEC-Verzeichnis dann in v4l-dvb-saa716x-20210111.spec in ca. Zeile 28 hinter "Source:" das Archiv durch das "saa716x-5.11.zip" ersetzen (ich hoffe, das %setup geht auch mit zip statt tar)

    und rpmbuild -bb v4l-dvb-saa716x-20210111.spec aufrufen.

    (oder auf Suse 15.3 warten, das Anfang Juni kommen soll :D)

    Ohne Gewähr ....