Jump to content

DVBViewer v7.0.0.0(4) – Delegierter Timeshift wird vom Server nach einem DVBViewer-Absturz fortgesetzt


dbotev

Recommended Posts

So, anbei ein echt unschöner Fehler bei aktiviertem Tweak „Timeshift-Aufnahmen an den Media Server delegieren“.

Anscheinend wurde kein Watchdog-Mechanismus bei einem Delegierten Timeshift implementiert.

Support.zip wird hier nicht helfen, da es sich um einen besonderen Fall nach einem Client-Absturz handelt, daher verzichte ich erstmals auf das Hochladen. Das wird wirklich nichts bringen. Das Reproduzieren ist trivial.

So wird der Bug reproduziert. Jeder kann es selber mit Client v7.0.0.0(4) und Server 3.0.0.0(1) ausprobieren:

         1. DVBViewer Server und Client sind mit aktiviertem Tweak „Timeshift-Aufnahmen an den Media Server delegieren“ und mit aktiviertem Timeshift am selben PC zu betreiben.

Hinweis: DVBViewer Client und Server müssen wirklich auf demselben PC laufen.

        2. Beliebigen Sender einstellen.

  3. Einige Sekunden warten.

            4. Prozess DVBViewer.exe hart terminieren (z.B. mit dem CMD Kommando taskkill /F /IM DVBViewer.exe). Somit wird quasi ein ungewollter Client-Absturz erzwungen.

        5. Im Web Interface den Server-Status beobachten –> Timeshift läuft weiter, Tuner bleibt belegt, die Festplatte wird langsam voll, PC geht nie in Schlafmodus usw …usw…

 

Um den PC vom „Geiselzustand“ zu befreien, sollte man den Timeshift-Timer  manuell im Server-Web Interface löschen, oder…

…DVBViewer erneut starten, den gleichen Sender einstellen, Sender umschalten oder DVBViewer ordnungsgemäß schließen.

Service stoppen und anschließend Service neu starten bringt natürlich nichts, da der Timeshift-Timer-Task immer noch präsent ist.

Ganz wichtig: die Timeshift Datei sollte man nach dem Spiel manuell Löschen, da diese unnötigen Speicherplatz belegt.

 

Wie bin ich draufgekommen:

Heute war meine Festpatte voll. Mehrere PVR Aufnahmen wurden vermutlich wegen Tuner-Mangel und HDD-Platzmangel nicht gestartet. Schade...

Nach genauer  Untersuchung habe ich festgestellt, dass der Schreibvorgang einer Timeshift Datei nicht ordnungsgemäß beendet wurde und der Tuner entsprechend nicht freigegeben wurde, obwohl das Häkchen bei „Timeshiftdatei-Beibehalten“ beim Client von mir nie gesetzt wurde.

Dabei konnte ich mich an einem ungewollten Absturz des DVBviewers an diesem Tag erinnern. Der Absturzverursacher war eher die Grafikkarte beim Monitorwechsel und nicht direkt DVBViewer.exe.

Immerhin solche Client-Abstürze passieren und sollten keinesfalls  Memory Lags verursachen und Hardware Ressourcen blockieren.

 

 

Hinweis zur Problemlösung:

Im WEB Interface sieht man eindeutig, dass der Server den Erzwungenen Clientabsturz erkennt. Die Clientliste im Web Interface wird einige Sekunden nach dem erzwungenen Clientabsturz leer (bei mir war ja nur ein Client verbunden).  Der Server wäre also auch ohne Watchdog in der Lage sein, sich selber vom ungewöhnlichen „Geiselzustand“ zu befreien.

 

 

Edited by dbotev
Link to comment

Was du beschreibst, ist nur die Spitze des Eisbergs.

 

Um die wirklichen Dimensionen des Problems zu erahnen, mache dir kurz klar, dass es kein Timeshift gebraucht hätte, um die konzeptionelle Schwäche in der DVBViewer <--> DMS-Beziehung aufzudecken. Eine stinknormale an den DMS delegierte manuelle (Sofort-)Aufnahme mit anschließendem DVBViewer-Absturz hätte es auch getan. Die läuft nämlich ebenfalls standardmäßig 23:59 Stunden (per Tweak anpassbar), wenn sie niemand stoppt.

 

Mache dir weiterhin klar, dass auch ein Remote-DVBViewer auf einem anderen PC manuelle Aufnahmen veranlassen kann, der währenddessen vielleicht gar kein TV, sondern lokal eine Audio CD wiedergibt, also als Client gar nicht in Erscheinung tritt. Und dass es mehrere mit dem Server assoziierte DVBViewer im Netzwerk geben könnte, die Aufnahmen delegieren. Und dass nicht nur der DVBViewer, sondern im Prinzip jeder hergelaufene Client Aufnahmen starten kann. Dazu reicht ein Browser auf einem Smartphone.

 

Im DMS gibt es keine Client- oder Sessionverwaltung, die manuelle Aufnahmen notfalls abbrechen könnte, falls sich der Client, der sie veranlasst hat, nicht in regelmäßigen Intervallen z.B. über eine TCP-Verbindung meldet. Der DMS weiß überhaupt nicht, wer für welche dieser Aufnahmen verantwortlich ist. Es liegt allein an den Clients, sie irgendwann zu stoppen.

 

Deshalb lässt sich das nicht einfach durch einen Bugfix beheben. Es erfordert eine konzeptionelle Änderung mit entsprechendem Implementationsaufwand. Und das ist nur ein Punkt auf der To-Do-Liste....

 

Soweit klar? Kurzfristig wird sich das nicht ändern. Es gibt nur einen Wachhund, der ausufernde Aufnahmen stoppen kann: Das bist du selbst :)

 

Link to comment

Im Prinzip vollkommen berechtigte Antwort, wenn es tatsächlich um die Aufnahme (Record ) die Rede wäre…

Ich würde gern Timeshift und Record voneinander klar trennen.  

