Beiträge von machtnix

Mit richtige Anzeige meine ich die Darstellung des skindesigner skins, dieser zeigt bei laufenden remotetimern ein rot blinkendes Symbol hinter dem Timer an.

Bei Suchtimern wird allerdings der lokale Host zur Aufnahme angelegt. Das ist unabhängig von der Einstellung der SVDRP Standardmaschine. Diese gefundenen Timer stelle ich dann ab und zu rechtzeitig auf den Server um.

Schade das die Voreinstellung für Suchtimer (Suchtimer SVDRP Standardmaschine Ja / Nein) nicht konfigurierbar ist.

Vielleicht hat ja TomJoad ein Einsehen und macht das auswählbar

Ja, genau.

Epgsearch läuft auf dem Client und Die VDR Peering Funktion setzt den Timer auf dem Server.

Auf dem Client habe ich in den Einstellungen-Sonstiges, SVDRP Verbindung: "nur mit der Standardmaschine" und bei SVDRP Standardmaschine: den Servernamen eingestellt.

Auf dem Server: SVDRP Verbindung: "mit jeder Maschine" und SVDRP Standardmaschine: leer lassen.

Allerdings musste ich die Timeranzeige auf den Client durch die vom epg2vdr Plugin ersetzen lassen, um eine richtige Anzeige zu bekommen.

Habe gerade das aktuelle epgsearch-plugin 2.4.1 getestet mit der VDR Peering Funktion. Auf die Schnelle sieht es gut aus mit der Peering Unterstüzung

Da hat sich wohl doch einiges getan (freu )

Hier VDR 2.3.1 erster Test VDR Peering + epgsearch

habe ich damals dieses Problem konkretisiert. Klaus hatte auch einen Vorschlag wie das epgsearch plugin Server-Client tauglich gemacht werden könnte.

Für mich war es aber, mangels Programmierkenntnissen nicht möglich das im Plugin umzusetzen.

Hallo,

leider kommt jetzt bei der Mali450 ein anderer Fehler:

May 06 14:25:03 CoreELEC vdr[3936]: [3936] loading plugin: /usr/local/lib/vdr/libvdr-softhdodroid.so.2.6.1

May 06 14:25:03 CoreELEC vdr[3936]: [3936] ERROR: /usr/local/lib/vdr/libvdr-softhdodroid.so.2.6.1: undefined symbol: glGenVertexArrays

Zitat

Kann mal jemand mit einer Mali 450 feedback geben ob es nun geht.

Ok, baut gerade. Ergebnis folgt

Jetzt schonmal danke an alle Beteiligten.

Alles nochmal neu gebaut - Leider gleicher Fehler

vdr: /usr/local/lib/vdr/libvdr-softhdodroid.so.2.6.1: undefined symbol: glBlitFramebuffer

CoreELEC:~ # ldd /usr/local/lib/vdr/libvdr-softhdodroid.so.2.6.1

        /usr/lib/libarmmem-v7l.so (0xf53d5000)
        libasound.so.2 => /usr/lib/libasound.so.2 (0xf5330000)
        libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0xf5285000)
        libGLESv2.so => /usr/lib/libGLESv2.so (0xf5165000)
        libdrm.so.2 => /usr/lib/libdrm.so.2 (0xf5156000)
        libdl.so.2 => /usr/lib/libdl.so.2 (0xf5143000)
        libavutil.so.56 => /usr/lib/libavutil.so.56 (0xf4eac000)
        libavcodec.so.58 => /usr/lib/libavcodec.so.58 (0xf3e35000)
        libavfilter.so.7 => /usr/lib/libavfilter.so.7 (0xf3b7d000)
        libswresample.so.3 => /usr/lib/libswresample.so.3 (0xf3b59000)
        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xf39d4000)
        libm.so.6 => /usr/lib/libm.so.6 (0xf396b000)
        libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0xf393e000)
        libc.so.6 => /usr/lib/libc.so.6 (0xf37ff000)
        libpthread.so.0 => /usr/lib/libpthread.so.0 (0xf37d6000)
        librt.so.1 => /usr/lib/librt.so.1 (0xf37bf000)
        /usr/lib/ld-linux-armhf.so.3 (0xf73d5000)
        libbz2.so.1.0 => /usr/lib/libbz2.so.1.0 (0xf37a0000)
        libz.so.1 => /usr/lib/libz.so.1 (0xf378c000)
        libdav1d.so.5 => /usr/lib/libdav1d.so.5 (0xf36a1000)
        libspeex.so.1 => /usr/lib/libspeex.so.1 (0xf367e000)
        libswscale.so.5 => /usr/lib/libswscale.so.5 (0xf360c000)
        libpostproc.so.55 => /usr/lib/libpostproc.so.55 (0xf35f1000)
        libavformat.so.58 => /usr/lib/libavformat.so.58 (0xf3459000)
        libgnutls.so.30 => /usr/lib/libgnutls.so.30 (0xf3260000)
        libidn2.so.0 => /usr/lib/libidn2.so.0 (0xf3212000)
        libnettle.so.8 => /usr/lib/libnettle.so.8 (0xf31cc000)
        libhogweed.so.6 => /usr/lib/libhogweed.so.6 (0xf318e000)
        libgmp.so.10 => /usr/lib/libgmp.so.10 (0xf3123000)

