mh0001 Posted January 15, 2011 Share Posted January 15, 2011 Hallo! Ist es möglich, den Ladebalken vom DVBViewer zu deaktivieren, oder zumindest zu verhindern, dass dieser die Kontrolle über die Anzeige übernimmt und einen auf den Desktop zurückholt? Hintergrund dieser Frage ist, dass ich gelegentlich über den TaskScheduler Aufnahmen plane, die auch mal stattfinden, wenn ich gerade spiele. Sobald jedoch der TaskScheduler den DVBViewer startet, holt mich der Ladebalken augenblicklich auf den Desktop zurück, das Spiel wird minimiert, was gerade bei Onlinespielen dann recht ärgerlich ist. Ich habe es schon so im TaskScheduler eingestellt, das der DVBViewer minimiert gestartet wird, allerdings findet dieses Minimieren dann immer erst nach Durchlaufen des Ladebalkens statt. Kann man den also irgendwie ganz ausschalten, oder es zumindest so konfigurieren, dass dieser im Hintergrund bleibt und nicht den Fokus auf sich zieht? Quote Link to comment
Tjod Posted January 15, 2011 Share Posted January 15, 2011 Nicht das ich wüste. Aber du solltest dir mal den Recording Service angucken. http://de.DVBViewer.tv/wiki/DVB_Recording_Service http://de.DVBViewer.tv/wiki/Recording_Service_Installationsanleitung Mit dem sollte es keine Spielunterbrechungen bei Aufnahmen geben Quote Link to comment
Martin K Posted January 15, 2011 Share Posted January 15, 2011 Du könntest auch einfach vor dem Spielen schon den DVBViewer starten, ggf. die Wiedergabe schließen und/oder den DVBViewer minimieren. Dann brauchst du auch nichteinmal den TaskScheduler um den DVBViewer zu starten, da dieser ja sowieso schon läuft. Ist dann im Prinzip auch nicht anders als wenn du den Recording Service verwendest, der läuft ja genauso im Hintergrund. Du kannst ja auch einen Task erstellen, der automatisch mit dem Windows-Start zusammen auch den DVBViewer minimiert startet, das ist dann wirklich genau das selbe wie den Recording Service zu verwenden Quote Link to comment
Tjod Posted January 15, 2011 Share Posted January 15, 2011 Was das unterbrechen des Spiels angeht ist das vielleicht das gleiche. Aber die restlichen Funktionen die der Recording Service bietet bekommst du dadurch nicht Der Installation auffand (einfach nach Anleitung) den der Recording Service bedeute, lohnt sich meiner Meinung nach für die meisten. Grade wenn man häufig was aufnimmt und den DVBViewer nicht immer laufen hat. das ist dann wirklich genau das selbe wie den Recording Service zu verwendenSo eine aussage kann eigentlich nur von jemanden kommen der sich dem Recording Service noch nicht wirklich angeguckt hat Quote Link to comment
mh0001 Posted January 16, 2011 Author Share Posted January 16, 2011 (edited) Danke für den Tip, hab den Recording Service jetzt mal eingerichtet. Noch ein viel großartigerer Nebeneffekt ist, dass sich mit dem Webinterface ja Möglichkeiten bieten, die ich schon immer gern gehabt hätte, nämlich remote übers Internet, wenn ich mal weg bin, den aktuellen Stand der Aufnahmen zu checken und zu sehen, ob noch alles so läuft wie ich mir das gedacht habe. Ich wusste ja gar nicht, was man damit alles Tolles machen kann ^^ Es sollte für remote-Zugriff dann doch reichen, den Port für das Webinterface im Router zu forwarden, und natürlich ein Passwort einzustellen, damit da nicht jeder draufkann, oder? Der Router meldet bei jeder Änderung der öffentlichen IP-Adresse diese automatisch bei einem DynDNS-Service, und dann müsste ich ja im Prinzip über dyndnshostname:port direkt auf mein Webinterface kommen? Edited January 16, 2011 by mh0001 Quote Link to comment
Tjod Posted January 16, 2011 Share Posted January 16, 2011 Du musst auch noch an die Windows Firewall denken. Der Recording Service richtet bei der Installation da nur eine Regel für das lokale Netzwerk ein. Quote Link to comment
Equinox Posted January 17, 2011 Share Posted January 17, 2011 Es sollte für remote-Zugriff dann doch reichen, den Port für das Webinterface im Router zu forwarden, und natürlich ein Passwort einzustellen, damit da nicht jeder draufkann, oder? Der Router meldet bei jeder Änderung der öffentlichen IP-Adresse diese automatisch bei einem DynDNS-Service, und dann müsste ich ja im Prinzip über dyndnshostname:port direkt auf mein Webinterface kommen? Sollte gehen, so wirklich sicher ist das aber noch nicht, da das Passwort unverschlüsselt übertragen wird. Um das zu verhinden bräuchtest du einen SSL Tunnel. Du kannst dir dafür z. B. mal Stunnel anschauen. Quote Link to comment
Tjod Posted January 17, 2011 Share Posted January 17, 2011 Das stimmt so nicht! Sofern du keinen Uhr alt Browser verwendest wird das Passwort nicht unverschlüsselt übertragen (RFC2617). Einen SSL Tunnel brauchst du nur wenn du dir bei den anderen Sachen wie EPG oder Timern sorge machst dass da jemand mitlest. Quote Link to comment
Martin K Posted January 18, 2011 Share Posted January 18, 2011 (edited) So eine aussage kann eigentlich nur von jemanden kommen der sich dem Recording Service noch nicht wirklich angeguckt hat Ich hatte ihn zweimal drauf (mit längerer Pause dazwischen) und hatte ihn beide Male am nächsten Tag wieder runtergeschmissen. Der kann irgendwie nicht mehr als wenn ich mir den DVBViewer in den automatischen Windows-Start lege (minimiert und ohne Wiedergabe), wie oben beschrieben. Aufnehmen per Timer tue ich nicht so häufig und wenn, dann reicht mir der DVBViewer dazu. Meistens nutze ich die Sofortaufnahme. Das einzige was er mehr kann ist die Bedienung und das EPG über's Netzwerk, aber das brauche ich auch nicht wirklich. Und die Funktionen, dir mir beim DVBViewer fehlen, bietet der Recording Service leider auch nicht: Aufnahmen einem festen Tuner zuweisen, Automatisches EPG-Update (geht nur für den Recording Service selbst, aber wird nicht im DVBViewer übernommen). Dazu kommt noch der Nachteil, dass man beim Recording Service das EPG nicht auf die Favoriten-Sender beschränken kann, wie es im DVBViewer möglich ist. Alles in allem nur sinnvoll, wenn man einen Netzwerkzugriff haben möchte. Edited January 18, 2011 by Martin K Quote Link to comment
Tjod Posted January 18, 2011 Share Posted January 18, 2011 Automatisches EPG-Update (geht nur für den Recording Service selbst, aber wird nicht im DVBViewer übernommen)Wenn der DVBViewer das EPG nicht übernimmt stimmt was mit den Einstellungen nicht. Quote Link to comment
mh0001 Posted January 18, 2011 Author Share Posted January 18, 2011 Eine etwas unschöne Sache ist mir aufgefallen, und zwar verhindert der Recording Service sobald ich eine Aufnahme programmiere (habe es über das Webinterface getan), dass der PC in den Standby gehen kann, es findet nur eine Sperrung bzw. der Windows-Abwesenheitsmodus statt. Das soll unter Umständen zwar so sein, aber eigtl. nur dann, wenn in den nächsten 15 Min. eine Aufnahme bevorsteht (Einstellung des Recording Service). Allerdings kann ich auch für nächste Woche programmieren, und der Standby wird geblockt. Interessanterweise reicht ein manuelles Stoppen und Neustarten des Recording Service aus, und der PC kann trotz weiterhin programmierter Aufnahme in den Standby gehen. Quote Link to comment
Tjod Posted January 18, 2011 Share Posted January 18, 2011 Entfern mal die haken bei den Beiden Optionen Verhindere Stromsparmodus/Ruhezustand... http://de.DVBViewer.tv/wiki/Optionen_Service_-_Web/UPnP Quote Link to comment
mh0001 Posted January 18, 2011 Author Share Posted January 18, 2011 Jap, das wars! Danke! Quote Link to comment
Martin K Posted January 18, 2011 Share Posted January 18, 2011 Wenn der DVBViewer das EPG nicht übernimmt stimmt was mit den Einstellungen nicht. Hmm, was könnte denn an den Einstellungen nicht stimmen? Also so wie ich das gesehen habe, nutzt der Recording Service seine eigene EPG.dat im config Unterordner. Wie soll die denn vom DVBViewer übernommen werden? Aber das EPG Update im Recording Service selbst hat ja auch nicht so richtig geklappt: Das erste mal ging's noch, aber 12 Stunden später wurde dann überhaupt nix mehr geupdated... Quote Link to comment
Tjod Posted January 18, 2011 Share Posted January 18, 2011 http://de.DVBViewer.tv/wiki/Recording_Service_Installationsanleitung#DVBViewer_Recording_Service_Einstellungen Quote Link to comment
Martin K Posted January 19, 2011 Share Posted January 19, 2011 (edited) http://de.DVBViewer.tv/wiki/Recording_Service_Installationsanleitung#DVBViewer_Recording_Service_Einstellungen Ach tatsächlich, das hab ich wohl übersehen Danke für den Hinweis! Wusste nicht, dass sich der Recording Service auch im DVBViewer integriert. Wenn man jetzt noch für das EPG Update einen festen Tuner zuweisen kann und für die Aufnahmen den anderen Tuner fest zuweisen, dann wäre es perfekt... Weißt du auch woran es lag, dass das EPG Update nach 12 Stunden nicht mehr funktionierte? Als die Zeit erreicht war, die im Webinterface unter Status beim Nächsten EPG Update angegeben war, ist diese einfach 5 Min. weitergesprungen, ohne dass das EPG geupdated wurde. Das selbe, wenn ich manuell auf EPG Start geklickt habe. Die Tuner waren übrigens alle frei. Edited January 19, 2011 by Martin K Quote Link to comment
Equinox Posted January 19, 2011 Share Posted January 19, 2011 Das stimmt so nicht! Sofern du keinen Uhr alt Browser verwendest wird das Passwort nicht unverschlüsselt übertragen (RFC2617). Einen SSL Tunnel brauchst du nur wenn du dir bei den anderen Sachen wie EPG oder Timern sorge machst dass da jemand mitlest. Ja, ich wollte jetzt hier nicht mit Details langweilen. - Es wird nicht direkt das Passwort übertragen, jedoch eine Zeichenfolge, die ein Angreifer abfangen und sich damit beim Webinterface authentifizieren kann (innerhalb eines begrenzten Zeitfensters). Solange die Kommunikation unverschlüsselt stattfindet, ist das ganze jedenfalls weder Man-in-the-Middle- noch abhörsicher. Natürlich ist es erstmal nicht besonders kritisch, wenn jemand von außen auf den RS zugreifen kann. Allerdings weiß ich nicht, wie die Sache ausgehen würde, wenn jemand mal systematisch den Webserver des RS auf Sicherheitslücken untersuchen würde. - Wäre zumindest denkbar, dass man sich darüber Zugriff aufs System verschaffen kann. Ich werde jedenfalls keinen unverschlüsselten Zugriff über das Internet auf einen Rechner, der bei mir im LAN hängt, zulassen. Außerdem ist ein SSL Proxy so schwer jetzt wirklich nicht zu konfigurieren. Quote Link to comment
Moses Posted January 19, 2011 Share Posted January 19, 2011 Sicherheitslücken im Service haben nichts mit verschlüsselt oder nicht zu tun... im Gegenteil: Die Verschlüsselung erhöht die Komplexität der Software, was gleichzeitig Sicherheitslücken wahrscheinlicher macht (mit der selben Paradox klingenden Tatsache haben Desktop-Firewalls zu kämpfen ). Sicherheitslücken funktionieren ja nicht, indem irgendwer irgendwo mit lauscht und dann aufgezeichnete Sachen schickt. Sondern es wird versucht fehlerhafte Anfragen an den Service zu schicken, und ob man da vorher eine einfache TCP Verbindung oder eine TCP Verbindung über SSL aufbaut tut überhaupt nichts zur Sache. Und gerade, wenn man dann noch externe Software für den SSL Tunnel nimmt, kann die für ganze andere Dinge anfällig sein. In der Hinsicht vergrößert sich das Risiko tatsächlich. Besonders, weil die Software für den SSL Tunnel wahrscheinlich weiter verbreitet und damit interessanter zum "mal austesten" für Hacker ist, als es der Recording Service jemals sein wird, selbst wenn er offen sein sollte, wie ein Scheunentor. Übrigens: Verschlüsselung alleine ist auch nicht Man-in-the-Middle-sicher. *mal zurück klugscheiß* Quote Link to comment
Equinox Posted January 20, 2011 Share Posted January 20, 2011 Sicherheitslücken im Service haben nichts mit verschlüsselt oder nicht zu tun... im Gegenteil: Die Verschlüsselung erhöht die Komplexität der Software, was gleichzeitig Sicherheitslücken wahrscheinlicher macht (mit der selben Paradox klingenden Tatsache haben Desktop-Firewalls zu kämpfen ). Natürlich haben Sicherheitslücken im RS etwas mit Verschlüsselung zu tun - wenn man die Verschlüsselung über eine zusätzliche Software realisiert, ist der RS nämlich nach außen nicht mehr sichtbar. Dann ist es ziemlich egal, wie sicher oder unsicher er ist. Sicherheitslücken funktionieren ja nicht, indem irgendwer irgendwo mit lauscht und dann aufgezeichnete Sachen schickt. Sondern es wird versucht fehlerhafte Anfragen an den Service zu schicken, und ob man da vorher eine einfache TCP Verbindung oder eine TCP Verbindung über SSL aufbaut tut überhaupt nichts zur Sache. Schon klar, aber unter welchen Voraussetzungen ist es für einen Angreifer wohl einfacher eine Verbindung aufzubauen? Und gerade, wenn man dann noch externe Software für den SSL Tunnel nimmt, kann die für ganze andere Dinge anfällig sein. In der Hinsicht vergrößert sich das Risiko tatsächlich. Besonders, weil die Software für den SSL Tunnel wahrscheinlich weiter verbreitet und damit interessanter zum "mal austesten" für Hacker ist, als es der Recording Service jemals sein wird, selbst wenn er offen sein sollte, wie ein Scheunentor. Na ja, nehmen wir mal den Apache als wohl verbreitetstes Beispiel für einen Webserver, den man als SSL Proxy verwenden kann. Natürlich ist der ständig Angriffen ausgesetzt. Ebenso wird aber ständig an der Beseitigung kritischer Sicherheitslücken gearbeitet. Natürlich ist jeder offene Port ein Risiko - egal welcher Dienst da "lauscht". Ich würde aber bei einer Software, die ständig Angriffen ausgesetzt ist und dementsprechend weiterentwickelt wird (SSL Proxy), das Risiko als geringer einstufen als bei einer Software, deren Entwickler den Fokus verständlicherweise auf andere Dinge setzen als die Sicherheit des Webservers (RS). - Zumindest wenn man überlegt, wer die potenziellen Angreifer sind. - Profis werden das kaum sein, weil ja eigentlich nichts interessantes zu holen ist. Übrigens: Verschlüsselung alleine ist auch nicht Man-in-the-Middle-sicher. Ach nein, wirklich? Quote Link to comment
mh0001 Posted January 25, 2011 Author Share Posted January 25, 2011 (edited) Was ruft die Funktion im Recording Service, "Reset nach Standby", eigtl. genau auf? In der Wiki steht, es funktioniert nur dann, wenn die DVB-Hardware im Gerätemanager ein Deaktivieren zulässt. Dementsprechend hat es bisher bei meiner USB Cablestar Combo HD nicht funktioniert, weil der Treiber kein Deaktivieren zugelassen hat. Jetzt habe ich aber festgestellt, dass im Technisat-Treiberarchiv auch eine Variante des Treibers versteckt ist mit dem Zusatz "(Without HID)". Wenn man den alten Treiber vorher restlos entfernt hat (also auch "Treibersoftware entfernen" anhakt beim Deinstallieren), und diesen manuell auswählt, wird nach dessen Installation kein HID-Device gefunden und installiert, und das Deaktivieren der Cablestar Combo funktioniert auf einmal völlig problemlos! Die HID-Variante des Treibers verhindert also das Deaktivieren. Allerdings tut die nach wie vor angehakte Option im Recording Service nun nicht mehr als vorher. Manuell kann ich diesen Reset aber herbeiführen durch eigenhändiges De- und wieder Aktivieren im Gerätemanager. Leider habe ich sonst stets nach Standby nur ein schwarzes Bild. Tut die Funktion evtl. bei der Cablestar einfach nichts, weil generell angenommen wurde, dass keiner der Treiber das Deaktivieren unterstützt? Edited January 25, 2011 by mh0001 Quote Link to comment
mh0001 Posted January 30, 2011 Author Share Posted January 30, 2011 (edited) Hab das Problem jetzt selber gelöst. Ich weiß nicht, welche Routinen der RecordingService für den Reset nutzt. Jedenfalls gibt die devcon.exe, die man einzeln bei MS runterladen kann, ebenso wie das Log des RevordingService ein "failed" aus, egal, mit welchen Rechten man es ausführt. Die Problem ist, dass die Standalone devon.exe eigtl. 32 bit Routinen nutzt, und sich nicht in der Hinsicht beschwert, also vom WOW6432Node ausgeführt wird, und dabei natürlich keinen Zugriff auf die 64 bit Treiber haben. Allerding gibt es im Windows Driver Kit - iso von Microsoft (http://www.microsoft.com/downloads/en/details.aspx?displaylang=en&FamilyID=36a2630f-5d56-43b5-b996-7633f2ec14ff) unter den Tools eine devcon.exe, die nativ für 64bit-Systeme vorgesehen ist (AMD64-version). Ruft man die auf, funktioniert der restart einwandfrei. Da ich nicht weiß, wie man im Recording Service einen Aufruf nach dem Aufwachen aus dem Standby definiert, hab ich das jetzt anders gelöst. Man lege im Aufgabenplaner folgenden Task an: Trigger: Bei Ereignis - Protokoll: System, Quelle: Microsoft-Windows-Power-Troubleshooter, Ereignis-ID: 1 (bedeutet: PC wacht aus Standby auf) Unabhängig von Benutzeranmeldung, mit höchsten Rechten ausführen Aktion: Pfad\AMD64\devcon.exe restart *0003 (für Technisat Cablestar geräte), mit 30 Sek. Verzögerung zum Trigger Das Reset im Recording Service kann man dann ausschalten. Funktioniert 100% einwandfrei und ohne Nebenwirkungen. Edited January 30, 2011 by mh0001 Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.