Timerliste des RS wird im DVBViewer nicht immer angezeigt

[chrisbu]

Hallo Experten und Mitleser,

 

mir macht ein Problem im Zusammenspiel DVBViewer --> Recording Service Kopfzerbrechen.

 

Und zwar klappt die Anzeige der im Recording Service hinterlegten Timer in einem angebundenen DVBViewer Pro 4.9.6.20 nicht. Es sieht so aus, als ob nur beim Start des DVBViewers einmal die Timerliste vom Recording Service abgerufen wird. Da sehe ich dann die programmierten bzw. laufenden Timeraufnahmen sowohl in der Timeranzeige über die Menüleiste oder auch im OSD. Kann hier dann auch Timer des Recording Service löschen usw.

 

Wenn ich aber eine Aufnahme über diesen DVBViewer programmiere (OSD oder über das EPG-Menü), dann wird diese zwar korrekt an den Recording Service übermittelt und dort aufgenommen, aber ich sehe diesen Timer dann nicht mehr in der Timerliste auf dem DVBViewer. Diese ist einfach leer. Erst wenn ich den DVBViewer beende und neu starte, dann sehe ich diesen Timer hier wieder und kann ihn z.B. löschen. Es scheint so, als ob die Timerliste zwischen Recording Service und dem DVBViewer zwar einmal beim Start abgeglichen wird, aber während des Betriebs neu hinzugekommene Timer der DVBViewer nicht mehr mitbekommt (selbst wenn er sie selbst programmiert hat).

 

Das kuriose ist, dass es nur bei einem Rechner auftritt (Windows XP Service Pack 3). Ein anderer Rechner (ebenfalls Windows XP Service Pack 3) hat dieses Problem nicht. Auch der Rechner, wo der Recording Service läuft zeigt dieses Problem in seiner lokalen DVBViewer Installation nicht. Die Konfiguration des DVBViewers (insbesondere die Optionen für den Recording Service) sind bei beiden XP-Rechnern absolut identisch. Die Aufnahmeliste ist von dem Problem nicht betroffen, die zeigt stets die im lokalen Aufnahmeverzeichnis und beim Recording Service vorhandenen Aufnahmen an, kann sie abspielen, usw. Nur die Timerliste scheint sich im laufenden Betrieb nicht zu synchronisieren, obwohl die entsprechende Option gesetzt ist.

 

Ich habe im Ausschlussverfahren einiges probiert, was alles nichts gebracht hat:

 

- Neuinstallation / Neukonfiguration des DVBViewers auf dem XP-Client

- Abschalten Firewall / Virenscanner sowohl auf dem XP-Client als auch auf dem RS Rechner

- Testweise mal lokale Installation des Recording Service auf dem XP-Client, gleiches Problem

- Abklemmen zweiter Netzwerkkarte auf dem XP-Client

 

Es scheint zumindest kein Kommunikationsproblem mit dem Recording Service Rechner zu sein, da auch bei lokal installiertem Recording Service dieselbe Problematik auftritt.

 

Ich habe keine Idee mehr, woran das noch liegen könnte. Der Timer wird wie gesagt korrekt an den Recording Service geschickt, aber der DVBViewer sieht ihn nicht mehr, außer wenn er neu gestartet wird. Was noch auffällt ist, wenn man über das EPG-Fenster des DVBViewers programmiert und daraus den Timer erstellt, verfärbt sich die aktuelle Sendung im EPG-Fenster dann nicht in rot, so wie es bei dem anderen (funktionierenden) XP-Client passiert. Das Festplattensymbol in der OSD-EPG-Anzeige zeigt sich nach einer dort durchgeführten Programmierung auch nicht dauerhaft... nur einmal in der noch offenen OSD Anzeige nach der Programmierung erscheint es, aber wenn man einmal aus dem OSD EPG-Menü raus und wieder rein geht, ist dort auch das Festplattensymbol vor der programmierten Sendung verschwunden (OSD: Concinnity 3D).

 

Leider komme ich im Moment nicht an den Rechner, um eine support.zip zu erstellen, aber vielleicht hat ja jemand eine zündende Idee, woran das liegen könnte. Was genau findet bei diesem Timerabgleich statt? Gibt es bestimmte Abhängigkeiten außerhalb des DVBViewers (weitere Software, Runtime Libraries, .NET Updates, etc.)? Kann man über ein Logging mehr Informationen bekommen?

 

