Beiträge von kls

    Seltsam. Ich hatte das explizit ausprobiert und dachte, dass das


    // allow it to always reuse the same port:

    int ReUseAddr = 1;

    setsockopt(sock, SOL_SOCKET, SO_REUSEADDR, &ReUseAddr, sizeof(ReUseAddr));

    gereicht hätte. Wieso hat das dann bei mir funktioniert und bei dir nicht?


    Klaus

    Das sieht schon mal sehr gut aus.

    Ich hab das mal installiert und im Prinzip funktioniert es, zumindest für normale Webseiten.

    Wenn ich aber eines der Javascript-Files redirecten möchte (mit dem Redirector im beiliegenden Screenshot), dann wird vom Web-Server "dolphin" nichts angefordert und die Seite baut sich auch nicht auf wie normal. Das heißt, der Redirector macht zwar anscheinend was, aber nicht richtig.

    Mache ich was falsch?


    Klaus

    Die Aufrufe sind leider ziemlich tief verschachtelt.

    Ausserdem wird auch mit Cookies gearbeitet, die natürlich vom Server kommen müssen.

    Den größten Teil direkt laufen zu lassen und nur die betreffenden Dateien lokal zu laden dürfte schon der richtige Weg sein.

    Momentan verstehe ich nur nicht, warum das mit der proxy.pac Datei überhaupt nicht greift...


    Klaus

    Danke für den Tipp mit dem Proxy.


    In dem Zusammenhang bin ich auf das Thema "Automatic proxy configuration" gestoßen: https://en.wikipedia.org/wiki/Proxy_auto-config.

    Damit soll es möglich sein, ausgwählte Requests an einen Proxy zu schicken und den Rest direkt zu holen.

    Wenn ich, um das mal auszuprobieren, ein File "proxy.pac" folgenden Inhalts erstelle

    Code
    1. function FindProxyForURL(url, host)
    2. {
    3. return "PROXY myproxy.de:1234";
    4. }

    (wobei "myproxy.de:1234" durch konkrete, funktionierende Werte ersetzt sind) und dieses im Firefox in den "ConnectionSettings" unter "Automatic proxy configuration URL" als "file:///home/kls/proxy.pac" angebe, dann müssten eigentlich alle Request über den Proxy gehen. Es geht aber nach wie vor alles direkt (sehe ich an den nicht erfolgenden Log-Meldungen des Proxies). Der Proxy als solcher funktioniert und wird auch benutzt, wenn ich ihn im Firefox unter "Manual proxy configuration" eingebe.


    Übersehe ich da was? Mir würde diese Variante gut gefallen, weil ich auf meinem lokalen Rechner eh einen kleinen Web-Server am Laufen habe und so genau die Requests für eines der Javascript Files auf diesen umleiten könnte.


    Klaus

    Ich betreibe einen "digitalSTROM" Server zur Haussteuerung. Im Web-Interface zur Konfiguration gibt es leider einen Bug, der mich sehr stört, den die Jungs bei digitalSTROM aber nicht willens oder in der Lage sind zu fixen. Daher wollte ich mir das selber mal anschauen und mein Glück versuchen ;-).


    Wenn ich die entsprechende Seite des Servers aufrufe bekomme ich sowas:

    Die einzelnen *.js Files kann ich mir mit wget auf die lokale Platte laden. Allerdings läuft das Ganze natürlich nicht lokal, weil die Funktionen versuchen, Daten vom Server zu laden, was natürlich nicht geht, wenn ich es lokal aufrufe.


    Weiß vielleicht jemand hier, ob es möglich ist, dem Browser (Firefox, würde aber auch jeden anderen nehmen, wenn er das kann) zu sagen "hol dir javascript Files nicht vom Server, sondern von einem lokalen Verzeichnis"? Dann könnte ich die Verbindung zum Server (HTTPS) ganz normal aufbauen, aber meine lokalen Kopien der *.js Files verwenden und in diesen Veränderungen vornehmen, um den Bug zu lokalisieren und evtl. zu fixen.


    Klaus

    Ich bin gerade dabei, das Problem mit DVB-Devices anzugehen, die unter einem "adapter" mehrere "frontends" haben, aber nur *ein* "demux" bzw. "dvr" (siehe hier).

    Dabei fällt auf, dass sich das wohl ziemlich mit dem Konzept des "Device-Bondings (mehrere DVB-S-Devices an *einem* Sat-Kabel, die somit immer nur *eine* Sat-Ebene empfangen können und daher diesbezüglich synchronisiert werden müssen) "beissen" könnte. Zunächst wird es wohl darauf hinauslaufen, dass es in der Doku heissen wird "Bei der Verwendung von Multi-Fontend-Devices ist nicht garantiert, dass "Device-Bonding" funktioniert". Für mich war "Device-Bonding" (aka "LNB sharing") von jeher ein "ungeliebtes" Feature und ich habe es damals nur widerwillig eingebaut. Wenn es jetzt in diesem neuen Zusammenhang damit Probleme gibt, würde ich dazu tendieren, es tatsächlich wieder zu entfernen. Denn "Multi-Frontend Devices" sind wohl "here to stay" aber statt "Device-Bonding" gibt es heutzutage deutlich bessere Lösungen wie etwa Unicable.


    Dies nur mal als Randbemerkung, um vielleicht mal zu sehen, wie viele denn überhaupt (noch) Device-Bonding verwenden.


    Klaus

    Das"kann man" ist eigentlich durch "sollte man" zu ersetzten.

    Da man die einzelnen Frontends nur exklusiv zu verwenden kann, ist es besser sie hinter einem gemeinsamen Frontend zu verstecken.

    Mein "kann man machen" bezog sich darauf, dass TBS *zwei* Frontends anlegt, obwohl immer nur eines davon verwendet werden kann. Man sollte das aber eher *nicht* machen - was du vermutlich gemeint hast ;-).


    Klaus

    Vielleicht kann man aus den einzelne Frontends auch ein "Masterfrontend" erstellen, in dem die Delivery-Systems und fe.caps "aufaddiert" werden und in dem dann je nach Bedarf das richtige "Subfrontend" ausgewählt wird.

    Im Prinzip wird es darauf hinauslaufen.


    Klaus

    Ich habe gestern auf meine diesbezügliche Frage vom TBS-Support die Antwort erhalten:


    Ein Tuner hat zwei frontends einen für DVB-C/T und einen für DVB-S/S2
    Daher wird das Übertragungssystem nicht mit DTV_SET_DELIVERY_SYSTEM unterschieden.

    Das kann man machen, müsste man aber nicht. Schließlich wird zwischen DVB-T und -C auch mit DTV_SET_DELIVERY_SYSTEM umgeschaltet, also sollte das auch mit DVB-S und wer weiß was künftig noch alles kommen kann möglich sein. Einziger Grund, der für zwei Frontends sprechen kann ist, dass es halt wirklich zwei verschiedene Bausteine sind. Was aber letztlich keine Rolle spielt und genauso gut hinter DTV_SET_DELIVERY_SYSTEM hätte versteckt werden können, wenn man es denn den Applikationen einfach hätte machen wollen ;-).


    Aber gut, nehmen wir mal an, das wird sich nicht ändern. Wäre es dann eine zulässige Annahme, dass ein Adapter, der mehrere Frontends hat, diese dann und nur dann unabhängig voneinander (also gleichzeitig) verwenden kann, wenn es zu jedem frontendX auch ein zugehöriges caX, demuxX und dvrX gibt, und dass es, wenn von den Frontends immer nur *eines* exklusiv verwendet werden kann, nur genau *ein* ca0, demux0 und dvr0 und *keine* caN, demuxN und dvrN (N > 0) gibt?

    In letzterem Falle könnte VDR dann *ein* cDevice anlegen mit entsprechend vielen cDvbTunern und bei der Auswahl des Delivery-Systems halt noch eine Abfrage vorschalten, welcher der Tuner das DS liefern kann.


    Klaus

    beim Astrometa DVB-T2 USB Adapter kann von den 2 Frontends immer nur eines geöffnet sein. Deshalb schlägt derzeit DvbOpen für das Frontend1 (DVB-T2) fehl. Wird sich daran etwas ändern (DvbOpen nach Bedarf) ?

    Wenn ein Adapter zwei Frontends hat, dann wird davon ausgegangen, dass die auch *gleichzeitig* verwendet werden können. Ist dies nicht der Fall, dann darf der Treiber nur *ein* Frontend implementieren, das dann über DTV_SET_DELIVERY_SYSTEM entsprechend gesteuert wird. Siehe meine Anmerkungen hier.


    Klaus

    Es geht ja auch nicht darum, irgend einen Sender zu verwenden. Es wird genau der Sender verwendet, der live oder für eine Aufzeichnung genommen werden soll. Und mit dem wird geschaut, welches Device diesen empfangen kann. Wenn sich im System nur ein einziges Device befindet, welches z.B. DVB-T2 kann, dann ändert sich zum bisherigen Verhalten gar nichts. Gibt es mehrere Devices, die DVB-T2 können, so werden diese alle durchprobiert. Aber halt immer nur mit dem gewünschten Kanal. Genauso, wie es jetzt schon mit den CAMs gemacht wird. Wenn es mehrere CAMs gibt, die alle "behaupten", einen bestimmten Sender (aufgrund der CA-ID) entschlüsseln zu können, dann werden diese der Reihe nach durchprobiert, bis evtl. eines gefunden wird, das es tatsächlich kann.


    Klaus

    Bei den CAMs habe ich hierfür die Funktion "Activate" eingebaut. Damit bliebt das Device auf jeden Fall mit dem gewählten CAM auf den eingestellten Sender. Etwas Ähnliches kann man sicher auch für den von dir geschilderten Fall machen, so dass die Automatik vorübergehend stillgelegt wird. Wobei sie ja eh nicht greifen würde, wenn es in deinem System nur *ein* DVB-T2-Device gibt (was bei mobiler Anwendung ja eher wahrscheinlich ist).


    Klaus