Nichtsdestotrotz - das mit dem REC-Button beim DVBViewer ist mir seit 40 Jahren bewusst, noch bevor es ja DVBViewer gab. Klar bin ich beim Drucken der REC-Buttons selber schuld…insbesondere, wenn ich auf REC drucke und danach STOP vergesse. Das war noch in der Welt der VHS-Rekorder vor 40 Jahren so, wird auch so weiter bleiben. Kein Thema.

Wir sind aber nicht mehr in der Welt der VHS Rekorder.

Der gravierende Unterschied hier ist (außer der Tatsache, dass Record kein Timeshift ist): beim delegierten Timeshift druckt ja quasi die Software im Hintergrund auf den imaginären REC-ähnlichen „Timeshift“-Button (Achtung! Kein REC sondern Timeshift) und zwar - sowohl beim Starten, als auch beim Stoppen. Das macht also nicht der Anwender selbst, sondern die Software. Damit will sich der heutige Anwender nicht befassen.

Egal – den Tweak habe ich gerade abgeschaltet und damit hat sich das... Der Tweak wäre irgendwann in Verbindung mit einem „Remote-Timeshift“ interessant. Ich bin momentan am Überlegen, ob ein sonstiger Nutzen des Delegierens gegenüber der klassischen Timeshift-Lösung zu finden ist. Vielleicht übersehe ich was. Gerne lerne es hier.

Trotzdem ein Verbesserungsvorschlag (das wird aber niemandem gefallen …ich mache es trotzdem): Wenn der delegierte Timeshift wirklich als Record zu betrachten ist, dann möge, bitte, zumindest das Server-Icon unten im Taskbar bei einem delegierten Timeshift ROT sein! So soll es bei einem Record seit mehr als 40 Jahren sein. So ist es auch beim DVBViewer-Record normalerweise.

Bei Rot habe ich als der „alleinige Wachhund“ deutlich bessere Chancen. Insbesondere nach einem verpassten Client-Absturz. Man schaut nicht gern 100mal am Tag über Web-Interface, ob der Server Status noch OK ist.  Ich bezweifele aber, dass dieses Permanent-Rot den Anwendern gefallen wird.  Mir gefällt es ehrlich gesagt auch nicht.

Also – der Anwender hat hier als „Wachhund“ keinerlei Chancen…schade…Delegierter Timeshift-AUS

 

Link to comment

Rot bei Timeshift wäre für mich total kontraproduktiv. Ich habe permanenten Timeshift aktiv, folglich wäre das Icon bei mir immer rot. Dann müsste ich laufend ins Webinterface schauen ob gerade eine Aufnahme läuft oder nicht.

Die Tweak-Option, Timeshift an den DMS zu delegieren ist per Default ja aus, bei mir übrigens auch. 99% der Anwender werden gar nicht auf die Idee kommen die zu aktivieren (bzw. überhaupt den Tweaker zu benutzen) wenn alles läuft.

 

Link to comment
1 hour ago, dbotev said:

Der Tweak wäre irgendwann in Verbindung mit einem „Remote-Timeshift“ interessant.

 

Beim Remote-Timeshift ist das Problem nicht das Delegieren der Aufnahme, sondern die Wiedergabe im DVBViewer, weil er die Datei nicht direkt von der Platte lesen kann, sondern über eine HTTP-Verbindung erhält. Zwar kann der DVBViewer via HTTP gelieferte Dateien abspielen, aber diese Fähigkeit hat nur der für Dateiwiedergabe zuständige Zweig. Die Live-Wiedergabe-Unit, die die Timeshift-Wiedergabe organisiert, kann das nicht. Um das zu ändern, müsste einiges umgebaut werden.

 

1 hour ago, dbotev said:

Ich bin momentan am Überlegen, ob ein sonstiger Nutzen des Delegierens gegenüber der klassischen Timeshift-Lösung zu finden ist.

 

Einen Nutzen gibt es, wenn man die Timeshiftaufnahme mit "Timeshift-Datei beibehalten" in eine bleibende Aufnahme umwandelt. Sie gelangt so in die Aufnahmedatenbank des Media Servers, erscheint dadurch automatisch in allen UPnP-Clients, im Webinterface, via DVBViewer Add-On in Kodi, im DVBViewer-Controller unter Android...

 

Wird die Timeshiftaufnahme vom DVBViewer durchgeführt, muss man in dem Fall einges beachten und veranstalten, um sie in den Media Server zu integrieren.

 

Timeshiftaufnahmen vorheriger Versionen ließen sich überhaupt nicht in die Aufnahmedatenbank integrieren, nicht mal in die des DVBViewers, und waren technisch so gestaltet, dass sie manche Clients ohne Nachbearbeitung nicht abspielen konnten.

 

Wie auch immer - der Report im ersten Post hat erst mal zu einer Verbesserung geführt. Der Media Server speichert den zur Timeshiftaufnahme gehörenden Timer nicht mehr in seiner svctimers.xml. Dies verhindert, dass die Timeshiftaufnahme nach einem Server-Stopp und -Neustart sinnlos fortgesetzt wird. Der Server könnte die Datei im Prinzip auch gleich löschen, wenn er gestoppt wird, was aber nur gelingt, wenn der DVBViewer sie nicht mehr geöffnet hat.

 

Link to comment
vor 2 Stunden schrieb Griga:

 

Beim Remote-Timeshift ist das Problem nicht das Delegieren der Aufnahme, sondern die Wiedergabe im DVBViewer, weil er die Datei nicht direkt von der Platte lesen kann, sondern über eine HTTP-Verbindung erhält. Zwar kann der DVBViewer via HTTP gelieferte Dateien abspielen, aber diese Fähigkeit hat nur der für Dateiwiedergabe zuständige Zweig. Die Live-Wiedergabe-Unit, die die Timeshift-Wiedergabe organisiert, kann das nicht. Um das zu ändern, müsste einiges umgebaut werden.