Werde also heute Nacht weiter basteln und berichten, wenn ich die Lösung gefunden habe. Sollte jemand helfen können, wäre ich sehr dankbar.

 

Viele Grüße,

Chris

[chrisbu]

So, jetzt gibt es auch noch die support.zip dazu. Habe den Versuchsaufbau so gering wie möglich gehalten mit lokal installiertem Recording Service. DVBViewer wurde mit -debug gestartet. Dann um 20:27 Uhr habe ich über Menü -> DVBViewer -> EPG Fenster im aktuell laufenden Programm die aktuelle Sendung markiert und auf Timer erstellen geklickt. Recording Service nahm auf, aber der Programmeintrag im EPG Fenster wurde nicht rot. Dann eine Minute bis 20:28 Uhr gewartet und Menü -> DVBViewer -> Aufnahme-Programmierung geöffnet. In der Liste wurde die gerade vor einer Minute an den Recording Service gesandte Aufnahmeprogrammierung nicht angezeigt. Dann DVBViewer beendet, den laufenden Timer über das WebInterface vom Recording Service gelöscht und auch den Recording Service beendet. Dann support.zip gezogen.

 

Ich hoffe, hier kann ein Experte helfen. Es ist völlig unklar, wo es bei dieser ansonsten eigentlich einwandfrei funktionierenden Kommunikation mit dem lokal installierten Recording Service klemmt.

 

Vielen Dank!

 

 

[chrisbu]

Habe noch etwas weiter geforscht...

 

es ist wirklich so, dass sich die Timeliste im DVBViewer und die Timerliste im Recording Service nur ein einziges Mal beim Start des DVBViewers abgleicht. Nur dabei erlangt der DVBViewer Kenntnis von den im Recording Service vorhandenen Timern. Er bekommt dann im weiteren Betrieb keine Änderungen mehr mit. Weder wenn neue Timer hinzugekommen sind (auch wenn Sie von diesem DVBViewer dorthin gesandt worden sind), noch wenn Timer zwichenzeitlich gelöscht wurden.

 

1. Versuch: DVBViewer gestartet, EPG-Fenster, aktuelle Sendung ausgewählt, Timer erstellen geklickt, Aufnahme startet im RS, aber aktuelle Sendung wird im EPG-Fenster (DVBViewer) nicht rot, Timer wird auch unter Aufnahme-Programmierung nicht angezeigt. Die laufende Aufnahme selbst sieht man aber in der Aufnahmeliste des DVBViewers, kann die Datei auch abspielen. Die Aufnahmeliste wird also immer on the fly synchronisiert mit dem RS. Erst nach einem Neustart erscheint der Timer dann auch in der Aufnahme-Programmierung und auch im EPG-Fenster ist die aktuelle Sendung dann rot. Löschen des Timers klappt dann auch.

 

2. Versuch: wie oben, beim zweiten Start des DVBViewers sehe ich ja dann den Timer unter Aufnahme-Programmierung, lösche ihn aber dann nicht im DVBViewer, sondern über das Web-Interface des Recording Service. Wie erwartet bekommt der DVBViewer das dann wieder nicht mit, denn dort wird der Timer immer noch in der Aufnahme-Programmierung angezeigt. Erst nach dem nächsten Neustart des DVBViewers ist er dann weg, oder wenn ich im DVBViewer halt noch mal löschen klicke... obwohl der Timer beim Rs ja schon nicht mehr exisitiert hat.

 

3. Versuch: Wenn ich nebenbei mal im Browser die Timerliste vom RS als XML über das API abrufe, ist der aktuelle Zustand immer korrekt... also wenn der Timer erstellt wurde, wird er als XML-Struktur ausgegeben, auch mehrmals hintereinander, bis er wieder gelöscht wurde. So ähnlich greift der DVBViewer ja bestimmt auch zu.

 

Ich vermute, dass das Problem also eher auf der DVBViewer Seite und nicht beim RS zu suchen ist. Aber eben nur auf diesem XP-Rechner... auf dem anderen geht das alles einwandfrei.

 

