Vorbereitung 2.4.1

  • Wow, was für eine Diskussion.


    Was mich betrifft wird da nix gestöpselt, es geht nur darum dass nach einer idle Zeit das device halt wieder freigegeben wird. Und das funzt auch mit dem Patch für 2.4.1 nach wie vor prima. Und meiner Meinung nach ist es längst überfällig dass sowas im vdr ootb funktionieren würde. TVHeadend hat sowas beispielsweise von Hause aus drinne

    Kodi 18.7 & 19.0a1 @ openSUSE 13.1 x86_64 - Asus E35M1-I DELUXE | 8GB Ram | 250G 2.5" HD
    Kodi 19.0a1 on 1st Raspberry Pi B @ XBian | Kodi 19.0a1 on Raspberry Pi 3 @ XBian | Kodi 17.6 on SolidRun i.MX6 @ XBian
    VDR 2.4.1 with Dynamite, Epgsearch, Live, Streamdev-server, Vnsiserver and Wirbelscan Plugin on Cubieboard2 @ Debian Stretch

  • Hi,

    Imho wissen die meisten Udev-Gegner nicht so recht was es macht und kann.

    Es ist schon ein geniales Stück Software.

    Ich habe schon mehrfach die libudev im professionellen Umfeld eingesetzt. Hat jedes mal viel Zeit gespart. Aber es gab oft Diskusionen mit Kunden und Kollegen....

    Grüße, Dieter :-)

  • Quote

    Und es geht nicht so sehr um das Abziehen eines usb-dvb-Sticks, der in Benutzung ist, sondern um das nachträgliche Anstöpseln eines solchen. Oder um solche Karten, die bei der Initialisierung so lange brauchen und der vdr schon lange gestartet sein könnte. Damit man keine Verrenkungen mehr machen muss, um den Start des vdr künstlich zu verzögern.


    Das ist alles? Deswegen braucht man eine weitere lib anstelle einfach nur cDvbDevice::Initialize zu modifizieren und damit von Zeit zu Zeit auf neue Einträge in /dev zu testen.

  • Hi,

    Na ja und Strom sparen bei längerer Nichtbenutzung von Devices führen manche noch an.

    Mfg Stefan

    Test-VDR1: HP rp5700 Fertigsystem, Core2Duo E6400, 2GB RAM, FF-SD C-2300, nvidia Slim-GT218 x1 | easyVDR 2.0 64Bit
    VDR3: in Rente

    VDR4: MSI G31M2 v2, Digitainer2-Geh., t6963c 6" gLCD, E5200, 2GB, 3TB WD Red, GT730, 2x TT S2-3200; easyVDR 3.5 64bit
    VDR5: Gigabyte
    GA-G31M-S2L, Intel E2140, Zotac GT730 passiv, Digitainer2-Geh., t6963c 6 " gLCD, 2 TB WD Red, 2x TT S2-3200 (an 1 Kabel) easyVDR 3.5 64bit
    VDR6:
    Intel E5200, GT630 passiv, F1 750 GB, t6963c gLCD, 2x TT S2-3200 | easyVDR 3.5 64bit
    VDR-User #1068
    www.easy-vdr.de

  • Ich reagiere lieber auf Events als immer wieder zu pollen.


    libjpeg, fontconfig usw. stört dich auch oder sind diese Abhängigkeiten ok? Warum sind einige Abhängigkeiten ok und andere nicht? Wofür sind solche libs denn sonst da, wenn man sie nicht genau für den Zweck nutzt, für den sie gedacht sind? In diesem Fall geht es um eine Benachrichtigung, wenn sich was an den Devices ändert.


    Aber egal, wir werden uns da nie einig...

  • für diejenigen, welchen diese libs *brauchen*.


  • Das ist alles? Deswegen braucht man eine weitere lib anstelle einfach nur cDvbDevice::Initialize zu modifizieren und damit von Zeit zu Zeit auf neue Einträge in /dev zu testen.

    Sieht für mich nach einem NIH-Problem aus.


    Mein Informatik-Dozent an der Uni hat stets darauf bestanden das die Nutzung einer Bibliothek, bzw. von bestehendem Code immer besser ist als selbst von Null an neu anzufangen. Vorausgesetzt natürlich die Lizenz der Bibliothek ist zu meinem Projekt kompatibel. Diese Bibliothek ist im Idealfall schon in anderen Projekten im Einsatz und ist entsprechend zu dem Zeitpunkt, wo ich mich für die Nutzung entscheide, oft schon recht umfangreich getestet und optimiert. "libudev" ist faktisch für jede halbwegs moderne Linux-Distribution ein Pflicht-Standard. Ein moderner Desktop läuft nicht mehr ohne. Von daher sehe ich das Problem nicht.


    "Stromsparen" ist mir persönlich relativ egal, aber weil ich da selber für Arch dran rumgebastelt habe kann ich sagen, dass "VDR starten wenn alle DVB-Devices da sind" gar nicht so einfach ist. Man kann nur schwer mit Sicherheit sagen wann denn nun alle Devices da sind. Eigentlich geht das aktuell nur in der Form das ein Benutzer die Anzahl an Devices, die da sein muss, irgendwo hart einstellt und man dann über udev (ja, ich weiß) und systemd den Start so verzögert bis diese Anzahl von Devices beim Betriebssystem angemeldet wurde.


    Wenn es aber jetzt schon faktisch nicht ohne udev geht, aber voraussetzt das der VDR-Benutzer irgendwo einträgt wie viele Devices vorhanden sind für das harte Verzögern des Starts könnte man doch auch udev in den VDR einbauen wenn man es dann damit schafft dem Benutzer diese Vorwahl einer Tuner-Anzahl zu ersparen. VDR ist auch mit allen Bemühungen nicht ganz so trivial aufzusetzen wie z.B. tvheadend. Wenn man hier einen Konfigurationsschritt sparen könnte wäre das definitiv ein Gewinn.

  • Um hier noch etwas mehr Stimmung zu machen: ;)

    Ich habe aktuell immer noch einen vdr-2.4.0 (yavdr-ansible-bionic) im Einsatz, eben wegen dem dynamite-Plugin.

    Ich nutze das dynamite-Plugin vorallem, um zur Laufzeit des VDR verschiedene Tuner problemlos und ohne einen Neustart aus- und auch wieder einhängen zu können. Und das klappt mit dem dynamite-Plugin perfekt.


    Ein Umstieg auf einen Produktiv- VDR > 2.4.0 kann und werde ich deshalb auch erst vollziehen, wenn es auch für die aktuelleren VDRs eine solche Möglichkeit gibt, um verschiedene DVB-devices ein- und auszuhängen. :)