Posts by MarkusE

I downgraded to v2.4.5, same behaviour.

Im git ist ein update. Bitte testen

> The wheel moves up/down in the menu and controls volume without it.

While the volume control with wheel works like a charm, the wheel does not move up/down in the menu. How could that be fixed?

All other feature described in #1 work fine

Quote from SHofmann

Aber es macht doch überhaupt keinen Sinn, ein Zeichen im Titel falsch – in diesem Fall als Indikator für ein Unterverzeichnis – zu interpretieren. Ich finde, kls sollte das ändern.

Das zu ändern wäre eine Inkompatibilität, und sollte vermieden werden.

Es gibt hier auch kein richtig oder falsch. VDR definiert eindeutig, wie welches Zeichen zu interpretieren ist. Damit macht VDR das richtig. Falsch wäre, wenn es diese Definition nicht gäbe oder sie zweideutig wäre.

Quote from MegaV0lt

Was ist \x16 für ein Zeichen? Die Meldung kommt ja bei jedem Klick auf einen Punkt im Menü

https://www.ascii-code.com/de

-> Synchronisierungssignal

Quote from MegaV0lt

Funktionieren tut alles. Nur die Meldungen kommen wenn ich z. B. auf 'Timer', 'Programm' oder 'Suche' (Betrifft alle Menü-Punkte) gehe

Code

Okt 31 07:13:01 vdr01 vdr[1757]: 2025-10-31 07:13:01.29807 [1757.139643412543040] WARN tntnet.httpmessage.parser - invalid character '\x16' in method
Okt 31 07:13:01 vdr01 vdr[1757]: 2025-10-31 07:13:01.29809 [1757.139643412543040] WARN tntnet.worker - bad request
Okt 31 07:13:01 vdr01 vdr[1757]: 2025-10-31 07:13:01.30034 [1757.139643387364928] WARN tntnet.httpmessage.parser - invalid character '\x16' in method
Okt 31 07:13:01 vdr01 vdr[1757]: 2025-10-31 07:13:01.30036 [1757.139643387364928] WARN tntnet.worker - bad request

Ich kann das hier nicht reproduzieren. Die Fehlermeldung hilft auch nicht wirklich. Warum und wie '\x16' zu tntnet kommt, ist auch unklar. Eigentlich ersetzt AppendHtmlEscapedAndCorrectNonUTF8 so was durch '?'.

Also, wenn live ansonsten fehlerfrei funktioniert, würde ich diese Meldungen einfach ignorieren.

MegaV0lt , funktionieren die Timer mit dem aktuellen git?

Quote from MegaV0lt

Wenn ich in Live auf z. B. Timer gehe erscheint im Syslog:

Code

Okt 27 16:57:55 vdr01 vdr[25333]: 2025-10-27 16:57:55.62258 [25333.140119054992960] WARN tntnet.httpmessage.parser - invalid character '\x16' in method
Okt 27 16:57:55 vdr01 vdr[25333]: 2025-10-27 16:57:55.62259 [25333.140119054992960] WARN tntnet.worker - bad request
Okt 27 16:57:55 vdr01 vdr[25333]: 2025-10-27 16:57:55.62735 [25333.140119432468032] WARN tntnet.httpmessage.parser - invalid character '\x16' in method
Okt 27 16:57:55 vdr01 vdr[25333]: 2025-10-27 16:57:55.62737 [25333.140119432468032] WARN tntnet.worker - bad request

Im git ist ein Update. Bitte testen. Ich kann das nicht selbst testen, da bei mir der Fehler nicht auftritt.

Quote from MegaV0lt

Klappt noch nicht so richtig:

Folge 7 wird als 1 aufgenommen und Folge 8 ganz ohne Infos

Im git ist ein Update. Ich habe jetzt int dist_required_if_episodeName_ext_epg_provider_is_available = 500 gesetzt.

Damit erkennt tvscraper, dass die korrekte Episode nicht in TheTVDB ist, wenn Daten von einem externen EPG Provider da sind.

Wenn der Patch in epgsearch drin ist werde ich mir den live Patch vornehmen

im git ist ein update

Quote from clausmuus

Getestet wurde mit folgenden Versionen:

b3136f7a080a7c8557f274ba7ce53b1972b0cad4 (vom April), keine Probleme