Das wissen vermutlich die meisten, ich erwähne es trotzdem. Als Zwischenlösung bis es soweit ist mache ich es folgendermaßen, um „Remote-Timeshift“ Funktionalität an einem Client zu emulieren: \\ServerPC\D$\PVR\TEMP\Timeshiftdatei.ts  ..also Lesen von der Festplatte über Intranet.  Der Pfad ist nur ein Beispiel und lässt sich mit jedem beliebigen Player  (DVBViewer, VLC,Kodi) auf dem Remote-Client abspielen. Nachteil- sobald der DMS das Beschreiben der Datei „Timeshiftdatei.ts“ unterbricht (z.B. wegen Senderwechsel) ist es vorbei. Durch die neue „Timeshift-Beibehalten Option“ wird dieser Nachteil einigermaßen umgangen. Das Ganze funktioniert natürlich nur im eigenen Netz. Immerhin, dadurch lässt sich die Vergangenheit als Notlösung auf einem remote Client abspielen.

Zitat

 

Einen Nutzen gibt es, wenn man die Timeshiftaufnahme mit "Timeshift-Datei beibehalten" in eine bleibende Aufnahme umwandelt. Sie gelangt so in die Aufnahmedatenbank des Media Servers, erscheint dadurch automatisch in allen UPnP-Clients, im Webinterface, via DVBViewer Add-On in Kodi, im DVBViewer-Controller unter Android...

 

Wird die Timeshiftaufnahme vom DVBViewer durchgeführt, muss man in dem Fall einges beachten und veranstalten, um sie in den Media Server zu integrieren.

 

Timeshiftaufnahmen vorheriger Versionen ließen sich überhaupt nicht in die Aufnahmedatenbank integrieren, nicht mal in die des DVBViewers, und waren technisch so gestaltet, dass sie manche Clients ohne Nachbearbeitung nicht abspielen konnten.

 

Danke für die Erläuterung. Wieder was gelernt. Ich hab, warum auch immer, die Timeshift-Delegieren-Option aktiviert und habe die klassische Methode nicht lang genug evaluiert.

 

 

@HaraldL: ja das mit Rot beim Timeshift sehe ich genauso. War nur ironisch gemeint, um den Unterschied zwischen Timeshift und Record etwa anzudeuten.

 

Edited by dbotev
Link to comment
21 hours ago, Griga said:

Der Media Server speichert den zur Timeshiftaufnahme gehörenden Timer nicht mehr in seiner svctimers.xml. Dies verhindert, dass die Timeshiftaufnahme nach einem Server-Stopp und -Neustart sinnlos fortgesetzt wird. Der Server könnte die Datei im Prinzip auch gleich löschen, wenn er gestoppt wird, was aber nur gelingt, wenn der DVBViewer sie nicht mehr geöffnet hat.

 

Das Löschen ist möglich, z.B. bei folgendem Ablauf:

  • Der DVBViewer hat eine Timeshiftaufnahme an den lokalen DMS delegiert.
  • DVBViewer stürzt ab oder wird abgeschossen, Timeshiftaufnahme läuft auf dem DMS bis zu 23:59 Stunden weiter.
  • DMS wird gestoppt -> stoppt die Timeshiftaufnahme und löscht sie, falls möglich. Falls das Löschen nicht gelingt, weil die Datei noch im DVBViewer geöffnet ist, gelangt die Aufnahme in die Aufnahmedatenbank und kann später über das Webinterface gelöscht werden.
  • DMS wird wieder gestartet, die Timeshiftaufnahme ist vielleicht und der dazugehörige Timer auf jeden Fall weg.

Die Frage ist jedoch: Will man das so? Wenn der DVBViewer abstürzt, hat man keine Gelegenheit mehr, ein Beibehalten der Aufnahme zu veranlassen. Nach einem Stopp des DMS ist sie dann unwiederbringlich weg. Außerdem stoppt der DMS alle Aufnahmen, wenn der Anwender den PC in "Energie sparen" herunterfährt, und würde in dem Fall auch versuchen, die Timeshiftdatei zu löschen. Dabei ist unklar, ob erst der DVBViewer auf "Energie sparen" reagiert und Wiedergabe und Timeshift beendet (-> Löschen gelingt) oder erst der DMS (Löschen gelingt nicht).

 

19 hours ago, dbotev said:

Als Zwischenlösung bis es soweit ist mache ich es folgendermaßen, um „Remote-Timeshift“ Funktionalität an einem Client zu emulieren: \\ServerPC\D$\PVR\TEMP\Timeshiftdatei.ts

 

Das kann mit dem aktuellen DVBViewer 7.0.0.x nicht funktionieren, da er beim Delegieren von Timeshiftaufnahmen explizit anhand der IP-Adresse (!) des DMS ermittelt, ob es sich um einen lokalen DMS handelt. Falls nicht, wird nicht delegiert.

 

Nichtsdestotrotz ist die Verwendung von UNC-Pfaden eine Idee... wenn (und nur wenn) der DMS Timeshiftaufnahmen in ein Verzeichnis schreibt, dass in den DMS-Optionen -> Aufnahmen -> Aufnahmeverzeichnisse als UNC-Pfad eingetragen ist, kann der DVBViewer mit einigen wenigen Anpassungen eine Remote-Timeshiftaufnahme delegieren und wiedergeben (das kriegt die Live-Wiedergabe-Unit hin). Der wesentliche Punkt ist dabei, dass der DVBViewer die Timeshiftaufnahme in der vom DMS erhaltenen Timerliste mit einem UNC-Pfad vorfindet.

 

