Ach so - konkret ist mein Problem, dass das OSD (dvbsddevice) nicht mit dem Bildaufbau hinterherkommt und der vdr nahezu unbedienbar ist. So ein Bildaufbau kann schon mal 5 Sekunden brauchen - schön zeilenweise.
Welchen Skin nutzt du denn? Die Bandbreite für das OSD ist bei den FF-Karten ja beschränkt, so dass man da animierten OSD-Inhalte wie Laufschriften eher nicht haben will.
wenn ich den vdr im Hintergrund starten will (vdr &), dann bleibt der hängen, wenn er kbdremote erzeugt.
muss ich den vdr für diesen Fall als daemon aufrufen ?
Welchen Sinn hat es denn einen Prozess im Hintergrund zu starten, wenn er von stdin lesen soll? Wenn das nur zum Testen ist und du noch andere Dinge in einer Shell erledigen willst, schalte auf ein anderes TTY oder nimm einen Terminal-Multiplexer wie tmux. Oder du schaltest die kbdremote ab, wenn du sie nicht benötigst.
wenn ich den vdr unter /usr/bin durch meinen selbst kompiliert ersetze, dann startet "service vdr start" den vdr, wartet aber auf irgendwas und bricht dann mit timeout den vdr wieder ab.
Das lässt sich aus der vdr.service Zeile 8 ableiten, worauf er wartet:
Behavior of
notifyis similar toexec; however, it is expected that the service sends a notification message via sd_notify(3) or an equivalent call when it has finished starting up. systemd will proceed with starting follow-up units after this notification message has been sent. If this option is used,NotifyAccess=(see below) should be set to open access to the notification socket provided by systemd. IfNotifyAccess=is missing or set tonone, it will be forcibly set tomain. Note that currentlyType=notifywill not work if used in combination withPrivateNetwork=yes.
Also muss der VDR mit Unterstützung für sd_notify kompiliert werden (vgl. https://projects.vdr-developer…/Make.config.template#n91 im Template für die Make.config) - wobei mir nicht klar ist, warum du nicht gleich die Quellen für das VDR-Paket nutzt, wenn du schon die Systemd-Unit daraus verwenden willst.
Wie übergibt das service-skript dem vdr die Parameter ?
Gar nicht, der VDR liest die Konfiguration selbstständig aus dem ARGSDIR - das sollte wie in der
/usr/share/doc/vdr/README.Debian.gz bzw. https://www.yavdr.org/documentation/0.6/de/ch01s06.html beschrieben funktionieren.
Was sagt denn vdr --showargs bei dir?
Bei meinem ION-System musste ich bei den neueren Kerneln nachhelfen und habe das mit einer Systemd-Unit gelöst:
Ich habe gestern mal die kürzere Variante der Udev-Regel, die auch Upstream gelandet ist, in das Paket eingebaut (das Paket bei Ubuntu/Debian nutzt aus irgendeinem Grund nicht die Udev-Regel, die im Quellcode mitgeliefert wird, sondern hat eine eigene Variante).
Ich sehe da Emergency-Exits - das passiert, wenn ein Tuner keinen Empfang hat, während eine Aufnahme läuft und man den "Notausstieg" nicht in den Einstellungen abgeschaltet hat.
Wenn die in https://patchwork.kernel.org/patch/9904169/ genannte Anpassung bei dir hilft, kann ich gerne ein angepasstes Paket für ir-keytable bauen.
Es wäre auch möglich dem VDR nur eine bestimmte Zahl von Tunern zuzuweisen und minisatip den Rest - dann könnten die Clients immer noch die unproblematischen Sender empfangen und die Problemkanäle holt man sich dann auf dem Umweg über den VDR.
ist folgendes Szenario mittels VDR denkbar,...minisatip ----> VDR -----> Dreambox?
Wenn man der Dreambox einen Stream vom Streamdev-Server unterschieben kann möglicherweise (das streamdev-Plugin ist leider schon einige Zeit ungepflegt und wird mit Patches am Leben gehalten - ich habe da schon mal von Hakeleien im Zusammenspiel mit der Entschlüsselung gelesen, wobei das z.T. so aussah, als ob da ein Tuner im System nicht zuverlässig Sender tunen konnte).
Am sinnvollsten wäre es IMHO den VDR direkt für die TV-Ausgabe zu nutzen (da hat sich in den letzten Monaten erfreulich viel bei den Ausgabeplugins getan, so dass man da mit einer halbwegs aktuellen Intel- oder Nvidia-Karte keine Probleme haben sollte, solange man kein 4k mit HDR braucht) - yavdr-ansible kann einem da bei der Vorkonfiguration des Systems einiges an Arbeit abnehmen) oder als zweitbeste Lösung den VDR über das vnsiserver-Plugin an KODI zu hängen.
Ich möchte einen VDR-Server betreiben, der mit einem CI modul umgehen kann und die Programme mittels
SatIP verteilt.
Der VDR selbst kann - wie schon von M-Reimer geschrieben - nicht SAT>IP Server spielen und mit dem satip-Plugin nur als Client für einen solchen Server (wie z.B. minisatip oder tvheadend) agieren. Soweit ich das gelesen habe beschränken die problematischen CI+ Karten, wegen denen du das ganze vermutlich auf dich nimmst, auch die Anzahl der gleichzeitig entschlüsselbaren Sender, so dass man da mit einer MAX S8 und einer CI+-Karte nur einen Bruchteil der Tuner für solche Sender nutzen kann.
1. Welche Distribution wäre denn für VDR- und Linuxanfänger besonders geeignet oder wäre es besser
ein normales Linux aufzusetzen und dann den VDR zu installieren?
So ganz ohne Wissen zu Linux dürften MiniDVBLinux oder EasyVDR (da am besten auf die kommende Version 4 warten) am besten geeignet sein, weil die die Details vor dir verstecken. Wenn man mehr Kontrolle haben möchte, aber nicht alles zu Fuß einrichten will, kann man Gen2VDR (da müsste man helau fragen, wie man da an einen Account kommt) oder yavdr-ansible nehmen. Wenn du mehr selber machen willst, kannst du z.B. ein Ubuntu 18.04 selber aufsetzen und die Pakete aus https://launchpad.net/~yavdr/+…/ubuntu/experimental-main und https://launchpad.net/~seahawk…+archive/ubuntu/vdr-2.4.1 nutzen. Damit hast du aktuelle VDR-Pakete und ein paar Extras wie ein aktuelles minisatip zur Verfügung.
Alternativ ginge auch Arch Linux mit den vdr4arch-Paketen, aber da liegt der Fokus mittlerweile mehr darauf den VDR als PVR-Backend für KODI zu nutzen.
Alles selber bauen geht natürlich auch, aber da ist man je nachdem welche Plugins man nutzen will z.T. recht gut beschäftigt sich Patches und Workarounds aus dem Forum hier zusammenzusuchen.
2. Sind in den fertigen Distributionen schon die Treiber für Digital Devices Satkarten enthalten?
Was für eine Karte hast du genau? Die Treiber für die meisten Karten sind mittlerweile im Kernel integriert, so dass man die OOTB nutzen kann, wenn der Kernel aktuell genug ist.
3. Wie installiere ich denn Plugins (z. B. SatIP), gibt es dafür Tutorials?
Entweder über die von der Distribution genutzte Paketverwaltung oder selber aus den Quellen bauen - wie das genau gelöst ist, hängt von der jeweiligen Distribution ab.
4. Wie installiere ich Patches, gibt es dafür Tutorials?
Patches werden üblicherweise mit patch auf den Quellcode angewendet und dann wird das Programm/Plugin damit kompiliert. Auch hier hängt das Vorgehen stark von der verwendeten Distribution ab, wie man das am bequemsten machen kann.
Ein Upgrade von trusty auf bionic? Das ist nun wirklich nicht vorgesehen - damit hast du auch noch die ganzen Template-Leichen von yaVDR 0.6 im System.
Wie startet frontend-dbus-send eigentlich die Apps aus den VDR Anwendungsmenü?
Das hatte ich hier schon mal erklärt: Ansible - OSD-Menüstruktur beeinflussen?
Da kommt wohl manchmal beim Start etwas durcheinander.
Ich meine das da im Fehlerfall bei ir-keytable das rc-5 Protokoll fehlte.
Sollte man den IR von der Budget-CI vielleicht besser ganz deaktivieren?
Mir ist nicht ganz klar, wie da etwas durcheinander kommen soll - immerhin sucht sich ir-keytable ja selbst für das angegebene Device die Keytable heraus (das wird über die udev-Regel /lib/udev/rules.d/60-ir-keytable.rules angestoßen). Aber probier es doch einfach aus, ob das etwas bringt. Ansonsten würde ich auch mal schauen, ob da irgendetwas aktiv ist, das versucht vom lirc-Geräteknoten zu lesen, der für serial_ir angelegt wurde (ich weiß ja nicht, was du gegenüber der Vorkonfiguration durch yavdr-ansible alles verändert hast).
Wo bringt man das in yaVDR am besten unter oder gibt es da schon was.
Ich denke, dass das am besten in einer udev-Regel aufgehoben sein dürfte (alternativ kann man auch eine Systemd-Unit nutzen, die von udev getriggert wird):
Wenn du Mount-Optionen vorgeben können willst und einen automounter für udisk2 suchst, könntest du dir mal https://github.com/coldfix/udiskie ansehen.
Den nutze ich auch bei yavdr-ansible.
Die betreffenden Tasten kann man selber beliebig festlegen (hier KEY_ZOOM und KEY_PROG2).
Das geht auch mit nur einer Taste, wenn man als Befehl frontend-dbus-send toggle nutzt:
Mich würde ja eher interessieren, warum da sporadisch nach dem Starten kein Bild kommt...
Wenn man 4x hintereinander den Power-Button des Rechners drückt, fährt er (ausgelöst von vdrpbd) am VDR vorbei geordnet herunter.
Früher gab es mal das yaVDR Web Frontend mit einem schön großen Reset Knopf. Der ließ sich im Notfall auch prima vom Handy aus drücken. Gibt es das bei yaVDR Ansible nicht mehr oder kann man das wieder installieren?
Das Webfrontend passt leider nicht mehr zum Unterbau.
Eine Webseite mit einem Reboot-Knopf ist schnell gebastelt - z.B. mit python3-flask:
Und dann den Webserver unter einem Nutzer (wie z.B. vdr) starten, der das System herunterfahren darf:
env FLASK_APP=reboot_web.py flask run --host=0.0.0.0 --port=5000
Wenn man will, kann man das auch hinter einem richtigen Webserver verstecken und eine Zugangskontrolle einbauen.
Mein Ansatz für das neue Webfrontend war ein REST-Backend zu haben, das dann von einer Single Page Application (oder beliebigen anderen Clients) genutzt werden kann - als Proof of concept sind damals https://github.com/seahawk1986/yavdr-backend und https://github.com/flensrocker/yavdr-webconfig entstanden (da ist u.a. auch schon die PAM-Authentifizierung mit Benutzerpasswort umgesetzt) - leider hatten mini73 und ich dann keine Zeit daran groß weiterzuentwickeln.
Wenn es jemanden interessiert, kann ich meine Notizen heraussuchen, wie man das mit nginx und gunicorn aufsetzen kann (eine Route für die Reboot-Funktion ist wie oben zu sehen schnell eingebaut).
Da für Ansible mit ansible-runner mittlerweile ein Python-Modul entwickelt wird, das eine langfristig stabile API verspricht, wollte ich mir das Backend für Ubuntu 20.04 noch mal ansehen, wenn alles brauchbar mit Python3 läuft.
Was steht denn in den Logdateien von KODI (/var/lib/vdr/.kodi/temp/kodi.log)?
Die Ausgabe ist auf 60Hz wegen dem TV.
Es ist selten, dass ein TV keine 50 Hz kann... - aber falls das wirklich der Fall ist, kannst du nicht viel mehr machen als den 60Hz-Modus in den Einstellungen von softhddevice zu aktivieren, um die Meldungen zu unterdrücken.
Nov 3 14:40:47 avdr vdr: [1438] frontend 2/0 timed out while tuning to channel 51 (kabel eins Doku), tp 610
Nov 3 14:40:47 avdr vdr: [1441] frontend 3/0 timed out while tuning to channel 6 (3sat HD), tp 626
Nov 3 14:40:47 avdr vdr: [1435] frontend 1/0 timed out while tuning to channel 39 (ANIXE SD), tp 538
Das sieht so aus, als ob nur ein Tuner Empfang hat - die Konstellation mag der VDR nicht wirklich, dadurch gibt es ständig Hänger.
Würde es helfen auf das softhdcuvid_hevc plugin umzusteigen?
softhdcuvid setzt eine ausreichend aktuelle Nvidia-Karte voraus, die CUVID unterstützt. Ich würde mal das "normale" vdr-plugin-softhddevice probieren.
