[gelöst]Server und Client - Streamdev & Co

Ist die channels.conf auf beiden Rechnern identisch?

Hi.

Ich habe bei mir im Wohnzimmer das gleiche Problem (direkt nach dem Einschalten geht's, aber auf einen anderen gestreamten Sender umschalten geht nicht).

Mein Setup:

Server: VDR 1.3.36 ohne patches, nur streamdev-server plugin

Client 1 (macht Probleme): VDR 1.3.36 mit BigPatch, diverseste Plugins

Client 2 (geht): VDR 1.3.29 ohne patches, diverseste Plugins

Und nein, es liegt nicht am naheliegenden: weder der BigPatch noch die Plugins sind schuld, das habe ich alles schon probiert.

Client 2 hat zwar eine FF Karte, aber keinen SAT-Anschluss und bekommt daher alle Sender gestreamt. Das funktioniert tadellos.

Client 1 hat eine FF Karte MIT SAT-Anschluss und streamt nur ORF1+2, ATV+ etc. also die verschlüsselten Sender. Wenn ich nun zB ORF1 schaue, dann ARD -> kein Problem, schalte ich wieder auf ORF1 auch kein Problem. Schalte ich auf ORF2 ist es wie bei Dir: schwarzer Schirm, aber richtiges EPG. Wenn ich jetzt den VDR neu starte, kommt der ORF2, aber eben kein anderer gestreamter Sender mehr.

Da es bei Client 2 geht und ich ausser re-starten nichts tun muss, um den Sender zu bekommen, liegt es eindeutig am client.

Mein Verdacht ist, dass das streamdev gar nicht mehr versucht, sich zum Server zu connecten. In den Serverlogs steht nämlich nichts von einem Kanalwechsel des clients. Nur warum es das nicht tut ist mir schleierhaft!

Eventuell hängt es mit der VDR Version zusammen. Welche Version hast Du auf dem client?

K.

Zitat

Mein Verdacht ist, dass das streamdev gar nicht mehr versucht, sich zum Server zu connecten. In den Serverlogs steht nämlich nichts von einem Kanalwechsel des clients. Nur warum es das nicht tut ist mir schleierhaft!

Ich stelle bei mir das Gleiche fest.

Kann bitte jemand, bei dem das funktioniert, bitte bestätigen, ob das normal ist, oder nicht?
Dann kann man da vielleicht weitersuchen.

danke
austen

Ich habe bei mir jetzt noch ein paar Tests gemacht und folgendes festgestellt (Server blieb unverändert, am Client habe ich verschiedene Versionen probiert):

- vdr 1.3.29 - OK
- vdr 1.3.32 - OK
- vdr 1.3.32-bigPatch - FEHLER
- vdr 1.3.34 - FEHLER
- vdr 1.3.34-bigPatch - FEHLER
- vdr 1.3.36 - FEHLER
- vdr 1.3.36-bigPatch - FEHLER

Es hat also eindeutig mit der Version zu tun. Das interessante ist, dass Version 1.3.32 ohne BigPatch geht, mit BigPatch aber nicht. Danach aber ist es egal, ob BigPatch verwendet wird oder nicht, es geht auf keinen Fall.

Übrigens in jenen Fällen, wo das Umschalten funktioniert, steht im server log:

Streamdev: Setting data connection to 192.168.100.4:32938

Ich frage mich, ob das ganze irgendwie mit dem Livebuffer zusammenhängt. Auch das ist nämlich interessant: Aufnehmen von verschiedenen gestreamten Sendern geht immer, bei live habe ich die genannten Probleme. ABER: den Livebuffer aktivieren bringt nix, dann bleibt der Bildschirm trotzdem schwarz.

K.

kann ich bestätigen.

ab linvdr > 1.3.29 bleibt bei vdr zu vdr verbindungen mit streamdev der bildschirm schwarz.

bei mir läufts mit, halt mit gentoo

vdr (1.3.34) - The Video Disk Recorder
streamdev-client (0.3.3-pre3-geni) - VTP Streaming Client
streamdev-server (0.3.3-pre3-geni) - VDR Streaming Server
softdevice (0.2.0) - A software emulated MPEG2 device

hatte aber die selben probleme mit älteren und vor allem verschiedenen Versionen.

dxr3 läuft ebenfalls

Zitat

Original von niknak
bei mir läufts mit, halt mit gentoo

Ich glaube nicht, dass es an der Distri oder am Kernel liegt. Es scheint aber im Forum einige zu geben, bei denen es mit VDR > 1.3.29 problemlos läuft.

Gleichzeitig haben sich in diesem Thread hier aber sehr viele gemeledet, bei denen exakt die gleichen Probleme auftreten. Es muss also irgendeinen gemeinsamen Nenner geben.

Ich werd's mal mit aktueller Version, ganz ohne Patches und ganz ohne Plugins (ausser streamdev) probieren, dann vielleicht den einen oder anderen Patch dazuspielen. Mal sehen ob man so was rausfindet.
Irgendwo habe ich auch einen Kommentar von jemandem gelesen, der meint, mit einem bestimmten Skin läuft streamdev bei ihm viel stabiler. Vielleicht liegt's also auch an den Skins?

Das Dumme ist, das ich halt fast immer nur am Wochenende dazu komme, so richtig "grosse" Versuche zu starten...

K.

Also mittlerweile glaube ich doch, dass es am BigPatch liegt. Um zu testen, was schuld ist habe ich folgendes gemacht:

- vdr 1.3.36 frisch aus dem tar.bz2 entpackt
- streamdev Plugin über cvs co aus dem CVS geholt

--> Umschalten hat funktioniert!

Ich habe dann ein Plugin nach dem anderen reinkopiert, kompiliert und nochmal gestartet -> bei jedem Plugin hat's funktioniert, bis ich dann alle wieder beisammen hatte.

Dann habe ich den bigPatch (-test1) angewandt und siehe da: die gleichen Probleme, wie von allen beschrieben: erster Stream-sender geht, alle anderen sind schwarz.

Ich habe nun beide Versionen (mit/ohne BP) in verschiedenen Verzeichnissen, und kann einmal die eine, einmal die andere Version starten: mit BP gibt's Probleme, ohne funkt's!

Sieht so aus, als müsste ich mir ansehen, welche Parts vom BigPatch ich wirklich will, die so "reinpatchen" und sehen, ob es dann auch Probleme gibt.

K.

Ich habe das selbe Problem (Auch nach booten Bild da und danach beim Umschalten nur ein schwarzes Bild)!

Gibt es inzwischen eine Lösung?

Habe LinVDR 0.7 nach der Anleitung aus diesem Thread (http://vdr-portal.de/board/thread.php?threadid=41270&sid=&hilight=streamdev) für DXR3 installiert (ist VDR 1.3.36 mit BigPatch).

Mein Server hat 2 Budget Karten und als Ausgabe Device eine DXR3 Karte. Mein Client hat eine DXR3

Hi Krampus,

es scheint, unsere Ergebnisse nähern sich an: Ich hatte letztes WE auch mal ein paar Versuche unternommen und da meine Ergebnisse anders ausgefallen sind, als Deine, wollte ich zunächst einmal meine Versuche gegenchecken und in den Source sehen und dann erst meine Ergebnisse verbreiten. Da ich dazu leider nicht gekommen bin, hier meine Ergebnisse vom letzten WE:

(PS1: Immerhin habe ich nach diesen Tests wieder ein stabiles Client-Server-System - auch wenn ich einige Features des Bigpatches schmerzlich vermisse.)
(PS2: Ausserdem wollte ich ursprünglich nicht in diesem Thread antworten, da ich nicht glaube, dass das Problem LinVDR-spezifisch ist - ich nutze Gentoo mit selbst erzeugtem VDR.)

--- hier meine (vorbereitetes) Posting vom letzten WE ---
Hallo zusammen,

angeregt durch Krampus' Beobachtungen habe ich auch mal ein paar Versuche vorgenommen.

Da ich bei einem Update stets sofort den BigPatch einspiele und nicht alle Versionsspünge mit mache, konnte ich bislang nicht sagen, ab welcher Version sich das Problem genau eingestellt hat.

An dieser Stelle möchte ich mich auch mal ganz herzlich bei Frank99 bedanken, für die immense Arbeit, die er sich mit der Pflege und Aktualisierung des BigPatches macht!

Für meine Versuche habe ich auf dem Server vdr-1.3.36 incl. bigpatch-test2 und streamdev aus dem CVS von heute Vormittag verwendet.

Der Server ist auf den Kanal eingestellt, den der Client beim Start anzeigen sollte, für diese Versuche RTL (Kanal 3). Der Server spielt jedoch während der Versuche eine Aufnahme ab. Erscheint nach dem Start des Client ein Bild, so betätigte ich Cursor-Up, was ein Umschalten nach SAT1 (Kanal 4) bewirken sollte.

Auf dem Client habe ich verschiedene Versionen von VDR vanilla und dem für jede Version aktuellstem BigPatch (von bigpatch.vdr-developer.org) zusammen mit streamdev-cvs, xine-0.7.6 und remote-0.3.3 verwendet.

Im Folgenden verwende ich folgende Bezeichnungen:

OK : Erster Sender nach dem Start ist sichtbar, Kanalwechsel funktioniert einwandfrei
NOK: Erster Sender nach dem Start ist sichtbar, nach dem Umschalten ist das Bild schwarz

Bei anderweitigem Verhalten ist dies gesondert vermerkt.

Folgende Versionen habe ich auf dem Client getestet:

VDR vanilla:

OK: vdr-1.3.29
OK: vdr-1.3.30
OK: vdr-1.3.31
OK: vdr-1.3.32
OK: vdr-1.3.33
OK: vdr-1.3.34
OK: vdr-1.3.35
OK: vdr-1.3.36

Merkwürdig, das steht im Widerpsruch zu Krampus' Beobachtungen, nach denen vanilla 1.3.34 und 1.3.36 nicht funktioniert.

VDR mit BigPatch:

OK : vdr-1.3.29-bigpatch-test1                  (1)
NOK: vdr-1.3.29-bigpatch-test1_with_LiveBuffer  (2)
OK : vdr-1.3.29-bigpatch-test2                  (3)
NOK: vdr-1.3.30-bigpatch-test2_with_LiveBuffer
NOK: vdr-1.3.31-bigpatch-test7_with_LiveBuffer
NOK: vdr-1.3.32-bigpatch-test1
NOK: vdr-1.3.33-bigpatch-test1
NOK: vdr-1.3.34-bigpatch-test2
NOK: vdr-1.3.35-bigpatch-test1
NOK: vdr-1.3.36-bigpatch-test3a

(1) hat AFAIK keinen LiveBuffer
(2) Es erscheint direkt "Kanal nicht verfügbar"
(3) hat AFAIK keinen LiveBuffer

Nun, diese Beobachtungen legen für mich den Schluss nahe,. dass das Kanalwechselbproblem irgendwie mit dem LiveBuffer-Patch zusammen hängt oder durch eine andere Änderung am BigPatch verursacht wird, die zeitlich nahe zur Integration des LiveBuffer-Patches im BigPatch vorgenommen wurde,

Ein Kanalwechsel präsentiert sich im syslog wie folgt:

Funktionierender Kanalwechsel (mit 1.3.36):

Client:

Nov 19 15:52:13 bero vdr[11208]: switching to channel 4
Nov 19 15:52:13 bero vdr[11217]: transfer thread ended (pid=11217, tid=131080)
Nov 19 15:52:13 bero vdr[11219]: TS buffer on device 6 thread ended (pid=11219, tid=163850)
Nov 19 15:52:13 bero vdr[11218]: buffer stats: 699325 (33%) used
Nov 19 15:52:14 bero vdr[11218]: receiver on device 6 thread ended (pid=11218, tid=147465)
Nov 19 15:52:14 bero vdr[11208]: buffer stats: 1865336 (88%) used


Nov 19 15:52:14 bero vdr[11261]: transfer thread started (pid=11261, tid=196616)
Nov 19 15:52:14 bero vdr[11262]: receiver on device 6 thread started (pid=11262, tid=213001)
Nov 19 15:52:14 bero vdr[11263]: TS buffer on device 6 thread started (pid=11263, tid=229386)
Nov 19 15:52:15 bero vdr[11261]: setting audio track to 1 (0)

[SIZE=7](Leerzeile händisch eingefügt.)[/SIZE]

Server:

Nov 19 15:52:14 seca vdr[23582]: streamdev-livestreaming thread ended (pid=23582, tid=7880720)
Nov 19 15:52:14 seca vdr[23581]: streamdev-writer thread ended (pid=23581, tid=7864333)
Nov 19 15:52:14 seca vdr[22680]: buffer stats: 1492997 (35%) used


Nov 19 15:52:14 seca vdr[22680]: Streamdev: Setting data connection to 192.168.1.5:1047


Nov 19 15:52:14 seca vdr[23742]: streamdev-writer thread started (pid=23742, tid=7897101)
Nov 19 15:52:14 seca vdr[23743]: streamdev-livestreaming thread started (pid=23743, tid=7913488)

[SIZE=7](Leerzeile händisch eingefügt.)[/SIZE]

Im Log des Client ist zu sehen, wie bei dem Kanalwechsel drei Threads beendet und anschliessend erneut gestartet werden: 'transfer', 'TS buffer on device 6' und 'receiver on device 6'.

Hier ein nicht funktionierender Kanalwechsel (mit vdr-1.3.36-bigpatch-test3a):

Client:

Nov 19 16:04:32 bero vdr[7214]: switching to channel 4
Nov 19 16:04:32 bero vdr[7223]: transfer thread ended (pid=7223, tid=131074)
Nov 19 16:04:32 bero vdr[7214]: buffer stats: 1021592 (48%) used


Nov 19 16:04:32 bero vdr[7254]: transfer thread started (pid=7254, tid=180226)

Hier ist zu sehen, dass zwar der 'transfer' Thread beendet und später neu gestartet wird. Die beiden anderen Threads werden jedoch nicht beendet und neu gestartet.

Server:

Nov 19 16:04:33 seca vdr[23971]: streamdev-livestreaming thread ended (pid=23971, tid=8028176)
Nov 19 16:04:33 seca vdr[23970]: streamdev-writer thread ended (pid=23970, tid=8011789)
Nov 19 16:04:33 seca vdr[22680]: buffer stats: 944817 (22%) used

Leider habe ich jetzt keine Zeit mehr, mich weiter mit dem Problem zu beschäftigen.

Aber Dank dieser Diskussion habe ich jetzt - wenn ich auch mit einem weineneden Auge auf den BigPatch verzichten muss - zumindest wieder einen funktionsfähigen Client.

Interessant wäre es sicherlich, mal nachzuforschen, wo diese beiden Threads erzeugt und wo diese beendet werden und warum dies bei den Versionen big BigPatch nicht geschieht.

Hmm, etwas lange geworden, dieses Posting. Aber vielleicht hilft es ja jemandem bei der weiteren Eingrenzung des Fehlers...

bye, Alex

Hi.

Zitat

Original von Elian
Klingt ja schonmal etwas aufbauend. Welche Distri verwendest du?

Ich verwende Fedora Core 4 und übersetze mir den VDR+Plugins immer selbst aus den Sourcen, die ich mir hier bzw. von den einzelnen Servern herunterlade. Also keine vdr-spezifische distri.

Daher denke ich auch, dass triple955 Recht hat:

Zitat

Original von triple955
(PS2: Ausserdem wollte ich ursprünglich nicht in diesem Thread antworten, da ich nicht glaube, dass das Problem LinVDR-spezifisch ist - ich nutze Gentoo mit selbst erzeugtem VDR.)

Zitat

Original von triple955
Aber Dank dieser Diskussion habe ich jetzt - wenn ich auch mit einem weineneden Auge auf den BigPatch verzichten muss - zumindest wieder einen funktionsfähigen Client.

Geht mir auch so. Ich habe mir zwei Dinge gedacht, die man als nächstes probieren könnte:

• Bigpatch einspielen und dann den LiveBuffer Patch mit patch -r anwenden. Das müsste ihn ja theoretisch wieder entfernen. Habe aber keine Ahnung, ob das funktioniert und was bringt. Muss man ausprobieren.
  

  
  

• Die im BP enthaltenen Patches einzeln einspielen (zumindest jene, die man wirklich will). Natürlich sollte man zwischendurch auch immer testen, ob's jetzt noch geht.
  

  
  

• Die dritte Variante wäre natürlich, der Sache mit den Threads nachzugehen, die triple955 aufgeworfen hat. Aber dazu kenne ich mich im VDR zu wenig aus, fürchte ich.

So oder so ist es etwas zeitaufwändig und ich weiss nicht, ob sich das vor Weihnachten noch ausgehen wird.
Falls ich etwas weiterbringe, werde ich jedenfalls berichten!

ciao,
K.

Zitat

Original von Elian
Morgen soll es diesen neuen Lifebuffer-Patch dann auch in einem neuen BigPatch geben - würde mich freuen, wenn das einer ausprobieren könnte.

Wäre doch seehr dankbar, wenn das irgendwie wieder funktionieren würde.

Elian

Sorry. Ich hab's soeben probiert (1.3.37 mit bp-test3) und das Ergebnis war das gleiche.

Ich habe derzeit 1.3.36 mit den Patches

sortrec
enAIO
missingplugins

laufen und damit funktioniert streamdev+umschalten problemlos. Ich wollte eigentlich noch die Patches

disableDoubleEpgEntry
timerinfo
cmdsubmenu
showdetails

einspielen, aber da gab's rejects. Ich habe mich aber nicht weiter damit beschäftigt, möglicherweise wären die rejects leichts aufzulösen gewesen. Soweit ich das durchblicke ist genau das die Hauptarbeit, die im BigPatch steckt.

K.

Hi Krampus

Zitat

Original von Krampus

[*]Die dritte Variante wäre natürlich, der Sache mit den Threads nachzugehen, die triple955 aufgeworfen hat. Aber dazu kenne ich mich im VDR zu wenig aus, fürchte ich.

Ein wenig habe ich kürzlich noch im Source gewühlt.

Wenn Du so fix mit Compilieren bist :-), könntest Du mal folgendes probieren:

In der Datei device.c eines mit BigPatch versehenen VDRs die Funktion "void cDevice:: Detach(cReceiver *Receiver)" suchen. Ganz am Ende der Funktion (ungefähr Zeile 1473) ist folgendes zu sehen:

if (!receiversLeft)
    ;//Cancel(3);

Entferne hier mal den Strichpunkt und die doppelten Schrägstriche, so dass der Aufruf von Cancel(3) nicht mehr auskommentiert ist, also so aussieht:

if (!receiversLeft)
    Cancel(3);

Disclaimer: Ich habe keine Ahnung, aus welchem Grund diese Zeile - im Vergleich zum Standard-VDR - auskommentiert wurde und/oder auf welche Funktion diese Änderung mglw. negative Auswirkungen hat! Zumindest die Funktion des LiveBuffer-Patches nutze ich selbst nicht, da an meinem Server kaum fern sehe.

Diese Änderung habe ich am 28.11. probehalber an einem vdr-1.3.37 incl. BigPatch-test1 durchgeführt und damit läuft - zumindest bei mir - das Streaming wie gewünscht.

Ich wollte die Sache allerdings noch ein Weilchen im Betrieb testen, bevor ich mich damit an Frank99 (BigPatch) und/oder an thomas83? (LiveBuffer) wende und nachfrage, warum diese Zeile auskommentiert wurde.

Es wäre also vielleicht nicht schlecht, wenn Du das nochmal gegenchecken würdest.

HTH, Alex

Hi Triple955,

mit der von Dir vorgeschlagenen Änderung funktioniert es auch wieder mit dem BigPatch! Danke!

Gruß,
Nico