[live] [partially merged] Finden existierender Aufzeichnung ohne Tvscraper

Ich nutze Live ohne den Tvscraper. Bis einschließlich Version 3.1.8 hat Live immer existierende Aufzeichnungen gefunden und in der Programmübersicht aufgelistet. Doch seit einer Codeänderung im März 2023 findet Live im Programm ohne die Scraper-Daten keine existierenden Aufzeichnungen mehr.

Gibt es äußer mir noch andere Nutzer, die ohne den Scraper unterwegs sind? Falls ihr dieses Problem ebenfalls kennt, hätte ich hier einen Patch, der das Problem löst, für die Scraper-Gemeinde aber diesbezüglich ohne Einfluss ist:

• 0011 Fixed no existing recording found without tvscraper.zip

Der Patch hat allerdings noch eine kleine "Nebenwirkung", denn habe die Darstellung existierender Aufzeichnungen in der Programmübersicht visuell etwas überarbeitet.

Auch habe ich die Funktion, welche, die Namen von Aufzeichnungen fürs Suchen und Sortieren normalisiert, dahingehend überarbeitet, dass nicht nur wie bisher Interpunktionszeichen eliminiert, sondern auch Whitespace-Sequenzen zu einem einzigen Space konsolidiert werden. Das sollte auf die Funktion für den Scraper aber keine Auswirkung haben – mag das vielleicht mal jemand testen?

MarkusE: Im Code wird noch ein weitere Spalte verwaltet, die aber – so meine Interpretation – ohne Offline-Referenz den Tabellenaufbau zerstört (die Zeile weicht dann um eine Spalte ab). Ich habe diesen Teil auskommentiert, aber das solltest du dir vielleicht nochmals anhand von Spieldaten ansehen und eine adaptive Lösung vorschlagen. Im Patch ist das hier:

-  if (archiveDescr.length != 0) col_span1--;
+// if (archiveDescr.length != 0) col_span1--;

Viele Grüße

Stefan

Quote from kfb77

Was ist anders bei mir (oder dir) ?

Keine Ahnung, aber mit dem Stand vor der besagten Änderung bzw. dem aktuellen Stand und dem Patch geht es jedenfalls. Ob es alle Aufzeichnungen betrifft oder nur die, bei denen es mir aufgefallen war, ist ebenfalls unklar.

Quote from kfb77

Was ich aber in dem Zusammenhang vermisse, wäre, dass ein vorhandener Timer (natürlich zu einem anderen Zeitpunkt, sonst wird er ja als aktiver Timer angezeigt) auch in den Suchergebnissen angezeigt werden würde. Das verhindert versehentlich doppelte Timer zur gleichen Sendung.

Das habe ich bisher noch nie vermisst, was aber auch an meiner Vorgehensweise liegen mag: Wann immer ich eine Sendung (Film) aufnehmen möchte, suche ich nach ihren Wiederholungen und programmiere sie alle. Vor allem auch deshalb, weil bei sich gerade bei HD-Aufzeichnungen gerne mal TS-Fehler einschleichen. Und Aufnahmen mitten in der Nacht verzichten auch auf den einen oder anderen Werbeblock bzw. eingeblendete Programmhinweise, die man dann notfalls auch mal herausschneiden kann.

Doppelte Timer sind bei mir also fast schon der Normalfall. Wenn ich einen Timer dann nicht mehr benötige, setze ich ihn auf inaktiv (deshalb Patch Nr. 10) oder lösche in gleich.

Eine solche Erweiterung müsste sich aber wohl am besten Markus vornehmen, denn so tief stecke ich im Timer-Manager nicht drin…

Viele Grüße

Stefan

Nur nochmals zum Vergleich mit dem aktuellen Master (mit dem von mir vorgeschlagenen Patch):

… und dem Commit bfbaab7 ("Transponder") unmittelbar davor:

Wie man sieht, findet er im ersten Fall die Aufzeichnung, im zweiten leider nicht. Ob das daran liegt, dass ich den Untertitel mit zusätzlichen Informationen ergänze und er deshalb nicht 1:1 dem aus dem EPG entspricht, vermag ich nicht zu sagen. Klar ist jedenfalls, dass v3.1.8 die Aufzeichnungen trotzdem noch gefunden hat.

Quote from MarkusE

Damit werden mehr Sendungen als Duplikate betrachtet als vorher. Das betrifft nur Sendungen, die tvscraper nicht identifiziert hat. Wenn ihr keinen tvscraper nutzt, betrifft es alle Sendungen.

Mein Annahme war, dass bei aktivem Tvscraper immer ein scraperVideo gesetzt ist. In diesem Fall verhielte sich der Code wie vorher. Aber vielleicht war diese Einschätzung zu optimistisch…

Wie wäre es also damit:

0011a Revised searchNameDesc exit condition.zip

return !LiveFeatures< features::tvscraper >().Recent();

Damit sollte sich der Code bei geladenem Tvscraper wirklich identisch verhalten und auch nicht mehr Duplikate finden als vorher.

Viele Grüße

Stefan

Quote from MarkusE

shofmann , es geht mir nicht darum, dass sich für Verwender von tvscraper nichts ändern darf. Es darf nur nicht insgesamt schlechter werden.

Schon klar, aber wenn auf einmal (deutlich?) mehr Aufzeichnungen gefunden werden als vorher, kann das für euch genauso lästig sein wie für mich die Tatsache, dass auf einmal gar keine mehr gefunden wurden.

Der zweite Vorschlag hilft beiden Gruppen, weil eben alles "beim alten" bleibt. Aus systematischen Gründen ist er zudem die korrektere Variante.

Und wer, ich zum Beispiel ich, die Namen der Aufzeichnungen etwas modifiziert, damit die einzelnen Sequels schön untereinander gelistet werden, wie etwa:

• Star Trek 01 - Der Film
• Star Trek 02 - Der Zorn des Khan
• …
• Star Trek 12 - Into Darkness

usw., der wünscht sich vielleicht auch noch eine Suche vorhandener Aufzeichnungen über den Titel. Einen solchen Patch hätte ich auch noch in der Schublade liegen…

Viele Grüße

Stefan

Das schaue ich mir in den nächsten Tagen gerne einmal an, sobald ich etwas Zeit dafür finde. Ich habe in den letzten Tagen so viel Zeit in Live investiert, dass ich mein anderes Backlog mal aufarbeiten muss…

Vielleicht hat aber auch Markus schnell eine Lösung zur Hand, denn dein Problem dürfte ja beide "Betriebsarten" (mit/ohne Tvscraper) betreffen, oder?

Viele Grüße

Stefan

Quote from wmautner

bereits die aktuell laufende Aufnahme als "Vorhandene Aufnahme" angezeigt wird - ließe sich da, solang noch der timer läuft, das unterbinden?

Ich habe gerade den Patch für inaktive Timer dahingehend überarbeitet, dass bei einem gerade laufenden Timer das Timer-Symbol blinkt und nicht nach vorhandenen Aufzeichnungen gesucht wird.

Weil aber gerade eine Aufnahme läuft, kann ich den Patch nicht gegen den aktuellen Master testen. Bitte also um etwas Geduld, bis ich ihn im genannten Thead gepostet habe.

Viele Grüße

Stefan

Der Patch (0010c) liegt jetzt vor. Wenn ich Markus' letzte Anfrage richtig deute, bringt er ihn gerade ins Git.