kls Entwickler

Selbst das halte ich für zu lang. Ich würde eher an eine bis sehr wenige Sekunden denken.

[…] Das ist aber schon ein sehr großes Zeitintervall!

[…] Ich hab das gerade nochmal nachgestellt: zum Benutzer hin wird immer <errors> angezeigt. <tmperrors> dient nur dazu, nach einer Fortsetzung der Aufnahme nach einer Unterbrechung die bis dahin geschätzte Anzahl der Fehler (<tmperrors>) von <errors> abziehen zu können, um dann die genaue Anzahl anhand der neu hinzukommenden PTS-Werte ermitteln zu können. Das Ganze entstand aus der Forderung, dass die Anzahl der gemeldeten Fehler möglichst auch nach einem Schnitt uder Index-Neugenerieren…

Nach MakeDirs() wird cStatus::MsgRecording(device, Recording.Name(), Recording.FileName(), true) aufgerufen. Ein Status-Plugin kann zurecht erwarten, dass das Directory von Recording.FileName() zu dem Zeitpunkt bereits existiert. Würde MakeDirs() erst (verzögert) im cRecorder aufgerufen, wäre das u.U. nicht der Fall, wenn es 27 Sekunden dauern kann, bis die Platten aktiv sind.

Da die "Fehler" ganz am Schluss auftreten (Code, 3 lines) und mit 51 (bei 25fps) ziemlich genau 2 Sekunden Video entsprechen, schließe ich auf ein Timing-Problem beim Beenden von cRecorder::Action(). Ich hatte damals eine "Karenzzeit" von 2 Sekunden (LEFTOVERTIMEOUT) eingebaut, was bei mir immer ausgereicht hat, bei dir aber anscheinend gerade so überschritten wurde. Aber wenn ich es mir recht überlege braucht es das gar nicht, denn ich weiß ja am Schluss, ob die Schleife ordentlich beendet…

[…] Das könnte natürlich sein.

[…] Das heißt, der Client "sieht" gar nicht das Video-Verzeichnis des Servers? Dann kann das natürlich nicht funktionieren.

[…] recording.h: (Code, 2 lines) recording.c: LengthInSeconds() -> NumFrames() -> cIndexFile::GetLength() (Code, 9 lines) Möglicherweise liefert stat() einen Fehler. Vielleicht liefert die markierte Zeile einzufügen brauchbare Infos.

Kannst du bitte mal alle Log-Meldungen im Zusammenhang mit dieser Aufnahme posten?

[…] Die Frage ist dann wohl, warum das keine gültigen Daten liefert, denn ansonsten hätte ja Recording->LengthInSeconds() schon einen richtigen Wert geliefert. Recording->LengthInSeconds() ruft cRecording::NumFrames() auf, was wiederum cIndexFile::GetLength() aufruft. Wenn, dann würde ich dort mal nachschauen, was schiefgeht.

[…] Kannst du mal in svdrp.c DumpSVDRPDataTransfer = true setzen und schauen, worüber sich die zwei so unterhalten?

Wenn während der Aufnahme der Datenstrom abbricht, dann wird die Zahl der fehlenden Frames geschätzt (Anzahl der Sekunden der Unterbrechung mal FPS) und als <tmperrors> in die info-Datei geschrieben. <errors> ist (aus Gründen der Rückwärtskompatibilität) die Gesamtzahl der Fehler und beinhaltet auch <tmperrors>. Wird die Aufnahme in diesem Zustand abgebrochen, bleibt in deinem Fall O 51 51 stehen. Die Frames fehlen aber am Ende der Aufnahme und sind somit nicht wirklich fehlerhaft. Die auf der…

man vdr.5: (Code, 6 lines)

Was mir noch eingefallen ist: diese Änderung hilft nur bei Timern, die weit genug in der Zukunft liegen. Bei einem neu angelegten Timer, der sofort loslaufen soll, dauert es trotzdem 27 Sekunden, in denen das Menü "eingefroren" ist.

Wenn das ein bekannter Fehler in exit() ist wundert es mich etwas, dass der nicht dort behoben wird. Dein Workaround sieht für mich gut aus. Sind die sleep(1) wirklich nötig? Die erste Log-Meldung halte ich für überflüssig, denn es wurde bereits esyslog("PANIC: watchdog timer expired - exiting!"); gemeldet. Die zweite Meldung würde ich zu esyslog("PANIC: watchdog timer failed - aborting!"); machen.

Wenn mir jemand zeigen kann, wo der Fehler in VDR liegt, kann er das auch gerne hier in diesem Thread tun.

Etwas nachgebessert, damit auch wirklich mindestens 60 Sekunden vor dem Timer-Start der SpinUp gemacht wird: (Code, 52 lines)

Falls die Frage an mich ging: mit distcc habe ich keine Erfahrung. Ich compiliere immer auf der Zielmaschine.