Wie wäre es mit einem touch aus dem post recording hook auf die .update im root Aufnahmeverzeichnis ?
So mache ich es auch. Läuft.
Wie wäre es mit einem touch aus dem post recording hook auf die .update im root Aufnahmeverzeichnis ?
So mache ich es auch. Läuft.
Vielleicht hilft das weiter. Die channels-Sache wurde schon länger als deprecated markiert...
Ich hätte da gar nichts einzuwenden sondern würde eher noch die Frage in den Raum stellen, ob es schaden würde, einfach auch fertige Features als commit zwischen den Versionsnummern ins git zu pushen. Evtl. auch in einem develop branch, denn jeder testen kann.
Ich glaube aber, die Diskussion gab es schon mal in dem git-Thread...
Dann bin ich leider wieder raus
nobanzai Ich nutze selbst keinen EPG Dienst, hatte aber in der Vergangenheit auch mal das Problem mit doppelten Events. Kannst du ausschließen, dass im EPG von VDR selbst ohne zusätzliches epg-Programm nach einer gewissen Zeit doppelte Einträge auftauchen? So klar konnte ich das aus dem Thread nicht herauslesen...
Hat noch jemand das alte File wireguard-tools-1.0.20210914.tar.xz mit der sha256sum 69de713458a887cddb46b2fd1d43bf20548f693136af95792e65ec925538c770?
Ja, ich. Hier.
So, jetzt
Ich habe jetzt in der config.txt
dtparam=audio=on und audio_pwm_mode=1 eingestellt und kann die Aussetzer nachstellen.
Es kommt die ring buffer empty Meldung, danach werden die AlsaBuffers geflusht und wieder A/V synchronisiert und das verursacht die Hänger.
Gegenprüfung mit #audio_pwm_mode=1, d.h. in der Folge audio_pwm_mode=2, weil default -> keine Probleme.
Für mich ok, weil ich analog eh nicht nutze und es mit mode 2 wohl funktioniert. Wenn jemand sagen kann, woran das liegt und wie man das lösen könnte, gerne her mit Vorschlägen, ansonsten würde ich da erstmal einen Haken setzen...
4GB.
Was hattest du in der config.txt eingestellt?
auch nicht mit dem Ausgang auf Klinke und auf einem RPi4 oder andere Hardware?
Nein. Funktioniert mit RPI4 so wie es soll. Mysteriös...
Sehr komisch. Kannst du mir da das log auch nochmal einstellen? default:CARD=device habe ich nicht. Das klingt auch schräg...
Hast du jetzt das USB Teil dran?
Ich kanns übrigens immer noch nicht nachstellen und als einzigen Unterschied kann ich die Signalquelle ausmachen. DVB-C vs. DVB-S...
Danke. Kannst du mir nochmal deine setup.conf schicken? Hier habe ich die Probleme nicht. Was hängt denn bei dir am Klinke Ausgang dran? Obwohl der ja eigentlich "dumm" sein sollte.
Das Log von oben ist mit der 12er Version ohne meine Debugs, oder?
Danke. Bei mir sieht das so aus:
https://pastebin.com/raw/GfYPLEtC
Irgendwie fehlt da im Gegensatz zu meinem Log einiges, z.B. das laden der conf-Dateien, ein AlsaSetup - ist das Log komplett?
Ansonsten kann ich es hier nicht nachstellen. Funktioniert einwandfrei.
Was mir noch einfällt, ist auf stereo audio zu schalten oder den rpi4 doch mal mit einem audio-fähigem hdmi zu verbinden. Das müsste evtl. auch mit einem Monitor ohne Lautsprecher gehen (dann mit -a auf hdmi einstellen).
Ansonsten bin ich erstmal ratlos, kommt denn überhaut ein Ton?
Normalerweise sollte damit das Update auf LE13 aus einem LE12 funktionieren..., Also img.tar.gz in .update und reboot.
Nochmal eine Frage:
Der Server nimmt auf ein Verzeichnis auf, das auch auf dem Server liegt?
Dein Client bindet das Verzeichnis über cifs oder nfs ein?
So wärs gut. Dann ist streamdev komplett aus dem Spiel.
Hast du beim ersten Log 2 Timer gestartet oder werden die ts Dateien so klein gestückelt?
Ansonsten deute ich "leichte Glitches, keine Aussetzer" so, dass zumindest die
weg sind. Ich vermute das Problem eher bei streamdev als bei softhddevice.
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
Und dann wäre ich nochmal auf die Logs gespannt. Evtl. komplett, wenns geht
Lokale Aufnahme ist eh besser, dann ist das Netzwerk nicht in Spiel. Das hat den Sinn festzustellen, ob es am Live-Signal liegt oder an der Aufnahme.
Wenn du eine lokale Aufnahme hast und der client autark läuft, kannst du ihn ja einfach vom Netzwerk trennen, streamdev-client deaktivieren und die Aufnahme abspielen. Ich weiß nicht, ob du da noch ein dummydevice brauchst, glaube aber nicht.
Dann wäre die Suche auf den Client eingegrenzt und wenn es nicht klappt, kann es nur an der Aufnahme, softhddevice-drm-gles oder ffmpeg etc. liegen.
Bis auf die Aufnahme kann ich bei mir das exakt gleiche Setup aufsetzen und versuchen, deine Situation nachzustellen.
Falls die lokale Aufnahme klappt, der Livestream aber nicht, kann es "nur" der Server, streamdev oder das Netzwerk sein.
So würde ich das mal analysieren und versuchen einzugrenzen.
Der zeitliche Abstand der Meldungen könnte ganz gut zu den "Haklern" im Bild passen.
Ich würde sagen, das ist eindeutig zyklisch mit einem Abstand von 24-25 Sekunden... Hm.
Spiel mal eine Aufnahme ab!
Ich würde so vorgehen: Einfacher Aufbau, d.h. nur notwendigste Plugins am Server = streamdev und nur notwendigste am Client = sreamdev, softhddevice. Dann nochmal schauen. Du musst herausfinden, ob das Problem am Server, Netzwerk oder Client liegt. Nachdem ich das Problem nicht nachvollziehen kann (und es auch nicht z.B. auf den Rockchips habe) würde ich erstmal softhddevice ausschließen oder ans Ende der Kette stellen.
Ursache gefunden, siehe https://forum.libreelec.tv/thr…?postID=193434#post193434.
Temporärer fix ist, den Patch wieder rein zu nehmen, aber ich denke das wird bald in LE gefixt.
Hier RE: [VDR*ELEC] VDR Client Konfiguration / remoteosd / größerer ring-buffer? hast du 2 channels und hier RE: [VDR*ELEC] VDR Client Konfiguration / remoteosd / größerer ring-buffer? die 6 channels. Der Fehler ist zwar beide Male da, aber was ist da anders?