Ich habe es mal probiert. Der Netzwerkpfad war DMS -> WLAN -> Fritzbox -> Gigabit-LAN -> DVBViewer. Meine Erfahrungen:

  • Im Prinzip funktioniert es, aber schon beim Ersten HD nur mit stockender zeitversetzter Wiedergabe (bei RTL SD ok). Das Problem dabei: Der DMS liefert den Sender doppelt, einmal als RTSP-Livestream, einmal zeitversetzt aus der Timeshiftdatei. Die daraus resultierenden 25 MBit/s netto sollte mein WLAN eigentlich locker schaffen, aber irgendwo geht es zu langsam. Wer weiß, was Windows beim Zugriff über UNC-Pfade veranstaltet.... ;)
  • Es dauert im DVBViewer ca. 3 Sekunden vom Anklicken des Timeshift-Buttons bis zum Wechsel in den Timeshiftmodus, wegen einigem Hin- und Her: Der DVBViewer beantragt beim DMS durch Senden eines Timers eine Timeshiftaufnahme, dieser startet sie, fordert alle DVBViewer-Clients auf, die geänderte Timerliste zu laden, meldet anschließend den Start einer Aufnahme, der DVBViewer klappert die Timerliste ab, ob sich darin eine für Timeshift passende laufende Aufnahme wiederfindet, öffnet sie...
  • Suchen & Springen sind ok, aber Spulen ist hakelig. Das war erwartet und ist bei Wiedergabe einer Remote-Datei über eine HTTP -Verbindung auch nicht viel besser.
  • Wenn der DVBViewer aus irgendeinem Grund nicht auf die Remote-Timeshiftdatei zugreifen kann (z.B. weil sie keinen UNC Pfad hat), gibt es ein Unglück. Der DMS startet zwar die Aufnahme, aber der DVBViewer findet sie nicht vor, begibt sich folglich nicht in den Timeshiftmodus und wird die Timeshiftaufnahme deshalb niemals stoppen/löschen. Die läuft dann 23:59 Stunden, sofern der Anwender-Wachhund nicht aufpasst... dafür habe ich noch keine Lösung. Sie müsste in etwa so aussehen, dass der DMS den gesendeten Timeshift-Timer mit einem Fehlercode zurückweist, wenn er feststellt, dass ein Remote-DVBViewer-Client damit nichts anfangen kann.

Bei Interesse könnte ich eine experimentelle DVBViewer-Testversion zur Verfügung stellen.

 

 

Link to comment
vor 16 Stunden schrieb Griga:

 

 

Bei Interesse könnte ich eine experimentelle DVBViewer-Testversion zur Verfügung stellen.

 

 

Klingt interessant...rumspielen um die Weihnachtszeit herum wäre kein Problem. Hätte gern über private Nachricht.

Bei mir wäre die Kette andersrum:

DMS -> Gigabit-LAN --> Fritzbox -> WLAN -> Remote DVBViewer.

das kann ich im Prinzip  auch:  DMS  -> Gigabit-LAN --> Fritzbox -> 100er-LAN -> Remote DVBViewer.

 

Edited by dbotev
Link to comment
6 hours ago, dbotev said:

Hätte gern über private Nachricht.

 

Entweder so, oder in dem bald kommenden Bugifix-Release als Tweak aktivierbar.

 

6 hours ago, dbotev said:

Bei mir wäre die Kette andersrum: DMS -> Gigabit-LAN --> Fritzbox -> WLAN -> Remote DVBViewer.

 

Ich hab's inzwischen auch andersherum probiert. War eher noch schlechter.

 

23 hours ago, Griga said:

Im Prinzip funktioniert es, aber schon beim Ersten HD nur mit stockender zeitversetzter Wiedergabe

 

Das liegt nicht an meinem WLAN. Der DVBViewer Client kann problemlos gleichzeitig eine vom Server via HTTP gelieferte HD-Aufnahme und das Erste HD als RTSP Live Stream Bild-in-Bild abspielen. Die dafür benötigten 30 MBit/s (laut Ressourcen-Monitor) treffen auf keinen Flaschenhals.

 

Das Problem ist eher das SMB-Protokoll, das  Windows für den Datentransfer beim Zugriff auf Freigaben mittels UNC-Pfaden verwendet. Auslöser scheint insbesondere zu sein, dass der DVBViewer-Client mindestens einmal pro Sekunde die aktuelle Dateigröße abfragt. Sie ändert sich bei Timeshiftdateien ja dauernd. Blendet man die Kontrollleiste ein, die die Angabe für die Anzeige des Sliders braucht, wird die Dateigröße doppelt so oft abgefragt. Dann bricht bei mir die zeitversetzte HD-Wiedergabe vollends ein - Prädikat: ungenießbar! Offenbar arbeitet SMB unter diesen Bedingungen ziemlich ineffizient. Eine ständig wachsende Timeshiftdatei ist halt etwas anderes als eine bereits abgeschlossene Videodatei.

 

Allerdings war bei mir ein Windows 7 PC beteiligt, der das Niveau auf SMB 2.0 drückt. Ab Windows 8.1 gibt es SMB 3.0, eventuell mit Verbesserungen. Das bleibt zu testen...

 

Link to comment
15 hours ago, Griga said:

Dann bricht bei mir die zeitversetzte HD-Wiedergabe vollends ein - Prädikat: ungenießbar! Offenbar arbeitet SMB unter diesen Bedingungen ziemlich ineffizient.

 

Problem gelöst. Der entscheidende Faktor ist die Puffergröße beim Lesen. Der DVBViewer liest bei Timeshift zu kleinteilig. Wenn der Explorer aus einer Netzwerkfreigabe kopiert, verwendet er einen 60k-Puffer, der DVBViewer nur ein Zehntel. Bei 48k ist im DVBViewer die Wiedergabe von Remote Timeshift auch bei HD-Sendern flüssig.

 

Das Problem besteht wahrscheinlich auch in vorherigen DVBViewer-Version, wenn jemand eine Netzwerkfreigabe auf einem anderen PC mittels UNC-Pfad als Zielverzeichnis für Timeshift festlegt. Die Wiedergabe bereits fertiger Aufnahmen via UNC-Pfad scheint dagegen nicht so kritisch zu sein.

 

Link to comment
vor 5 Stunden schrieb Griga:

 

