Posts by mini73

    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.

    Ich komme sehr gut sowohl mit Windows als auch Linux zurecht. Das sollte nur ein Scherz sein, deswegen der Smiley...

    Und auch unter Windows hilft mir regelmäßig ein Rebuild meiner Programme. Und auch unter Linux braucht es manchmal einen Reboot, wenn irgendwas arg festklemmt. Weil es meistens einfach schneller geht, als irgendwie zu gucken, was ich wo an Dienst neustarten muss.


    Aber ich will nicht weiter abschweifen, das hat nichts mit dem Problem dieses Threads zu tun.


    Schade, dass das Neubauen nicht geholfen hat.


    Ohne skindesigner gibt es keine Crashs? Vielleicht gibt es irgendwo noch falsches Locking?

    Hast du mal alles komplett neu übersetzt, insbesondere die Plugins zusammen mit dem vdr? Nicht, dass die sich in irgend einer Struktur uneinig sind über die Auslegung und die falschen Bits manipulieren.

    Am besten das System auch mal nach alten Include-Dateien durchsuchen und diese bereinigen, damit wirklich alles (vdr und alle Plugins) aus den gleichen Stand kompiliert wurden.

    Moin!


    Ich war in letzter Zeit (naja, seit ein paar Jahren) ja nicht mehr so wirklich aktiv in Sachen vdr. Ich schaue hier im Portal schon noch regelmäßig rein, lese aber nicht mehr viel. In erster Linie kümmere ich mich um die (zum Glück seltenen) Spam-Meldungen und ab und zu lese ich ein wenig mehr, falls es mir interessant erscheint.


    Jetzt hab ich aber endlich meinen Kabelanschluss gekündigt und werde die 17€ pro Monat in irgendwas anderes investieren. TV hab ich sowieso schon seit Jahren nicht mehr gesehen, weder Live noch aufgezeichnet. Nachdem Big Bang Theory endlich durch war (die letzten Staffeln hab ich dann sowieso über Prime oder Netflix gesehen) und bei uns im Haushalt sowieso nur Video on Demand läuft, macht es für mich einfach keinen Sinn mehr, noch einen Fernsehanschluss zu bezahlen...


    Noch hab ich aber keine Lust, die Verkablung im Haus zu entfernen, mal sehen, was mir für das Kabel noch einfällt. Vielleicht kommt in ein paar Jahren ja endlich der Glasfaseranschluss (unsere Stadtwerke bauen nach und nach die ganze Stadt aus) und vielleicht kommt da ja wieder ein TV-Signal rein. Ist ja auch relativ egal. Ich weiß gar nicht, ob es überhaupt noch irgendwo was interessantes im Fernsehen gibt... :)


    Nur so viel zu meiner aktuellen Situation...


    Ich hab "dynamite" noch auf dem Schirm, ich muss den Patch mal ins Repository übernehmen. Sinnvoller fände ich aber, wenn der vdr nativ "hotplug" bei den Devices unterstützen würde (eins der letzten statischen Arrays im vdr), mit einem ähnlichen Lock-Mechanismus wie bei Channels und Recordings. Dann kann man da vielleicht mal ein sinnvolles udev-Plugin bauen, welches nicht gleich so viel machen muss, sondern einfach nur Devices zur Laufzeit ein- und aushängen kann. Und parallel dazu ein "energy-saver"-Plugin, welches dann hotplug-fähige Devices nach einer Weile Nichtnutzen "schlafen" legen kann.

    Leider bin ich nie dazu gekommen, diese Sachen mal ernsthaft anzugehen, mein Berufsleben hat leider einen viel zu großen Anteil an meiner Freitzeit... :P

    Und mein Interesse ist auch viel mehr in Richtung Webentwicklung gegangen (Asp.Net Core & Angular, falls mal jemand darüber labern will...).


    Ich bin also immer noch hier, nur jetzt offiziell auf Sparflamme.


    Lars.