Posts by mini73

    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.

    Ich hatte mit dem Patch angefangen, ihn aber nie zu Ende programmiert. Ich hab meinen vdr seit Ewigkeiten nicht mehr gestartet...


    Es gab Änderungen in cDvbDevice wegen Geräten, die mehrere Frontends anbieten, von denen immer nur eins genutzt werden kann (Hybrid-Karten mit S/T). Da sind dann ein paar Funktionen dazugekommen, die ich mit dem Patch schon selbst implementiert hatte (Schließen/Öffnen des Device). Dadurch muss der ganze Code an der Stelle komplett überarbeitet werden. Hab ich bisher einfach keine Zeit gefunden, und ich weiß auch nicht, ob ich dafür irgendwann Zeit finden kann.


    Ich würde am ehesten ganz von vorne anfangen und SVDRP-Befehle für das Schließen eines dvb-devices einbauen und automatisches wieder öffnen, sobald es benutzt wird. Direkt im vdr ohne Plugin. Dynamite hat quasi jedes Device mit einem Proxy-Device ersetzt, damit es eine Chance hat, sich in die Kommunikation zwischen vdr und device einzuhängen und je nach Zustand dann dem vdr zu sagen "device ist nicht verfügbar" bzw. das Device dann einfach wieder zu öffnen.


    Sowas würde ich heute eher weglassen und mich auf die eine Aufgabe konzentrieren: Device schließen (auf Befehl oder nach irgend einem Timeout) und wieder öffnen, wenn es gebraucht wird. Dazu einfach mal einen älteren vdr und den passenden Patch begutachten, was und wo da was passiert. Sollte eigentlich mit etwas Zeit machbar sein.


    Lars

    Das ist ein übliches Timing-Problem. Die Hardware wird parallel zu den verschiedenen Diensten initialisiert. Wenn ein Dienst eine spezielle Hardware beim Start braucht, muss man das Init-System dafür benutzen, diese in der richtigen Reihenfolge zu starten.

    Gerade USB-Sticks sind manchmal etwas lahm bei der Initialisierung.

    Als Grund für den festen UDP-Port kann ich mir folgendes vorstellen:

    Die vdr sollen sich ja in einem Peer-to-Peer-Netzwerk selbstständig finden. Deshalb wird ein UDP-Broadcast auf einem festen Port gesendet. Wenn jeder vdr auf einem anderen UDP-Port lauschen würde, müsste es für jeden Port einen Broadcast geben. Es ist in so einem P2P-Netzwerk nicht vorgesehen, dass auf einem Peer der Dienst mehrfach läuft.


    Lars.