Beiträge von schmirl

Svdrposd liest die Tab-Position aus dem Server-Menü aus. Die Breite jeder Spalte ergibt sich aus der max. Zeichenzahl die in der gesamten Liste für diese Spalte gefunden wurde.

Wie sieht denn die Liste aus? Gibt es Texte die abgeschnitten sind (weil zu breit für die Spalte) bzw. die über mehrere Spalten gehen? Das wäre in der Tat ein Problem.

Du kannst das svdrpservice-Plugin mit Debug-Option kompilieren, dann werden alle Ausgaben ins Log geschrieben ("make clean; SVDRPSERVICE_DEBUG=syslog make install")

Zitat

Debugging:
----------
Compile with SVDRPSERVICE_DEBUG=syslog if you want to see the commands
and replies in the log. Use SVDRPSERVICE_DEBUG=stderr (actually any
value will do) to get output on the terminal where you started vdr.

Die Latency-Meldungen kommen nur wenn der VDR Watchdog-Timeout aktiviert ist und der Debug-Level auf Default bzw. -l 3 steht.

Der Client öffnet immer mehrere Verbindungen:

Hier kommt die erste Verbindung rein und es wird die DVB-Karte belegt:

Jul 26 23:08:41 (none) user.info vdr: [4206] Streamdev: Accepted new client (HTTP) 192.168.178.34:56211
Jul 26 23:08:41 (none) user.debug vdr: [4662] streamdev-livestreaming thread started (pid=4200, tid=4662, prio=high)
Jul 26 23:08:41 (none) user.debug vdr: [4661] streamdev-writer thread started (pid=4200, tid=4661, prio=high)
Jul 26 23:08:41 (none) user.debug vdr: [4663] receiver on device 1 thread started (pid=4200, tid=4663, prio=high)
Jul 26 23:08:41 (none) user.debug vdr: [4664] TS buffer on device 1 thread started (pid=4200, tid=4664, prio=high)

Dann kommt die zweite Verbindung, die aber gleich wieder abgebaut wird und folglich keine weitere Rolle spielt (was auch immer deren Zweck ist):

Jul 26 23:08:47 (none) user.info vdr: [4206] Streamdev: Accepted new client (HTTP) 192.168.178.34:56212
Jul 26 23:08:47 (none) user.debug vdr: [4666] streamdev-livestreaming thread started (pid=4200, tid=4666, prio=high)
Jul 26 23:08:47 (none) user.debug vdr: [4665] streamdev-writer thread started (pid=4200, tid=4665, prio=high)
Jul 26 23:08:48 (none) user.err vdr: [4206] ERROR: read from client (HTTP) 192.168.178.34:56212 failed: Connection reset by peer
Jul 26 23:08:48 (none) user.info vdr: [4206] streamdev-server: closing HTTP connection to 192.168.178.34:56212
Jul 26 23:08:48 (none) user.err vdr: [4665] ERROR: streamdev-server: couldn't send data: Bad file descriptor
Jul 26 23:08:48 (none) user.debug vdr: [4665] streamdev-writer thread ended (pid=4200, tid=4665)
Jul 26 23:08:48 (none) user.debug vdr: [4666] streamdev-livestreaming thread ended (pid=4200, tid=4666)

Und hier nun die dritte Verbindung:

Jul 26 23:08:48 (none) user.info vdr: [4206] Streamdev: Accepted new client (HTTP) 192.168.178.34:46600
Jul 26 23:08:48 (none) user.debug vdr: [4668] streamdev-livestreaming thread started (pid=4200, tid=4668, prio=high)
Jul 26 23:08:48 (none) user.debug vdr: [4667] streamdev-writer thread started (pid=4200, tid=4667, prio=high)

Dann wird die erste Verbindung geschlossen. Die DVB-Karte bleibt aber offenbar von der dritten Verbindung belegt:

Jul 26 23:08:58 (none) user.err vdr: [4206] ERROR: read from client (HTTP) 192.168.178.34:56211 failed: Connection reset by peer
Jul 26 23:08:58 (none) user.info vdr: [4206] streamdev-server: closing HTTP connection to 192.168.178.34:56211
Jul 26 23:08:58 (none) user.debug vdr: [4662] streamdev-livestreaming thread ended (pid=4200, tid=4662)
Jul 26 23:08:58 (none) user.debug vdr: [4661] streamdev-writer thread ended (pid=4200, tid=4661)

Rund zwei Minuten später nimmt der Client scheinbar keine Daten mehr an. Der Puffer von Streamdev läuft voll und Streamdev trennt die Verbindung Nummer drei. Jetzt wird auch die DVB-Karte wieder freigegeben:

