Proxmox 7.1-7 bzw. letztes Update 6.4-11 macht Probleme mit tvheadend
- Thread starter viper67
- Start date
Endlich bin ich auf diesen Thread gestoßen und weiß jetzt somit endlich mal wo der Fehler liegt. Ich habe den Sat2Ip Receiver ausgetauscht, neue VMs installiert, verschieden Container ausprobiert: Alles ohne Erfolg und bei Proxmox 6.4 keinerlei Probleme. Jetzt ist hald die Frage wie wir das debuggen, damit der Bug nachgewiesen und behoben werden kann?
Die Ursache ist schon seit Monaten bekannt, scheint aber nur schwer zu beheben zu sein.
Die Fehler entstehen dardurch, dass der Buffer Cache von dem LXC Container bei Verwendung eines UDP Stream sich beständig vergrößert und nie geleert wird. Auf der VM habe ich das nicht gemessen, aber bei meinen früheren Test wurde der Stream auch dort instabil. Ich vermute, dass das dort auch passiert, weiß es aber nicht. Das free Memory geht dann auf 0 und genau in diesem Moment wird der TV Stream massiv gestört und erholt sich auch nicht mehr.
Es gibt einen "bloody Workaround". Man kann einen Cron Job auf dem Host starten, der alle x- Minuten den Buffer Cache löscht.
Das kann nur auf dem Host gemacht werden, weil der Client einen Write Error bekommt. X hängt von dem Memory des Containers ab. Ich habe meinem LXC Container 2 GB zugewiesen, da ist x ungefähr 4 Minuten. Das muss man ausprobieren.
Der Befehl, der mit dem Cron Job auf dem Host ausgeführt werden muss, lautet
sync && echo 3 > /proc/sys/vm/drop_caches
Ob das unter allen Randbedingungen völlig rückwirkungsfrei ist, kann ich nicht sagen.
Die Fehler entstehen dardurch, dass der Buffer Cache von dem LXC Container bei Verwendung eines UDP Stream sich beständig vergrößert und nie geleert wird. Auf der VM habe ich das nicht gemessen, aber bei meinen früheren Test wurde der Stream auch dort instabil. Ich vermute, dass das dort auch passiert, weiß es aber nicht. Das free Memory geht dann auf 0 und genau in diesem Moment wird der TV Stream massiv gestört und erholt sich auch nicht mehr.
Es gibt einen "bloody Workaround". Man kann einen Cron Job auf dem Host starten, der alle x- Minuten den Buffer Cache löscht.
Das kann nur auf dem Host gemacht werden, weil der Client einen Write Error bekommt. X hängt von dem Memory des Containers ab. Ich habe meinem LXC Container 2 GB zugewiesen, da ist x ungefähr 4 Minuten. Das muss man ausprobieren.
Der Befehl, der mit dem Cron Job auf dem Host ausgeführt werden muss, lautet
sync && echo 3 > /proc/sys/vm/drop_caches
Ob das unter allen Randbedingungen völlig rückwirkungsfrei ist, kann ich nicht sagen.
Mein Fokus lag auch auf den RAM Überlauf. Nachdem ich dieses jedoch behoben habe, kamen nach ca. einer Stunde streamen auf dem gleichen Transponder wieder Continuity Errors, welche ab dem ersten Zeitpunkt dann einfach weiter und weiter ansteigen, was ein Streamen so gut wie unmöglich machen.
Es gibt also meiner Meinung nach zwei Probleme:
1. Memory Hole bei Containern
2. Irgendein Problem mit viel UDP-Traffic.
Ersteres ist nachstellbar. Das zweite Problem mit UDP ist etwas schwieriger, ich denke mal, dass ab einem gewissen Zeitpunkt irgendwelche Pakete im Kernel verloren gehen. Hier habe ich absolut keine Ahnung wie man sowas nachstellen kann. Wäre mal interessant was passiert, wenn man den SAT>IP UDP-Traffic über GRE in eine VM mit nem älteren Kernel tunnelt...
Das tut mir leid, dass der WA nicht geholfen hat.
Auf meinem System funktioniert der Workaround bisher auch bei stundenlangem Streaming ohne Probleme.
Bei der Aufnahmen von drei parallelen Sendern und 2 GByte Memory und einem Crontab, der alle 3 Minuten die Caches löscht, "oszilliert" mein Free Memory zwischen 1800 und 880 MByte.
Auf meinem System funktioniert der Workaround bisher auch bei stundenlangem Streaming ohne Probleme.
Bei der Aufnahmen von drei parallelen Sendern und 2 GByte Memory und einem Crontab, der alle 3 Minuten die Caches löscht, "oszilliert" mein Free Memory zwischen 1800 und 880 MByte.
Derzeit das Debian 10 Standard 7-10-1 Image. Das hatte ich mal testhalber installiert, um zu sehn, ob es an der Debian Version liegt.
Das Image hat sich aber genau so verhalten, wie das Debian 11 image und da habe einfach weitergemacht.
Ich habe auch noch einen Container mit Debian 11, da könnte ich jetzt auch nochmal testen. Ich glaube aber das hat nichts mit dem OS zu tun, sondern liegt irgendwie an Promox 7.x.
Ich benutze derzeit für meine Tests übrigens NextPVR, weil dieser TV Server viel einfacher einzurichten ist als Tvheadend, das Repro viel besser gepflegt sind und der Support im Forum super ist! Außerdem glaube ich das TVheadend nicht mehr lange lebt.
Aber das Verhalten mit dem Memory ist unabhängig von dem TV Server.
Das Image hat sich aber genau so verhalten, wie das Debian 11 image und da habe einfach weitergemacht.
Ich habe auch noch einen Container mit Debian 11, da könnte ich jetzt auch nochmal testen. Ich glaube aber das hat nichts mit dem OS zu tun, sondern liegt irgendwie an Promox 7.x.
Ich benutze derzeit für meine Tests übrigens NextPVR, weil dieser TV Server viel einfacher einzurichten ist als Tvheadend, das Repro viel besser gepflegt sind und der Support im Forum super ist! Außerdem glaube ich das TVheadend nicht mehr lange lebt.
Aber das Verhalten mit dem Memory ist unabhängig von dem TV Server.
Habe mich nicht weiter damit beschäftigt, aber ich glaube hier: [1] inklusive der Folgeposts geht es um das gleiche Problem und wie es scheint gibt es dort wohl auch eine Lösung.
[1] https://forum.proxmox.com/threads/c...iller-kill-processes.67666/page-2#post-486905
[1] https://forum.proxmox.com/threads/c...iller-kill-processes.67666/page-2#post-486905
Das ist nur der Workaround für RAM-Überlauf.
Hmm... Bin jetzt auf einem Debian 11 Image, aber nach ca. 1 Stunde bekomme ich bei mehreren parallelen Streams auf einem Transponder nur noch Continuity Errors und die Streams freezen. Ich verstehs nicht
Scheint bei mir auch zu funktionieren, aber ich habe noch nicht lange getestet.
Last edited:
Auf der 4.3-2027~ge3f4f222e.
Ich habe das "unstable" repro von tvheadend. Das ist meines Wissens die einzige Distribution, die auf Debian bullseye läuft.
Läuft seit dem 19.9. stabil.
Das halte ich für ein Gerücht.
Nimm doch einen anderen Tuner, dann sind die Probleme gelöst.