Was mich immer wieder beim Aufräumen in Live stört, ist die Tatsache, daß sämtliche gesetzten Markierungen sofort weg sind, wenn man bei der Bearbeitung z.B. der Duplikat-Liste dazwischen eine Aufzeichnung "editiert", also etwa den Namen oder Serienkennung ändert. Das ärgert deutlich mehr als daß "unsichtbare/ausgefilterte" Einträge nicht mitbearbeitet werden.
</motzmode off> 
Was mich immer wieder beim Aufräumen in Live stört, ist die Tatsache, daß sämtliche gesetzten Markierungen sofort weg sind, wenn man bei der Bearbeitung z.B. der Duplikat-Liste dazwischen eine Aufzeichnung "editiert", also etwa den Namen oder Serienkennung ändert.
Hier ein Patch gegen den aktuellen Master, der die markierten Aufzeichnungen als Cookie speichert und beim Neuladen der Seite erneut selektiert:
Bitte testet, ob das eure Bedürfnisse erfüllt. Beachtet aber bitte, dass in den virtuellen Ordnern "Serien" und "Filmsammlungen", die bei Nutzung des TvScraper eingeblendet werden, alle darin gelisteten virtuellen Aufzeichnungen die gleiche ID für die Checkbox haben wie das Original in "Dateisystem". Je nachdem was aufgeklappt ist und welche Checkbox der Browser beim Zugriff über die ID setzt, wird möglicherweise eine andere Checkbox für die gleiche Aufzeichnung als vorher gesetzt. Sichergestellt ist aber, dass es im Dateisystem die gleiche Aufzeichnung ist.
Bis zu wie vielen markierten Aufzeichnungen funktioniert der Patch denn?
Die max. Länge von Cookies ist doch begrenzt.
Hier ein Update für den Patch gegen den letzten Commit 61c810a:
Ich habe die Cookie-Größe auf 4K erhöht (siehe oben) und dabei gleich auch die Cookie-Funktionen überarbeitet. Zudem werden die Markierungen jetzt nicht nur gelöscht, wenn der VDR neu gestartet wird, sondern auch, wenn sich der Kontext ändert. Der Kontext ist hierbei die Kombination von hierarchischer/flacher Anzeige und aktive/gelöschte Aufzeichnungen.
Ich hatte zwar auch überlegt, ob man für hierarchisch bzw. flach die Auswahl jeweils getrennt speichern sollte, sodass sie beim hin- und herwechseln erhalten bliebe. Aber vermutlich gibt es dafür keinen wirklich nützlichen Use-Case, weshalb ich darauf verzichtet habe.
Was noch fehlt, ist ein Button für das Wiederherstellen der Auswahl. Das reiche ich in einer ruhigen Minute nach. Ich muss mich aber vorher noch mit anderen Dingen außerhalb des VDR-Universums beschäftigen…
Die verwendeten IDs der Checkboxen sind die VDR recording IDs. Bleiben bis zu einem VDR Restart verwendbar -> wir müssen das Cookie bei einem VDR Restart löschen.
Und da ist noch ein Designfehler in recordings 
. Die checkbox IDs können 2 mal verwendet werden . Das war bisher egal. weil diese IDs nicht verwendet wurden. Wird aber hier zu Fehlern führen, da müssen wir uns etwas überlegen. Man könnte z.B. Folder ID + Recording ID zu einer Checkbox-ID kombinieren.
Maximal unterstützte Anzahl von markierten Aufzeichnungen: Eine ID ist ca. 7 Zeichen lang, + Komma gibt 8. 4K/8 gibt 500. Das müsste in allen praktischen Situationen ausreichen.
Die verwendeten IDs der Checkboxen sind die VDR recording IDs. Bleiben bis zu einem VDR Restart verwendbar -> wir müssen das Cookie bei einem VDR Restart löschen.
Der Patch 11a macht das doch schon:
Zudem werden die Markierungen jetzt nicht nur gelöscht, wenn der VDR neu gestartet wird, sondern auch, wenn sich der Kontext ändert. Der Kontext ist hierbei die Kombination von hierarchischer/flacher Anzeige und aktive/gelöschte Aufzeichnungen.
Nochmals in anderen Worten: Das Cookie wird gelöscht, wenn der VDR neu gestartet wird oder ein Wechsel von hierarchischer nach flacher Anfzeige oder von aktiven zu gelöschten Aufzeichnungen erfolgt.
Also alles schon drin. 
Die checkbox IDs können 2 mal verwendet werden
Auch das hatte ich schon angemerkt. Ich halte das allerdings für unproblematisch, wenn man die Duplikate erkennt und nicht versucht, eine schon gelöschte Aufzeichnung ein zweites Mal zu löschen und somit eine Fehlermeldung vermeidet. Unschön ist natürlich, dass beim Wiederherstellen der Markierungen in seltenen Fällen der falsche Zwilling markiert werden könnte. Aber dazu müssten beim Laden der Seite beide Ordner gleichzeitig aufgeklappt sein, was wohl eher selten der Fall sein dürfte.
Mein Patch 4f verwendet deshalb eindeutige IDs, welche auch den Ordner-Hash beinhalten, und gefühlt lädt er auch die Seite schneller. Das einfachste wäre insofern, diesen Patch zu nutzen, zumal er die "flache" Auswahl in aufgeklappten Ordnern als Standardeinstellung ja ebenfalls beinhaltet. Das Wiederherstellen der Markierungen auf Basis von Patch 4f ist gleich das Nächste auf meiner Liste, da ich den Patch auf jeden Fall selbst nutzen werde. Das Cookie wird die IDs auch optimiert speichern, sodass womöglich sogar noch mehr Markierungen wiederhergestellt werden können. Auch plane ich eine Möglichkeit, sich die in (möglicherweise eingeklappten) Ordnern markierten Aufzeichnungen anzeigen zu lassen, etwa über einen Filter. Mal sehen…
Was also spricht gegen diesen Patch? Man muss das Rad ja nicht unbedingt ein weiteres Mal erfinden...
Könntest Du den Patch 4 so ändern, dass:
Also nur:
Klar kann ich das machen. Der erste Punkt war übrigens überhaupt nicht im Patch mit drin.
Damit der Patch für meine Belange auch geeignet ist, würde ich nur die Änderungen von setup.ecpp und pages/setup.ecpp weglassen, sodass der Patch ausschließlich das von dir gewünscht Verhalten zeigt. Intern kann ich bei mir dann leicht die andere Variante wieder ergänzen.
Wenn du damit einverstanden bist, wäre uns beiden geholfen…
Hier wäre dann der überarbeitete Patch, der auch die Markierungen speichert und wiederherstellt:
Intern ist es, wie gesagt, bis auf eine kleine Korrektur der bisherige Patch, nur halt eben ohne die Möglichkeit der Auswahl zwischen den beiden Auswahlvarianten.
Warte bitte noch, mir ist noch eine Unstimmigkeit aufgefallen…
OK, hier ein Update mit einigen Fixes sowie einer Textkorrektur:
Letzteres ist eine Diskrepanz im Master. Dort heißt es zwar
… doch der Button spricht von:
Weil das recht unschön ist, habe ich das einheitlich auf den Wortstamm "Auswahl" umgestellt und das Wording der Buttons einander angeglichen:
Wenn dir das nicht zusagt, kannst du es ja wieder ändern…
PS: Wenn mehr Aufzeichnungen ausgewählt sind, als das Cookie speichern kann (also etwa alle Spielfilme), dann bricht das Setzen der Checkboxen einfach ab. Ich habe darauf verzichtet, einen Meldung auszugeben. Aber man könnte natürlich auch eine Fehlermeldung anzeigen lassen, wie etwa beim Versuch, eine nicht mehr vorhandene Aufzeichnung abspielen zu wollen. Wie siehst du das?
Ich hab mir "0004h Recordings selection.patch" angesehen.
Da ist noch zu viel drin.
Ich will ja nicht sagen, dass das schlecht ist. Ich brauche aber dafür unterschiedliche Patches.
Könntest Du bitte einen Patch bauen, der nur folgendes macht:
Die Änderung in recman.h hat hiermit doch nichts zu tun.
Die Änderung korreliert mit einer sinnvollen Verbesserung in styles.css, welche einige CSS-Regeln signifikant vereinfacht. Das kann man zwar auch anders lösen, was ich inzwischen auch gemacht habe, konsequenter wäre jedoch die Korrektur in recman.h. Aber wie du meinst…
Ich will ja nicht sagen, dass das schlecht ist. Ich brauche aber dafür unterschiedliche Patches.
Schön, dass wir darin übereinstimmen. Ich habe den Patch auf den von dir gewünschten Funktionsumfang reduziert und in zwei Teile zerlegt, die wegen innerer Abhängigkeiten in dieser Reihenfolge anzuwenden wären:
Außerdem noch:
Das was du für unnötig hältst, erachte ich insbesondere für die Maintenance der styles.css schon als wünschenswert und möchte darauf auch nur ungern verzichten. Die Arbeit, das nochmals aufzuteilen, werde ich aber nicht mehr investieren, zumal du dann doch alles wieder zusammenschmeißt:
Das ist dem Verständnis und der Traceability von Änderungen nicht dienlich. Am Schluss weiß man gar nicht mehr, was genau da eigentlich geändert wurde. Also ja, deine Forderung nach einzelnen Patches kann ich in dieser Hinsicht durchaus nachvollziehen. Deine Commit-Strategie allerdings nicht, denn diese steht dazu im Widerspruch. Und dein striktes Regime, für jeden Pipifax einen eigenen Patch zu fordern, empfinde ich angesichts dessen zuweilen als ziemlich unfair…
Ich zitiere hier mal die Google Antwort, auf die Frage "Was ist ein guter Git Pull Request (PR)". Auch wenn man nicht alles glauben darf, was Suchmaschinen, vor allem im KI Mode hergeben, entspricht das dem, was in jedem Software Entwicklungsunternehmen und auch bei open source Standard ist.
Da ich eigene Patche in Live drin habe, ist es immer sehr schwer in solchen Massen Commits die Stelle zu finden, wo nach Updates der rebase schief geht.
Ein guter Git Pull Request (PR) ist entscheidend für effiziente Code-Reviews, hohe Codequalität und eine reibungslose Zusammenarbeit im Team. Er dient als strukturierter Vorschlag, Änderungen aus einem Feature-Branch in den Haupt-Branch (z. B. main oder develop) zu übernehmen.
Hier sind die Best Practices für einen guten PR:
1. Umfang und Struktur
Klein und fokussiert: Ein guter PR enthält nur Änderungen für ein spezifisches Thema, einen Bugfix oder ein Feature. Zu große PRs sind schwer zu reviewen und führen zu Fehlern.
Klare Commit-Nachrichten: Nutzen Sie aussagekräftige Nachrichten, die erklären, warum eine Änderung gemacht wurde.
Funktionsfähiger Code: Der Code im PR sollte den CI/CD-Prozess (Builds, Tests) ohne Fehler bestehen.
2. Dokumentation und Kommunikation
Aussagekräftiger Titel und Beschreibung: Beschreiben Sie prägnant, was der PR tut. Eine gute Beschreibung enthält Kontext, den Grund der Änderung und ggf. Links zu Issues (z.B. Jira).
PR-Templates nutzen: Viele Teams nutzen Vorlagen, die Checklisten enthalten (z. B. "Tests geschrieben", "Dokumentation aktualisiert").
Bilder/GIFs: Bei UI-Änderungen helfen Screenshots oder GIFs, die Änderungen schnell zu visualisieren.
3. Prozess und Review
Frühzeitiges Feedback: Kleine, häufige PRs ermöglichen schnelleres Feedback und reduzieren Konflikte beim Mergen.
Konfliktlösung: Sorgen Sie dafür, dass Ihr Branch aktuell ist und keine Konflikte mit dem Haupt-Branch bestehen.
Offenheit: Ein guter PR ist ein Werkzeug zur Zusammenarbeit – nehmen Sie Kommentare an und diskutieren Sie Verbesserungen.
Ein gut strukturierter PR spart Zeit, minimiert Bugs und fördert den Wissensaustausch im Team. > Die Änderung korreliert mit einer sinnvollen Verbesserung in styles.css, welche einige CSS-Regeln signifikant vereinfacht. Das kann man zwar auch anders lösen, was ich inzwischen auch gemacht habe, konsequenter wäre jedoch die Korrektur in recman.h. Aber wie du meinst…
Ich habe nichts gegen diese Änderung an sich. Ich habe etwas dagegen, wenn diese Änderung mit einem Patch kommt, der damit nichts zu tun hat. Einen Patch von Dir, der nichts anderes macht als '_new' durch ' new' zu ersetzten (und die daraus resultierenden notwendigen Änderungen), würde ich übernehmen. Weil Du von css mehr Ahnung hast von als ich.
Ich habe gerade in "0004i-1 Recording selection.patch" noch
var inputs = form.getElementsByTagName('input');
- let all_del='';
+ let all_del = [];
for (var i = 0; i<inputs.length; i++) {
if (inputs[i].type == 'checkbox' && inputs[i].checked &&
inputs[i].value && inputs[i].value.startsWith('recording_')) {
const id = inputs[i].value.substring(10);
- all_del = all_del + id + ",";
- var err = await execute('action.html?id=' + act + '_' + inputs[i].value);
- if (!err.success) alert (err.error);
+ if (all_del.indexOf(id) < 0) {
+ var err = await execute('action.html?id=' + act + '_' + inputs[i].value);
+ if (!err.success) alert (err.error);
+ all_del.push(id);
+ }
}
}
- if (all_del == '') return;
+ if (all_del.length == 0) return;
let new_loc = '';
if (window.location.href.includes("?")) {
let pos = window.location.href.indexOf("deleted=");
if (pos == -1) {
- new_loc = window.location.href + "&deleted=" + all_del;
+ new_loc = window.location.href + "&deleted=" + all_del.join(',');
} else {
- new_loc = window.location.href.substring(0, pos) + "deleted=" + all_del;
+ new_loc = window.location.href.substring(0, pos) + "deleted=" + all_del.join(',');
}
} else {
- new_loc = window.location.href + "?deleted=" + all_del;
+ new_loc = window.location.href + "?deleted=" + all_del.join(',');
}
window.location=new_loc;
} gefunden. Auch hier: Das hat nichts mit dem Selektieren von Änderungen zu tun. Und ob es diese Änderung besser macht, ist aus meiner Sicht Geschmackssache. Man kann erst eine Liste bauen, und aus dieser Liste dann einen String zusammensetzen. Oder man baut halt gleich den String. Geht wohl beides. So eine Änderung als separaten Patch würde ich wohl ablehnen.
Also, worum geht es:
Und ja, ich habe auch schon große Patches von Dir übernommen. Und ja, da waren auch schon Dinge drin versteckt, die ich dann erst später gefunden habe. Die ich nicht übernommen hätte, wenn ich sie früher gefunden hätte.
Man kann erst eine Liste bauen, und aus dieser Liste dann einen String zusammensetzen. Oder man baut halt gleich den String. Geht wohl beides. So eine Änderung als separaten Patch würde ich wohl ablehnen.
Wahr ist, dass beides zum Ziel führt. Aber die Empfehlung ist, in Javascript (wie übrigens auch in Python) der besseren Performance halber statt vieler String-Verkettungen besser ein Array mit anschließendem join() zu verwenden. Und wenn etwas vor zig Jahren beliebig umständlich und wenig performant kodiert wurde, das aktuelle Javascript inzwischen vielleicht gar eigene Operationen dafür bereit hält, wollen wir das dann auf ewig so lassen? Hat die Verbesserung der funktionalen wie nicht-funktionalen Code-Qualität denn keinen Wert? 
Und ja, ich habe auch schon große Patches von Dir übernommen. Und ja, da waren auch schon Dinge drin versteckt, die ich dann erst später gefunden habe. Die ich nicht übernommen hätte, wenn ich sie früher gefunden hätte.
Darüber haben wir uns ja schon ausgetauscht, und seitdem grenze ich die Patches ja funktional entsprechend ein. Auch wenn mir eine Vielzahl "offener" Patches (siehe #413) wegen des ständigen Rebase der zugehörigen Branches und möglicher Konflikte das Leben nicht gerade einfach macht.
Ich möchte bei jeder Änderung entscheiden, ob ich sie im Code haben will (oder eben auch nicht)
Deshalb brauche ich für jede Änderung einen eigenen Patch
Dass ich das größtenteils verstehe, hatte ich ja geschrieben. Du verstehst aber bestimmt auch, dass sich das vom Arbeitsablauf her nicht immer so leicht einhalten lässt. Wenn du selbst ein Problem findest, was macht du dann damit: einen eigenen Commit zu einem späteren Zeitpunkt oder einen Fix en passant? Wohl doch eher letzteres – ein paar Zugeständnisse wären also schon hilfreich.
Und wenn wir schon so kleinteilig vorgehen, ist es dann nicht nachvollziehbar, dass sich diese Granularität auch im Git mit vernünftigen Commit-Messages wiederfinden sollte? Der Beitrag von kfb77 gibt schließlich genügend Hinweise, warum dies sinnvoll ist.
Ich verstehe deine Position inzwischen besser und versuche, mich darauf einzustellen. Und ich hoffe, dass du die Dinge auch aus meiner Warte betrachten und nachvollziehen kannst, was mir von Arbeitsablauf in der Zulieferung größere Probleme bereitet. Letztlich wollen wir doch erreichen, dass die Bedürfnisse aller "Stakeholder" – also Maintainer, Contributor und Builder – gleichermaßen Berücksichtigung finden.
Wir sind etwas abgeschweift. Ich möchte wieder zum Thema "[live] Markierungen von Aufzeichnungen speichern" zurückkehren. Bitte macht für alle anderen Diskussionen neue Threads auf.
Ich habe in meiner Testumgebung "0011a Restore selected recordings.patch" installiert und getestet.
Das funktioniert so weit, und wenn ich z.B. zwischen einzelnen "Aufzeichnungen" Ansichten wechsle, dann werden die markierten Aufzeichnungen auch zurückgesetzt.
Wenn ich jetzt aber z.B. von Aufzeichnungen zu Timer wechsle und dann wieder zu Aufzeichnungen, dann bleiben die Markierungen in den Aufzeichnungen erhalten. So ein Verhalten möchte ich nicht haben, da man damit nicht rechnet. Ich habe versucht, das über request.getHeader("Referer:") zu lösen, das hat aber so nicht funktioniert.
Wie seht ihr das?
Don’t have an account yet? Register yourself now and be a part of our community!