Posts by mini73

    Moin!


    Nein, ein Plugin muss nicht Schuld sein, aber so könnte man es herausfinden. Sonst müsstest du den vdr auch einfach mal ohne Plugins laufen lassen. Wenn der Speicherverbrauch dann auch ansteigt, dann ist der vdr Schuld. Das wäre dann der Schritt, wenn man die Plugins ausgeschlossen hat. Aber man könnte auch damit anfangen.


    Es ist natürlich schwer, einen Fehler zu finden, wenn man das System eigentlich nicht wirklich anfassen kann.


    vdr 2.4.1 müsste seine Konfiguration aus /etc/vdr beziehen. Da müsste es ein conf.d-Verzeichnis geben, wo man dann einzelne Abschnitte deaktivieren kann.


    Viel Erfolg!


    Lars.

    Moin!


    Am besten mal die Hälfte der Plugins deaktivieren, um zu schauen, ob eins davon der Schuldige ist.

    Wenn nicht, dann von den übrig gebliebenen wieder die Hälfte deaktivieren.


    Ist der Speicherverbrauch dann nicht mehr so radikal, dann war bei der zuletzt deaktivierten Hälfte das gesuchte dabei. Da die Anzahl bei dir recht übersichtlich ist, eins nach dem anderen wieder aktivieren, bis es feststeht.


    Ist natürlich mit einem Produktivsystem nicht so einfach. Und der Speicherverbrauch scheint sich ja auch über Tage aufzuschaukeln, oder? Evtl. sonst mal ein Dev-System aufsetzen und versuchen, das Problem nachzustellen.


    Lars.

    TS-Pakete sind ja 188 Bytes, jedes mit einem kleinen Header.

    Wenn die in ein anderes Format mit größeren Paketen kopiert werden, gibt es weniger Header.


    Aber klar, irgendwelche Streams können auch weggelassen werden.

    Sind alle Audiospuren da?

    Sind noch andere Streams in den TS-Dateien? Keine Ahnung, was da noch sein könnte...

    Technisches Highlight bei mir: Kabelanschluss ist gekündigt... :)

    Nachdem ich schon ein paar Jahre kein Linear-TV mehr aufgenommen, geschweige denn geschaut habe, dachte ich mir, dass ich mir das auch sparen kann...


    Schön, mal wieder von dir zu hören!


    Lars.

    Hinkt der Vergleich nicht ein wenig?


    Bei der git-Variante kannst du den Feedback-Loop genauso weglassen wie beim diff. Und wenn man dann noch bedenkt, dass man einen Account nur einmal erstellen muss, gibt es eigentlich keinen relevanten Unterschied mehr.


    Und wo ist das Hochladen des Patches? Oder soll der nur für den Eigengebrauch sein? Wenn ja, dann kann das git commit/push natürlich genauso entfallen.

    Ich nutze git täglich - ich google auch regelmäßig nach Sachen, die ich nicht häufig mache.

    Wie bei jedem neuen Tool. das man erlernt, verbraucht man anfangs mehr Zeit dafür. Aber das gibt sich irgendwann. Wenn das Ziel aber eine "saubere Historie" ist, dann sollte man mit Branches arbeiten und beim Merge die Commits dann squashen, damit man einen "sauberen" Commit hat.

    Oder man committed halt erst dann, wenn man soweit ist - das ist Geschmackssache.


    Ich persönlich sehe auch kein Problem darin, wenn man mal was falsches eingecheckt hat, dass man das mit einem späteren Commit wieder bereinigt.

    Aber da darf jeder so arbeiten, wie er will. Man muss sich nur einig sein, wenn man zusammen an einem Repository arbeitet. Wenn da jemand einfach wieder Commits verschwinden lässt, die andere evtl. schon gepullt haben, dann handelt man sich mehr Ärger als nötig ein.

    "surround51:CARD=PCH,DEV=0" klingt ja nach einem Alsa-Hardware-Device, welches von PipeWire natürlich belegt ist.

    Ansonsten musst du mal herausfinden, was die Fehlermeldung "Der Rechner ist nicht aktiv" genau bedeutet.


    Lars.

    Einmal im debian-Verzeichnis nachsehen (oder in der dsc-Datei bei Launchpad):


    Build-Depends: debhelper (>= 9), libjpeg-dev, libcap-dev, dh-systemd, libncursesw5-dev, libfreetype6-dev, libfontconfig-dev, gettext, python3, linux-libc-dev (>= 3.0), libfribidi-dev, libsystemd-dev, bash-completion

    Das klingt nach ähnlichen Problemen wie mit Pulseaudio. Der Daemon ist im Grunde nur auf einen User ausgelegt und läuft in dessen Kontext.

    Wenn man verschiedene User Ton auf die gleiche Hardware ausgeben lassen möchte, dann muss man wohl eine systemweite Instanz davon laufen lassen.

    https://bbs.archlinux.org/viewtopic.php?id=265878


    Das war mit Pulseaudio auch schon nicht einfach, ich hab aber keine Ahnung, wie das mit PipeWire läuft - von dem Ding hab ich sowieso erst vor kurzem "aus Versehen" was gehört, weil Fedora das jetzt per default benutzt.


    Lars.

    Trotzdem kann ich durchaus nachvollziehen das man sich alles aus "std" in den globalen Namespace holt. Für mich ist das irgendwie "fester Bestandteil der Sprache C++" und wenn man diese Typen viel nutzt, dann wird das ständige "std::" irgendwann lästig.

    Ich verstehe dein Denken dahinter, aber "in echt" ist das halt immer etwas anders.


    Der vdr stammt aus einer Zeit, wo die STL sehr bescheiden war, insbesondere, was ihre Performance betraf. Auch wir bei mir in der Firma haben für unsere C++ Projekte damals (vor 20 Jahren) eigene String-Klassen usw. geschrieben, weil wir bestimmte Features brauchten, die die STL damals nicht geboten hat.

    Und auch wir haben das alles nicht in einem eigenen Namespace, weil es einfach nicht nötig war.


    Code entwickelt sich halt - und man muss ihn immer in seinem Kontext sehen.

    Der vdr benutzt nicht viele wirkliche C++ Features (nur ein wenig Klassen, Vererbung, Templates...) und vor allem einfach keine STL. Das muss man schon unterscheiden, auch wenn es bei anderen Sprachen (C#, Java, Python...) anders läuft und das Framework kaum von der Sprache zu trennen ist.

    Könnte man natürlich jetzt auch umdrehen und fragen: Warum hat der VDR nicht über den gesamten Code einen eigenen Namespace "vdr".

    Weil es nicht nötig war. :)


    In der "freien Wildbahn" ist vieles etwas pragmatischer als am "grünen Tisch". Und wenn man etwas zu einem Projekt beiträgt, dann muss man immer den Kontext des Projekts betrachten.


    Und selbst wenn alles in einem Namespace "vdr" wäre - ich vermute, es würde dann genügend Plugin-Entwickler geben, die dann "using namespace vdr;" benutzen würden, weil sie ja eine Menge aus diesem Namespace benutzen wollen würden. Und dann würde es sich wieder beißen...

    Insofern muss man dann abwägen, wie viele "vdr::" man im Gegensatz zu "std::" schreiben müsste. Ich würde es dann vorziehen, den Namespace in der Unterzahl dann nicht einfach per "using" einzubinden.


    Letztlich darf man aber immer machen, was man möchte, solange ads richtige dabei am Ende herauskommt.


    Lars.

    PulseAudio soll ja durch PipeWire abgelöst werden, also macht es vermutlich nicht mehr viel Sinn, jetzt noch PulseAudio-Unterstützung zu programmieren - vor allem, weil das auch nicht so einfach ist.


    Was genau benutzt du denn jetzt? PipeWire oder PulseAudio?

    Vermutlich wäre es am sinnvollsten, PipeWire zu benutzen und dann den vdr als "legacy alsa"-Programm dort anzudocken? Keine Ahnung, ob andere Programm das schon vernünftig unterstützen.

    https://wiki.archlinux.org/tit…#ALSA/Legacy_applications

    https://gitlab.freedesktop.org…running-alsa-applications


    Es macht sicherlich keinen Sinn, das PulseAudio-Alsa-Plugin zu benutzen, um dann PulseAudio auf PipeWire laufen zu lassen.


    Lars.

    Informatik an der Hochschule hat nicht immer den passenden Bezug zur Realität - nicht böse gemeint...


    Das funktioniert nämlich nur, wenn alle beteiligten Komponenten mit Namespaces arbeiten. Und auch dann kann man immer in diese Falle laufen, dass es Doppeldeutigkeiten gibt. Wenn man Glück hat, dann meckert der Compiler...


    Da der vdr-Code komplett ohne Namespaces ist, ist es dann immer so eine Sache, wenn man durch ein using den globalen Namespace mit Dingen füllt...


    Lars.

    Moin!


    Einfach mal das Readme genau lesen und sich die Beispiele für das dynamite-dummydevice [1] und pvrinput [2-5] ansehen, dann sollte hoffentlich klar werden, was mcli machen muss.


    Letztendlich ist es so, dass dynamite alle Device-Slots im vdr belegt (minus ein paar für Ausgabe usw.). Und wenn der vdr auf einen dieser Tuner zugreifen will, dann erstellt es im Hintergrund per "new" das entsprechende Device-Objekt des Plugins, welches dann alles initialisieren muss, was es so muss.

    Wenn nach Ablauf des Idle-Timeout niemand mehr auf das Device zugegriffen hat, dann wird das Plugin-Device-Objekt einfach per "delete" wieder gelöscht, also muss es im Destruktor alles aufräumen, als ob der vdr beendet wird.


    [1] https://github.com/flensrocker…lob/master/dynamite.c#L55

    [2] https://github.com/flensrocker…blob/master/device.h#L167

    [3] https://github.com/flensrocker…/blob/master/device.c#L20

    [4] https://github.com/flensrocker…blob/master/device.c#L284

    [5] https://github.com/flensrocker…lob/master/device.c#L1533



    Lars.