Jul 26 23:11:07 (none) user.debug vdr: [4663] buffer usage: 70% (tid=4668)
Jul 26 23:11:08 (none) user.debug vdr: [4663] buffer usage: 80% (tid=4668)
Jul 26 23:11:09 (none) user.debug vdr: [4663] buffer usage: 90% (tid=4668)
Jul 26 23:11:10 (none) user.err vdr: [4663] ERROR: 1 ring buffer overflow (188 bytes dropped)
Jul 26 23:11:13 (none) user.err vdr: [4667] ERROR: streamdev-server: couldn't send data: Connection timed out
Jul 26 23:11:13 (none) user.info vdr: [4667] streamdev-server: closing HTTP connection to 192.168.178.34:46600
Jul 26 23:11:13 (none) user.debug vdr: [4667] streamdev-writer thread ended (pid=4200, tid=4667)
Jul 26 23:11:13 (none) user.debug vdr: [4668] streamdev-livestreaming thread ended (pid=4200, tid=4668)
Jul 26 23:11:13 (none) user.debug vdr: [4664] TS buffer on device 1 thread ended (pid=4200, tid=4664)
Jul 26 23:11:13 (none) user.debug vdr: [4663] receiver on device 1 thread ended (pid=4200, tid=4663)

Das gleiche Spiel mit den drei Verbindungen wiederholt sich dann mit BFS.
Scheinbar streamst Du im PES-Format. Tritt das bei TS auch auf?

Was mir auffällt: Der Quellport der ominösen dritten Verbindungen unterscheidet sich deutlich von den Quellports der ersten beiden, was auf eine andere Anwendung hindeuten könnte. Vielleicht ein Virenscanner oder AndroVDR und MX-Player öffnen beide eine Verbindung? Ich fürchte, mehr kann ich Dir da nicht weiterhelfen. Vielleicht weiß der Entwickler von AndroVDR weiter.

In Deiner netstat-Ausgabe ist die Verbindung auf TIME_WAIT, die Verbindung wurde also bereits getrennt. Da auch keine weiteren Verbindungen bestehen, sollte der SVDRP-Port frei sein. Bekommst Du die SVDRP-Begrüßungsmeldung wenn Du Dich mit telnet an den Port verbindest? Schau bitte auch mal im Log nach "max. latency time"-Meldungen. Wieviele Sekunden werden Dir da angezeigt?

Poste oder maile mir bitte mal das Log (VDR ohne -l Option starten oder mit -l 3)

Alte Gewohnheit ;), sorry. Muss mit aktueller Portnummer natürlich "netstat -ntp | grep :6419" heißen.

Möglicherweise ist der SVDRP-Port auf dem Server durch einen anderen Client oder ein Programm belegt. Kannst Du Dich wenn das Problem auftritt erfolgreich per telnet mit dem SVDRP-Port des Servers verbinden? Falls nein, sollte Dir "netstat -ntp | grep 2001" einen Hinweis liefern, wer gerade den Port belegt.

@Dampf: hast PM

Du könntest Dein Glück mal mit dem vdr-remote_instant_recordings.patch versuchen, den Du in den Sourcen des remotetimers-Plugins findest. Ich habe den Patch damals so gestrickt, dass er auch mit dem timersync-Plugin funktionieren müsste.

Bezüglich Sat>IP habe ich leider weder die Zeit noch den Eigenbedarf um mich damit näher auseinanderzusetzen. Was wäre denn minimal notwendig um die genannten Clients zu unterstützen? Spätestens wenn UPnP notwendig ist, bin ich nicht mehr begeistert, wenn so ein Schwergewicht Bestandteil von Streamdev werden soll (und sei es auch nur als Bibliothek). Da würde dann eine Lösung mit separatem Plugin für die Steuerschicht besser gefallen. Für irgendein VDR-Plugin mit UPnP/DLNA-Ambitionen habe ich auch vor einiger Zeit mal die Möglichkeit geschaffen, über URL-Parameter DLNA-Header in der HTTP-Antwort zu setzen.

Zurück zum Problem mit VDR 2.1.4: Leider ist es nicht möglich, die problematische Stelle weitgehend zu meiden. Allerdings gab es ein paar unnötige Aufrufe die ich nun entfernt habe. Vielleicht genügt dies ja schon. Ich habe den Link im Eingangspost auf die neue Version geändert.

