Beiträge von klausb

    Leider hat alles nichts genutzt :( Status jetzt:

    • Ethernet Probleme behoben --> war wohl das Kabel
    • ein cron-job schreibt alle 5 Minuten eine Nachricht, damit man sieht, bis wann der Rechner normal läuft.
    • in der setup.conf (s. Anlage) alle Timeouts auf "0" gesetzt
    • dummydevice aktiviert

    Resultat:

    • läuft VDR, so gibt es schon 38 Minuten nach Start des VDR einen Absturz (Zeitstempel 9:12 - 9:50 im Log)
    • läuft VDR und wird von einem Client genutzt, so ist alles o.k.
    • läuft VDR nicht, so gibt es keine Probleme über mehr als 24-Stunden.

    In der beiliegende syslog Datei sind wichtige Punkte mit "@@@" zusätzlich markiert


    Insgesamt ratlos

    Hast du in der setup.conf vom VDR mal die Timeouts ausgestellt?

    SVDRPTimeout=0

    MinUserInactivity=0

    Die anderen Timeouts hatte ich schon auf 0 gestellt, nicht jedoch den SVDRPTimeout das muss ich nochmal testen. Denn es ist wirklich so, dass der Rechner problemlos durchläuft, wenn der VDR Prozess nicht läuft. Auch solange der VDR genutzt wird, gibt es keine Probleme.


    Die Kiste lässt sich ohne Probleme ganz klassisch herunterfahren. Die Frage bleibt, warum der VDR bei einem Inactivity Timeout den Rechner nicht regulär herunterfährt. Welcher Part ist dafür verantwortlich?

    aber warum nicht mal dieselbe IP einfach fix am VDR einstellen?

    Ja danke, das werde ich mal versuchen.

    Du kannst die avahi-linker.service, sowie die vdr-network-monitor.service und vdr-update-monitor.service deaktivieren, wenn du nicht die von anderen yaVDRs angekündigte Freigaben automatisch einbinden lassen willst.

    Auch das ist eine gute Idee. Danke!


    Übrigens:

    • vdr-network-monitor.service ist nicht vorhanden
    • wozu ist der "VDR ACPI power button handling daemon" da? (gerade selbst nachgeschaut) ;)

    Die Zeilen vor deiner Zeile #1 wären interessant.

    Hier sind sie. Sahen für mich nicht wirklich verdächtig aus. Interessant ist, dass die link down / up  Meldung mehrfach währen des Betriebs auftaucht, die Kiste aber erst während der Nacht ohne laufenden Client abschmiert.


    Übrigens habe ich jetzt vorsichtshalber mal das Kabel getauscht ;)


    Realtek bashing spare ich mir.

    Das ist gut, denn es ist ja keine Realtek Karte, sondern Teil des Nvidia Chips.

    Ich habe auf meinem alten System einen VDR-headless Server (Ubuntu focal) mit Hilfe von yaVDR-ansible aufgesetzt. Zusätzlich noch vnsiserver aktiviert. Play via Kodi-Client, Aufnahmen, etc. alles läuft normal und problemlos jedoch: Irgendwann, wenn die Server nicht mehr genutzt wird, läuft er in einen undefinierten Zustand:

    • kein Ping und damit natürlich auch
    • keine Verbindung via ssh mehr möglich
    • Power ist noch an, jedoch keinen Disk-Aktivität mehr zu sehen
    • im log gibt es die Meldung kernel: [11159.910200] forcedeth 0000:00:0a.0 enp0s10: link down(up). Das hat offensichtlich etwas mit "nForce Ethernet support" zu tun, der auch in dmesg auftaucht forcedeth: Reverse Engineered nForce ethernet driver. Version 0.64., jedoch habe ich keine Ahnung, was dort zu tun ist :(
    • auch der nouveau Treiber wird initialisiert, da aber weder Tastatur, noch Display angeschlossen ist, sollte das doch keinen Einfluss haben.

    Bisher hilft nur noch Hard-Reset.


    Konfiguration:

    Ausschnitte aus dem syslog


    Wo kann ich weiter suchen?

    • was kann ich noch alles deaktivieren?
    • außer vnsi/ssh/scp Zugriff benötige ich an sich nichts

    Gegenprüfung mit #audio_pwm_mode=1, d.h. in der Folge audio_pwm_mode=2, weil default -> keine Probleme.

    Das habe ich leider nie getestet :(

    Ist schon komisch da


    „audio_pwm_mode=2 (the default) selects high quality analogue audio using an advanced modulation scheme.“


    Da erwartet man höhere Last.


    Aber ja! „Fertig“!


    rell und auch alle anderen RPi4 Nutzer: Wenn man - wie die meisten - keine 4k@60Hz Medien zu Verfügung hat, macht es Sinn, in der config.txt den Parameter hdmi_enable_4kp60=1 zu deaktivieren. Der RPi4 wird dann nur noch handwarm und nicht mehr heiß! Siehe dazu: hdmi_enable_4kp60 (Raspberry Pi 4 only) "


    Setting hdmi_enable_4kp60 increases power consumption and temperature.

    Hast du jetzt das USB Teil dran?

    Ja und das macht den Unterschied! Dadurch muss der Ton nicht mehr per Software erzeugt werden. Kostenpunkt 12€. Den Parameter für -a habe ich dann per aplayermittelt.

    Ich kanns übrigens immer noch nicht nachstellen

    auch nicht mit dem Ausgang auf Klinke und auf einem RPi4 oder andere Hardware?


    Log schicke ich heute Abend. Übrigens den analog Output habe ich in der config.txt wieder deaktiviert.

    Ich habe jetzt mal einen kleinen USB-to-Audio Ausgang bestellt. Mal sehen, was damit passiert.

    Jetzt funktioniert alles!

    Als Aufrufparameter ist -a default:CARD=Device gesetzt. Damit hat man einen einwandfreien Ton und keine Ruckler/Aussetzer oder Fehlermeldungen!


    Fazit: Der interne RPI4 Audio Ausgang erzeugt neben dem schlechten Ton sehr unerwünschte Nebenwirkungen :cursing:


    rell Nochmals ganz herzlichen Dank für die Geduld!


    Wo und wie veröffentlicht man das so, dass möglichst wenige erneut diesen steinigen Weg gehen?

    Ist das der einzige VDR im Netzwerk oder liegen die Timer auf einem anderen VDR?

    Aktuell ist das der einzige VDR, aber es kann sein, dass ich den Timer mal via VNSI von einem Kodi (vdr*ELEC) gesetzt habe.

    "timer 0" sind nicht gespeicherte Timer. Wenn Du z.B. in epgsearch die Suche verwendest, gibt es haufenweise timer 0.

    Hatte ich mir gedacht und epgsearch deaktiviert. Taucht trotzdem immer noch unverändert auf.


    Wie werde ich die Altlasten los?

    Vorab: die Datei timers.conf ist leer ;)


    Irgendwann habe ich wohl mal die u.a Timer angelegt, die immer wieder im Log erscheinen. Vielleicht war es auch ein Suchtimer.

    Code
    Jun 30 22:47:52 vdr7 vdr[6286]: [6312] timer 0 (7 2208-2315 'Bones - Die Knochenjägerin') set to event Mi. 03.07.2024 22:10-23:05 'Bones - Die Knochenjägerin'
    Jun 30 22:47:52 vdr7 vdr[6286]: [6312] timer 0 (7 2303-0010 'Bones - Die Knochenjägerin') set to event Mi. 03.07.2024 23:05-00:00 'Bones - Die Knochenjägerin'
    Jun 30 22:47:57 vdr7 vdr[6286]: [6312] timer 0 (7 2013-2120 'Bones - Die Knochenjägerin') set to event Mi. 03.07.2024 20:15-21:10 'Bones - Die Knochenjägerin'
    Jun 30 22:47:57 vdr7 vdr[6286]: [6312] timer 0 (7 2108-2220 'Bones - Die Knochenjägerin') set to event Mi. 03.07.2024 21:10-22:10 'Bones - Die Knochenjägerin'

    ... aber wie werde ich die wieder los? Sie erscheinen nicht im "Timer" Menu, auch die Datei timers.conf ist leer. Die Plugins epgsearch etc. habe ich schon deaktiviert. Trotzdem wird mir der gesamte Log zugemüllt.


    Frage also: Wo findet vdr solche Einträge noch?

    Kannst du mir nochmal deine setup.conf schicken?

    Siehe hier: setup.conf und enabled_plugins. In der setup.conf sind natürlich noch Einträge für inaktive Plugins vorhanden.


    Am Ausgang hängt ganz einfach ein Kopfhörer oder eine kleiner Aktivlautsprecher. Das der analog Audio Ausgang qualitativ recht mies ist, ist aus den diversen Foren natürlich bekannt. Dürfte, da Software generiert auch etwas Last verursachen, jedoch sollte sich das nicht solche Probleme verursachen. Ich habe jetzt mal einen kleinen USB-to-Audio Ausgang bestellt. Mal sehen, was damit passiert.


    Das Log von oben ist mit der 12er Version ohne meine Debugs, oder?

    Es ist die VDR-LibreELEC-RPi4.aarch64-13.0-2024-06-27.1 Bei den vielen Debug Ausgaben ist es manchmal schwer, die entscheidenden Punkte zu finden und ich wollte nur mal die einfachen Dinge probieren.

    Also: Ich denke, das Problem ist lokalisiert ... aber noch nicht überwunden :(

    1. Im OSD habe ich dem softdevice einen Downmix auf Stereo eingestellt ... das war es nicht
    2. Gibt man als Audio-Output HDMI an, so läuft alles glatt
    3. Gibt man Analog Audio an, so gibt es die Hänger in Bild und Ton. Das ist synchron mit den "ring buffer" Meldungen im log. Übrigens ein "Hänger", also keine Ausfall, sondern sowohl Ton, als auch Bild bleiben stehen.

    Ein kommentierten Log findet man hier: https://pastebin.com/raw/nSQR4tAZ


    Die Frage ist jetzt weiterhin, wie man den Analog-Kanal fehlerfrei zum Laufen bringt


    Übrigens: Danke für die geduldige Hilfe!


    Nachtrag: Ja “es kommt ein Ton” ;(


    Übrigens: Wiedergabe via Kodi, vnsi klappt ohne Hänger in Bild und Ton. Dort gibt es allerdings im Analog Ton leichte Glitches oder Zischlaute, ohne das dabei allerdings im Bild etwas zu sehen ist.

    Wenn du willst, kannst du dir von hier ein Update installieren, in dem ein paar Log-Flags für softhddevice gesetzt sind. Vielleicht gibts dann mehr Aussagen...

    VDRSternELEC Version ist https://github.com/Zabrimus/VD…e050d8e92984b14e9fc230dc3

    Das ist LibreELEC 13. Ich habe bisher 12 (VDR-LibreELEC-RPi4.aarch64-12.0-2024-06-22.1) im Einsatz. Sollte ich da besser das Image einspielen und nicht nur ein Update?

    Hast du beim ersten Log 2 Timer gestartet oder werden die ts Dateien so klein gestückelt?

    Ja. War ein Versehen. Habe aber beim Replay eine ein paar Minuten laufende lokale Aufnahme genommen. In dem Fall Replay ist also streamdev nicht im Spiel. Im Fall der Aufnahme schon, aber da wird ja nur die .TS Datei erzeugt.


    Dein Client bindet das Verzeichnis über cifs oder nfs ein?

    Habe ich für diesen Versuch absichtlich NICHT gemacht! Es könnte also wirklich streamdev sei.
    Jedoch: Spielt man den Live-Stream via Port 3000 / und VLC-Player ab, so gibt es keine Problem. Und der wird ja auch vom streamdev-server bereitgestellt.

    Wenn du willst, kannst du dir von hier ein Update installieren

    Danke! Werde ich mal testen und berichten


    Übrigens: wenn ich via Kodi und vnsiserver schaue, gibt es keinerlei Bild Probleme und die Systemlast scheint sogar geringer zu sein, als mit vdr/softhddevice

    Erster Test "minimal Konfiguration" abgeschlossen:

    • Server nur streamdev-server und live
    • Client nur streamdev-client, softhddevice und live

    Identisches Verhalten mit gleichen Rucklern und gleichen Fehlermeldungen.


    Zweiter Test "lokale Aufnahme" vom Server:

    • Aufnahme einer HD Sendung gestartet (Quelle ist der Server)
    • Wiedergabe: Manchmal leichte Glitches im Bild, jedoch keine Aussetzer

    ABER: Nach Ende der Aufnahme gerät alles aus dem Lot ?!

    Code
    Jun 26 10:40:15 LibreELEC vdr[1400]: [1423] cStreamdevFilter::PutSection(Pid:18 Tid: 64): Flushed 3499 bytes, max queue: 213504
    Jun 26 10:42:53 LibreELEC vdr[1400]: [1404] [softhddevice] AlsaPlayer: ring buffer empty Videopkts: 182
    Jun 26 10:42:57 LibreELEC vdr[1400]: [1493] non blocking file reader thread ended (pid=1400, tid=1493)
    Jun 26 10:42:57 LibreELEC vdr[1400]: [1492] dvbplayer thread ended (pid=1400, tid=1492)
    Jun 26 10:42:57 LibreELEC vdr[1400]: [1400] switching to channel 2 C-1-1079-11110 (ZDF HD)
    Jun 26 10:42:57 LibreELEC vdr[1400]: [1400] switching to channel 1 C-1-1051-10301 (Das Erste HD)
    Jun 26 10:42:57 LibreELEC vdr[1400]: [1400] info: Kanal nicht verfügbar!

    Ein Restart des vdr auf beiden Seiten "heilt" und man hat wieder die alte Situation :(

    Ja, das ist wahrscheinlich die einzige Möglichkeit der Sache näherzukommen. Zur Bedienung würde ich auf beiden Seiten noch das live Plugin hinzufügen. Das sollte doch nicht stören oder?


    Wie kann ich eine Aufnahme vom Server auf dem Client abspielen? Unter "Aufnahmen" liegen ja nur die lokalen --> also einen read only CIFS mount?


    Brauche aber noch ein paar Hinweise zu Samba, denn obwohl es ja eine /etc/samba/smb.conf gibt, ist Samba offensichtlich nicht aktiviert. Auch kann man diese Datei ja wohl nicht editieren. Habe gesehen, dass es in ./config eine samba.conf.sample gibt.


    Also Fragen:

    • Wie starte ich Samba?
    • Wie kann ich einen Eintrag in der fstab setzen, um die Aufnahmen des Servers zu mounten?

    ... oder läuft das alles über die Kodi Einstellungen?