Posts by mini73

    Tipp: wenn du nicht weißt, in welchen Thread es gehört, dann ist es vermutlich ein eigener. Wir müssen mit denen nicht sparsam sein... :)

    Ist die Bedeutung von vdr-abi bekannt?


    Grob erklärt: immer, wenn sich öffentliche Teile des vdr ändern, die Plugins brauchen (z.B. Header), muss der Paket-Maintainer die vdr-abi-Version anpassen, damit der User nicht Plugins installieren kann, die nicht zum installierten vdr passen.


    Wird nun ein neues vdr-Paket gebaut, dauert es eine Weile, bis alle Plugins nachgezogen und gegen das neue vdr-Paket gebaut wurden. In dieser Zeit kann man kein Update machen, weil nicht alle Pakete zusammenpassen. Genauso kann man dann nicht mehr gepflegte Pakete erkennen.


    Wenn man sich darüber hinwegsetzt, lässt man Programmteile aufeinander los, die sich über die binäre Struktur ihrer Klassendefinitionen usw. uneins sind und damit die lustigsten und nicht so lustigen Verhaltensweisen auslösen. Undebugbar.


    Wenn also ein Plugin nicht zum vdr passt, wurde es entweder beim Neubauen der Plugins vergessen und es muss einfach nur neu gebaut werden (geht auch lokal), oder es wird nicht mehr gepflegt und sollte dann auch nicht mehr benutzt werden.


    Da hilft eine Nachfrage beim Paket-Maintainer oder man wird einfach selbst zu einem: PPA anlegen, vdr-Paket kopieren, warten, bis es gebaut wurde, dann die benötigten Plugins kopieren.


    Lars.

    Die Recording-Info ließe sich leichter abwärtskompatibel ändern, da sie ja zeilenweise aufgebaut ist und man nur einen neuen Buchstaben vergeben muss. Dabei weiß ich jetzt nicht genau, ob ältere vdr-Versionen unbekannte Buchstaben ignorieren und beim Schreiben wieder in die Datei einfügen.


    Die timers.conf hat pro Zeile einen Eintrag, bei dem die Felder mit Doppelpunkt getrennt sind. Deshalb lässt sie sich nicht erweitern. Denkbar wäre, sich ein neues Format auszudenken, was ähnlich der Recording-Info ist und sich damit leichter in der Zukunft um neue Felder erweitern ließe. Das macht aber einen Wechsel zwischen vdr-Versionen schwierig. Natürlich könnte ein neuerer vdr beide Dateien schreiben, müsste beim Einlesen aber prüfen, ob die alte timers.conf neuer ist als die neue timers.xxx, falls eine ältere Version sie verändert hat.


    Dazu kommt, dass es evtl. auch externe Tools gibt, die diese Datei bearbeitet, keine Ahnung.

    Für mich wäre ein Wechsel des Dateiformats aber ok, wenn es dann z.B. einen vdr 3.x gäbe, damit klar ist, dass es keine Abwärtskompatibilität gibt. Man muss ja nicht jede Designentscheidung von vor 20 Jahren als gesetzt sehen. Ab und zu darf man sowas auch mal überdenken. :)

    Da wurde schon mal drüber diskutiert und beim letzten mal wurde die Idee von Klaus verworfen.


    Intern braucht der vdr keine Id, da für jede Aufnahme, Event, Timer usw. ein Objekt im Speicher gehalten wird, welches der vdr benutzt.


    Problem ist bei einer neuen UUID aber auch, dass alte Aufnahmen usw. erst mal gar keine haben, d.h. die müssten erst mal alle eine bekommen, was dann bei readonly-Archiven ein Problem ist. Und es würde sich die Struktur der Recording-Info, der timers.conf usw. ändern, d.h. es gäbe da keine Abwärtskompatibilität.


    Ist also nicht "mal eben so".


    Machbarer wäre wohl eher, den ein oder anderen Aufnahme-SVDRP-Befehl fit zu machen, dass es mit dem Pfad umgehen kann. Das ist ja quasi eine UUID der Aufnahme, die sich eben nur ändert, wenn die umbenannt wird.

    dbus2vdr hat seine eigene Liste an Aufnahmen. Die "Id" einer Aufnahme ist leider nicht das, was man bei einer Id erwartet. Richtig schön wäre es, wenn es in der Recording-Info eine uuid gäbe, die sich in der Lebenszeit der Aufnahme nie ändert und auch Neustarts des vdr überlebt.

    Man kann zwar SVDRP zum Verschieben von Aufnahmen benutzen, muss man aber nicht. Du kannst ja auch ganz normale Dateioperationen benutzen.


    Schade ist auch, dass MOVR nur die Id benutzt (die sich zwischen LSTR und MOVR ändern kann, falls der vdr zufällig neustartet). Die einzig zuverlässige Id einer Aufnahme ist ihr aktueller Pfad.

    Sundtek legt keine "richtigen" dvb-devices an, weshalb sie sich mit anderen Kerneldevices überlagern können (so war es jedenfalls früher, das ist ja ein Userspace-Treiber).

    Es hilft, wenn man über die /etc/sundtek.conf eine passende Adapternummer vorgibt, so dass sich User- und Kerneltreiber nicht in den Weg kommen.

    Wir haben mal ein Python-Api-Backend angefangen, dass per dbus mit dem vdr kommuniziert. Dazu dann ein Frontend in Angular. Das ist aber mangels Freizeit wieder eingeschlafen. Das meiste macht man jetzt ja auch eher über das Playbook, oder?

    Ich kenne mich zu wenig mit dem Container aus, aber irgendwas wird dafür sorgen, dass es seine Verbindung zum dbus-Daemon nicht behalten kann, weshalb es versucht, eine neue Verbindung herzustellen.


    Läuft da ein dbus-daemon oder ist das kdbus und wie ist das Ding konfiguriert? Da musst du dich mal schlau machen...