Ich bin mit dem Ausschlussverfahren jetzt mit allen auch noch so verrückten Ideen durch, einfach nichts zu machen. Einziger Unterschied zu dem anderen XP-Rechner ist, dass das Windows-Verzeichnis hier WINXP und nicht WINDOWS heißt. Könnte das irgendwas damit zu tun haben?

 

So langsam bleibt wohl nur noch der Versuch einer kompletten Neuinstallation des XP mit allem drum und dran... au Mann, das wäre echt riesiger Aufwand.

 

Vielleicht gibt es ja noch einen entscheidenden Tipp.

 

Gruß,

Chris

[Tjod]

Es gab glaube ich schon mal so ein Problem, da lag es irgendwie daran dass der PC keine richtige IP-Adresse hatte. Die Kommunikation hat dann zwar Trotzdem noch geklappt aber die Update Benachrichtigung das es neue Timer gibt kamen irgendwie nicht an.

 

In einem anderen Fall lag es glaube ich daran dass die Senderliste im RS und im DVBViewer Client zu unterschiedlich waren.

[chrisbu]

Hallo Tjod, vielen Dank für die Antwort. Ich hatte auch viel gegoogelt und im Forum gesucht, ob es schon mal ein ähnliches Problem gab, konnte aber leider nichts finden. Gut, dass Du dich daran erinnerst, dass es so was schon mal gab.

 

Zumindest den zweiten Part kann ich ausschließen, weil RS und DVBViewer eine exakt gleiche Senderliste verwenden und in meinem für die Fehlersuche gestalteten einfacheren Aufbau mit DVBViewer und RS zusammen auf dem betroffenen Rechner nutzen ja eh beide die gleiche Liste.

 

Das Thema Netzwerkkarte / IP-Adressen ist mir gestern bis in die Nacht auch durch den Kopf gegangen und ich habe noch einiges probiert. Auf dem Rechner ist auch ein 1394 (Firewire) Host Adapter, der automatisch auch als weitere Netzwerkkarte eingebunden wird. Diese zeigt auch (obwohl zurzeit keine Videokamera über FireWire angeschlossen ist) immer einen Link an, die TCP/IP-Einstellungen des Adapters sind aber auf Standard, d.h. keine feste IP-Adresse, sondern DHCP.

 

Ich habe dann mal die Bindungsreihenfolge der Netzwerkkarten überprüft und gesehen, dass die Ethernet-Karte vor der 1394-Karte gebunden wird und damit eigentlich die primäre Netzverbindung sein sollte. Trotzdem habe ich der 1394 Karte mal alle Protokolle weggenommen, sie sogar mal deaktiviert, auch mal den gesamten 1394-Gerätetreiber deaktiviert, dazwischen immer wieder neu gebootet und der DVBViewer hat trotzdem immer noch das gleiche Verhalten bei den Timern gezeigt.

 

Kann mir jemand kurz erklären, wie das mit den Timer-Updates genau funktioniert? Du sprachst von Update-Benachrichtigungen, was ja im Prinzip eine Kommunikation vom Recording Service zum DVBViewer wäre... also dass der Recording Service von sich aus dem DVBViewer mitteilt, wenn sich in seiner Timerliste irgendwas geändert hat. Ich hatte bisher vermutet, dass der DVBViewer jedesmal, wenn man eine EPG-Ansicht oder Timerliste zur Ansicht öffnet, beim Recording Service die aktuelle Timerliste holt und sie dann anzeigt bzw. in der EPG-Ansicht die Sendungen kennzeichnet, für die ein Timer bzw. laufende Aufnahme existiert.

 

Ich glaube, kann mich aber nicht genau erinnern, dass es auf dem Rechner sogar mal funktioniert hatte mit der Timer-Synchronisierung. Da hatte ich ihn direkt mit einem anderen XP-Rechner und einem dort testweise installierten RS verbunden, per direkter Verbindung über einen Switch und mit festen IP-Adressen auf beiden Seiten. Jetzt ist es aber wie gesagt auch mit lokaler Installation des Recording Service und durchgängige Verwendung der 127.0.0.1 Localhost Adressen nicht mehr möglich, die Timerliste im laufenden Betrieb des DVBViewers zu updaten.

 

Zur Netztopologie:

 

LAN-Adapter: angeschlossen per DHCP an Fritz!Box 7270, die wiederum Internetverbindung hat