CoreELEC:~ # ls -la /var/lib/libMali.so

lrwxrwxrwx    1 root     root            24 Aug  6  2021 /var/lib/libMali.so -> /usr/lib/libMali.m450.so

CoreELEC:~ # ls -la /usr/lib/*GL*

lrwxrwxrwx    1 root     root            19 May  3 10:08 /usr/lib/libEGL.so -> /usr/lib/libMali.so
lrwxrwxrwx    1 root     root            19 May  3 10:08 /usr/lib/libEGL.so.1 -> /usr/lib/libMali.so
lrwxrwxrwx    1 root     root            19 May  3 10:08 /usr/lib/libEGL.so.1.0.0 -> /usr/lib/libMali.so
lrwxrwxrwx    1 root     root            19 May  3 10:08 /usr/lib/libGLES_CM.so.1 -> /usr/lib/libMali.so
lrwxrwxrwx    1 root     root            19 May  3 10:08 /usr/lib/libGLESv1_CM.so -> /usr/lib/libMali.so
lrwxrwxrwx    1 root     root            19 May  3 10:08 /usr/lib/libGLESv1_CM.so.1 -> /usr/lib/libMali.so
lrwxrwxrwx    1 root     root            19 May  3 10:08 /usr/lib/libGLESv1_CM.so.1.0.1 -> /usr/lib/libMali.so
lrwxrwxrwx    1 root     root            19 May  3 10:08 /usr/lib/libGLESv1_CM.so.1.1 -> /usr/lib/libMali.so
lrwxrwxrwx    1 root     root            19 May  3 10:08 /usr/lib/libGLESv2.so -> /usr/lib/libMali.so
lrwxrwxrwx    1 root     root            19 May  3 10:08 /usr/lib/libGLESv2.so.2 -> /usr/lib/libMali.so
lrwxrwxrwx    1 root     root            19 May  3 10:08 /usr/lib/libGLESv2.so.2.0 -> /usr/lib/libMali.so
lrwxrwxrwx    1 root     root            19 May  3 10:08 /usr/lib/libGLESv2.so.2.0.0 -> /usr/lib/libMali.so
lrwxrwxrwx    1 root     root            19 May  3 10:08 /usr/lib/libGLESv3.so -> /usr/lib/libMali.so
lrwxrwxrwx    1 root     root            19 May  3 10:08 /usr/lib/libGLESv3.so.3 -> /usr/lib/libMali.so
lrwxrwxrwx    1 root     root            19 May  3 10:08 /usr/lib/libGLESv3.so.3.0 -> /usr/lib/libMali.so
lrwxrwxrwx    1 root     root            19 May  3 10:08 /usr/lib/libGLESv3.so.3.0.0 -> /usr/lib/libMali.so

Dann hat wohl pbg4 Recht mit seiner Vermutung, dass der AMLOGIC S905W SOC vom softhdondroid plugin nicht unterstützt wird

Gruß

Ja, die richtige dtb.bin ist offensichtlich installiert und Kodi läuft auch einwandfrei. Erst beim umschalten über das Kodi Menue auf den VDR wird's dunkel - kein OSD - nichts.