Problem gelöst. Der entscheidende Faktor ist die Puffergröße beim Lesen. Der DVBViewer liest bei Timeshift zu kleinteilig. Wenn der Explorer aus einer Netzwerkfreigabe kopiert, verwendet er einen 60k-Puffer, der DVBViewer nur ein Zehntel. Bei 48k ist im DVBViewer die Wiedergabe von Remote Timeshift auch bei HD-Sendern flüssig.

 

Das Problem besteht wahrscheinlich auch in vorherigen DVBViewer-Version, wenn jemand eine Netzwerkfreigabe auf einem anderen PC mittels UNC-Pfad als Zielverzeichnis für Timeshift festlegt. Die Wiedergabe bereits fertiger Aufnahmen via UNC-Pfad scheint dagegen nicht so kritisch zu sein.

 

 

 

Hm, die Probleme mit Samba sind bei mir nicht so kritisch. Ich lese die nicht komplett abgeschlossene Timeshift oder Record Dateien auf dieser Art und Weise seit mehreren Jahren:  über UNC-Pfad.

 

Ich habe hierfür  Kodi(Android 10 Handy, oder FireTV Stick, oder PC Win10x64),  DVBViewer(Client PC Win10x64)  und  MXplayer(Android 10 Handy) benutzt. Ich habe hauptsächlich SD Sender dafür benutzt.

 

Ich experimentiere gerade mit nicht abgeschlossener Aufnahme auf ein HD Sender(Wird eben auf die SSD Platte vom DMS unter Win10x64  geschrieben, Stream Datenrate zwischen 8 und 10 MBit/s laut DVBViewer Systeminfo) .

 

Welcher 19.2°E-SAT oder freier Unitymedia DVBC Sender hat die höchste Datenrate? Den hätte ich gern für weitere Tests.

 

Beim von mir gewählten HD Sender speziell sieht es gerade so aus:

MX Player- läuft flüssig über Wlan am Client mit SMB. Ich kann aber nicht vor und zurückspulen. Die Aufnahme wird natürlich vom Anfang an gestartet.

Kodi Android über Wlan - läuft flüssig. Ich kann aber nicht vor und zurückspulen. Die Aufnahme wird natürlich vom Anfang an gestartet.

DVBViewer über Remote Client v7.0.0.4:  läuft flüssig über Wlan. Ich kann ohne Probleme vor und zurückspulen. Ich kann ganz am Ende der Aufnahme vorspulen, der DVBViewer Player läuft trotzdem kontinuierlich weiter wie beim Live TV.

 

Parallel läuft auf dem DMS PC der Lokale DVBViewer v7.0.0.4 Client auf dem selben HD Stender - alles Klasse… allerdings hier läuft das Video natürlich nicht über Samba  

 

Update: tja wenn ich zu weit entfernt vom Router bin (über 7m) habe ich ab und zu Stottern. Wir haben aber hier mindestens 40 Wlan Router in der Umgebung. Mein Wlan Funkt ganz klassisch auf 2.4GHz.

Edited by dbotev
Link to comment

Zunächst zur Begriffsklärung: Samba ist eine freie SMB-Implementation für Nicht-Windows-Systeme:

 

https://de.wikipedia.org/wiki/Samba_(Software)

 

Nicht-Windows-Systeme werden vom DMS typischerweise über HTTP versorgt, nicht über SMB, es sei denn, du greift z.B. unter Android direkt auf Windows-Freigaben zu. Auf meinem Android Tablet geht das nur mit einem Dateimanager.

 

Ich habe es inzwischen mit dem Server unter Windows 8.1 und dem DVBViewer-Client unter Windows 10 probiert. Das gleiche Problem bei zu kleinem Puffer. Es liegt also nicht an SMB 2.0 unter Windows 7.

 

Der Zugriff eines DVBViewer-Clients auf eine laufende Aufnahme in einer Remote-Freigabe ist aus den folgenden Gründen nicht unbedingt mit Timeshift vergleichbar:

  • Es wird kein Live Stream parallel übertragen, der die Datenrate verdoppelt.
  • Der DVBViewer verwendet den Zweig für Dateiwiedergabe, mit einem Puffer, der doppelt so groß ist wie der für Timeshiftwiedergabe im Live-Zweig.

Die Wiedergabe einer laufenden Aufnahme in einer Remote-Freigabe hat hier bei dem Versuch mit Windows 10 auch eingermaßen störungsfrei funktioniert. Erst beim Einblenden der Kontrollleiste gab es zeitweise kleine Tonaussetzer (bedingt durch zu langsam laufendes Video). Ich hatte dabei ZDF HD verwendet, das gerade mit Bitraten von 12 - 13 MBit/s aufwartete, d.h. der Windows Ressourcenmonitor zeigte bei Timeshiftwiedergabe einen Traffic von 25 MBit/s und mehr an. Die Datenrate wechselt bei den Sendern je nach gesendeten Inhalten, und es spielt auch eine Rolle, ob du Video-Fülldaten bei Aufnahmen entfernen lässt (siehe DMS-Optionen -> Aufnahmen).

 

Link to comment
vor 7 Stunden schrieb Griga:

Zunächst zur Begriffsklärung: Samba ist eine freie SMB-Implementation für Nicht-Windows-Systeme

Ja, sorry, ich habe auch die Android Geräte im Kopf gehabt, als ich den Post geschrieben habe. Ich kann leider Smaba mit SMB nicht mehr ersetzen.

 

Zitat

 

Nicht-Windows-Systeme werden vom DMS typischerweise über HTTP versorgt, nicht über SMB, es sei denn, du greift z.B. unter Android direkt auf Windows-Freigaben zu. Auf meinem Android Tablet geht das nur mit einem Dateimanager.

Auch unter Windows mache ich es über den Dateimanager momentan. Ich kann es ja zumindest beim Timeshift nicht anders mit dem 7.0.0.4 Client. Der DMS auf dem SperverPC weiß ja praktisch nichts davon.   

Zitat

