[streamdev] Streamen von Aufnahmen

Was all die DVB/TS/MPEG-Details angeht, da bin ich auch "raus", kenn mich da nicht aus, da werden mir vlc-debugging Ausgaben auch nicht helfen (ich verwendete für die Tests eh die Linux-Version und sehe alles in der Konsole: wenn alles OK ist (neben freetype-errors) lediglich ein paar "TS discontinuity", im Fehlerfall aber tatsächlich sehr viel für den Laien unverständliches Zeugs (kurzer Anfang s. unten)).

Wobei ich eben - siehe auch letzter Post - sowieso Zweifel habe, ob sich Aufwand hier auszahlen würde, weil zumindest der vlc eigentlich absolut alles "frisst", was man ihm vorsetzt, sprich egal ab welchem Byte-Index man ihm die Aufnahme vorsetzt. Einzige Ausnahme ist eben nur, wenn man auf die initiale 0- Anfrage mit einem range-Header antwortet, der nicht mit 0 startet (um so auch ein Springen zurück bis max. zum Anfang zu ermöglichen, hier immer als "full_" Modus bezeichnet).

Dass das ganze vielleicht demnächst auch in yavdr landet freut mich (auch wenn ich es bisher selbst nicht benutze).

[mpeg2video @ 0x7f75cc003ee0] ac-tex damaged at 7 0
[mpeg2video @ 0x7f75cc003ee0] ac-tex damaged at 5 1
[mpeg2video @ 0x7f75cc003ee0] ac-tex damaged at 7 2
[mpeg2video @ 0x7f75cc003ee0] ac-tex damaged at 4 3
[mpeg2video @ 0x7f75cc003ee0] skipped MB in I frame at 14 4
[mpeg2video @ 0x7f75cc003ee0] ac-tex damaged at 3 5
[mpeg2video @ 0x7f75cc003ee0] ac-tex damaged at 20 6
[mpeg2video @ 0x7f75cc003ee0] Warning MVs not available
[mpeg2video @ 0x7f75cc003ee0] concealing 1620 DC, 1620 AC, 1620 MV errors
[mpeg2video @ 0x7f75cc003ee0] ac-tex damaged at 7 0
[mpeg2video @ 0x7f75cc003ee0] ac-tex damaged at 5 1
[mpeg2video @ 0x7f75cc003ee0] ac-tex damaged at 7 2
[mpeg2video @ 0x7f75cc003ee0] ac-tex damaged at 4 3
[mpeg2video @ 0x7f75cc003ee0] skipped MB in I frame at 14 4
[mpeg2video @ 0x7f75cc003ee0] ac-tex damaged at 3 5
[mpeg2video @ 0x7f75cc003ee0] ac-tex damaged at 20 6
[mpeg2video @ 0x7f75cc003ee0] Warning MVs not available
[mpeg2video @ 0x7f75cc003ee0] concealing 1620 DC, 1620 AC, 1620 MV errors
[mpeg2video @ 0x7f75cc003ee0] 00 motion_type at 41 18
[mpeg2video @ 0x7f75cc003ee0] invalid cbp at 23 11
....

Ich habe nun endlich meinen Haupt-VDR nach zweieinhalb Jahren mal wieder aktualisiert, auf 2.0.3 - so dass nun auch das aktuelle streamdev plugin damit läuft.

Erst da fällt nun auf, dass die recordings-Seite so noch wenig brauchbar ist, denn sie ist völlig unsortiert - weder alphabetisch noch nach Datum (wie ich es mir wünschen würde) - was bei 265 Aufnahmen im Moment nicht wirklich praktikabel ist (einziger Ausweg: Browser-Textsuche). Ausserdem bräuchte man möglichst noch einen resume-Link je Aufnahme. Das sind ja Dinge, wo ich vielleicht wieder selbst sehen könnte, ob ich sie irgendwie hinbekomme.

Leider gibt es noch ein grösseres Problem. Der VDR stürzt ab, sobald man die recordings-Seite aufruft und gleichzeitig eine Aufnahme läuft. Dabei reagiert er sofort nicht mehr auf die FB. Das was grade läuft läuft weiter, auch Streaming funktioniert noch - so lange, bis dann der watchdog zuschlägt und einen Restart auslöst.
Im Log findet sich absolut nichts, abgesehen vom watchdog PANIC.
Verwendet man nur das Streaming als solches, ohne die recordings.html aufzurufen, gibt es keine Probleme. Für den Aufnahmen-Index kann man ggf. auch das svdrpsend Kommando LSTR verwenden - wenn man denn eine Konsole verfügbar hat. Aber für den Alltag ist das nat. nichts. Ausserdem ist mir früher schon aufgefallen, dass manchmal die Reihenfolge (und also die Indices) der recordings-Seite nicht die gleiche ist wie die, die LSTR liefert.
Ohne laufende Aufnahme passiert erst mal nichts. Aber wenn man die recordings-Seite aufgerufen hatte und später dann eine Aufnahme startet, ist das Phänomen sofort wieder da. Vielleicht lässt sich aus diesen Tatsachen ja eine Theorie des Problems ableiten..