aab7739d6c15543288436ac5b9edd13d6ab65518 hatte Probleme mit defekten UTF-8 Zeichen im EPG

6df137173e33937e13ca72c3350e5c304bc99fbf funktioniert Programme und Aufnahmen nicht mehr, dafür gibt's aber keine Probleme mit defektem UTF-8

Und wenn ihr bei i6df137173e33937e13ca72c3350e5c304bc99fbf im Browser das java-script Debugging einschaltet, kommt der Fehler, dass LabelAndAction nicht definiert ist. Und wenn ihr dann den Browser Cache leert (manchmal muss man das auch 2 mal machen, in Firefox mit strg-F5), dann funktioniert es wieder. Korrekt?

> Ich bin jetzt auch nochmal auf die live Version 3.5.2 von gestern vor der Änderung zurück.

Schreibe doch bitte mal genauer, mit welchem commit es noch geht, und mit welchem dann nicht mehr.

Und, wenn es nicht geht: erst mal Browser Cache leeren, geht bei mit mit Strg-F5

> Wie soll das gehen?

Habe ich doch schon geschrieben:

Quote

Oder, einfacher: In der Liste der Timer in live ist eine Spalte "Suchtimer". Ein Click da drauf bringt Dich genau zum dem Suchtimer, der den Timer erstellt hat.

Quote from MegaV0lt

Das verstehe ich nicht. Identische Timer sollen ja nicht erzeugt werden. Aber die Prüfung auf Staffel Ab sollte doch erfolgen, auch wenn sich titel und Kurztext nicht geändert haben.

Ich vermute, Du hast mehrere Suchtimer, die zu einem bestimmten Event einen Timer erstellen würden. Wenn dann einer dieser Suchtimer einen Timer erstellt hat, hat dieser Suchtimer gewonnen, und alle anderen Suchtimer ignorieren das Event.

Wenn also ein Timer nicht so aussieht / upgedatet wird wie erwartet, dann musst Du als Erstes herausfinden, welcher Suchtimer bei diesem Timer gewonnen hat.

<s-id>350</s-id>
<s-id>437</s-id>
<s-id>527</s-id>

jetzt müsstest Du mal schauen, welche Suchtimer das sind

Oder, einfacher: In der Liste der Timer in live ist eine Spalte "Suchtimer". Ein Click da drauf bringt Dich genau zum dem Suchtimer, der den Timer erstellt hat.

Quote from MegaV0lt

Die Suchtimer zu 'Chicago Fire', 'Chicago Med' und 'Chicago P.D.' sind doch relativ eindeutig und haben auch unterschiedliche 'Suchtimer-ID'. Wie kommt EPGSearch dazu zu denken sie seien von einer anderen Suche erstellt worden?

Poste doch mal das AUX Feld der erstellten Timer. In diesem Feld steht, von welchen Suchtimer dieser Timer erstellt wurde.

Quote from clausmuus

Dann scheint der live crash immer dann aufzutreten, wenn beim Empfang von EPG Daten, diese nicht korrekt Konvertiert werden können. Warum das bei der MLD-6.5 der Fall ist, müssen wir noch untersuchen. Aber unabhängig davon sollte live sich nicht an fehlerhaften Zeichen erhängen. Die 3.5.0 war da ja noch unempfindlicher.
Franky kann Dir bestimmt eine epg.data (und dazu passende channels.conf Zeile) zur Verfügung stellen, die diese fehlerhaft Kodierten Zeichen enthält, damit Du das nachstellen kannst. Du musst dann nur dafür sorgen, dass der VDR nicht die EPG Daten überschreibt (also z.B. den EPG Scan abschalten und beim Einschalten einen anderen Senden vorauswählen).
Beim VDR Start gibt's bei der MLD die gleichen charset Log Meldungen.

Da hast Du natürlich recht.

tntnet crasht bei ungültigem utf-8. live konvertiert daher ungültiges utf-8 in '?'. Das ist bei Multischedule verlorengegangen, warum ist mir unklar. Ich habe es jetzt wieder eingebaut, es ist also im aktuellen git. Leider im Blindflug, da ich keine Möglichkeit zum Testen habe.

Daher die Bitte an Euch, mit dem jetzt aktuellen git (commit -m "utf8-sanitize-multischedule") zu testen. Wenn damit der Fehler immer noch auftritt, könnt ihr mir ja hier Testdaten verfügbar machen.

ist im git