Posts by mini73

    Müsste nicht bei jeder neuen Aufnahme ein Recording(-Info)-Objekt erstellt werden? Aber das wäre nach einem Neustart immer noch genauso groß wie vorher.


    Ich könnte mir auch am ehesten vorstellen, dass irgendwas im Schedules/Events nicht korrekt "vergessen" wird bzw. dort zu viele Objekte vorgehalten werden, die eigentlich nicht mehr gebraucht werden.

    Ich würde WLAN deaktiveren. Wozu ist das gut?


    Der Rechner hat zwei IPs im gleichen Netzwerk. Ich kann mir vorstellen, dass die Pakete mal über das eine Interface und mal über das andere rausgehen. Und wenn das WLAN genutzt wird, ist es langsam.


    Viele Programme sind nicht darauf ausgelegt, über eine bestimmte IP raus zu gehen. Dann kann es passieren, dass du durch die "zu kleine Tür" musst.

    Wenn zwei Computer über zwei Wege miteinander verbunden sind, kann es durchaus Probleme geben.


    Was zeigen denn "ip addr show" und "ip route list"?

    Du könntest beim new und delete den Pointer protokollieren und anschließend die Listen vergleichen. Wenn dann ein Pointer beim delete fehlt, ist es ein Leak. Sowas müsste aber libleak und Konsorten eigentlich finden.

    Es gibt zwei Gründe für steigendes Speichervolumen:


    - Ein Leak, weil ein Pointer "vergessen" wird, ohne ihn freizugeben.

    - Eine Datenstruktur, die immer mehr Daten sammelt und größer wird, aber kein Leak im klassischen Sinne ist, weil immer noch ein Pointer irgendwo aktiv ist und jeder Block noch bekannt ist. Das werdet ihr mit sowas wie Valgrind und Konsorten nicht finden. Da hilft nur regelmäßiges protokollieren.


    Kandidaten für den zweiten Fall sind Listen usw. der Events, Schedules, Recordings, Channels...

    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...

    Es gibt DVB-Karten, die z.B. ein T- und ein S-Frontend haben, von denen aber immer nur eins exklusiv geöffnet werden kann. Wenn ich mich richtig erinnere, unterstützt der vdr das seit 2.4.1. Das zog einige Änderungen an cDvbTuner usw. nach sich, genau an den Stellen, wo der Patch auch eingreift. Ich hatte mit dem Patch schon angefangen, dann aber keine Zeit mehr, es zu Ende zu bringen.

    Deshalb wird der noch nicht richtig funktionieren.


    Ich weiß nicht, was die Aversion gegen udev soll. Das ist so ziemlich in jeder Distribution vertreten, es ist nichts exotisches. 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.


    Und natürlich würde ich den Patch genauso einreichen, wie alle anderen Anpassungen, die ich gemacht habe. Und wenn Klaus das für gut befindet, hab ich Glück gehabt. Wenn nicht, dann eben nicht.

    Der beta-Patch ist bzgl. Multi-Frontend nicht fertig. Da war bisher keine Zeit.


    Ich würde das ganze Ding sowieso eher einstampfen und in einen einfachen Patch umwandeln wollen, der nur das macht, wofür dynamite eigentlich gestartet wurde: dvb-devices nach dem Start per udev erkennen und einbinden und genauso zur Laufzeit wieder aushängen können. Ich finde, das ist ein wichtiges Feature, welches dem vdr noch fehlt. Die devices sind noch viel zu statisch.

    Weil es da schon ein paar gravierende Änderungen im Bereich der DVB-Karten mit mehreren, nicht gleichzeitig zu benutzenden Frontends gibt. Der alte dynamite-Patch passt da nicht so einfach drauf.


    Und einfach nur einen diff irgendwie auflösen, dass er kompiliert, hat in meinen Augen nichts mit verantwortungsvoller Programmierung zu tun.


    Der Source ist da und unter GPL, ihr dürft damit machen, was ihr wollt. Aber auf eigene Verantwortung.


    wirbel einfach mal ins Readme schauen, dann kann man lesen, was es tut und entscheiden, ob man es braucht.

    dbus2vdr hat die betroffene Funktion nicht benutzt. Es hat aber den ReadLock auf die Recordings gehalten, als es cControl::Shutdown aufgerufen hat. SVDRP gibt davor explizit den Lock frei, weil das wohl so sein muss laut Kommentar. Das macht dbus2vdr jetzt auch.

    Mit vdr 2.4.2 und neuem dbus2vdr sollte es an der Stelle hoffentlich keine Probleme mehr geben. Aber das Augabeplugin kann natürlich auch noch ein verstecktes Problem haben.