MediathekView vergisst gesehene Sendungen

[MenchenSued]

Könntest Du mal die URLs der Datenbank und der mittleren Auflösung einer Beispielsendung vergleichen? Nur wenn beide übereinstimmen, kann die Sendung markiert werden. Die Auflösung beim Download sollte keine Rolle spielen.

[styroll]

@MenchenSued sagte: Könntest Du mal die URLs der Datenbank und der mittleren Auflösung einer Beispielsendung vergleichen? Nur wenn beide übereinstimmen, kann die Sendung markiert werden.

Das habe ich für die in der obigen Liste aktuellste Wilsberg-Folge “Achtsam bis tödlich” gemacht:
18.05.2025: https://nrodlzdf-a.akamaihd.net/none/zdf/25/02/250208_2015_sendung_wil/1/250208_2015_sendung_wil_a1a2_3360k_p36v17.mp4
01.02.2025: https://rodlzdf-a.akamaihd.net/none/zdf/25/02/250208_2015_sendung_wil/1/250208_2015_sendung_wil_a1a2_2360k_p35v17.mp4

@BugMelder: Die URL ist zumindest für die Basis-URL (mittlere Qualität), die verglichen wird, unterschiedlich, was das beobachtete Verhalten erklärt. In einem solchen Fall gilt die Sendung technisch gesehen als neu, da die URL gewechselt hat (wohl wegen den MV-seitigen Änderungen beim ZDF, welche URL als höchste/mittlere/geringste Qualität in die Liste genommen werden soll).

@BugMelder sagte: Einzige Änderung, die ich gemacht habe, ist die Markierungsfarbe auf helles Gelb zu setzen, da ich das besser erkennen kann. Ein Muster, wann und wie die Markierungen verschwinden, kann ich nicht erkennen.

Dazu gab’s zwar erst kürzlich ein ähnlicher Fall:

@DieterK sagte in Import der Historie in neuer Version 14.2.0 geht nicht:
Dann wollte ich die Anzeigefarben ändern und plötzlich war nichts mehr markiert, so wie zuvor.

… aber zumindest bei meinen kurzen Tests konnte ich keine Auffälligkeit feststellen.

EDIT: Beitrag wurde nach kurzem Test aktualisiert.

[BugMelder]

Für die Sendung Wilsberg - Blinde Flecken steht unter dem Filmereiter
https://nrodlzdf-a.akamaihd.net/none/zdf/24/04/240413_2015_sendung_wil/1/240413_2015_sendung_wil_a1a2_2360k_p35v17.mp4

in der Datenbank:

https://rodlzdf-a.akamaihd.net/none/zdf/24/04/240413_2015_sendung_wil/1/240413_2015_sendung_wil_a1a2_3360k_p36v17.mp4

Also ein fehlendes n nach dem https://

Andererseits müsste es ja auch viel mehr Wilsberg-DB Einträge geben, statt nur noch 10.

Außerdem, wenn ich im Filmereiter im Kontextmenü auf Infodatei erzeugen klicke, wird nur eine leere 0-Byte große Datei erstellt.

[styroll]

@BugMelder sagte: Also ein fehlendes n nach dem https://

Da ist das Ende auch noch komplett anders, vgl. mein eben aktualisierten Beitrag oben.

[MenchenSued]

@BugMelder
Wir hatten vor einigen Wochen die Auflösung beim ZDF geändert, die mittlere Auflösung hat dadurch eine andere URL bekommen. Bei Deinem Beispiel 2360k_p35v17 gegenüber 3360k_p36v17. Damit wäre es erklärbar, dass es sich damit um zwei unterschiedliche Filme handelt.

[BugMelder]

Ja, das ist ja blöd. Aber warum verschwinden die Einträge dann aus der Datenbank? Dadurch kann man dann auch keine lokale Aktualisierung/Repatur durchführen.

btw.: Hier auf der Forenseite erscheint unten im footer ein “undefined”.

[DerReisende77]

@BugMelder Da Du die DB ja schon im DB Browser offen hattest, mache doch mal bitte folgendes:

1. MV beenden
2. history.db im DB Browser öffnen
3. Reiter SQL ausführen öffnen
   4.Im Textfeld eingeben:

REINDEX;

5. Play Button drücken.
   Unten sollte so etwas ähnliches erscheinen:

Ausführung wurde ohne Fehler beendet.
Ergebnis: Abfrage erfolgreich ausgeführt. Benötigte 489 ms 
In Zeile 1:
REINDEX;

6. Menü Werkzeuge/Integritätsprüfung ausführen
7. DB Browser beenden
8. MV neustarten

[DerReisende77]

@BugMelder sagte in MediathekView vergisst gesehene Sendungen:

Ja, das ist ja blöd. Aber warum verschwinden die Einträge dann aus der Datenbank? Dadurch kann man dann auch keine lokale Aktualisierung/Repatur durchführen.

btw.: Hier auf der Forenseite erscheint unten im footer ein “undefined”.

