Das Problem beim Schneiden ist, dass das Filesystem mit SSD schneller voll läuft als VDR es prüft. Da werden dann schon mal 10 GB in 23 sec kopiert. Mit einer vergleichsweise langsamen HDD gibt es keine Probleme.
Um mal zu diesem Thema zurück zu kommen: wie kann man das lösen? Immer warten mit dem Schneiden bis "vielleicht" die alten Aufnahmen gelöscht sind ist ja keine Lösung zumal laufende Aufnahmen dabei abbrechen können.
Ich mounte die Devices immer über Namen (/dev/sda1 etc.), nie über UUIDs. Von daher sollte es also schon passen.
Aber wer weiß, wo sonst noch UUIDs verwendet werden?
Die UUIDs müssten noch in der grub.cfg stehen und werden von mkinitrd angepast. Ich würde folgendes probieren (habe letztes Jahr damit die Systempartition von Suse 15.x kopiert):
Das Problem beim Schneiden ist, dass das Filesystem mit SSD schneller voll läuft als VDR es prüft. Da werden dann schon mal 10 GB in 23 sec kopiert. Mit einer vergleichsweise langsamen HDD gibt es keine Probleme.
Ich hätte da noch ein ähnliches Problem: wenn man auf einer relativ vollen SSD schneidet kann es passieren, dass nicht rechtzeitig alte zum Löschen markierte Aufnahmen gelöscht werden und die Platte dann voll läuft und auch Aufnahmen abbrechen.
Kann man das öfter prüfen? Oder auch das MinDISKSPACE hoch setzen?
Was zeigt denn der Dell Laptop als Geschwindigkeit am Ethernet-Anschluss an?
Meine Fritzbox 7490 schafft mindestens 250MBit Down und 50MBit Up.
Der interne Gigabit-Ethernet-Switch der 7490 schafft das, da das Glasfasermodem offenbar ein externes Gerät ist und via LAN1 als Uplink angeschlossen sein müsste.
Das DSL-Modem der 7490 schafft max. 100 MBit/s. Da Taipan aber einen Glasfaseranschluß hat und wie o.a. eine Fritzbox 5530 Fiber nutzt, spielt das hier keine Rolle.
Was zeigt denn der Dell Laptop als Geschwindigkeit am Ethernet-Anschluss an?
Kannst Du mit einem anderen PC via Ethernet testen, z.B. ein ISO mit dem VDR runter laden?
... deshalb schrieb kls ja auch "As a quick test" (um die richtige Stelle im Code zu finden) und "I'll see..." und nicht, dass es das Problem behebt
VDR wurde aber während der Aufnahme mehrfach unterbrochen
Was meinst Du mit unterbrochen? Ist der VDR gecrasht oder wurde er restartet? Restart via Notausstieg oder miitels systemctl oder ähnlichem?
Ist das mit den max. 40 Zeichen bei Ordnern für Aufzeichnungen eigentlich hart im VDR gesetzt?
In epgsearch gibt es eine Grenze von 40 Zeichen falls Du damit Aufnahmen programmierst
Ich habe das im Makefile mit PLUGIN_EPGSEARCH_MAX_SUBTITLE_LENGTH=4096 hochgesetzt
... damit langsame SAT>IP-Server genug Zeit haben einen Befehl umzusetzen bevor der nächste kommt??
Zumindest bleiben die Pids, die hinzugefügt oder gelöscht werden sollen in der Liste und werden beim nächsten UpdatePids() (nach Ablauf des Timeout) zum SAT>IP-Server geschickt. Trotzdem kann das zu langsam (oder unsychronisiert?) sein und das Bild dann schwarz bleiben. Da hilft es dann auch nicht mit den Zahlentasten die Sendernummer nochmal einzugeben. Manchmal gibt's aber auch nach etlichen Sekunden doch ein Bild.... Seehr seltsam das Ganze ...
Ich denke, das ist bei den alten Full-Featured-Karten mal besser gelaufen
Bei mir tritt es mit der TT S2-6400 Full-Featured-Karte bei HD-Aufnahmen auf, SD habe ich nicht getestet.
Dass der VDR am Ende der Wiedergabe nicht auf Eingaben reagiert habe ich auch schon öfters beobachtet, allerdings immer nur bei Aufnahmen, die direkt vorher geschnitten wurden, als würde er warten, "dass da noch was kommt" wie beim Anhalten des Live-TV. Gefühlt tritt das erst seit VDR 2.4.x auf.
Bei "älteren" Aufnahmen (geschnitten vor etlichen Minuten? oder Stunden ?) wartet er am Ende ca. 10 Sec bis er wieder auf Live-TV schaltet, ist in dieser Zeit aber bedienbar.
cSatipTuner::UpdatePids() im SatIP-Plugin scheint die zu liefernden Pids nur zu ändern, wenn mindestens der Timeout von 250ms erreicht ist falls der force-Parameter nicht gesetzt ist.
Wenn der VDR die Daten schneller erwartet bzw. prüft kommt es zu der Meldung "...not found, got ...." da der SATIP-Server noch die alten Pids liefert.
Ist das auch für altere Versionen relevant? openSuse hat momentan Kernel 5.3 und ab Juni 5.14
Evtl. passt diese Lösung zu Deinem Problem ...
Beim Start prüft skinElchiHD, ob ein TrueColor OSD zur Verfügung steht (https://github.com/FireFlyVDR/…d95941/skinelchihd.c#L216). Wenn sich das dann nachträglich ändert wird's schwierig ....
Ähnlich Probleme gibt's wenn das Ausgabedevice detached ist wenn der VDR gestartet wird.
Eigentlich wäre eine Funktion SuspendOsd() im VDR nötig um jegliche Skin-Aufrufe zu unterbinden, oder?
wäre es möglich den Crash des VDR abzufangen
Probier doch mal, ob die Kanalanzeige auch crasht wenn Du folgende Zeile in displaychannel.c einfügst:
That explains why I did not stumble over that issue during development 
Das sieht aus, als wäre OSDsize 0 x 0 Pixel. Das wird mit esyslog protokolliert und im Log müsste dazu etwas mit "skinelchiHD DisplayChannel: Creation of pixmap failed....." stehen. Bekommst Du das?
Abfangen kann ich das nicht, nur wenn vor JEDEM Pixmap-Zugriff ein if stehen würde was das ganze nicht nur unleserlich sondern auch fehleranfällig macht. Allein in displaychannel.c sind 122 Pixmap-Zugriffe! Der Konstruktor kann auch kein "false" oder sowas zurück liefern um anzuzeigen, dass das Erstellen des OSD nicht funktioniert hat.
Das Skin geht davon aus, dass es auch etwas darstellen soll wenn es aufgerufen wird - warum sonst sollte man es aufrufen? Wenn wirklich nichts dargestellt werden soll müsste es dafür einen Schalter im VDR geben, der das OSD disabled, also die Skins nicht aufruft.
Als Workaround müsste das setzen einer OSD Größe im nulldevice helfen (GetOSDSize darf nicht 0 x 0 zurück liefern).
Wo crasht er denn?