1394-Adapter: nicht angeschlossen, steht auf DHCP und behauptet, Link zu haben

Firewall: Sunbelt Personal Firewall (ehemals Kerio)

 

Zur Fritz!Box... von dem Konflikt, dass diese auch den Port 8089 (zumindest wohl nach Außen Richtung Internet) belegt, habe ich schon gelesen und andere Ports für den Webserver des RS und die Unicast-Schnittstelle versucht... ohne Erfolg.

 

Was kann ich jetzt noch probieren? Das muss doch irgendwie in den Griff zu bekommen sein.

 

Mit einer Neuinstallation des Rechners werde ich jedenfalls noch warten, das wäre die letzte Option. Vielleicht kann mein Testaufbau ja mit weiterer Forschung und Tipps dazu dienen, die Ursache zu klären und das dann gut zu dokumentieren, damit andere Nutzer nicht in die gleiche Falle tappen.

[Tjod]

Zumindest eine der beiden Sachen war glaube ich bei einem internen Betatest. Ich finde das grade aber auch nicht und ob meine Erinnerungen wirklich ganz richtig sind weiß ich auch nicht. Und ob die beiden Sachen mit der aktuellen Version überhaupt noch relevant sind weiß ich auch nicht.

 

Wie das mit dem aktualisieren der Timerliste genau funktioniert wenn im RS eine neue Aufnahme hinzugefügt wird kann wahrscheinlich wenn nur Lars erklären.

[Lars_MQ]

Der RS sendet einen UDP Broadcast an 255.255.255.255:1901 um Update ereignisse an die Clients zu verbreiten. Wahrscheinlich wird das von der Firewall blockiert.

[chrisbu]

Danke Lars, das ist ja eine hilfreiche Information für die weitere Suche. Firewall hatte ich zwar deaktiviert und keinen Unterschied festgestellt, aber muss noch mal mehr damit rumprobieren. Es gibt ja bei Sunbelt Personal Firewall z.B. die Option, dass während des Systemstarts alle ausgehenden Verbindungen geblockt werden sollen. Vielleicht startet der Recording Service beim Hochfahren vor der Firewall und blockt damit irgendwas, das dann auch im laufenden Betrieb die Broadcasts nicht mehr verteilt. Leider kann man die Firewall nicht dauerhaft abschalten, beim Neustart ist sie immer wieder an. Muss im schlimmsten Fall mal deinstallieren und dann schauen.

 

Noch eine Frage... gibt es seitens der Programmierung vielleicht eine Bindung an einen bestimmten Adapter, über den der beschriebene Broadcast verschickt wird? Oder geht das immer automatisch an alle installierten Adapter. Bei mehreren Netzwerkkarten dürfte das wichtig sein. Kann man per Konfiguration (zum Ausprobieren) mal festlegen, dass diese ausgehenden Update Ereignisse an einen bestimmten Netzwerkadapter geschickt werden? Oder statt Broadcast auich direkt an eine angegeben IP-Adresse?

 

Vielen Dank, langsam habe ich wieder mehr Hoffnung, das Problem lösen zu können.

[chrisbu]

Leute, ich habe die Ursache gefunden! Es lag tatsächlich an der Verwendung mehrerer Netzwerkadapter.

 

Aber erst mal der Reihe nach.

 

Das bei der (nur testweise durchgeführten) Installation des Recording Service auf dem XP-Rechner, wo der DVBViewer das Aktualisierungsproblem der Timerliste auch zeigt, liegt scheinbar wirklich an der Sunbelt Personal Firewall, die trotz eingerichteter Freigaben (ein- und ausgehend für DVBViewer und Recording Service) die Updatenachrichten (Broadcasts) vom Recording Service blockiert. Auch wenn die Firewall abgeschaltet wurde. Vermutlich ist bereits beim Systemstart eine Blockierung eingetreten, weil der RS ja mit Windows und evtl. vor der Firewall startet. Aber dafür eine Lösung zu finden, verfolge ich nicht weiter, denn es ging ja um den Zugriff dieses DVBViewers auf einen Recording Service auf einem anderen Rechner mit Windows 7:

 