Ob die Einträge aus der Datenbank verschwinden kann zum jetzigen Zeitpunkt nicht gesagt werden. Die History prüft beim Speichern von geladenen Filmen, ob die Normal-URL schon drin ist. Wenn nicht, wird ein Eintrag gespeichert ansonsten nicht da ein älterer Eintrag schon vorhanden ist.
WICHTIG: Auch wenn mehr Spalten (als Reminiszenz an die alte history.txt) vorhanden sind ist allein die url der ausschlaggebende Faktor.

Und zum Schluß noch eine wirklich doofe Frage: Im Filterdialog ist Gesehene Filme nicht anzeigen nicht aktiv,oder?

[BugMelder]

Zur doofen Frage: Ein Filter ist nicht aktiv.

Einige Wilsberg-Einträge sind definitiv aus der DB verschwunden. Das sieht man an meinem Screenshot. Von den 2995 Einträgen haben nur noch 10 das Thema “Wilsberg”, habe aber 68 mp4-Dateien heruntergeladen.
In der Pseudo-JSON-Datei filme.json sind zur Zeit aber nur noch 54 vorhanden, weil die anderen wohl inzwischen nicht mehr in der Mediathek verfügbar sind.

Ich hatte mir am 18.5.2025 eine Kopie der history.db gesichert und kann damit nun testen.
(Die zugehörige db.wal-Datei war 0 Bytes groß)

DB-Browser Aktionen durchgeführt. integrity_check sagt: ok. MV gestartet. Keine Änderung.

In MV wird mir unter “Hilfe”/“Hilfsmittel”/“History-Datenbank optimieren” 256 Duplikate gefunden angezeigt. “bereinigen” löscht diese dann. Danach keine weiteren Auswirkungen. Ich habe diesen Menüpunkt noch nie vorher aktiviert und jetzt erst entdeckt.

[BugMelder]

Irgendwo ist da noch der Wurm drin. Ich habe jetzt mal “History-Datenbank optimieren” ausgeführt. Einige Datensätze wurden gelöscht. Nun wird mir in diesem Dialog “0 Duplikate” angezeigt. Wenn ich aber mit dem DB Browser folgendes Statement ausführe:

select url,count(*) from seen_history
group by url
order by 2

werden mir trotzdem noch mehrfach vorhandene url angezeigt. Einige doppelt, 3-fach oder 4-fach. Beispiele:
http://nrodl.zdf.de/dach/3sat/17/12/171231_lindenberg_zeit_patc_musik/6/171231_lindenberg_zeit_patc_musik_2328k_p35v13.mp4
http://nrodl.zdf.de/dach/3sat/18/12/181231_evanescence_patc_musik/4/181231_evanescence_patc_musik_2328k_p35v13.mp4

Vor der Bereinigung gab es sogar einige url 8-fach oder 9-fach.

[DerReisende77]

Nein da ist kein Wurm drin. Die history.txt damals hat jeden Download immer wieder eingetragen und somit zig Duplikate erzeugt. Diese wurden dann auch stumpf in die history.dbüberführt.
Irgendwann habe ich angefangen die Duplikate aufzuräumen, aber nicht so radikal weil es einige Leute gibt die unbedingt in der History rumgraben wollen um da Sachen zu suchen/finden.
Die Deduplizierung führt daher quasi folgendes durch:

CREATE TABLE temp_history AS SELECT DISTINCT datum,thema,titel,url FROM seen_history ORDER BY datum;

und die richtige Suche dementsprechend wäre:

SELECT COUNT(*) FROM (SELECT DISTINCT datum,thema,titel,url FROM seen_history);

Ist alles im Code lesbar.

[DerReisende77]

In der nächsten nightly habe ich das Verhalten angepasst und es werden nun alle Duplikate basierend auf der URL aus der DB entfernt. Es werden keine Reminiszenzen der Vergangenheit mehr behalten.

[BugMelder]

Danke für die Erklärungen. Die bringen Licht ins Dunkel.
Ich habe auch weiter recherchiert. Ich habe im Dezember 2019 einen neuen Rechner bekommen. Dann irgendwann Ende 2020 die history.db vom alten auf den neuen Rechner übertragen und dort mit MV weitergearbeitet. Da die Downloads aber immer so lange dauern, habe ich die danach teilweise auf dem alten Rechner laufen lassen, dabei aber nicht an die history.db gedacht.

Ich habe jetzt nicht jeden Einzelfall geprüft, aber einige der vermissten history-Einträge sind in der history.db des alten Rechners enthalten. Ich muss diese nun nur noch mit der history.db des neuen Rechners zusammenführen. Dann sind alle Einträge wieder da, bis auf die ZDF-URL-geschädigten.

Damit ist das Thema wohl erledigt.

Einige der nun noch mehrfachen url-Einträge unterscheiden sich nur durch das Datum. Da habe ich wohl einen Teil der Sendung angeschaut und dann am nächsten Tag weitergeschaut.

[BugMelder]

Könnte man in der seen_history noch eine spalte “modus” INTEGER einfügen, die 1 enthält für angeschaut, 2 für downgeloadet und 3 für beides oder ggf. zwei DB-Einträge. Ist aber nicht notwendig, ich habe nur laut gedacht.