Posts by FireFly

Bei mir werden die wieder frei gegeben, aber es dauert etwas (10 min?), da der VDR die Aufnahmen immer verzögert löscht.

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.

seahawk1986 wrote:

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

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

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.

berndb wrote:

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.

kls wrote:

'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

kamel5 wrote:

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

jsffm wrote:

Doch nicht, wenn als unsigned deklariert.

Dann geht aber kein -1 für "undefined". Und bei einem Überlauf kann es auch wieder 0 werden.

in recordings.h fehlt noch ein "const"

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

MegaV0lt wrote:

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

Ich hatte gestern ein paar Aussetzer und dabei gesehen, dass der NaluDumper TS Continuity Fehler im Syslog meldet.

https://www.udo-richter.de/vdr/naludump.html
Fortschrittsanzeige gibt's da aber auch nicht.

Es gibt ein Update für skinElchi HD mit folgenden Änderungen:

• improved responsiveness during textscrolling
• fixed display of mcText

Hier geht es zur Homepage

und hier direkt zum Download 0.5.4

Happy compiling

FireFly

Evtl. war das e-tobi und sein Patch im Anhang?!?

S:oren wrote:

Das IR-Device ist nur das letzte, was der Treiber initialisiert. Wenn das da ist, sind sicher auch die DVB-Devices der S2-6400 einsatzbereit.

Oh, interessant

Bei mir war das aber bisher nie nötig, wahrscheinlich ist der Rechner "langsam genug" (2x 1,6 GHz)

thinokoe wrote:

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.

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.

thinokoe wrote:

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

Danke, das kannte ich noch nicht

Uwe wrote:

Du kannst aber dem dvbhddevice einfach die Option „-o“ mitgeben.

Das dvbhddevice Plugin hat aber gar keine Parameter, im Quelltext des Plugins werden auch keine ausgewertet....

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 )

Ohne Gewähr ....