Posts by seahawk1986
-
-
Man kann sich ggf. mit dem printf Kommando für find das Leben etwas leichter machen und numfmt lässt sich sagen, welches Feld es beackern soll:
-
Versuchst du das über die VDR-eigenen Mechanismen oder über epgsearch - falls letzteres: ist dein epgsearch-Plugin mit Unterstützung für PCRE gebaut worden?
-
Ist das ein focal oder VDR 2.4.8 spezifischer Patch? Läßt sich der in den Plugin-Sourcecode mit übernehmen?
Der Patch gleicht aus, dass es da noch kein #include <algorithm> für neuere gcc-Versionen in der tools.h von älteren VDR-Versionen gibt:
Diff
Display MoreIndex: vdr-plugin-tvguideng-0.3.4/helpers.c =================================================================== --- vdr-plugin-tvguideng-0.3.4.orig/helpers.c 2023-11-14 15:33:47.000000000 +0100 +++ vdr-plugin-tvguideng-0.3.4/helpers.c 2023-11-21 14:47:23.024126271 +0100 @@ -1,3 +1,4 @@ +#include <algorithm> #include <sstream> #include <vdr/osd.h> #include <vdr/plugin.h> Index: vdr-plugin-tvguideng-0.3.4/timemanager.c =================================================================== --- vdr-plugin-tvguideng-0.3.4.orig/timemanager.c 2023-11-14 15:33:47.000000000 +0100 +++ vdr-plugin-tvguideng-0.3.4/timemanager.c 2023-11-21 14:50:39.268133184 +0100 @@ -1,3 +1,4 @@ +#include <algorithm> #include <time.h> #include <vdr/tools.h> #include "config.h" @@ -170,4 +171,4 @@ stopUnion = stop; } return new cTimeInterval(startUnion, stopUnion); -} \ No newline at end of file +} Index: vdr-plugin-tvguideng-0.3.4/recmanager.c =================================================================== --- vdr-plugin-tvguideng-0.3.4.orig/recmanager.c 2023-11-14 15:33:47.000000000 +0100 +++ vdr-plugin-tvguideng-0.3.4/recmanager.c 2023-11-21 14:53:53.508140026 +0100 @@ -1,3 +1,4 @@ +#include <algorithm> #include <vdr/menu.h> #include "services/remotetimers.h" #include "helpers.h"
-
Ah moment, da hatte ich noch die falsche Adresse für das Upstream-Git - jetzt sollte es passen - zumindest für jammy, unter focal und dem VDR 2.4.8 gibt es mal wieder den Spaß mit dem dem fehlenden #include <algorithm> für std::replace ... - da kommt es gleich noch mit Patch
-
Die GT 630 Gen 2 unterstützt soweit ich weiß kein CUVID aka NVDEC fürs Dekodieren: https://developer.nvidia.com/v…de-gpu-support-matrix-new, damit macht das vdr-plugin-softhddevice-cuvid keinen Sinn.
Bei Fehlern in den einzelnen Frames müsste man mal schauen, ob man das mit Empfangsstörungen oder Lastspitzen korreliert.
Beim Umschalten hängt es an den Einstellungen von softhddevice, wie es Bild und Ton handhabt - am sichersten ist es die Buffer für Audio und Video komplett zu leeren, dann dauert das Umschalten aber länger. Beim Ton würde ich AV Sync Start mit der Einstellung "early audio" versuchen.
-
Ist unterwegs.
-
Musste mit erschrecken feststellen das die eingebundenen PPAs trotzdem focal sind...
Wenn ich das richtig im Kopf habe, werden die bei einem do-release-upgrade nur vorübergehend deaktiviert, aber nicht endgültig entfernt - das müsste man also selber machen: https://wiki.ubuntuusers.de/Pa…halten/PPA/#PPA-entfernen
-
- No package matching 'python3-kmodpy' is available (manuell editiert -> ./roles/yavdr-common/tasks/configure_system.yml)
- No package matching 'yavdr-i18n' is available (Lösung hier)
Das spricht dafür, dass du das PPA https://launchpad.net/~seahawk…archive/ubuntu/jammy-main nicht eingebunden hast - der focal-Branch zeigt standardmäßig auf die PPAs für focal.
Zum Rest: was sagt apt policy vdr-plugin-softhdcuvid?
-
osd2web agiert als Skin-Plugin - und es kann immer nur einen aktiven VDR-Skin bzw. VDR-OSD geben. Aber man kann den Skin zur Laufzeit ändern (z.B. über das Monitor-Symbol am mitgelieferten Web-Client, ansonsten gibt es da auch noch SVDRP-Befehle, so dass man das z.B. mit dem Umweg über irexec über die Fernbedienung umschalten könnte).
Mir ist auch nicht klar, was der Vorteil davon ist, das Menü auf beiden Bildschirmen gleichzeitig darzustellen - wenn der TV aus ist, kann man osd2web auf dem zweiten Bildschirm zur Darstellung des VDR-Menü nutzen, wenn der TV an ist, nimmt man das VDR-OSD.
Wenn ich nur osd2web verwenden würde, gibt es eine Möglichkeit, osd2web zu beschleunigen? Oder liegt das an meinem System?
Ich hatte mal einen alternativen Client für das Plugin mit Python, kivy und twisted gebastelt - dabei ist mir aufgefallen, dass die Ausgabe deutlich verzögert ist, wenn es mehrere aktive Clients gibt und mindestens einer davon der mitgelieferte Web-Client ist. Meine damalige Implementierung mit twisted und autobahn für die asynchrone Kommunikation über den Websocket kann den Port für die Verbindung nicht teilen, so dass es nur eine Instanz pro System geben darf, aber außer einer kleinen Latenz zwischen den beiden Systemen (localhost ist erwartungsgemäß schneller als andere Rechner im Netzwerk) leidet die Schwuppdizität nicht besonders, wenn es mehr als einen Client gibt - das ist ein screencast von einem zweiten Client, der im Netzwerk hängt (auf dem VDR läuft währenddessen ebenfalls eine Instanz der Programms) - es gibt eine gewisse Verzögerung zwischen Tastendruck und Menü-Änderung, aber das fühlt sich noch halbwegs akzeptabel an:
External Content youtu.beContent embedded from external sources will not be displayed without your consent.Through the activation of external content, you agree that personal data may be transferred to third party platforms. We have provided more information on this in our privacy policy. -
Der X-Server kann nicht mit HDR umgehen - aktuell klappt soweit ich weiß nur softhddrm mit Intel-IGPs/GPUs ohne laufende GUI.
Für Wayland steckt die HDR-Unterstützung noch in den Kinderschuhen und man bräuchte Ausgabeplugins, die das dann eines Tages tatsächlich ausnutzen.
-
würde es nicht reichen, den neuesten Nvidia-Treiber zu installieren und nur die yavdr-xorg-Rolle aus dem Playbook laufen zu lassen ?
Ja, das sollte es auch tun.
-
Wenn du das Playbook erneut laufen lässt, sollte er den passenden nvidia-Treiber für die neue Karte installieren (müsste aktuell
nvidia 535.129.03 sein) - es kann sein, dass der Rechner danach einen Neustart braucht, damit er den X-Server zur Bildschirmerkennung erfolgreich starten kann. Gemäß https://github.com/yavdr/yavdr…xorg/defaults/main.yml#L1 ff. bevorzugt das Playbook die Ausgabe über HDMI gegenüber der Ausgabe über den Displayport, aber das kann man Anpassen wenn man will (dazu die Liste in eine host_vars/localhost kopieren und die Reihenfolge anders setzen).
-
ChatGPT hilft auch nicht wirklich :O|
Ich habe noch nie gesehen, dass das bei komplexeren Programmen hilfreich ist - insbesondere bei Rust scheitert das grandios (aber dafür findet man schnell die Seiten, die für das Training genutzt wurden).
Die Progressbar (laufende Sendung) unter der Uhr am Display, statt blau sehr grell "rot, orange, grün .." anzuzeigen .. finde ich leider nicht auf die Schnelle. Sollte doch ein "Farbwert" (wie [color=3333ff]) sein? Die "Dicke" des Balkens etwas größer zu stellen, bin mir da absulut nicht sicher, wo "rumschrauben".
Das hatte ich schon weiter oben verlinkt, das Widget hat kein Farb-Attribut, weil es die Balken aus mehreren Bildern zusammensetzt:
Das Progressbar-Widget ist ein bisschen unpraktisch - https://stackoverflow.com/a/51732176 bietet da einen Ansatz, um die Farbe zu ändern.
-
Ich würde vermuten, dass du yavdr-ansible nutzt, das standardmäßig Ton über pulseaudio ausgibt (man muss dann nach der Installation eigentlich nur auf die Ausgabe per HDMI (Stereo, auch für komprimiertes Multichannel-Audio wie DTS) umschalten) - pulseaudio greift sich beim Start der grafischen Sitzu8ng die Soundkarte (und gibt sie später frei, um zu ermöglichen, dass sie in einen Stromsparmodus gehen kann), weshalb es nur mit Verzögerung klappt, dass der VDR direkt auf das Alsa-Gerät zugreifen kann.
Es gäbe also mehrere Möglichkeiten:
- Du entfernst die Option in der softhddevice.conf, die das Plugin veranlasst direkt auf die Soundkarte zuzugreifen und stellst die Pulseaudio-Ausgabe auf den Sink für den HDMI-Ausgang um (z.B. über pavucontrol, das vorinstallierte pulsecontrol-Plugin oder über über DBus (zweiter Teil von Tester gesucht für programmatische Wahl des Ausgabegeräts über Pulseaudio, das Steuerungsskript läuft schon standardmäßig in der Session)
- Das yavdr-frontend Skript hat eine Option pulseaudio vorübergehend anzuhalten, wenn der VDR Ton ausgibt - dazu in der /etc/yavdr-frontend/config.yml die Option use_pasuspend für das genutzte oder alle Ausgabeplugins auf True setzen und das Skript bzw. den Rechner neu starten
- Du verhinderst, dass pulseaudio gestartet wird - entweder du deinstallierst es oder du regelst über die Konfiguration, dass es keinen autospawn macht und nimmst es aus dem Autostartskript für OpenBox heraus (https://github.com/yavdr/yavdr…s/openbox/autostart.j2#L8 f.) - das Template wird nach /var/lib/vdr/.config/openbox/autostart expandiert. Das hat den Nachteil, dass man dann in Programmen wie dem Firefox-Browser keinen Ton mehr hat.
-
Die Uhr (sollte hier "standard" sein) kommt nicht mehr.
Das hängt an dieser Zeile wenn die Wiedergabe beendet wird: https://github.com/seahawk1986…ster/osd2web_data.py#L170 - da könntest du auch 'clock' eintragen.
Ich bin etwas durch dein Skript "durchgstöbert" und hab über python/kivy ein wenig gelesen - sorry, keine Chance - da fehlt die Routine.
Ich bin damals über einen c't Artikel zu kivy gestolpert und bin recht schnell reingekommen (mich hat damals vor allem twisted mit der asynchronen Programmierung aufgehalten - das war lange, bevor Python3 asyncio bekommen hat) - aber danach habe ich nicht mehr wirklich etwas damit gemacht, weil es lange Zeit nur für Python2 verfügbar war.
Ich finde ja nicht mal in vdr_status_display.py, wo man zB. die Farben der Schrift für die Zeit ändern könnte oder für den Balken der laufenden Sendung unter der Uhrzeit.
Kivy splittet das auf - der Clock-Screen ist hier definiert: https://github.com/seahawk1986…/master/vdrstatus.kv#L639 ff. - formatierter Text funktioniert über Markup im String: https://kivy.org/doc/stable/ap…ix.label.html#markup-text - d.h. man müsste das in den String, der die aktuelle Uhrzeit repräsentiert einarbeiten: https://github.com/seahawk1986…dr_status_display.py#L220
Das Progressbar-Widget ist ein bisschen unpraktisch - https://stackoverflow.com/a/51732176 bietet da einen Ansatz, um die Farbe zu ändern.
-
-
Da gibt es mehrere Möglichkeiten - am einfachsten ist es das Programm mit dem Schalter -a für den Vollbildmodus mit automatischer Anpassung an die Bildschirmauflösung aufzurufen. Ansonsten unterstützt es auch noch andere Methoden wie einen Pseudo-Vollbildmodus, bei dem die Fensterdekoration entfernt wird und man eine beliebige Auflösung vorgeben kann:
Code
Display More$ ./vdr_status_display.py -h Kivy Usage: vdr_status_display.py [OPTION...]:: -h, --help Prints this help message. -d, --debug Shows debug log. -a, --auto-fullscreen Force 'auto' fullscreen mode (no resolution change). Uses your display's resolution. This is most likely what you want. -c, --config section:key[:value] Set a custom [section] key=value in the configuration object. -f, --fullscreen Force running in fullscreen mode. -k, --fake-fullscreen Force 'fake' fullscreen mode (no window border/decoration). Uses the resolution specified by width and height in your config. -w, --windowed Force running in a window. -p, --provider id:provider[,options] Add an input provider (eg: ccvtable1:tuio,192.168.0.1:3333). -m mod, --module=mod Activate a module (use "list" to get a list of available modules). -r, --rotation Rotate the window's contents (0, 90, 180, 270). -s, --save Save current Kivy configuration. --size=640x480 Size of window geometry. --dpi=96 Manually overload the Window DPI (for testing only.)
-
Da fehlen noch die Entwicklungs-Bibliothek für GTK - ich habe in der Openleap-VM folgende Pakete installiert, um den kiosk-browser bauen zu können:
- patch (weil ich den Patch aus meinem Debian-Quellpaket übernehmen wollte)
- make
- gcc
- gtk3-devel
- webkit2gtk3-devel
-
Das wär doch zu einfach
Man muss nur aus dem webkit2gtk-4.0 an den zwei Stellen im Makefile ein webkit2gtk-4.1 machen, dann baut es.