Nachtrag zum Hänger bei Aufruf der recordings-Seite während/vor Aufnahme: konnte das auch mit dem ursprünglichen Stand aus dem August reproduzieren, und auf dem Test-VDR, der ausser streamdev-server nur noch das Plugin skincurses enthält, sonst keinerlei Plugins.

Eine weitere Anforderung, die man in der Praxis brauchen wird: steigt man in laufende Aufnahmen ein, so ist immer dort Schluss, wo zum Zeitpunkt des Wiedergabe-Starts grade das Ende war (hängt man nur wenige Minuten zurück, ist dauernd Schluss und man muss dauernd etwa mit pos=time.x an fortschreitender Position wiedereinsteigen). Entweder automatisch durch Erkennen, dass die Aufnahme noch läuft, oder via Parameter sollte man erreichen können, dass solche Aufnahmen dann nicht mit fixer Länge (range-header / content-length) laut Stand bei Wiedergabe-Start gestreamt werden, sondern wie beim live-Streaming mit "open end". Wozu vermutlich die Aufnahme bei Erreichen des vermeintlichen Endes nochmal neu eingelesen werden muss.

Den zusätzlichen delete habe ich grad mal angetestet - leider kein Erfolg!
Hätte mich aber auch gewundert, das ist ja kein schleichendes Speicherloch, das sich nach langer Laufzeit irgendwann mal auswirkt. Es passiert unmittelbar - wenn man die recordings-Seite aufgerufen hat, ist dann gleich das OSD "tot" (auch bei skincurses) - und zwar, wie ich nun festgestellt habe, nicht nur, wenn eine Aufnahme läuft oder man eine startet, sondern es reicht schon die Aufnahme-Liste im Menu zu öffnen (sie erscheint nicht mehr), auch ohne laufende Aufnahme. Sieht also eher so aus, als würde die Liste durch die recordings-Seite irgendwie "kaputtgemacht" - bei C mit den Pointern ist sowas ja immer schnell mal passiert.

Mit laufenden Aufnahmen kann der recplayer wie beschrieben umgehen: er spielt bis zum Ende zum Zeitpunkt des Wiedergabe-Start. Ich denke man könnte grob so vorgehen: das Flag isStillRecording beim Wiedergabe-Start in der Instanz sichern (recstreamer oder recplayer?), und wenn dann das Ende erreicht wurde und dieses Flag gesetzt ist, müsste er sich selbst neu instanziieren mit Beginn = bisheriges Ende (die Aufnahme würde neu eingelesen, und das Spiel beginnt erneut).

Dass die Liste so sortiert ist, wie im VDR-Menu, konnte ich nachvollziehen - allerdings muss man die Liste dazu eben auch erst mal im VDR-Menu geöffnet haben. Bei einem reinen Streaming-Server zB wird das nie passieren. Man müsste also wenigstens den Aufruf vom Plugin aus initial mal "simulieren". Dann wär das soweit OK. Ansonsten meine ich mit Sortierung ja nicht zwingend eine Umsortierung der Indices (sobald die Seite gut funktioniert ist man ggf. nicht mehr so auf die Indices angewiesen, aber solange man die URLs selbst eingibt/zusammenbaut sind sie ja die einzig praktikable Variante) - nur die Reihenfolge der Liste in der Ausgabe sollte alphabetisch und nach Datum sortiert werden können - die Spalte mit dem Index würde eben mitsortiert. Notfalls könnte man das auch via JavaScript erledigen (zB JQuery tablesorter).
Das mit der eigenen Seite je Aufnahme zum komfortablen Abruf sämtlicher Möglichkeiten klingt gut
Jeglicher sich daraus ergebende Streaming-Link sollte natürlich immer auch als Text herauskopiert werden können - denn das direkte Anstarten per Browser-Klick im Streaming-Client klappt nach meinen bisherigen Erfahrungen wie schon mal erwähnt kaum. Etwa der Desktop-Firefox bei "öffnen mit vlc" versucht das als Datei herunterzuladen und das Ergebnis dann an den vlc zu geben - nicht den vlc selbst die URL öffnen zu lassen. Unter Android ist der vlc nicht mal im Angebot. Man wird also häufig die URL selbst kopieren müssen.

Und um die letzte potentielle Baustelle auch nochmal zu erwähnen, die mir vorschwebt: ein Modus /current (neben /<channel> und /<aufnahme>.rec), der im Optimalfall alles was am VDR passiert 1:1 auch so streamt. In einer ersten simplen Variante könnte er nur beim Start das grade laufende live-Programm bzw. die grade wiedergegebene Aufnahme ab resume (wobei das glaub ich doch nicht während der Wiedergabe regelmässig geschrieben wird) rausgeben. Bei Änderungen (Umschalten, Wiedergabe-Start/Stop etc) müsste man eben erst mal die /current URL im Client neu starten.

Wenn ich was "probiere", dann wären das höchstens Experimente, am ehesten bzgl. Thema laufende Aufnahme, deren Erkenntnisse ich Dir zeitnah mitteilen würde. Ist aber sehr ungewiss im Moment. Lass Dich nur von nichts abhalten - und Danke!

Ich kann für beide meiner VDRs bestätigen, dass die Hänger/Restarts Geschichte sind - Danke!