Der Zugriff eines DVBViewer-Clients auf eine laufende Aufnahme in einer Remote-Freigabe ist aus den folgenden Gründen nicht unbedingt mit Timeshift vergleichbar:

  • Es wird kein Live Stream parallel übertragen, der die Datenrate verdoppelt.
  • Der DVBViewer verwendet den Zweig für Dateiwiedergabe, mit einem Puffer, der doppelt so groß ist wie der für Timeshiftwiedergabe im Live-Zweig.

Ich verstehe es nicht ganz mit dem doppelten Stream.  Das hat bestimmt mit der tatsächlichen Implementierung der Kommunikation, wenn man quasi über die Client-DMS-Schnittstelle die Daten schickt und nicht direkt durch eine direkte Windows-Freigabe. Kann man nicht beim DMS nur den einen Stream schicken?

Ich habe auch kleines Stottern bei mir gehabt, allerdings unter ganz extremen Bedingungen.

Anbei meine Erkenntnisse (Siehe auch Snapshots dazu):

„Windows10x64-Freigabe“->“Gigabit-Lan“->Fritzbox->Wlan->“DVBviewer7.0.0.4 auf Windows10x64“

 

Timeshift:

\\MultimediaPC\D$\PVR\Temp\12-26_01-51-00_ZDF HD 19.2°...............ts

Die rot markierten Stellen zeigen die Vor-Zurückspulen-Ereignisse und  ich verstehe diese als Puffer-Füllen.

Kein Stottern. Flüssige Wiedergabe.

 

Record:

\\MultimediaPC\D$\PVR\12-26_01-58-48_ZDF HD 19.2°................ts

Kein Stottern. Flüssige Wiedergabe.

Die rot markierten Stellen zeigen die Vor-Zurückspulen-Ereignisse und  ich verstehe diese als Puffer-Füllen.

 

Record plus „speed.io Störlast“:

\\MultimediaPC\D$\PVR\12-26_01-58-48_ZDF HD 19.2°.......ts

 

Leichtes Stottern beim Sound während des Download Tests, ansonsten -  flüssige Wiedergabe.

Rot – das ist der Anteil des Speed Tests (beim Download) würde ich sagen

Grün – das ist der Anteil (beim Upload) des Speed Tests

 

Da muss man aber sagen - mein Wlan-Kommunikationszweig  scheint momentan physisch sowieso nicht mehr als 50-60 Mbit/s übertragen zu können. Ich habe es auch mit einem direkten (Copy-Paste) File-Transfer ausprobiert.  Ich weiß nicht wer - die Fritzbox oder die Wlan-Karte des Laptops den Engpass verursachen.

 

 

 

Record.jpg

Timeshift.jpg

Record2.jpg

Edited by dbotev
Link to comment
1 hour ago, dbotev said:

Ich verstehe es nicht ganz mit dem doppelten Stream. 

 

Gehe von herkömmlichem Timeshift im DVBViewer aus. Ein DVB-Tuner liefert einen Stream, dieser wird live wiedergegeben und gleichzeitig in eine Timeshiftdatei geschrieben. Wenn du nun in der Zeit zurückspringst, wird der Live Stream weiter empfangen (muss ja, weil der DVBViewer ihn noch aufnimmt) und gleichzeitig von der lokalen Festplatte gelesen.

 

Wenn nun der DVBViewer mit einem lokalen  oder Remote DMS assoziiert ist,  empfängt er typischerweise den Live Stream über ein RTSP Netzwerkgerät vom DMS. Delegiert er Timeshift, schreibt der DMS die Timeshift-Datei. Der DVBViewer verbindet Live & Datei zu einer Einheit, damit man ohne Bruch mit dem Positionsslider dazwischen wechseln kann. Für den schnellen Zugriff wird beides bereitgehalten, egal was du davon im Moment gerade brauchst. Bei Live-Wiedergabe bleibt die Datei geöffnet (allerdings ohne aus ihr zu lesen), bei zeitversetzter Wiedergabe bleibt der Live Stream aktiv.

 

Wenn der DMS aufnimmt, müsste der DVBViewer zwar bei zeitversetzter Wiedergabe den Live Stream nicht unbedingt aufrechterhalten. Dies würde aber zusätzliche Verzweigungen im DVBViewer-Code erfordern, die bei Remote-Timeshift den Live Stream je nach Bedarf ab/anschalten, und es würde beim Sprung zur Live-Position eine deutliche Pause geben. Hinzu kommt: Die Timeshiftaufnahme allein hat im DMS eine sehr niedrige Priorität. Würde der DVBViewer seinen Live Stream bei zeitversetzter Wiedergabe komplett abschalten und damit den Tuner im DMS quasi freigeben, würde jeder andere Client, der den Tuner für eine andere Frequenz braucht, ihn übernehmen und die Timeshiftaufnahme abbrechen.

 

Vermutlich lässt sich die doppelte Netzwerklast irgendwie ohne Nachteile vermeiden, aber es verlangt auf jeden Fall eine erhöhten Verwaltungsaufwand durch mehr Fallunterscheidungen.

 

Gedanken mache ich mir zur Zeit eher über zwei andere Probleme bei der Angelegenheit:

  • Der DMS signalisiert DVBViewer-Clients über UDP Multicast, dass sie die Timerliste neu laden sollen und er gerade eine für Timeshift in Frage kommende Aufnahme gestartet hat. UDP ist jedoch ein prinzipbedingt unzuverlässiges Protokoll, d.h. es gibt keine Garantie, dass die Botschaften beim Client ankommen (auch wenn es in einem Heimnetzwerk in den allermeisten Fällen funktioniert). Verpasst der DVBViewer Client nach der Anforderung von Timeshift aus irgendeinem Grund die DMS-Botschaften, läuft die Timeshiftaufnahme eventuell stundenlang, ohne dass der Client die Kontrolle übernimmt.
  • Was ist, wenn zwei DVBViewer-Clients die selbe Timeshiftdatei verwenden? Das ist bei Remote-Timeshift ohne weiteres möglich. Wechselt nun einer der Clients den Sender, bricht er damit Timeshift ab. Die Aufnahme wird auf jeden Fall gestoppt. Gelöscht werden kann die Datei nicht, da sie ja noch der andere Client geöffnet hält. Hier fehlt wieder eine Client-Verwaltung oder zumindest eine Referenzzählung, so dass der DMS weiß, wie viele Clients im Moment auf die Datei zugreifen.