Ich habe mit Wireshark und Internetrecherche herausgefunden, dass Windows 7 grundsätzlich UDP Broadcasts an 255.255.255.255 bei mehreren vorhandenen Netzwerkadaptern nur über den primären Adapter verschickt. Vista machte das wohl auch schon so, während Windows XP einen Broadcast noch über alle Adapter verschickte. Mein Windows 7 Rechner hat aber zwei Netzwerkkarten. An der primären Karte hängt mein internes LAN mit Internetrouter usw., während die zweite Karte Point-to-Point mit dem XP-Rechner verbunden ist. Die Update-Benachrichtigungen vom Recording Service per Broadcast gehen also nur auf der primären Netzwerkkarte (ins interne LAN) raus, nicht jedoch auf der zweiten Karte wo der XP-Client mit dem DVBViewer angebunden ist. Das erklärt die fehlende Aktualisierung in der Timerliste des DVBViewers, weil er keine Veränderungen der Timerliste des Recording Service mitbekommt.

 

Zur Lösung habe ich unter folgender URL ein kleines Programm gefunden, das unter Windows 7 als eine Art "Repeater" die nur an das primäre Interface rausgehenden Broadcasts einsammelt und diese dann noch mal über die anderen Netzwerkkarten rausschickt. So geht ein Broadcast dann doch über alle Netzwerkverbindungen raus. Nach der Installation und Start des Programms läuft der Recording Service dann tadellos in Verbindung mit dem DVBViewer auf dem Windows XP Client an der zweiten Netzwerkkarte.

 

http://winipbroadcast.e-t172.net/

 

Hier die Info zu dem Programm:

 

http://social.technet.microsoft.com/Forums/en-US/w7itpronetworking/thread/72e7387a-9f2c-4bf4-a004-c89ddde1c8aa/

 

Demnach läuft das Programm nur für Windows 7, bei Vista soll es Probleme geben und bei XP geht es gar nicht. In letzterem Fall braucht man es ja auch nicht, weil Win XP die Broadcasts von sich aus über alle Netzwerinerfaces rausjagt.

 

Man muss dem Programm nach der Installation noch in der Windows 7 Firewall ausgehende Verbindungen (nicht beschränkt auf lokales Subnet) gewähren. Das Programm startet als Dienst autmatisch mit Windows. Funktioniert perfekt!

 

Diese Lösung sollte aber eher als Workaround dienen, bis vielleicht eine Korrktur im Recording Service möglich ist, die auch bei mehreren Netzwerkkarten richtig funktioniert.

 

Vorschlag 1: Der Recording Service sollte alle vorhandenen Netzwerkadapter ja erkennen können. Die Update-Benachrictigungen könnten dann doch (passend für Vista und Windows 7) per Broadcast in alle angeschlossenen Subnetze verschickt werden. Also bei zwei Netzwerkkarten z.B. nach 192.168.0.255 (Subnetz am Adapter 1: 192.168.0.0/255.255.255.0) und nach 10.255.255.255 (Subnetz am Adapter 2: 10.0.0.0/255.0.0.0). Also (mehrere) Subnet-basierte Broadcasts.

 

Vorschlag 2: Der Recording Service sollte doch über alle angemeldeten DVBViewer Clients Bescheid wissen und deren IP-Adressen kennen. Die Update-Benachrichtigungen könnten doch dann auch per Unicast direkt an diese Clients verschickt werden. Die Netzlast dürfte bei den eher kleinen Paketen und der begrenzten Anzahl an gleichzeitig angemeldeten DVBViewer Clients durch diesen Mehrfachversand eigentlich nicht spürbar ansteigen, zumal das ja nur bei Änderungen an der Timerliste versandt wird. Das hätte dann auch den Charme, dass das auch über Router usw. funktionieren würde. Nach aktuellem Konzept müssen ja die DVBViewer Clients immer im direkt angebundenen Subnetz sein, um die Broadcasts zu empfangen.

 

Na, jedenfalls bin ich froh, dies gelöst zu haben und dass die Problematik hier gut dokumentiert ist, falls andere Nutzer mal das gleiche Problem haben. Vielleicht sollte man die Einschränkung und den Workaround mit in die Installationsanleitung aufnehmen.

 

Na denn, danke noch mal für die wertvollen Tipps,

ein schönes Wochenende

[Tjod]

Danke für deine ausführliche Analyse, auf jeden Fall interessante Informationen.

(in wie fern davon was in den RS einfließt kann ich aber nicht sagen)