Da Du die Verbindungsversuche im VDR Log siehst, kann man eigentlich das Netzwerk/Firewall ausschließen.
Steht im Syslog etwas zu der svdrphosts.conf? Kann VDR die Datei lesen? ist das Format korrekt?
Geht ein lokales "svdrpsend stat disk" o.ä.?
Da Du die Verbindungsversuche im VDR Log siehst, kann man eigentlich das Netzwerk/Firewall ausschließen.
Steht im Syslog etwas zu der svdrphosts.conf? Kann VDR die Datei lesen? ist das Format korrekt?
Geht ein lokales "svdrpsend stat disk" o.ä.?
Das macht keinen Unterschied. Auch wenn das abgeschaltet ist, wird es genauso überlagert.
Hmm, kannst Du mal nen Screenshot machen? Den kannst Du mir auch per PM schicken. Normalerweise ist immer etwas Platz zwischen den Spalten....
Es werden keine epg Bilder angezeigt bzw. der VDR hängt sich komplett auf und reagiert nicht mehr.
Ja, da verfangen sich die Threads manchmal .... In meiner aktuellen Version tritt das nicht mehr auf, aber an anderen Stellen hapert es noch ab und zu weshalb ich noch keine neuere Version veröffentlicht habe. Bei Interesse könnte ich Dir die Beta-Version zukommen lassen.
Hast Du das Paket intel-media-driver installiert?
Ich hatte mir damals notiert, dass libva für HW Dekodierung folgendes braucht:
Das Problem ist, dass nicht der Skin die Breite der Spalten definiert, sondern die übergeordneten Menüs (der Skin zeigt sie nur an). Es liegt also nicht am Ausgabedevice, eher am Font - wenn der klein genug gewählt wird überlagert es sich nicht (aber man kann die Schrift nicht mehr lesen :-().
Das steht noch auf meiner todo Liste, eine akzeptable Lösung habe ich aber bisher nicht dafür.
EDIT: Workaround: in den Einstellungen das HD/UHD-Symbol abschalten
Das habe ich auch, vermutlich ist das beschleunigte OSD mit OpenGL bei vaapi in softhddevice nicht eingebaut.
Daher steht in meiner Zeile noch zusätzlich das "-w disable-ogl-osd", damit die ganzen Meldungen nicht kommen.Oder irre ich mich und OpenGL ist auch bei vaapi im "normalen" softhddevice aktiv?
das liegt an der libGLEW, da schlägt das Init fehl. Da habe ich WOCHEN (!) mit dem Debugger verbracht und keine Lösung gefunden. Seitdem muss es mit "soft-OSD" = disable-ogl-osd laufen.
vaapidevice nutzt auch kein OpenGL-OSD
das "max()" gegen "std::max()" tauschen wie in de Fehlermeldung angegeben sollte doch mit allen gehen ....
I didn't get any warning regarding ffmpeg-4 during compilation.
Ja, das ist ja das fiese: Es kompiliert fehlerfrei, zeigt aber kein Bild
I guess vaapi-device still needs ffmpeg-3.x
Leider hat weder das deinstallieren des Pakets noch das Setzen der Variablen geholfen.
Ich wollte Dir nur sagen, dass du den i965 Treiber bei opensuse im Paket intel-vaapi-driver-2.4.0-lp152.1.4.x86_64.rpm findest. IIRC musst du den passenden Treiber (i965 oder iHD) zu deiner GPU wählen. Das fiese war, dass manche GPUs zwar offiziell von beiden unterstützt werden, aber nur mit einem ein Videobild liefern.
Und ich bezweifele weiterhin, dass VA-API für :0 und :1 gleichzeitig Streams dekodieren kann (fundiertes Halbwissen ;-)) Wenn der VA-API Dekoder von :0 schon belegt ist, kann :1 ihn vermutlich nicht mehr öffnen. Warum benutzt du nicht Display :0 ? Oder ist das im X gar nicht definiert?
Deinstalliere intel-media-va-driver va-driver-all
und installiere i965-va-driver-shaders
oder im Environment "LIBVA_DRIVER_NAME=i965" setzen (vorausgesetzt intel-vaapi-driver-2.4.0-lp152.1.4.x86_64.rpm ist installiert)
Nutzt Du wirklich ':1' anstatt ':0', also das zweite X-Display?
Ich hab je 2x die timersdone.conf und die epgsearchdone.data
je 1x in /etc/vdr/plugins/epgsearch/ und in /var/lib/vdr/plugins/epgsearch.
Ist das eine Verzeichnis nicht ein Link auf das andere? Einige Distris wollen das ja immer in beiden Verzeichnissen haben ....
Epgsearch macht das ganze Timer-Handling (Anlegen, Löschen, Modifizieren) über SVDRP.
Also hat hier wohl epgsearch die Hände im Spiel.
Im README von EPGsearch 2.4.0 habe ich aber gefunden:
Also sollte das doch intern ablaufen, als Plugin hat es ja auch Zugriff auf das API.
Ich habe gestern ein ähnliches Phänomen festgestellt: es fehlen etliche Suchtimer, die vorher erfolgreich angelegt wurden und in der timersdone.conf stehen. Lt. Log wurden sie beim Starten des VDR gelöscht: "SVDRP hdvdr < 127.0.0.1:41054 deleted timer 73" aber was sie gelöscht hat ist mir bisher nicht klar (Epgsearch würde ja nicht über SVDRP gehen sondern als Plugin direkt die Timer ändern, oder?).
Was ich bisher herausgefunden habe ist, dass alle ARD-Sender jetzt offenbar die Episodennummer in Klammern an den Titel anhängen, weshalb die Suchtimer teilweise nicht mehr greifen und dann vermutlich Epgsearch den Timer löscht. Da ich gerade mit XMLTV2VDR bastele hatte ich aber zunächst das in Verdacht.
andre1964
: nutzt Du externes EPG, also epg2vdr oder sowas? Steht in (älteren) Logs dass die Timer angelegt wurden und später wieder gelöscht wurden? Greifen die Suchtimer noch?
Ich gehe davon aus, dass m_ovg->MaxImageSize von cOsd::MaxPixmapSize() abgeleitet ist weil der Raspi nicht mehr als 2048x2048 kann.
Aber das kannst Du im Quelltext nachsehen oder jemand der das Ausgabeplugin kennt kann das beantworten
Die Funktion cOsd::MaxPixmapSize() gibt es erst ab 2.3.1, deshalb die Einschränkung APIVERSNUM >= 20301
Die HW-Beschränkung des Raspi gab es auch schon vorher ,-)
Dabei geht es um den Farbraum den (s)RGB und BT.709 abdecken. Details z.B. hier: https://en.wikipedia.org/wiki/Rec._709
ich glaube nicht, dass vaapi-device ffmpeg 4.x überhaupt unterstützt....
Kannst Du einem Backtrace erstellen um zu sehen, wo der Fehler auftritt? Die Kernelmeldungen helfen da leider nicht
Wer skinElchi HD in noch besserer Qualität sehen möchte, der sollte die neuen Patches aus dem git von VDR einspielen damit die Kurven antialiased dargestellt werden