googles: Cool - Danke! Auf den ersten Blick würde ich sagen, dass die meisten Aufrufe der Funktion mit der problematischen Stelle mittlerweile überflüssig geworden sind. Vielleicht schaffe ich es am Wochenende etwas zu basteln...

Dampfgarten: In Deinem Log gab es keine "CAM #: unassigned"-Meldungen, hat also nichts mit der besagten Stelle zu tun. Ich gehe davon aus, Du streamst im TS-Format? Könntest Du mit einem Tool wie z.B. wget (zur Not auch mit dem Web-Browser) ein paar Sekunden (2-3 sollten schon genügen) des HTTP-Streams speichern und dann mit VLC prüfen, ob der Stream abgespielt werden kann? Im Optimalfall gelingt es Dir, einen funktionierenden und einen nicht funktionierenden Stream zu finden. Es könnte aber auch passieren, dass in abgespeicherter Form alle Streams funktionieren. In dem Fall schickst Du mir einfach 4 oder 5 Samples. Dann kann ich mal schauen, ob mir an den Daten etwas auffällt.

CafeDelMar: Kein Problem - ich hoffe aber, dass das Problem in 6 Wochen schon gelöst ist ;). Bist Du umgezogen?

Vielen Dank für die Logs!

Dampfgarten: Bei Deinem ersten Log schaut es so aus, als ob der Client ein Problem mit den gestreamten Daten hat. Irgendwelche Meldungen im Client?

googles: Bevor Streamdev richtig loslegt, kommt immer eine "CAM #: unassigned"-Meldung. Das CAM wird also wieder freigegeben. Das könnte mit folgender Änderung in VDR 2.1.4 zu tun haben:
"- Now unassigning CAMs from their devices when they are no longer used."

diff -ruN vdr-2.1.3/device.c vdr-2.1.4/device.c
--- vdr-2.1.3/device.c	2014-01-02 11:31:58.000000000 +0100
+++ vdr-2.1.4/device.c	2014-01-21 12:12:01.000000000 +0100
@@ -1697,8 +1701,12 @@
       else if (receiver[i])
          receiversLeft = true;
       }
-  if (camSlot && Receiver->priority > MINPRIORITY) // priority check to avoid an infinite loop with the CAM slot's caPidReceiver
-     camSlot->StartDecrypting();
+  if (camSlot) {
+     if (Receiver->priority > MINPRIORITY) // priority check to avoid an infinite loop with the CAM slot's caPidReceiver
+        camSlot->StartDecrypting();
+     if (!camSlot->IsDecrypting())
+        camSlot->Assign(NULL);
+     }
   if (!receiversLeft)
      Cancel(-1);
 }

Ob ich einen Workaround in Streamdev bauen kann, muss ich mir erstmal in einer ruhigen Minute ansehen (wird eine Weile dauern). Falls jemand von euch die Möglichkeit hat, diese Änderung im VDR rückgängig zu machen und damit zu testen, wäre das sehr hilfreich.

Das Server-Log wäre das wichtigste (mit dem Default-Log-Level, also -l 3). Sollten sich nicht nur die CA-IDs sondern tatsächlich auch die PIDs ändern, wäre auch das Client-Log bei aktiviertem Filter-Streaming interessant. Andernfalls dürfte das Client-Log nichts relevantes hergeben.

Wenn's mit HTTP-Streaming funktioniert, könnte das sehr wohl an den PIDs liegen. Bei HTTP-(TS-)Streaming werden alle PIDs gestreamt. An den Streamdev-Client werden hingegen nur die PIDs übertragen, die der Client (!) anfordert. Darum wäre ich sehr interessiert an den besagten Log-Meldungen, um zu verstehen, was da überhaupt abgeht.

Könnte mir mal jemand aus dem Log die "changing ...of channel ... from ... to ..." Meldungen posten?

[EDIT]... und sind überhaupt "streamdev: channel ... changed" Meldungen im Log zu finden?[/EDIT]

Das ganze steht und fällt mit der Frage, was passieren soll, wenn zwei Clients die selbe Sendung sehen wollen. Ich halte nicht viel davon, in remotetimers die Mögilchkeit einzubauen, mehrmals die selbe Sendung aufzunehmen. Das lässt sich über mehrere VDR-Instanzen auf dem Server sauberer lösen.

Bei Dir Peter, scheint die Trennung der Verzeichnisse ja nicht ganz so wichtig zu sein. Allerdings gibt es mit epgsearch das Problem, dass es meines Wissens nach keine remotetimers Benutzer-IDs setzen kann. Oder gibt es irgendwie die Möglichkeit, epgsearch einen beliebigen Text in das Aux-Feld von Timern eintragen zu lassen?