wenn ich dann über ssh die start_vdr.sh ausführe kommt folgende Meldung in der Konsole:

killall: splash-image: no process killed

vdr: /usr/local/lib/vdr/libvdr-softhdodroid.so.2.6.1: undefined symbol: glBlitFramebuffer

Ich schaue mir morgen mal das log mit jornalctl -e an und melde mich dann nochmal.

Hallo Zabrimus,

habe alles gebaut bekommen und auf einer x96mini box installiert.

Installiert habe ich das "CoreELEC-Amlogic-ng.arm-19.5-Matrix_devel_20220502084341-Generic.img" War das richtig ?

Soweit hat wohl alles funktioniert - aber leider startet der VDR nicht.

Sieht so aus als wenn das softhdodroid Plugin ein Problem hat.

CoreELEC (community): 19.5-Matrix_devel_20220502084341 (Amlogic-ng.arm)

-sh: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)

# ./start_vdr.sh

killall: splash-image: no process killed

vdr: /usr/local/lib/vdr/libvdr-softhdodroid.so.2.6.1: undefined symbol: glBlitFramebuffer

Was könnte das Problem sein (Außer vielleicht ich selbst )

Außerdem gibt es eine Art syslog auf dem System? habe nichts gefunden.

Sicher, dass dein LAN im Dell Notebook überhaupt 1 GigaBit/s kann?

Selbst mache neuen Modelle können nur max. 100 MBit/s

Mir gelingt es nicht auf einem Notebook als Ausgabedevice softhddevice zu laufen zu bringen.

Lediglich xineliboutput geht.

Optimal wäre softhddevice mit der onboard NVIDIA und eine automatischen Einrichtung / Erkennung im YaVDR ansible.

lspci spuckt folgendes aus:

Besteht da Hoffnung, oder ist das technisch nicht möglich ?

Die NVIDIA lässt sich im BIOS auch nicht ausschalten. Auch die INTEL GPU wird nicht mit softhddevice vaapi genutzt

Gruß

Charly

Hallo jrie,

ich habe vor ca 2 Jahren einen IRMP-STM32-USB-IR-Empfänger gekauft (Platine eingeschweißt in Schrupfschlauch). Leider funktioniert dieser nicht mehr

Komischerweise funktioniert das Einschalten noch !?. Das deutet wohl auf einen Hardwaredefekt der USB Verbindung hin - oder ?

lsusb zeigt kein entsprechendes Gerät - egal welcher USB Port.

Das Teil ist dann wahrscheinlich reif für die Tonne ? Oder ist da was zu reparieren ?

Gruß

Charly

Zitat von mini73

Vermutung: Der Ton wird digital ausgegeben und ohne Recodierung kann softhddevice dann nichts an der Lautstärke regeln.

Bedeutet eine Recodierung eine Verschlechterung des Tons? oder eine hohe Last? oder warum wird bei digital Ton das Recodieren im softhddevice abgeschaltet ?

Bei Kodi kann man jedenfalls auch die Lautstärke über Toslink regeln. Einen Nachteil kann ich da nicht erkennen.

Stimmt ich meine das pass-trough über SP/Diff.

Bei Kodi funktioniert es - Beim VDR nicht

Oder verstehe ich falsch, dass Kodi mit "passtrough erlauben" die Ausgabe mit Passtrough ausgibt ?

Ist das grundsätzlich mit VDR unmöglich ?

Wollte jetzt mal versuchen die Lautstärke des Digitaltons über den VDR zu regeln.

Da dieses bei Kodi funktioniert, dachte ich es muss doch auch beim VDR möglich sein ?!?

Im Wiki vom Softhddevice habe ich folgendes gefunden und ausprobiert:

Digitale Ausgänge kann softhddevice nicht regeln. (noch nicht)

Mit diesem Eintrag in asound.conf kann man den Digitalen Ausgang trotzdem regeln.