Kurz gesagt: Wenn man serverbasiertes Timeshift wirklich sauber und vollständig  implementiert, kommt ein beträchtlicher Verwaltungs-Overhead mit entsprechendem Entwicklungsaufwand hinzu. Lohnt das? Wie auch immer - die augenblickliche Primitiv-Implementation auf Basis von UNC-Pfaden wird im kommenden Bugfix-Release enthalten sein. Remote-Timeshift muss jedoch durch einen separaten Tweak aktiviert werden und ist nur was für Anwender, die wissen, worauf sie sich einlassen:

 

Quote

Timeshift-Delegation an einen Remote-Media Server erlauben: Erlaubt dem DVBViewer, Timeshift-Aufnahmen an einen Media Server auf einem anderen PC zu delegieren. EXPERIMENTELL! Die obige Einstellung "Timeshift-Aufnahmen delegieren" muss eingeschaltet sein. Zusätzlich MUSS der Media Server so konfiguriert werden, dass er Timeshift-Aufnahmen in ein Verzeichnis mit Netzwerk-(UNC-)Pfad schreibt (siehe Media Server-Optionen -> Aufnahmen). Es gibt keine Absicherung gegen Fehlbedienung!

 

 

Link to comment

Also Tvheadend und Mediaportal können Server seitiges Timeshift. Aber ich kann dir nicht sagen, was bei denen damit dann alles möglich ist, so intensiv hab ich die nie ausprobiert.

Cool wäre wenn die Timeshift Datei dann von allen Clients verwendet werden könnte. Das heisst wenn man auf einen Sender schaltet, der gerade von nem anderen Client gestreamt wird und Timeshift an ist, könnte man auf dem neu dazu gekommenen Client dann auch zurückspulen. Evtl. sogar beim http Streaming z.B. mit der App. Obwohl ich nicht weiß, ob das mit den gängigen Playern in Android überhaupt möglich ist.

 

Oder weil man einfach die SSD im Client bei permanentem Timeshift schonen will und so das ganze auf magnetische Platten im Server oder sonst wo auslagern kann. Aber das geht ja bereits jetzt wenn man nen UNC Pfad als Timeshift Verzeichnis im Client benutzt. Das klappt bei mir im LAN hier sowieso schon immer ohne Probleme und ich bemerke da keinen Unterschied.

Link to comment
vor 9 Stunden schrieb Griga:

Kurz gesagt: Wenn man serverbasiertes Timeshift wirklich sauber und vollständig  implementiert, kommt ein beträchtlicher Verwaltungs-Overhead mit entsprechendem Entwicklungsaufwand hinzu. Lohnt das? Wie auch immer - die augenblickliche Primitiv-Implementation auf Basis von UNC-Pfaden wird im kommenden Bugfix-Release enthalten sein. Remote-Timeshift muss jedoch durch einen separaten Tweak aktiviert werden und ist nur was für Anwender, die wissen, worauf sie sich einlassen...

 

Ich wollte mich für diesen Tweak vorbereiten und habe die UNC-Pfade beim DMS wie folgt eingetragen:

"\\MultimediaPC\D$\PVR" und "\\MultimediaPC\D$\PVR\Temp" (für Timeshift)

anstatt die alten "D:\PVR" und "D:\PVR\Temp".

Ich habe anschließend die DMS-Aufnahmedatenbank aktualisiert.

Aus irgendeinem Grund wurden danach alle Aufnahmeeinträge aus der Datenbank gelöscht. Ist das normal?

Ich bin zurück auf „D:\PVR und D:\PVR\Temp“ gegangen. Die  Einträge konnte ich dadurch zumindest

retten.   

Link to comment
Am 26.12.2020 um 12:33 schrieb VinoRosso:

Cool wäre wenn die Timeshift Datei dann von allen Clients verwendet werden könnte. Das heisst wenn man auf einen Sender schaltet, der gerade von nem anderen Client gestreamt wird und Timeshift an ist, könnte man auf dem neu dazu gekommenen Client dann auch zurückspulen.

 

Das wird mit der experimentellen Implementation im kommenden 7.0.1 Bugifix Release technisch gehen, aber verwaltungstechnisch nicht. Der DMS hat keine Ahnung, wer alles eine laufende Timeshiftaufnahme verwendet. Die Folge: Wenn nur einer der beteiligten Clients den Sender umschaltet und dem DMS daraufhin sagt, er soll die (nicht mehr benötigte) Timeshiftaufnahme stoppen und löschen, macht der das. Zumindest das Stoppen. Löschen wird er nicht schaffen, wenn sonst noch jemand die Datei geöffnet hält.

 

Ich habe heute recherchiert, ob Windows eine Möglichkeit bietet, die Anzahl der Clients abzufragen, die zur Zeit die Datei geöffnet haben (also eine Art Reference Count). Dann könnte der DMS bei Anzahl > 1 (sich selbst mitgezählt) den Stopp verweigern. Habe aber nichts dazu gefunden.

 

Außerdem stellen sich bei multiplen Zugriffen weitere verwaltungstechnische Fragen. Z.B. können alle Clients die Timeshift-Aufnahme in eine bleibende umwandeln (oder umgekehrt) und sich gegenseitig widersprechen. Wer hat das Sagen?

 

Das Grundproblem ist hier der Zugriff über UNC-Pfade. Bei einer Auslieferung des Timeshift-Datei via HTTP hätte der Server eine Liste der Clients mitsamt IP-Adressen, würde die Zugriffreihenfolge kennen, könnte nachfolgende Kommandos (Stopp, Löschen) zuordnen und z.B. festlegen, dass nur der ursprüngliche "Erzeuger" bestimmen darf... aber das würde wie schon angemerkt den Korb für die Implementation im DVBViewer deutlich höher hängen. Mit den von @dbotev angeregten UNC-Pfaden ging es dort so verführerisch einfach.

 