Mein Vorschlag für Dich wäre:
Gemeinsames Video-Verzeichnis der Clients und des Servers in das alles aufgenommen wird, was nicht von epgsearch kommt. Ausblenden der Timer und Aufnahmen anderer Benutzer über remotetimers Benutzer-ID.
Jeweils ein Unterverzeichnis für Server, Client1 und Client2 für Aufnahmen über epgsearch (solange man da die Benutzer-IDs nicht setzen kann).

Das schöne an der Sache mit den Benutzer-IDs ist, dass jede Aufnahme nur einmal auf der Platte liegt. Trotzdem können mehrere Leute die selbe Aufnahme ansehen (in Verbindung mit der VDR Wiedergabe-ID auch mit eigener "Neu"-Anzeige und eigenem Wiedergabefortschritt) und jeder für sich den Timer/die Aufnahme abhaken. Erst der letzte löscht diese.

Das hört sich gut an. Auch wenn ich mir das momentan nicht erklären kann. Der LiveBuffer macht nichts anderes als die angegeben Zeitspanne zu warten, nachdem die ersten Daten bei Streamdev angekommen sind.

Hat einer von euch die Möglichkeit zu prüfen, ob die ChannelChange-Funktion überhaupt benötigt wird oder ob die kleine Verzögerung alleine auch schon genügt (sprich: Inhalt der ChannelChange-Funktion auskommentieren)?

Wie wäre es, wenn Du ausschließlich mit den Benutzer-IDs arbeitest (dann sieht ja auch jeder nur seine Timer und Aufnahmen obwohl sie im selben Ordner liegen) und über einen noch zu schaffenden Kommandozeilen-Parameter die Benutzer-ID fest eingestellt werden kann, so dass sie im Timer-Menü oder im Setup nicht mehr geändert werden kann?

Geschickt gelöst Zabrimus :tup. Erwähnenswert ist denke ich noch, dass mit Deinem Patch im Timer-Menü nur noch die Timer angezeigt werden, die einen zum Client passenden Aufnahmepfad haben.

Ich hätte den Patch gerne integriert, aber ein Problem habe ich damit: Was passiert, wenn zwei Clients mit unterschiedlichen Unterverzeichnissen die selbe Sendung aufnehmen wollen? Mit dem derzeitigen Patch würde Client2 im EPG sehen, dass schon ein Timer für die Sendung existiert und damit hat er Pech gehabt. Würde er den Timer trotzdem bearbeiten, bekommt der Timer den Aufnahmepfad client2~client1~ und somit klaut er Client1 die Aufnahme.

Stellt sich die Frage, warum ihr mit Untervereichnissen arbeitet:
Sollen die Clients nach Möglichkeit zu 100% voneinander getrennt werden, so dass letzlich jeder Client auch nur sein Unterverzeichnis als Video-Verzeichnis mountet? Dann müsste dafür gesorgt werden, dass tatsächlich zwei Timer mit unterschiedlichen Unterverzeichnissen programmiert werden. Einfacher wäre wahrscheinlich, auf dem Server für jeden der Clients je eine VDR-Instanz ohne DVB-Karten laufen lassen auf der die Timer für den jeweiligen Client programmiert werden. Die clientspezifischen VDR-Instanzen greifen dann ihrerseits (auch zum Aufnehmen) via Streamdev auf eine VDR-Instanz mit allen DVB-Karten zu.

Oder geht es nur um Ordnung im Server-Verzeichnis? Dann würde vielleicht eine Option "Default-Ordner für neue Timer" genügen. Bestehende Timer werden nicht angefasst. Damit es im Timer- und Aufnahmenmenü trotzdem geordnet zugeht die Benutzer-IDs von Remotetimers nutzen. Dann kann es zwar vorkommen, dass ein Timer/ ein Aufnahme die beide Clients sehen wollen im Ordner des falschen Clients liegt, trotzdem sieht jeder nur die Timer und Aufnahmen die er haben wollte.

Wenn es nur um die Menge der in den Menüs angezeigten Timer/Aufnahmen geht, würde ich ganz auf die clientspezifischen Unterverzeichnisse verzichten und nur mit Benutzer-IDs arbeiten

Danke Frodo. Hast Du die von mir verlinkte Datei verwendet oder (wie es der Name der Pakete nahelegt) den aktuellen Stand aus dem git? Im git sind die Änderungen noch nicht veröffentlicht. Hätte gerne erstmal Feedback, ob die Änderung überhaupt das Gewünschte bewirkt.