Transstreamproxy liefert Fehlermeldungen

JudgeDredd-vuplus · 4. Januar 2022, 15:37

Hallo Zusammen,

aktuell habe ich ein Problem mit dem Transstreamproxy Service meiner UNO4K.

Der Service schreibt mir im Sekundentakt folgende beide Meldung ins transtreamproxy.log

Quellcode

.[1;31m[ ERROR].[00m[1049] no found request done code. (std::exception) (main.cpp, main:389)
.[1;31m[ ERROR].[00m[1049] signal no : Broken pipe (13) (main.cpp, signal_handler:550)

Der Stream ohne Transcoding (Port 8001) sowie der transcodierte Stream (Port 8002) funktionieren beide ohne merklichen Probleme.

Grundsätzlich würde mich die LOG-Datei auch nicht weiter stören, wenn die nicht im Flash der Box liegen würde (/tmp).
So kommt es nämlich, das mein Monitoringscript Alarm geschlagen hat, da die Dateigröße schnell auf mehrere MB anwächst.

Wenn ich das Paket "enigma2-transtreamproxy (2.0-r11-vti03+git38+7675a1e-r11-vti03)" deinstalliere, passiert nichts und die Logeinträge kommen weiterhin.
Erst wenn ich das Paket "enigma2-plugin-systemplugins-transcodingsetup (vti-15.0.0-20200921-r00r01)" deinstalliere hören die Logmeldungen auf.

Wer kann mich denn mal in die richtige Richtung schieben, wie ich das Problem in den Griff bekomme ?
Sicherlich kann ich notfalls neu flashen und hoffen das es aufhört, aber die Ursache würde mich mehr interessieren.

Gruß,
JudgeDredd

GaborDenes · 4. Januar 2022, 16:19

JudgeDredd-vuplus schrieb:

LOG-Datei auch nicht weiter stören, wenn die nicht im Flash der Box liegen würde (/tmp).

/tmp liegt im RAM, nicht im Flash, das macht es aber nicht besser.

rdamas · 4. Januar 2022, 16:47

Wenn du an den Fehlermeldungen nicht interessiert bist und das Transcoding problemlos läuft, versuch mal, ob du die Fehlermeldungen komplett abschalten kannst. Dazu per SSH/Telnet/Putty/Konsole eingeben:

echo 0 > /tmp/.debug_on

Auch diese Datei liegt im RAM, muss also nach Boxenstart wieder angelegt werden - wenn es denn funktioniert...

JudgeDredd-vuplus · 4. Januar 2022, 17:09

rdamas schrieb:

... versuch mal, ob du die Fehlermeldungen komplett abschalten kannst...
echo 0 > /tmp/.debug_on

Nein, leider keinen Erfolg. Die Logeinträge kommen unverändert weiterhin.

rdamas · 4. Januar 2022, 17:17

Dann fällt mir als Workaround nur noch ein, das Logfile vor dem Start des Streams (also z.B. beim Start der Box) auf nicht-änderbar zu setzen. Der transtreamproxy ignoriert soweit ich das sehe den Fehler, dass er das Logfile nicht anlegen und schreiben kann.

Kannst ja mal versuchen:

> /tmp/transtreamproxy.log (leert die Logdatei und legt sie an, wenn nicht vorhanden)
chattr +i /tmp/transtreamproxy.log (setzt die Logdatei auf "immutable", also nicht-änderbar)

Evtl. tut's auch ein ln -s /dev/null /tmp/transtreamproxy.log

JudgeDredd-vuplus · 4. Januar 2022, 17:57

Hallo,

also die Idee, die Dateirechte mit
chattr +i /tmp/transtreamproxy.log
oder auch
chmod -w /tmp/transtreamproxy.log
anzupassen hatte ich schon im Vorfeld, war aber nicht erfolgreich.

Ich habe jetzt mal die Transcoding Pakete deinstalliert, damit mir das Monitoring nicht amok läuft.
Vielleicht kommen ja noch ein paar Tips zur Ursachenfindung.

Ansonsten bügel ich halt mal ein frisches Image drüber.
von den /etc Dateien hab ich sowieso ein Backup

Trotzdem Danke schonmal für den Versuch der Symptombekämpfung.

rdamas · 4. Januar 2022, 18:18

Also willst du gar nicht transkodieren? Dann kannst du auch den Port in der Datei /etc/inetd.conf abklemmen. Vielleicht hilft aber auch eine Neuinstallation, einen Versuch ist es wert.

Und wirf gerne auch mal einen Blick in die Sourcen. Der Fehler, der da protokolliert wird, wird durch fehlerhafte HTTP-Anfragen erzeugt. Woher die kommen, musst du mal bei dir im Netzwerk nachforschen - evtl. mit tcpdump/wireshark/... Jedenfalls macht nicht der transtreamproxy der Fehler, sondern irgendwelche Requests in deinem Netzwerk.

(Ich hab auch so ein nerviges Internet-Radio, das keine richtigen avahi-Requests kann und mein Log vollmüllt. "chmod -w" interessiert den Root-User übrigens ziemlich wenig.)

JudgeDredd-vuplus · 4. Januar 2022, 18:43

rdamas schrieb:

Also willst du gar nicht transkodieren?

Doch im Büro habe ich nur Monitore, aber ich habe ja noch die UNO4KSE.

rdamas schrieb:

Dann kannst du auch den Port in der Datei /etc/inetd.conf abklemmen.

Stimmt, die beiden Ports auskommentieren wäre die Alternative zum Paket deinstallieren.

rdamas schrieb:

Und wirf gerne auch mal einen Blick in die Sourcen. Der Fehler, der da protokolliert wird, wird durch fehlerhafte HTTP-Anfragen erzeugt. Woher die kommen, musst du mal bei dir im Netzwerk nachforschen - evtl. mit tcpdump/wireshark/... Jedenfalls macht nicht der transtreamproxy der Fehler, sondern irgendwelche Requests in deinem Netzwerk.

Das ist ja schonmal ein Hinweis. Mein Netzwerk ist in der Tat etwas umfangreicher. Vielleicht pack ich die VU mal in ein VLAN und schau mal was da so alles kommt. Wobei ich eher vermute, das die Anfragen aus dem gleichen Subnet kommen.
Spekulation: Mit der anderen UNO4KSE kann das aber nix zu tun haben, oder könnte es sein, das die die Request schickt ?

rdamas schrieb:

(Ich hab auch so ein nerviges Internet-Radio, das keine richtigen avahi-Requests kann und mein Log vollmüllt. "chmod -w" interessiert den Root-User übrigens ziemlich wenig.)

Multicast mag ich wie Fußpilz. Das mag ja für App-Liebhaber (ich hasse auch Apps :cursing:

) die auf die "Installationsautomatik" stehen, toll sein. Ich bin da etwas anders veranlagt. Ganz speziell wird es dann die Anfragen mit einem IGMP-Proxy auch noch zu routen.
Naja, ist nur meine Meinung und hat ja nix mit dem Problem zu tun. Also rege ich mich auch nicht auf :saint:

rdamas · 4. Januar 2022, 19:14

Mir fallen noch zwei (eher ein-drei-viertel) Lösungen ein:
- das Programm patchen und den String /tmp/transtreamproxy durch einen nicht existierenden Pfad ersetzen (z.B. /nix/transtreamproxy)
- das Programm neu übersetzen; allerdings fehlt dann wohl ein VTi Patch:

Source: git://code.vuplus.com/git/filestreamproxy.git;protocol=git;branch=transtreamproxy file://vti_set_additional_header.patch

- übersetzen wäre ja kein echtes Problem (gcc => meine "Database" Einträge).

JudgeDredd-vuplus · 4. Januar 2022, 20:02

rdamas schrieb:

- das Programm patchen und den String /tmp/transtreamproxy durch einen nicht existierenden Pfad ersetzen (z.B. /nix/transtreamproxy)

Aber wer weiß, ob dann nicht der Pfad angelegt wird. Wäre aber theoretisch eine Idee

rdamas schrieb:

das Programm neu übersetzen; allerdings fehlt dann wohl ein VTi Patch:

Gegen compilieren habe ich grundsätzlich nichts einzuwenden (mache ich mit Samba auch selbst). Allerdings habe ich dann wieder eine Diskrepanz zu der anderen VU und dem Feed.

Ich denke mal ich fang mal am Wochenende mit dem flashen von VTI an und im Falle von weiteren Problemen, gehe ich dann die Ideen der Reihe nach durch.

GaborDenes · 4. Januar 2022, 20:04

JudgeDredd-vuplus schrieb:

Ansonsten bügel ich halt mal ein frisches Image drüber.

wenn du vorher noch ein Image erstellst, bist du sehr schnell wieder auf dem jetzigen Stand zurück.

anudanan · 4. Januar 2022, 20:10

Aus Interesse und da ihr ja schon recht gut auf der Spielwiese hier unterwegs seid, eine Frage an euch.

Könnt ihr bei der transstreamproxy beim Abspielen von Aufnahmen z.b. mit dem VLC oder anderen Player Spulen oder Springen?

Meiner bisherigen Erkenntnis nach geht das nicht so ohne weiteres, weil der VLC oder andere Player einen neuen HTTP Request aufmachen und der alte noch offen ist und deshalb der HTTP Request abgelehnt wird, weil die Transcoding HW belegt ist. Zumindest bei den Boxen mit einer Transcoding HW. Bei der Ultimo4k oder Duo4kse könnte das sogar gehen.

Das ist zumindest beim openpli mit dem dortigen originalen streamproxy so.
Ich habe das ganze Teil dann mal umgeschrieben, damit das klappt. Bei mir geht das jetzt.

Da ich das mit einem vti aber nie probiert habe, wäre das mal interessant zu erfahren.

rdamas · 4. Januar 2022, 20:13

Der Pfad wird nicht angelegt:

Quellcode

char path[256] = {0};
sprintf(path, "%s.log", aName);
if (!(mLogHandle = fopen(path, "a+"))) {
mLogHandle = 0;
// printf("fail to open logger [%s].", path);
return false;
}

und

objdump -T /usr/bin/transtreamproxy | grep mkdir

@anudanan: keine Ahnung, hab den transtreamproxy eher noch nie benutzt, und werde ich wohl auch nicht, weil im lokalen Netzwerk der streamproxy sehr gut funktioniert.

anudanan · 4. Januar 2022, 20:18

Ist bei der VU der streamproxy ein eigenständiger Prozess, der das normale Streamen macht?
Den gibt es beim openpli gar nicht, weil das im enigma direkt enthalten ist.

rdamas · 4. Januar 2022, 20:37

Ja.

Source: git://schwerkraft.elitedvb.net/streamproxy/streamproxy.git;protocol=git file://vti_oe_e2_1.patch file://vti_support_remote_hbbtv.patch

hajeku123 · 4. Januar 2022, 21:01

rdamas schrieb:

ln -s /dev/null /tmp/transtreamproxy.log

@JudgeDredd-vuplus
Wenn du das so machen willst, die Log Datei erst erstellen lassen und im laufenden Prozess rm /tmp/transtreamproxy.log && ln -s /dev/null /tmp/transtreamproxy.log

rdamas · 4. Januar 2022, 21:11

Ich glaube, das geht nicht, wenn ich den Code richtig verstanden habe: der Logger wird am Anfang im Konstruktor initialisiert und merkt sich von dort ein offenes File-Handle.

Wenn du das File in tmp löscht, wird dann weiter ins RAM geschrieben, nur dass man es nicht mehr im Filesystem sieht. Der Logger öffnet nur die Datei ( fopen(path, "a+") ), das sollte meiner Meinung nachmit dem existierenden Symlink genauso funktionieren, oder?

hajeku123 · 4. Januar 2022, 21:54

Ich habe in den Sourcecode nicht reingeschaut. Wenn ein File-Handle offen bleibst ist das natürlich doof.
Dann bringt es nichts, die Datei zu löschen.
Vorher einen Symlink anzulegen ist dann sicherlich die sicherste Variante

@rdamas
Ich habe das bislang aber immer so verstanden, dass wenn eine Datei mit offenem File-Handle gelöscht wird, nichts weiter geschrieben wird.
Im Umkehrschluss bedeutet das ja, wenn ein File-Handle zu einer Datei auf der Festplatte offen bleibt die Datei gelöscht wird und dort weiter reingeschrieben wird. die Festplatte trotzdem volllaufen würde.
Das habe ich so noch nicht gesehen.
Ist das so?

EDIT:
Wieder was gelernt

This behavior is because when we remove a file, we’re actually unlinking the file name from the inode. The inode still exists, so we can write to and read from it if we keep the file open.
The system removes the inode when:

There are no more hard links pointing to it
There are no open file handles

This has another effect: If we remove a file but there are still open file handles pointing to it, the amount of free disk space won’t change.

rdamas · 4. Januar 2022, 22:25

Wollte gerade schreiben: ja ist so. Hab ich auch schon oft genug selber gemacht und erfahren. Unter MacOS und Linux kannst du z.B. bei HandBrake das File, welches du rekodierst, schon löschen, während daraus noch gelesen wird. Versuch das mal unter Windows...

Sehr ähnliche Geschichte: ein File umbenennen, während es noch heruntergeladen wird. Geht meine ich auch nicht unter Windows.

Quellcode

Quellcode

Tags