Am 26.12.2020 um 16:09 schrieb dbotev:

Ich (...) habe die UNC-Pfade beim DMS wie folgt eingetragen:

"\\MultimediaPC\D$\PVR" und "\\MultimediaPC\D$\PVR\Temp" (für Timeshift) anstatt die alten "D:\PVR" und "D:\PVR\Temp".

Ich habe anschließend die DMS-Aufnahmedatenbank aktualisiert. Aus irgendeinem Grund wurden danach alle Aufnahmeeinträge aus der Datenbank gelöscht. Ist das normal?

 

Da der DMS nicht erkennen kann, dass du nur ein Alias für ein ansonsten unverändertes Verzeichnis angibst, ist es für ihn gleichbedeutend mit einem Umbenennen des Aufnahmeverzeichnisses oder dem Verschieben sämtlicher Aufnahmen in ein anderes Verzeichnis. Ob er Aufnahmen bei einer Datenbankaktualisierung als solche wiedererkennt, hängt davon ab, ob es für sie EPG-Infodateien gibt (Aufnahme-Dateiname + .txt), die praktisch ein externes Backup des Datenbankeintrags darstellen. Ohne diese zusätzlichen Dateien handelt es sich für den DMS nur um schnöde Videodateien zweifelhafter Herkunft.

 

Ich habe dein Experiment nachvollzogen, und bei mir waren die Aufnahmen nach einer Aktualisierung der Aufnahmedatenbank mit dem neuen Pfad weiterhin im Webinterface vorhanden. Allerdings hat das unter Windows 8.1 stattgefunden. Bei Windows 10 ist eventuell zu berücksichtigen, dass ein im Systemkonto laufender Service nicht auf Netzwerkfreigaben zugreifen darf. Mehr dazu hier.

 

Zwei wichtige Punkte für eine Backup-Strategie hinsichtlich der Aufnahme-Datenbank:

  • EPG Info-Dateien schreiben lassen (siehe DMS_Optionen -> Aufnahmen). Falls sie fehlen, können sie nachträglich erzeugt werden. Dazu die Option aktivieren und dann eine Aktualisierung der Aufnahmedatenbank durchführen.
  • Vor Experimenten immer ein Backup der Datei SvcDatabase.db3 im Konfigurationsordner\Database\ erstellen!

 

Link to comment

Hehe, danke  die Hinweise!

Laut Griga: „Bei Windows 10 ist eventuell zu berücksichtigen, dass ein im Systemkonto laufender Service nicht auf Netzwerkfreigaben zugreifen darf.“ Ich glaube nicht, dass dies die primäre Ursache ist.

Bei mir war irgendwie Riesenchaos in der Datenbank.

Meine Beobachtung: durch das Rumspielen mit den Pfaden wurden manche Aufnahmen mit dem „D:/PVR“ assoziiert. Andere wurden mit „\\MultimediaPC\D$\PVR\“  oder manche sogar mit dem selbst kreierten Netzwerkshare „\\MultimediaPC\PVR\" assoziiert.  

Je nachdem welcher von den Verzeichnissen unter DMS-Optionen existierte und welcher fehlte,  hat der DMS entsprechend die Aufnahmeeinträge ein- oder ausgeblendet.

Am Endeffekt habe ich alle 3 Pfade eingetragen und die EPG-Textfiles erzeugt (EPG Info-Dateien schreiben lassen, siehe DMS-Optionen -> Aufnahmen). Danke für den Tipp. Wieder das gelernt!

Danach habe ich lediglich den UNC-Pfad behalten und nochmal die Datenbank aktualisiert.

Jetzt bin ich für die neue Beta-Version bereit.

Edited by dbotev
Link to comment
Am 28.12.2020 um 18:44 schrieb Griga:

Das wird mit der experimentellen Implementation im kommenden 7.0.1 Bugifix Release technisch gehen, aber verwaltungstechnisch nicht. Der DMS hat keine Ahnung, wer alles eine laufende Timeshiftaufnahme verwendet. Die Folge: Wenn nur einer der beteiligten Clients den Sender umschaltet und dem DMS daraufhin sagt, er soll die (nicht mehr benötigte) Timeshiftaufnahme stoppen und löschen, macht der das. Zumindest das Stoppen. Löschen wird er nicht schaffen, wenn sonst noch jemand die Datei geöffnet hält.

 

Ich habe heute recherchiert, ob Windows eine Möglichkeit bietet, die Anzahl der Clients abzufragen, die zur Zeit die Datei geöffnet haben (also eine Art Reference Count). Dann könnte der DMS bei Anzahl > 1 (sich selbst mitgezählt) den Stopp verweigern. Habe aber nichts dazu gefunden.

 

Kommando im Windows Power Shell:  "Get-SmbOpenFile | ft *"

 

[::1]  = Das ist der lokale Client

192.168.1.26   = Das ist der remote Client

 

...allerdings nach meinem Experiment - es dauert etwa 10s  bis Windows das Trennen des Clients erkennt. Ich habe Win10x64 

 

Copy/Paste aus dem Konsollenfenster:

 

 

PS C:\Users\UsrName> Get-SmbOpenFile | ft *

 

SmbInstance ClientComputerName ClientUserName     ClusterNodeName ContinuouslyAvailable Encrypted        FileId Locks Path

----------- ------------------ --------------     --------------- --------------------- ---------        ------ ----- ----

    Default 192.168.1.26       multimediapc\UsrName                                 False     False 1732482433845     0 D:\pvr\RecordName.ts

    Default [::1]              multimediapc\UsrName                                 False     False 1731677128857     0 D:\pvr\RecordName.ts

 

Edited by dbotev
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...