Moin!
Ich hab den aktuellen git-Stand mal ins yavdr-testing-PPA geladen, dann könnt ihr evtl. noch ein paar Tester motivieren.
Lars.
Moin!
Ich hab den aktuellen git-Stand mal ins yavdr-testing-PPA geladen, dann könnt ihr evtl. noch ein paar Tester motivieren.
Lars.
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
....
Display More
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.
Das mit dem Absturz schaue ich mir am Wochenende an. Schuß ins Blaue:
diff --git a/server/connectionHTTP.c b/server/connectionHTTP.c
index c3b3f90..827058f 100644
--- a/server/connectionHTTP.c
+++ b/server/connectionHTTP.c
@@ -36,6 +36,7 @@ cConnectionHTTP::~cConnectionHTTP()
{
delete m_Streamer;
delete m_Recording;
+ delete m_MenuList;
}
bool cConnectionHTTP::CanAuthenticate(void)
Display More
Ob eine Aufnahme noch läuft, sollte der recplayer über indexFile->isStillRecording() abfragen können. Die Gesamtlänge im Content-Range-Header muss in diesem Fall auf "*" gesetzt werden. Ob der Recplayer mit laufenden Aufnahmen umgehen kann, müsste untersucht werden.
QuoteAusserdem 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.
SVDRP hat eine eigene Recordings-Liste, die grundsätzlich unsortiert ist. Die List wird ausschließlich mit Aufruf von LSTR aktualisiert. Streamdev greift hingegen auf die "globale" Recordings-Liste zu. Die wird laufend aktualisiert und - sobald man ins VDR Recordings-Menü geht - auch sortiert oder umsortiert. Eine eigene Recordings-Liste auch für Streamdev halte ich für eine schlechte Idee (ist es IMHO auch bei SVDRP und verursacht Ärger z.B. beim serverseitigen Schneiden via remotetimers-Plugin). Die Timer-Liste müsste bei jedem Zugriff aktualisiert werden, was bei vielen Aufnahmen entsprechend lang dauert und schlimmstenfalls schlafende Festplatten aufweckt. Die globale Recordings-Liste sortiert sich immer wieder um, von daher ist der Zugriff über Aufnahme-Nummer auch eine schlechte Idee. Deshalb habe ich auch den Zugriff über Device- und Inode-Nummer eingeführt. Eine sortierte Aufnahmen-Liste in Streamdev kann auf die Sortierung durch VDR zurückgreifen, solange die Anzeige Verzeichnisweise passiert. Nur wenn alle Aufnahmen in einer langen Liste stehen, müsste sich Streamdev selbst um die Sortierung kümmern.
Jede Aufnahme sollte außerdem eine eigene Seite bekommen, um alle Link-Optionen abbilden zu können (Markierungen, Resume, Prozentualer Startpunkt). Bezüglich Menü ist also noch einiges zu tun.
Am Wochenende habe ich voraussichtlich wieder ein wenig Zeit. Gib mir bitte per PM bescheid, wenn Du dich um eine der Baustellen kümmerst, nicht dass wir die Arbeit doppelt machen.
Moin!
Ich hab Klaus mal vorgeschlagen, eine UUID oder anderweitig global eindeutige ID in der recording-info unterzubringen - leider mag er das nicht.
Das einzige, quasi unveränderliche Merkmal einer Aufnahme ist eigentlich nur ihr Verzeichnisname unterhalb des Video-Directories, oder? Natürlich kann man den ändern, aber das passiert wesentlich seltener als eine Umsortierung.
Lars.
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!
Die Aufnahmenliste wird ja regelmäßig aktualisiert, es kann sein, dass es beim Öffnen des Aufnahmemenüs auch direkt angestoßen wird.
Vor jedem Scan wird die interne Aufnahmenliste komplett gelöscht und dann neu aufgebaut. Wenn ein Plugin also irgendwie auf cRecording-Objekte aus dieser Liste zugreifen möchte, gibt's den segfault.
Das cRecordings-Objekt "Recordings" ist abgeleitet von cThread, deshalb hat das Objekt die Methoden Lock/Unlock. Die werden vom Videoscanner genutzt. D.h. wenn ein Plugin die Aufnahmenliste ansehen will oder kopieren möchte (wäre wahrscheinlich sinnvoll, damit man eigene Objekte hat, dürfte auch schneller gehen, als selbst die Platte zu durchsuchen oder ein eigenes cRecordings-Obekt zu benutzen), dann muss es sie vorher sperren.
Siehe http://projects.vdr-developer.…it/tree/recording.c#n1257
Diese internen Listen des vdr sind nicht immer für den Zugriff von Plugins geeignet.
Lars.
Fix für den Hänger ist eingecheckt. Der Lock auf den Recordings wurde wegen fehlendem virtuellen Destruktor nicht wieder freigegeben.
QuoteDas einzige, quasi unveränderliche Merkmal einer Aufnahme ist eigentlich nur ihr Verzeichnisname unterhalb des Video-Directories, oder?
Richtig. Da mir der Verzeichnisname aber zu lang war und ich mir außerdem das HTML-escaping von Sonderzeichen sparen wollte, nutze ich nun Device- und Inode-Nummer des Aufnahmeverzeichnisses.
Ich kann für beide meiner VDRs bestätigen, dass die Hänger/Restarts Geschichte sind - Danke!
Don’t have an account yet? Register yourself now and be a part of our community!