pcm.!default hdmi_complete
pcm.hdmi_hw {  type hw  card 1    #  <- Hier die Nummer der Karte  device 7  #  <- Nummer des Device
}
pcm.hdmi_formatted {  type plug  slave {    pcm hdmi_hw    #rate 48000    #  <- Optional! Hier die gewünschte Rate.     #channels 2    #  <- Optional! Anzahl der Kanäle.  }
}
pcm.hdmi_complete {  type softvol  slave.pcm hdmi_formatted  control.name hdmi_volume  control.card 1    #  <- Hier die Nummer der Karte
} 

Nun muß man noch softhddevice mitteilen, welchen Regler es regeln soll. Dazu das Vdr Startscript um

export ALSA_MIXER_CHANNEL=hdmi_volume

Leider bleiben alle meine Versuche ohne erfolg

Meine Frage nun:

Liegt es am von Yavdr 07 benutzten pulseaudio ?

Hat es schon jemand erfolgreich im Einsatz ?

Ideen / Hilfe zur Konfiguration ?

meine aplay -l (Benutze Card 0 /Device 1)

**** List of PLAYBACK Hardware Devices ****
card 0: DGX [Xonar DGX], device 0: Multichannel [Multichannel]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: DGX [Xonar DGX], device 1: Digital [Digital]
  Subdevices: 0/1
  Subdevice #0: subdevice #0
card 1: NVidia [HDA NVidia], device 3: HDMI 0 [HDMI 0]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 1: NVidia [HDA NVidia], device 7: HDMI 1 [HDMI 1]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 1: NVidia [HDA NVidia], device 8: HDMI 2 [HDMI 2]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 1: NVidia [HDA NVidia], device 9: HDMI 3 [HDMI 3]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 1: NVidia [HDA NVidia], device 10: HDMI 4 [HDMI 4]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 1: NVidia [HDA NVidia], device 11: HDMI 5 [HDMI 5]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

Nur zur Info:

Habe die Firefox Version 89.0 auf die 84.0.2 zurückgesetzt.

Alle Probleme mit hängendem VDR sind verschwunden.

Die neue Version hat offensichtlich ein Problem mit softhddevice -va-vapi. Mal Abwarten ob die nächste Version wieder funktioniert.

Zitat von Paulaner

Ich habe aber eine Nvidia-Karte GT1030 im VDR stecken und benutze softhddevice-cuvid, also kein vaapi!

Die habe ich auch in dem VDR, der mit Firefox funktioniert

Allerdings auf dem 3. Bildschirm

#
# *** ANSIBLE MANAGED FILE ***
# template: /home/charly/yavdr-ansible/roles/osd2web/templates/systemd/user/osd2web.service.j2
#
[Unit]
Description=Start firefox browser on the third DISPLAY if it exists
After=detect-third-display.service openbox-third.service
Wants=detect-third-display.service openbox-third.service
ConditionFileNotEmpty=%h/.third_display

[Service]
EnvironmentFile=%h/.third_display
Environment=url="http://localhost:4444/skins/mein/index.html?theme=graycd&onlyView=1"
Environment=browser="firefox --no-remote --kiosk --private-window"
EnvironmentFile=-%h/.config/osd2web/config
ExecStart=/usr/bin/on_vdr -o -c '${browser} "${url}"'
KillSignal=SIGINT

[Install]
WantedBy=yavdr-desktop.target

Echt verwirrend

Ich sehe den Zusammenhang mittlerweile eher mit dem Frontend als mit dem Streamdev Client.

Ein Client mit einer Nvidia Graka (softhddevice -vdpau), zwar ohne streamdev-client, funktioniert nach wie vor mit Firefox als osd2web Browser.

2 Clients mit Intel Graka (softhddevice -va-api) und streamdev-client mögen den "neuen" Firefox nicht mehr als Browser für osd2web.

Was genau das Problem verursacht, kann ich leider nicht feststellen.

Könnte eigentlich ja auch am softhddevice mit vaapi liegen.?!?

Ok, Problem gefunden !

Ich starte den osd2web.service schon lange mit dem Firefox als Browser

Jetzt nach einem Upgrade wurde der Firefox geupdated - danach der Fehler wie oben beschrieben.

Habe jetzt den Kiosk-Browser wieder im osd2web.service eingetragen und osd2web funktioniert wieder.

Was da mit dem Firefox Update passiert ist, bleibt mir ein Rätsel.

Gibt es jemanden, der ebenfalls yavdr 07 mit streamdev-client und osd2web am laufen hat und kürzlich apt-get dist-upgrade benutzt hat?

Das würde mir bei der Ursachenfindung helfen.