Leider vergessen:
diff --git a/.gitignore b/.gitignore
index f2c4ff9..e5174f4 100644
--- a/.gitignore
+++ b/.gitignore
@@ -3,6 +3,7 @@
/.dependencies_doc
/.doc_stmp
/MANUAL
+/README
/README.DE
/doc/
/html/Nochmal eine kleine Überarbeitung:
… und der Nachweis, dass die Korrektur das Gewünschte leistet, denn der Suchtimer:
0:!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!S:0:::0:0:0:0:1:1:1:0:::1:0:0:1:!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!!^pipe^!D:50:99:2:10:0:0:0::0:0:0:0:0:0:0:0:0:0:0:0::1:0:0:0:0:0:0:0:0:0:90::0… wird ohne den Patch verkürzt angezeigt:
… mit dem Patch aber korrekt:
Der Inhaltsfilter sollte ebenfalls funktionieren. Aufgrund der Art der Speicherung (zwei Hex-Digits pro ID) sollte das aber eh kein Problem sein.
Weil viele Strings kontextbezogen unterschiedlich kodiert werden, habe ich einen anderen Ansatz gewählt:
Der Puffer zum Lesen der Konfigurationsdatei ist jetzt 20 KBytes groß und der Puffer für das Zwischenspeichern eines Suchtimer-Felds auf 10-Byte-Sequenzen für Sonderzeichen ausgelegt. Jedes potentiell kodierte Feld wird sofort dekodiert und in den ursprünglichen Puffer geschrieben.
Damit sollte das Abschneiden von Strings bei maximaler Kompatibilität eigentlich sichergestellt sein. Bitte seht euch das einmal an.
PCRE bietet ja deutlich mehr Möglichkeiten…
Ich habe mir die Spezifikation für die regulären Ausdrücke von std::regex vor einiger Zeit und auch gerade eben nochmals angesehen. Und obwohl ich reguläre Ausdrücke selbst oft mit "allen Schikanen" nutze, vermisse ich eigentlich nichts, was man für Suchtimer so braucht.
Das hat auf Seite der Nutzer ggf. den Nachteil, dass bereits existierende Suchtimer nicht mehr funktionieren…
Was ich bislang nicht gemacht habe, ist, die Features der derzeit genutzten Bibliotheken tre, prce und pcre2 miteinander bzw. mit std::regex zu vergleichen. Ich würde aber erwarten, dass es in der Praxis nur wenige Problemfälle geben sollte. Dennoch ist das Risiko unerwartet fehlschlagender Suchtimer nicht einfach von der Hand zu weisen.
Vielleicht wäre es ja eine Alternative, std::regex im Makefile als vierte (Standard-)Option vorzusehen, um damit die anderen Bibliotheken über die Zeit ausphasen zu können. Wir müssen sowieso damit rechnen, dass irgendeine Distribution eines der Pakete früher oder später nicht mehr unterstützt. Bei Ubuntu ist mir Vergleichbares mit anderen Paketen schon das eine oder andere Mal passiert.
Unschön ist, dass bei der Expansion von Strings zum Speichern der Konfiguration einzelne Zeichen durch 8- bzw. 9-stellige "Makros" ersetzt werden…
Vielleicht muss man gar nicht so weit gehen, wie ich es hier skizziert habe. Wir haben einen MAXPARSEBUFFER von derzeit 10 KBytes. Jeder String hat eine Größe von MaxFileName (entspricht NAME_MAX) = 255 Bytes. Damit erfordert im Worst Case ein String von 254 Sonderzeichen (vereinfacht gerechnet) zur Codierung mit jeweils 10 Escape-Zeichen knapp 2,5 KBytes. Da wir derzeit fünf Strings pro Suchtimer haben (von denen derzeit nur Suchmuster, Kategorien und Serien-Verzeichnis derart kodiert werden), wäre der Puffer etwas zu knapp bemessen. Die Puffergröße (und damit die maximale Zeilenlänge der Konfigurationsdatei) sicherheitshalber auf 20 KBytes (vielleicht auch auf MaxFileName * 10 /*escaping*/ * 5 /*strings*/ + KILOBYTES(5) /*remainder*/) zu ändern, wäre aber wohl einfacher und weniger invasiv.
Die Codierung solcher Sonderzeichen selbst ist natürlich nach wie vor unschön und auch nicht für alle Strings einheitlich, siehe auch epgsearchext.c, Zeile 301 ff. für Kategorien:
while (strstr(catvalue, ":"))
catvalue = strreplace(catvalue, ":", "!^colon^!"); // ugly: replace with something, that should not happen to be part of a category value
while (strstr(catvalue, "|"))
catvalue = strreplace(catvalue, "|", "!^pipe^!"); // ugly: replace with something, that should not happen to be part of a regular expression… bzw. Zeile 248 ff. für Suchmuster, Inhaltsfilter und Verzeichnisse:
char* replaceSpecialChars(const char* in)
{
char* tmp_in = strdup(in);
while (strstr(tmp_in, "|"))
tmp_in = strreplace(tmp_in, "|", "!^pipe^!"); // ugly: replace a pipe with something
strreplace(tmp_in, ':', '|');
return tmp_in;
}Was nach wie vor nicht passt, ist, dass in epgsearchext.c, Zeile 424, beim Parsen die Stringlänge auf MaxFileName begrenzt wird:
if (valuelen > MaxFileName) valuelen = MaxFileName;
strn0cpy(value, pos, valuelen);… obwohl die Sonderzeichen an dieser Stelle noch nicht "dekodiert" sind (was erst nach dem vollständigen Parsen aller Felder in Zeile 647 und somit auf Basis der potentiell gekappten Strings erfolgt). Und damit werden Konfigurationsdaten – wie eingangs angemerkt – möglicherweise gekappt. Man müsste die Dekodierung also bereits hier vornehmen. Vielleicht sollte man besser grundsätzlich jeden String kodieren bzw. dekodieren; eine Dekodierung von Nicht-String-Daten wäre wohl unkritisch, weil solche Daten (Zahlen, Transponderkennungen usw.) die Escape-Sequencen wohl kaum enthalten dürften.
Alle Strings zentral zu kodieren und dekodieren müsste ich allerdings noch testen. Der Kompatibilität halber wäre dieser Ansatz aber die am wenigsten invasive Methode.
Im Code sind mir ein paar Kleinigkeiten aufgefallen, die vielleicht berichtigt werden sollten:
Keine Ahnung, wer von den sieben Kontributoren in GitHub nun der Haupt-Maintainer ist: TomJoad, schau dir das doch bitte mal an und entscheide, ob der Patch in die offizielle Codebasis übernommen werden soll. Hier eine Übersicht der wichtigsten Änderungen:
Noch ein paar Gedanken zum Schluss:
Sagt Bescheid, wenn ich euch bei solchen Arbeiten helfen kann.
Danke für die Rückmeldung. Ich versuche das umzusetzen. Da manche Icons vom EPG-Status abhängen, ist die Ermittlung der sichtbaren Icons für die Spaltenbildung vermutlich etwas schwieriger als bei den Aufzeichnungen.
Bei Programm und Timern haben wir ja glücklicherweise immer gleich viele, die alle in eine einzige Spalte passen.
Mit etwas generativer Hilfe bekommt man das Ganze schon hin. Hier mit vertikaler Ausrichtung mein derzeitiger Stand für bis zu 3 Icons (einspaltig) bzw. mehr als 3 Icons (zweispaltig):
Nur falls die Frage aufkommt: In siteprefs.css kann man auch für schmale Displays die Streaming-Icons anzeigen lassen.
Passt das so? Oder sollen 4 Icons lieber als 1x4 bzw. 2x2 angeordnet werden?
Und soll dieses Schema auch für "Was läuft" gelten? Derzeit sind die Icons dort noch horizontal angeordnet:
… weshalb ich es auch bei den Aufzeichnungen aus Gründen der Vereinheitlichung so vorgesehen hatte:
Ich für meinen Teil fände es so besser, wie es aktuell ist. Aber ich richte mich da nach euren Wünschen und konfiguriere es mir lokal so, wie ich es für mich gerne hätte… 
Ich habe den Patch bei mir aus gutem Grund mit drin. Und damit läuft bei mir seit Ewigkeiten alles so, wie es soll.
Mich muss also keiner überzeugen oder bekehren. Ausgangspunkt war doch – siehe oben –, dass nobanzai ähnliche Probleme hatte ich wie ich früher. Und falls andere diese auch haben, wäre eine "offizielle" Unterstützung halt hilfreich…
Was nützt dir das?
z.B.: wenn satip plugin genutzt wird, und aus igendeinem Grund nicht startet, hast du auch keine Aufnahme.
Auf einen Aspekt möchte ich aber schon noch hinweisen: Wenn der VDR wegen eines "zickigen" Plugins einfach einen Emergency-Exit vollführt, können prinzipiell zwei Dinge passieren:
In einer solchen Fehlersituation erfolgt also weder die nächste programmierte Aufnahme (Fall 1) noch wird der Rechner mit Programmierung der nächsten Startzeit heruntergefahren (Fall 2). Beides ist unschön.
Wenn der VDR – in unserem Fall wegen eines "defekten" Plugins – nicht anläuft, sollte der VDR meines Erachtens zumindest den Versuch unternehmen, die nächste Aufnahmezeit zu programmieren, bevor er den Emergency-Exit vollführt. Selbst wenn das VDR-Startskript den Rechner schlussendlich schlafen legen würde, würde der Start des VDR für die nächste Aufnahme wenigstens erneut versucht.
Wenn ich den Code richtig verstanden habe, gibt es primär zwei Gründe, warum das Laden eines Plugins fehlschlagen kann:
Was ein Plugin beim zweiten Schritt so alles treibt und warum es hier einen Fehler liefern könnte, lässt sich wohl nicht vollumfänglich ergründen. Ob ein Plugin hier zum Beispiel schon seine Konfigurationsdateien prüft und bei Problemen deshalb streikt, ist nicht auszuschließen. Auch wenn du vielleicht argumentieren magst, dass dergleichen nicht an dieser Stelle sondern vielleicht besser bei Initialize() erfolgen sollte. Doch hier in Form finden sich, wenn ich mich recht entsinne, etliche Beispiele für Plugins, die nach einem Neustart plötzlich nicht mehr gelaufen sind…
Seitdem ich den Patch drin habe, startet der VDR jedenfalls zuverlässig, wohingegen er vorher beim zeitgesteuerten Start für programmierte Aufnahmen schon hin und wieder über Plugins "gestolpert" ist und die Aufnahmen deshalb nicht durchgeführt wurden.
Dann lieber gleich gar nicht starten und den Benutzer dazu "zwingen", das Problem zu beheben.
Wenn wegen so etwas eine Aufnahme ausfällt, findet man das in der Regel nicht lustig… deshalb auch der Patch als "Weichmacher".
Evtl. ist es einfacher und besser, wenn man die Anzeige generell ein- und ausschalten könnte. Ich bin kein css Profi, aber evtl. könnte man in der oberen Zeile eine Checkbox einfügen, die den entsprechenden Tabellenzeilen on-the-fly ein "style=visibility:collapse" verpasst?
Ein bisschen anders sollte man das schon lösen, nämlich so, dass per Javascript der Klasse existing_recording in diesem Kontext ein display: none hinzugefügt oder dieses per revert-layer "gelöscht" wird; alternativ könnte man auch zwischen visiblility: hidden und visibility: initial hin- und herschalten. Man hätte somit nur eine Aktion auf der Klasse für alle betroffenen Zeilen der gesamten Tabelle statt einer Aktion für jede einzelne betroffene Zeile. Und neben der deutlich besseren Performanz bräuchte man auch keine Buchführung für bzw. Suche per Javascript vornehmen. Unangenehm wäre natürlich, wenn der Knopf oben in der Tabelle angesiedelt ist und man sich gerade weit unten in einer langen Programmübersicht befindet.
Aber wenn wir schon beim Brainstorming sind: Wie wäre es denn, Sendungen mit (vermeintlich) vorhandenen Duplikaten nur per Icon oder farblich zu kennzeichnen? Oft reicht das ja schon. Bei gefundenem Duplikat könnte man dann, wenn mehr Details gewünscht werden, wie üblich per Klick ein Info-Fenster für die vorhandene Aufzeichnung aufrufen. Dieses (neue) oder das derzeitige Verhalten sollte aber in den Einstellungen festgelegt werden können, weil manchem die komplett eingefügte Info lieber sein könnte.
Mir würde die derzeitige Lösung aber völlig genügen…
man könnte das ja in Abhängigkeit von der Zahl der Icons machen. Z.B zwei Icons untereinander, und bei drei Icons müsste man das prüfen. Wenn es mehr sind bräuchte man in jedem Fall mehr als eine Spalte.
Ich sehe eine Grenze bei drei, max. vier vertikalen Icons. Zum Vergleich die Situation bei "Programm":
Mit vier Icons wäre der zusätzlich eingenommene Platz meines Erachtens gerade noch akzeptabel:
CSS3 kann viel, doch ob man die Zahl der sichtbaren Icons als Selektor charakterisieren kann, ist fraglich – aber auch spannend. Ich überlege mir mal was.
Die Fallback-Lösung wäre jedenfalls, die standardmäßig max. vier Icons (Wiedergabe, IMDb gemäß Einstellungen, Bearbeiten, Löschen) wie bisher (und oben gezeigt) untereinander anzuordnen. Wer (wie ich) die Streaming-Icons über die siteprefs.css aktiviert, bekommt dann entweder 3x2 (dreispaltig wie derzeit):
… bzw. 2x3 (zweispaltig, falls präferiert):
… was auch eher der Anordnung in "Programm" entspräche.
Wie sind die Präferenzen?
Beispiel 2 siehe Anhang. Ich weiß nicht, wie das Feature gedacht ist, aber ich hätte erwartet, dass es vorhandene Aufnahmen anzeigt, die mit dem Event identisch sind. Das macht es aber nicht.
Die Event-ID kann dafür nicht herangezogen werden, weil jede Instanz einer Nachrichtensendung im EPG eine eindeutige Event-ID besitzt. Selbst wenn man die Event-ID in der Aufzeichnung gespeichert hätte, bekäme man (ausgenommen bei gerade laufender Aufnahme einer Sendung) keinen Match mit dem EPG.
Wenn ich den Code (recman.cpp, Zeile 444 ff.) richtig verstanden habe (Markus kann das gegebenenfalls noch genauer beschreiben), vergleicht Live in erster Linie den Titel eines Events mit den Namen der Aufzeichnungen auf der Festplatte. Erst wenn diese nicht übereinstimmen, werden in weit geringerem Maße Kurztext und Beschreibung zum Vergleich herangezogen (Zeile 466 ff.) – mit der Zielsetzung, möglichst noch ähnliche Aufzeichnungen zu finden – und nicht, um sie auszusortieren.
Und gerade bei den Nachrichtensendungen ist der Inhalt bis kurz vor der Sendung recht allgemein gehalten (siehe auch die Screenshots weiter oben):
…weshalb der Vergleich meist positiv ausfällt.
im schmalen Modus werden zur Zeit die Icons rechts noch nebeneinander angezeigt (bei Aufnahmen). In diesem Modus sollten sie untereinander sein. Könntest Du das bitte noch ändern?
In deinem Beispiel sind offenkundig alle Optionen zur Anzeige weiterer Icons abgeschaltet, also keine Streaming-Icons, keine IMBD-Links usw. Insofern ist dein Beispiel nicht allgemeingültig, wie dieses Beispiel zeigt:
Die starre Anordnung untereinander ist da sehr ungünstig:
Eine ziemliche eine Platzverschwendung, wie ich finde, weshalb ich das eigentlich nicht ändern möchte. Und bringt das von Platzbedarf her (gesparte 20px bei zwei bzw. 40px bei drei Icons nebeneinander) wirklich so viel, dass man die enorme Höhe angesichts von möglicherweise hunderten von Aufzeichnungen in Kauf nehmen will?
Aber wenn du darauf bestehst, können wir die "flexiblere" Anordnung natürlich in die siteprefs.css verlagern. Andere Meinungen hierzu?
Zusatzfrage: Warum startet VDR die alphabetisch nach einem Plugin (hier skincurses) gelegenen Plugins (hier tvscraper ...) nicht mehr, wenn ein Plugin so einen Fehler bringt?
Damit das nicht passiert, verwende ich schon seit Jahren folgenden Patch:
Eventuell könnte kls das in den VDR übernehmen und beide Verhaltensweisen (ähnlich dem Emergency Exit) konfigurierbar gestalten.
Was mir aufgefallen ist,unter Fernbedienung kein funktion F11 bei firefox & google-chrome.
Mit Firefox 138 und Chrome 136 poppt im OSD meines Produktiv-VDR der Lautstärke-Balken auf und erhöht bzw. verringert den Lautstärkewert. Weil der VDR aber in einem anderen Zimmer steht, fehlt die akustische Kontrolle. Ich gehe aber davon aus, dass sich die Lautstärke am VDR entsprechend der Anzeige im OSD ändert.
Bei meinem Entwicklungssystem ohne Ausgabe-Device lässt sich die Lautstärke nicht regeln, was ja auch nachvollziehbar ist.
Wie man sieht,hat sich die Umstellung auf css absolut gelohnt!
Danke, sehe ich auch so. Mit Firefox und Chrome habe ich auch auf einem Android-Handy getestet. Gespannt bin ich noch auf die Rückmeldungen von Safari-Nutzern, also Live unter macOS und iOS. Ich habe mich an den Kompatibilitätsübersichten orientiert und erwarte eigentlich keine Probleme… get your fingers crossed!
Ein paar Kleinigkeiten sind vielleicht noch anzupassen:
Was denkt ihr darüber? Und das eine oder andere sehen wir wohl erst dann, wenn die Zahl der Nutzer des neuen GUI und damit Zahl unterschiedlicher Environments steigt. Ich bin aber zuversichtlich… 
Gebt einfach kurz Bescheid, wenn euch etwas auffällt. Ich sammle das und gebe Markus dann die Korrekturen weiter.
Könnte epgsearch sein, oder auch epgd.
Ich verwende nur EpgSearch und kann diesen Effekt nicht bestätigen. Kling also nach epgd…
Das wurde ja schon gemacht und auch nur für diese Aufnahme, aber wie gesagt ist der Timestamp der Info-Datei nur Sekunden-genau.
Bleibt noch die Frage nach dem Wiedereinlesen im Cutter…
Ich finde, beides ergänzt sich doch recht gut:
Ich hatte den ersten Fall damals gar nicht auf dem Radarschirm. Danke, dass du das Ganze so detailliert untersucht hat. 
