Also bei mir geht es nur von 1-9. Danach gibt es keine Nummern mehr.
Ist das eine Standard VDR Einstellung oder ein Patch?
Das ist ein Patch - früher hieß der menuselection, heute multiple_digit_menu.
Also bei mir geht es nur von 1-9. Danach gibt es keine Nummern mehr.
Ist das eine Standard VDR Einstellung oder ein Patch?
Das ist ein Patch - früher hieß der menuselection, heute multiple_digit_menu.
Hallo,
Ist das eine Standard VDR Einstellung oder ein Patch?
ist wohl der Menuselection.patch den SHofmann verwendet.
Gruss
Wolfgang
Danke, der Hinweis war goldrichtig, daran hatte ich überhaupt nicht mehr gedacht. Das Problem findet sich in Zeile 9:
const char *cOsdMenu::hk(const char *s)
{
static cString buffer;
if (s && hasHotkeys) {
if (digit == 0 && '1' <= *s && *s <= '9' && *(s + 1) == ' ')
digit = -1; // prevents automatic hotkeys - input already has them
if (digit >= 0) {
digit++;
buffer = cString::sprintf("%2d%s %s", digit, (digit > 9) ? "" : " ", s);
s = buffer;
}
}
return s;
}
Display More
Die Leerzeichen sind hier "doppelt gemoppelt", denn das führende Leerzeichen ist überflüssig und mit %2d erzwingt man ja schon die Ausrichtung, sodass man das folgende %s für ein optionales Leerzeichen nicht mehr benötigt:
Und schon bekommt man eine schöne Ausrichtung der Menütexte:
Vielleicht sollte man den aktuellen Patch entsprechend anpassen, falls der noch auf dem alten Stand sein sollte.
Vielleicht sollte man den aktuellen Patch entsprechend anpassen, falls der noch auf dem alten Stand sein sollte.
Isser noch:
Hallo,
sieht hier so aus!
Vielleicht sollte man den aktuellen Patch entsprechend anpassen, falls der noch auf dem alten Stand sein sollte.
Ja gerne!
Gruss
Wolfgang
SHofmann zwar arg off-topic, aber magst du mir verraten, was hinter "11 Vergangene Nachrichten" steckt?
Kann man damit die letzten OSD-Messages anzeigen?
Und "12 Bildschirmfoto" würde mich bitte auch interessieren (ein Skript das einen Screenshot vom TV-Bild macht?).
Nummer 11 ist das alte Plugin mlist, das die OSD-Meldungen für eine spätere Inspektion protokolliert:
Ich habe hinzugefügt, dass man periodische Meldungen (wie etwa die Shutdown-Vorankündigungen) herausfiltern kann.
Nummer 12 ist das Plugin screenshot:
… das ich mir mit ein paar Patches angereichert habe:
Viel Spaß damit! ![]()
Gerade ist mir aufgefallen, dass bei "Web-Streaming" ein div-Element nicht geschlossen wird. Hier der Patch dazu:
diff --git a/pages/stream.ecpp b/pages/stream.ecpp
index c360b9b..4a6c16d 100644
--- a/pages/stream.ecpp
+++ b/pages/stream.ecpp
@@ -230,7 +230,7 @@ if (!epgEvent.Id().empty() ) {
<td class="topaligned">
<div class="withmargin">
<div class="nomargin nowrap"><$ (timeSpan) $></div>
- <div class="duration"><div class="progress"><& pageelems.progressbar progress=(epgEvent.Elapsed()) duration=(epgEvent.Duration()) &></div>
+ <div class="duration"><div class="progress"><& pageelems.progressbar progress=(epgEvent.Elapsed()) duration=(epgEvent.Duration()) &></div></div>
</div>
</td>
<td class="topaligned more">
Display More
Zudem wird die About-Box bei der Fernbedienung nicht korrekt angezeigt:
diff --git a/pages/remote.ecpp b/pages/remote.ecpp
index c0ba17c..0ef823c 100644
--- a/pages/remote.ecpp
+++ b/pages/remote.ecpp
@@ -310,7 +310,7 @@ if (!logged_in && LiveSetup().UseAuth()) {
<body onload="StreamInit(); FillIntervals()" onunload="StreamEnd()" onpagehide="saveScrollPosition('remoteDiv')" onpageshow="restoreScrollPosition()" onkeydown="return KeyboardInput(event);">
<& pageelems.logo &>
<& menu active="remote" component=("remote.remote_actions")>
- <div id="remoteDiv" class="remote">
+ <div id="content"><div id="remoteDiv" class="remote">
<# set containers to 'display: none' to avoid flickering upon loading #>
<div id="screenshot" class="screenshot">
% if (IsGrabImageAvailable() ) {
@@ -353,7 +353,7 @@ if (!logged_in && LiveSetup().UseAuth()) {
<area href="#" shape="rect" coords="110,324,137,339" alt="Blue" onclick="return KeyPress(<$ kBlue $>)" title="&lt;F4&gt;" />
</map>
</div>
- </div>
+ </div></div>
</body>
</html>
<%include>page_exit.eh</%include>
Display More
Im git ist ein Update. Die hier geposteten Korrekturen sind drin.
Außerdem: Nach dem Leeren des Browser-Cache (Strg-F5) sind bei Timern, Timer-Konflikten und Suchtimern die Pfeile in der 1. Spalte weg.
Aus meiner Sicht sind die obsolet, die Information ist ja über die Farbe der Zeile verfügbar.
Also, ich würde die dauerhaft entfernen. Wie seht ihr das? Falls ihr diese Pfeile behalten wollt, kann ich das auch über die siteprefs.css konfigurierbar machen.
Also, ich würde die dauerhaft entfernen. Wie seht ihr das? Falls ihr diese Pfeile behalten wollt, kann ich das auch über die siteprefs.css konfigurierbar machen.
Aus meiner Sicht OK. Aber lass den Code doch erst einmal drin, das display: none genügt meines Erachtens (zumindest fürs erste).
Ansonsten sieht es nach einem ersten kurzen Test gut aus. ![]()
Habe gerade einen dummen Fehler bemerkt, der dazu führt, dass sich in Suchtimern die Einstellungen für Zeit und Dauer nicht mehr löschen lassen:
diff --git a/epgsearch.cpp b/epgsearch.cpp
index 35ead9d..3555e65 100644
--- a/epgsearch.cpp
+++ b/epgsearch.cpp
@@ -175,7 +175,7 @@ std::string SearchTimer::ToText() {
switch (i) {
case 0: os << m_id; break;
case 1: os << ':' << cToSvReplace(m_search, "|", "!^pipe^!").replaceAll(":", "|"); break;
- case 2: os << ":" << (m_useTime ? "1" : ""); break;
+ case 2: os << ":" << (m_useTime ? "1" : "0"); break;
case 3: os << ':'; if (m_useTime) { os.appendInt<4>(m_startTime); }; break;
case 4: os << ':'; if (m_useTime) { os.appendInt<4>(m_stopTime); }; break;
case 5: os << ':' << m_useChannel; break;
@@ -196,7 +196,7 @@ std::string SearchTimer::ToText() {
case 9: os << ':' << m_useTitle; break;
case 10: os << ':' << m_useSubtitle; break;
case 11: os << ':' << m_useDescription; break;
- case 12: os << ':' << (m_useDuration ? "1" : ""); break;
+ case 12: os << ':' << (m_useDuration ? "1" : "0"); break;
case 13: os << ':'; if (m_useDuration) { os.appendInt<4>(m_minDuration); }; break;
case 14: os << ':'; if (m_useDuration) { os.appendInt<4>(m_maxDuration); }; break;
case 15: os << ':' << m_useAsSearchtimer; break;
Display More
Da habe ich wohl einen Testfall übersehen… ![]()
Und noch ein Problem, dass schon seit Urzeiten (zumindest seit v3.5.0) drin ist: Werte von EPG-Kategorien, die Doppelpunkte oder Pipe-Symbole enthalten, werden im Suchtimer-Formular falsch dargestellt (String-Felder) bzw. nicht erkannt (Auswahl per Check-Box):

Das liegt daran, dass Doppelpunkte bzw. Pipes als Separatoren dienen:
:1#Film,Serie|2#Abenteuer,Zeichentrick|3#16!^colon^!9|4#|5#2000|6#Ford|7#Spielberg !^colon^!!^pipe^!!^colon^!!^pipe^!!^colon^! Lucas|8#Tipp|9#12,16,18:
… und deren "Escapes" !^colon^! und !^pipe^! in den Kategorie-Daten nicht ausgetauscht werden.
Hier der entsprechende Patch:
diff --git a/epgsearch.cpp b/epgsearch.cpp
index 3235829..a0a6bb5 100644
--- a/epgsearch.cpp
+++ b/epgsearch.cpp
@@ -291,11 +291,18 @@ void SearchTimer::ParseChannelIDs(cSv data)
void SearchTimer::ParseExtEPGInfo(cSv data)
{
- m_ExtEPGInfo = std::vector<std::string>(cSplit<std::string>(data, '|').begin(), cSplit<std::string>::s_end());
+ m_ExtEPGInfo.clear(); // should be empty anyway, but cater for future use
+ if (!data.empty() && std::isdigit(data[0])) {
+ for (auto part : cSplit(data, '|')) {
+ m_ExtEPGInfo.push_back(std::string(cToSvReplace( part, "!^colon^!", ":" ).replaceAll("!^pipe^!", "|" )));
+ }
+ }
}
void SearchTimer::ParseBlacklist(cSv data)
{
+ m_blacklistIDs.clear(); // should be empty anyway, but cater for future use
+ if (!data.empty() && std::isdigit(data[0]))
m_blacklistIDs = std::vector<std::string>(cSplit<std::string>(data, '|').begin(), cSplit<std::string>::s_end());
}
Display More
(Hinweis: Der Editor hat möglicherweise die letzte Leerzeile wegoptimiert.)
Der Patch prüft zudem, dass die empfangenen EPG-Daten (siehe oben) bzw. Ausschlusslisten:
… mit einer Ziffer für einen Index beginnen; EPGsearch lieferte bei mir im Test hin und wieder (null).
Damit passt wieder alles:

Was mir gerade noch aufgefallen ist: Für das Löschen einer einzelnen Aufzeichnung erscheint eine Nachfrage, für das Löschen mehrerer markierter Aufzeichnung aber nicht. Der versehentliche Verlust einer größeren Zahl von Aufzeichnungen wäre aber besonders ärgerlich. Schön wäre es, käme da auch noch einmal eine Sicherheitsabfrage mit der Liste der zu löschenden Aufzeichnungen.
Ich habe allerdings derzeit keine Idee, wie man das programmatisch am besten bewerkstelligen könnte. Gefallen würde mir, wenn man auf Knopfdruck einen Filter aktivieren könnte, der nur die zum Löschen markierten Aufzeichnungen anzeigt. Dort könnte man einerseits einzelne Aufzeichnungen anhand ihrer Checkboxen wieder herausnehmen bzw. über den (derzeit nicht generierten) grünen Button alle Checkboxen ein einmal deselektieren.
Wie denkst du darüber?
Macht das wirklich Sinn ? Wer beim Löschen auswählen nicht nachdenkt, ob er das alles wirklich löschen will, wird auch die Nachfrage blind durchklicken. Für den der nachdenkt, bevor er was löscht, ist es eine unnötige Abfrage. Zur Not gibt es auch noch das undelete Plugin.
Macht das wirklich Sinn ? Wer beim Löschen auswählen nicht nachdenkt, ob er das alles wirklich löschen will, wird auch die Nachfrage blind durchklicken.
Das ist eine Sichtweise. Und die Nachfrage beim Löschen-Icon in der rechten Spalte stellst du ja auch nicht infrage.
Aber es geht ja nicht nur um die bewusste Auswahl (Intention), sondern auch darum, dass einem dabei ein Fehler unterlaufen kann (Aktion); etwa falsch geklickt und dies nicht bemerkt zu haben. Wem das noch nicht passiert ist, der werfe den ersten Stein…
Mein Use case: Ich nutze die Funktion häufig zum Ausmisten kürzlich angeschauter Episoden von Serien, die über mehrere Ordner verteilt sind. Zur Navigation klappe ich die schon auch mal zu, womit die schon angeklickten Episoden nicht mehr sichtbar sind. Die Ordner zwecks Kontrolle nochmals alle aufzuklappen und visuell nach den gesetzten Häkchen zu suchen, kann ja wohl nicht die Lösung sein. Vor dem Anklicken des Buttons nochmal alle markierten Titel filtern und damit vielleicht auch einen falsch selektierten noch rechtzeitig erkennen zu können, wäre meines Erachtens schon hilfreich, vor allem dann, wenn – wie bei Text-Filtern – die Hierarchie mit angezeigt wird. Und ja, es wird immer Fälle geben, wo auch das Sicherheitsnetz nicht geholfen hat, weil man zweimal zu sehr in Eile oder unkonzentriert war.
Ohne eine solche Kontrolle vor dem Löschen muss man halt das Protokoll nach dem Löschen inspizieren und mit dem Undelete schneller sein als der VDR mit dem Purge. ![]()
Und die Nachfrage beim Löschen-Icon in der rechten Spalte stellst du ja auch nicht infrage.
Nein, weil das wäre ein "one click delete", da macht eine Rückfrage Sinn, weil man könnte ja das Icon daneben treffen wollen.
Bei mehrfach Lösungen sind es immer mindestens die Häcken und dann der "Markierte Löschen", das ist ja damit schon die zweite Abfrage. Die Notwendigkeit für eine dritte Abfrage sehe ich für mich nicht.
Vorschlag: Auf der Seite unten ist ja noch genug Platz für einen zweiten Button. Die, die ihrer Auswahl vertrauen, nutzen weiterhin "Markierte löschen". Wer nochmals überprüfen will, bekommt einen Button "Markierte auflisten".
Nein, weil das wäre ein "one click delete", da macht eine Rückfrage Sinn, weil man könnte ja das Icon daneben treffen wollen.
Die bei Timern übrigens fehlt… da ist mir schon der eine oder andere (Such-)Timer flöten gegangen.
Vorschlag: Auf der Seite unten ist ja noch genug Platz für einen zweiten Button. Die, die ihrer Auswahl vertrauen, nutzen weiterhin "Markierte löschen". Wer nochmals überprüfen will, bekommt einen Button "Markierte auflisten".
Klingt gut, dann hat jeder die Wahl.
Stimmt, das kann bei mir aber kein Problem verursachen, da (fast) alle Timer Ergebnis von Suchtimer sind, die wieder angelegt werden. Wenn ich Timer los werden will (z.B. wegen Konflikt) muss ich sie eh deaktivieren.
Wenn du schon an dem Thema Aufnahme löschen dran bist, hätte ich noch ein Feature Request, den wir schon mal angeschnitten haben:
Bei Löschen einer laufenden Aufnahme den zugehörigen Timer zu deaktivieren. Sonst läuft die Aufnahme weiter und es wird eine unvollständige Aufnahme ab Zeitpunkt des Löschen erzeugt. Wenn man über VDR OSD eine laufende Aufnahme löscht wird der Timer auch gelöscht. Ich würde aber aus o.g. Gründen Timer deaktivieren bevorzugen.
Stimmt, das kann bei mir aber kein Problem verursachen, da (fast) alle Timer Ergebnis von Suchtimer sind, die wieder angelegt werden. Wenn ich Timer los werden will (z.B. wegen Konflikt) muss ich sie eh deaktivieren.
Ich erinnere mich, dass das nicht immer der Fall ist. Kann mich aber auch täuschen.
Bei Löschen einer laufenden Aufnahme den zugehörigen Timer zu deaktivieren. Sonst läuft die Aufnahme weiter und es wird eine unvollständige Aufnahme ab Zeitpunkt des Löschen erzeugt. Wenn man über VDR OSD eine laufende Aufnahme löscht wird der Timer auch gelöscht. Ich würde aber aus o.g. Gründen Timer deaktivieren bevorzugen
Stimmt, der VDR macht das. Das müsste sich MarkusE aber ansehen, da stecke ich wohl noch nicht tief genug drin. Ebenso die Sache mit dem Filtern auf Basis von Checkboxen.
Don’t have an account yet? Register yourself now and be a part of our community!