Beiträge von kls

Bedeutet das dann, dass nur eine Änderung in peerdemo nötig ist, und keine in VDR?

Klaus

I am currently working on a solution for this.

Klaus

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

Hab's gefunden.

Mein lokaler Webserver benutzt kein HTTPS, daher blockierte Firefox diesen "mixed content".

Wenn ich security.mixed_content.block_active_content auf false setze, dann klappt es!

Klaus

mini73 schrieb:

Gibt es auch für Firefox.

https://addons.mozilla.org/de/firefox/addon/redirector/

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

Wenn so eine umfangreiche proxy.pac funktioniert, sollte es mein simples Beispiel eigentlich auch tun.

Muss man noch irgend etwas Spezielles tun, das nicht offensichtlich ist?

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

(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

Bitte mal beide VDRs neu starten, die betreffende Aktion durchführen und mir dann die Logfiles ab dem Start der VDRs schicken.

Das Ganze bitte mit der original VDR Version 2.4.0 (am besten mit den Patches von ftp://ftp.tvdr.de/vdr/Developer/Patches/vdr-2.4) und ohne Plugins (ausser denen, die für den Empfang bzw. die Wiedergabe unbedingt erforderlich sind).

Klaus

Der Patch ftp://ftp.tvdr.de/vdr/Develope…07-fix-disabling-mtd.diff sorgt dafür, dass MTD abgeschaltet wird, wenn ein nicht-MTD-fähiges CAM eingesteckt wird, nachdem vorher ein MTD-fähiges benutzt wurde.

HelmutB schrieb:

Ich meinte eigentlich mein eigenes "kann man"

Sorry, das hatte ich dann falsch verstanden ;-).

Da gebe ich dir natürlich recht.

Klaus

HelmutB schrieb:

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

HelmutB schrieb:

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

HelmutB schrieb:

ich habe gedacht, es sollen wie jetzt bereits beim Start von VDR alle Adapter geprüft werden

Natürlich sollen sie das auch weiterhin. VDR muss ja wissen, welcher Adapter was kann.

Klaus

HelmutB schrieb:

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