Fix für GetDeviceForTransponder bei Device-Bonding und IPTV

  • HelmutB hat hier einen Fix für ein Problem bei der Device-Wahl mit IPTV gepostet und darin festgestellt, dass der Code im 'else if' Zweig nie ausgeführt wird, womit er vollkommen recht hat.


    Der Grund hierfür war ein "Fix", den ich damals hier gepostet hatte. Der war natürlich Quatsch, denn wenn MaySwitchTransponder() false ist, wird weder der 'if' noch der 'else if' Zweig ausgeführt, weil der Aufruf ja in beiden Bedingungen drin ist und sich das Ergebnis zwischen den beiden Aufrufen auch nicht ändert. Das Problem von damals trat damit nur einfach nicht mehr auf, weil die Auswahl des Devices über die Prioritäten ganz abgeklemmt wurde. Wie kamel5  hier richtig beobachtet hat, hatte sich durch den Patch das eigentlich beabsichtigte Verhalten bei VPS-Aufnahmen verändert. Es wurde, wenn alle Devices belegt waren, nicht mehr für eine höher priorisierte VPS-Aufnahme einige Zeit vor dem geplanten Beginn auf den entsprechenden Transponder geschaltet. Nachdem Device-Bonding für mich immer schon ein "ungeliebtes Feature" war und es damit aber ansonsten zu funktionieren schien, bin ich der Sache dann auch nicht weiter nachgegangen (siehe auch hier und hier).


    Anbei ein Patch, der zum Einen die Änderung von HelmutB enthält, dass immer das *erste* freie Device genommen wird, und zum Anderen im Falle von Device-Bonding die Prioritäten aller gebondeten Devices berücksichtigt. Damit sollten eigentlich beide Probleme gelöst und auch die Nebenwirkung bzgl. VPS-Aufnahmen behoben sein.


    Bitte testet diesen Patch ausgiebig, insbesondere kamel5 und dile .

  • Nachdem Device-Bonding für mich immer schon ein "ungeliebtes Feature" war und es damit aber ansonsten zu funktionieren schien, bin ich der Sache dann auch nicht weiter nachgegangen (siehe auch hier und hier).

    Mir wäre es auch lieber, wenn ich das nicht bräuchte, aber was soll man in einer Mietwohnung machen, wenn nur ein Anschluss bzw. zwei, wie bei mir, zur Verfügung steht. Deshalb vielen Dank dafür, das Du das nicht "ignorierst".


    Viele Grüße

    kamel5

    VDR 2.4.3: ASUS Prime X470-PRO, Ryzen 7 2700, 32GB, 6TB HD, GT630, Fedora 32 Kernel 5.6 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

  • kls , ich habe den Patch jetzt einige Zeit in Betrieb und leider ein paar Ungereimtheiten bzgl. Device-Bonding festgestellt.

    Ich muss das aber in den nächsten Tagen nochmal genauer untersuchen, ob es tatsächlich an diesem Patch liegt.

    Ich melde mich hier, sobald ich da ein Ergebnis habe.


    Viele Grüße

    kamel5

    VDR 2.4.3: ASUS Prime X470-PRO, Ryzen 7 2700, 32GB, 6TB HD, GT630, Fedora 32 Kernel 5.6 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

  • kls , ich habe heute mal ein paar Tests mit Plain-VDR und diesem Patch bzgl. Device-Bonding gemacht. Es ist tatsächlich so, das das damit nicht mehr richtig funktioniert. Mit dem Patch werden nicht mehr alle Devices zum Empfang von Kanälen benutzt, während gleichzeitig Aufnahmen laufen. Es werden dann nur noch Devices benutzt, die wenn ich es richtig verstanden habe, master sind. Anbei ein Log dazu. In der ersten Hälfte ohne Patch und in der zweiten Hälfte mit Patch.

    Meine Konfiguration ist dabei 2x2, also ein Kabel für tuner 0 und 1, sowie ein Kabel für tuner 2 und 3.


    Viele Grüße

    kamel5

    Files

    VDR 2.4.3: ASUS Prime X470-PRO, Ryzen 7 2700, 32GB, 6TB HD, GT630, Fedora 32 Kernel 5.6 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

  • Die Änderung an cDevice::Priority() hatte wohl zu viele Seiteneffekte, daher schlage ich folgendes vor:

    - für dvbdevice.[hc] und device.h wieder die Versionen aus 2.4.2 nehmen

    - in device.c den 'else if'-Zweig löschen:

    Damit bleibt lediglich der Fix von HelmutB , dass das erste Device genommen wird, welches den Transponder ohne Störung von Aufnahmen oder Live-View liefern kann. Da der 'else if' Zweig schon seit 8 Jahren nicht mehr aktiv war, hat er anscheinend niemandem gefehlt. Dieser Zweig sollte dafür sorgen, dass für eine anstehende VPS-Aufnahme der Live-Kanal umgeschaltet wird bzw. eine Aufnahme mit niedrigerer Priorität unterbrochen wird, falls kein freies Device verfügbar ist. So schaltet er halt zur Startzeit der Aufnahme "hart" um.

    kamel5 : kannst du bitte mit den genannten Änderungen bzw. Rückbauten nochmal testen?

  • kls : mit dieser Priority() ist man bei BondedDevices wirklich in der Zwickmühle weil es zwei Möglichkeiten gibt - bei einem Umschalten auf einen Kanal mit gleichen BondingParameter wäre es die tatsächliche Priority() des geprüften Device, bei einer Änderung der BondingParameter aber die höchste Priority() aller BondedDevices. Das lässt sich vermutlich ohne neue Seiteneffekte gar nicht so einfach umsetzten.


    Der "else if" Zweig könnte aber auch belassen werden wenn man nur BondedDevices davon ausschließt.

    LG

    Helmut

  • kls , mit den letzten Änderungen scheint es soweit noch zu funktionieren, zumindest konnte ich bisher keine Auffälligkeiten feststellen. Ich werde das die nächsten Tage weiter beobachten.


    Zur Vollständigkeit hänge ich hier meinen letzten benutzten Stand des Patches mal mit an.


    Viele Grüße

    kamel5

  • kamel5 es hätte mich ehrlich gesagt auch gewundert, wenn es sich damit anders verhalten hätte als früher, denn ob der 'else if' Zweig wegen der Bedingung, die immer false ist, nie durchlaufen wird, oder weil er ganz weggelassen wird, sollte keinen Unterschied machen.


    Aber HelmutB hat natürlich recht, warum sollen User mit nicht gebondeten Devices auf eine eigentlich gewollte Funktionalität verzichten müssen. Ich wollte zwar das Thema Device Bonding vollständig innerhalb cDvbDevice halten und es nicht in device.c haben, aber nachdem die Lösung durch ein einfaches cDevice::IsBonded() machbar ist, hab ich mich halt dazu durchgerungen.

    Anbei die hoffentlich endgültige Fassung dieses Fixes. Die Zeilennummern können etwas off sein, ansonsten sollte es aber passen.