DL's von MV in DB Sqlite Eintrag erfolgt nicht immer automatisch
-
@andy sagte in DL's von MV in DB Sqlite Eintrag erfolgt nicht immer automatisch:
Hallo,
alle von MV 13.7.1 (BS Win 10) aufgenommene Sendungen sollten eigentlich automatisch in DB SqLite nach lfd. Nr., ID, Datum, Thema, Titel und Url gelistet werden.
Das ist falsch.
Erstens werden in der history.db nur Einträge von manuellen Downloads hinterlegt. Abos lagern derzeit noch in der alten abo_history.txt.
Zweitens schreibt MV nicht wie in der alten Version stumpf wieder und wieder gleiche Einträge in die DB. Der einzig relevante Parameter ist die URL und die id. Der Rest ist da weil ich das nicht komplett entfernen wollte hat aber keine Relevanz.
Weiterhin prüft MV bevor es einen Eintrag in die DB vornimmt, ob die zu schreibende URL nicht schon existiert. Tut sie dies, wird kein Eintrag erzeugt da das Ergebnis für die Gesehen-Anzeige das gleiche mit dem alten Eintrag ist als wenn nun zwei vorliegen. Das macht keinen Sinn und kostet auch nur Performance.Heute mußte ich aber die Daten für 6 Sendungen in den einzeknen Filtern manuell eintragen. Dieses Problem taucht öfters auf. Woran kann das liegen?
Mit freundlichen Grüßen Andy
Wieso musstest Du für 6 Sendungen die Einträge manuell anlegen? Hat die grau hinterlegte Anzeige für gesehene/gedownloadete Filme nicht funktioniert? Oder welchen Grund gibt es sonst?
-
Wie soll ich das noch erklären! Ich kann nur das schildern, wie es bei mir abläüft…
Beispiel:
Wenn ich in MV “Anne Will” downloade, erscheint in DB SQLite sonst automatisch der volle Eintrag in der Zeile, so wie er in meinem Bild dargestellt ist und unter allen Filtern.
Heute musste ich jede dieser Sendungen in Thema, Titel und Url manuell einfügen,Für mich ist nicht entscheidend, dass nur die Url und ID maßgebend sein soll. Titel und Thema sind mir wichtiger.
Im ersten Beitrag sagte ich schon, dass ich keine Abos. verwende.
Die DL’s in MV sind alle manuell und wurden sonst, solange DB existiert, automatisch hinterlegt. Die ganzen Sendungen in meinem Bild sind neu und auch nicht doppelt. Trotzdem funktioniert es nicht. -
@andy Und Du hast wiederum nicht beantwortet was (vermeintlich) falsch läuft und weshalb Du meinst deswegen in der Datenbank Sachen manuell eintragen zu müssen.
Aber wie auch immer:
Ab Version 13.8 wird in der history.db für jeden Download nur noch die URL und die ID hinterlegt. Titel und Thema werden nicht mehr gespeichert. Die Felder bleiben leer. In einer folgenden Version wird eine (länger geplante) Optimierungsfunktion in MV integriert welche die Datenbank nach Duplikaten durchforstet und bereinigt. In diesem Zusammenhang werden dann auch die alten vorhandenen Titel und Themen aus der Datenbank entfernt.Open source developers do NOT have to:
- Make your issue a priority, just because you say so.
- Give you any sort of "timetable", or explanation for why it´s "taking too long".
Check your entitlement. Nobody owes you anything.
-
@derreisende77
Wenn ich wüsste, wie ich deine Fragen beantworten könnte, hätte ich sie beantwortet. Ich glaube, dass wir aneinander vorbeireden oder unterschiedliche Vorstellungen vom Nutzen so einer Tabelle haben.
So wie es aussieht, macht dann MV 13.8 für mich dann keinen Sinn.
Die Liste mit Titel und Thema fand ich sehr praktisch und übersichtlich. Die URL einer Sendung ist nicht auf Dauer gültig und wird von den Sendern manchmal verändert. Mit der ID kann ich nichts anfangen.
Gestern wurden wie gewohnt, wieder alle DL’s automatisch gelistet. -
@andy sagte in DL's von MV in DB Sqlite Eintrag erfolgt nicht immer automatisch:
Die Liste mit Titel und Thema fand ich sehr praktisch und übersichtlich.
Da muss ich zustimmen. Auch wenn ich die DB normalerweise nicht brauche, so habe ich schon ab und zu gezielt einige Einträge gelöscht. Und das wird erheblich vereinfacht, wenn eine Zeile einem Film zuzuordnen ist. Eine URL wie “https://arteptweb-a.akamaihd.net/am/ptweb/032000/032300/032352-000-C_EQ_0_VA-STA_05865974_MP4-1500_AMM-PTWEB_1YvjiZju7I.mpv” ist leider nicht sehr hilfreich.
@DerReisende77: Meiner Erfahrung nach dürfte sich die Suchgeschwindigkeit in einer DB nicht durch die Anzahl der Felder (Spalten) verändern sondern nur durch die Anzahl der Einträge (Zeilen). Warum also die DB unnötig klein halten.
MediathekView 14.3.0 nightly (4.3.2025), Linux Mint 21.3, VLC 3.0.16
-
Ich danke dir für deine Zustimmung. Eine Url ohne Titel und Thema ist unübersichtlich und bringt nichts.
Wenn ich in MV eine Sendung mit dem Titel und/oder Thema downloaden möchte und nicht sicher bin , ob ich den Beitrag schon gesehen habe oder nicht, dann lässt es sich in der DB SQLite besser und schneller wiederfinden.
In MV bekomme ich nur die jeweils abgefragte Sendung angezeigt, wenn sie schon heuntergeladen hatte.
Warum der Reisende unbedingt Titel und Thema entfernen will, verstehe ich nicht. Wenn andere User einen Nutzen davon haben, kann sie doch bleiben.!!!
-
@menchensued sagte in DL's von MV in DB Sqlite Eintrag erfolgt nicht immer automatisch:
@andy sagte in DL's von MV in DB Sqlite Eintrag erfolgt nicht immer automatisch:
Die Liste mit Titel und Thema fand ich sehr praktisch und übersichtlich.
Da muss ich zustimmen. Auch wenn ich die DB normalerweise nicht brauche, so habe ich schon ab und zu gezielt einige Einträge gelöscht. Und das wird erheblich vereinfacht, wenn eine Zeile einem Film zuzuordnen ist. Eine URL wie “https://arteptweb-a.akamaihd.net/am/ptweb/032000/032300/032352-000-C_EQ_0_VA-STA_05865974_MP4-1500_AMM-PTWEB_1YvjiZju7I.mpv” ist leider nicht sehr hilfreich.
Wieso nutzt Du dafür nicht einfach die Filmliste und setzt den gedownloadeten Film zurück auf ungelesen? Damit musst Du keine URL suchen und das Programm macht den Rest automatisch.
@DerReisende77: Meiner Erfahrung nach dürfte sich die Suchgeschwindigkeit in einer DB nicht durch die Anzahl der Felder (Spalten) verändern sondern nur durch die Anzahl der Einträge (Zeilen). Warum also die DB unnötig klein halten.
Jaein. Wenn man genügend RAM hat hält sich die Auswirkung von Spalten in Grenzen.
Und ja, Zeilen machen den meisten Aufwand, deshalb versuche ich ja auch die Redundanzen zu eliminieren in der Liste damit es flüssig bleibt. -
@andy sagte in DL's von MV in DB Sqlite Eintrag erfolgt nicht immer automatisch:
Ich danke dir für deine Zustimmung. Eine Url ohne Titel und Thema ist unübersichtlich und bringt nichts.
Wenn ich in MV eine Sendung mit dem Titel und/oder Thema downloaden möchte und nicht sicher bin , ob ich den Beitrag schon gesehen habe oder nicht, dann lässt es sich in der DB SQLite besser und schneller wiederfinden.
Das halte ich für ein Gerücht. Wieso nutzt Du denn die vom Programm angebotenen Möglichkeiten nicht?
Erläuterung:
Alle weiß hinterlegten Zeilen sind “ungesehen”, sprich noch nicht gedownloadet oder angesehen.
Die gelbe Zeile ist geogeblockt und von meinem Standort nicht abrufbar.
Die zwei grauen Zeilen beziehen sich auf Einträge, die mindestens einmal heruntergeladen wurden.Um sicher zu gehen dass Du keine schon geladenen Filme doppelt laden kannst/willst, gehst Du in das Filterfenster und aktivierst den Haken bei “Gesehene Filme nicht anzeigen”. Dann tauchen die Filme aus der history.db auch nicht mehr in MV aus. Das reduziert dann auch nebenbei die Anzahl der angezeigten Filme und entlastet auch das Programm bei der Suche, Filterung,…
In MV bekomme ich nur die jeweils abgefragte Sendung angezeigt, wenn sie schon heuntergeladen hatte.
Was logisch ist, da solange sie in der Downloadliste oxidiert und noch nicht geladen wurde also ungeladen/ungedownloadet/ungesehen ist und somit sich nicht in der History befinden kann da sie nicht angerührt wurde…
Davon abgesehen kannst Du jederzeit mittels Kontextmenü oder den Tasten g/u Einträge sofort als gesehen/ungesehen markieren. So blende ich z.B. bei mir die ganzen ORF Sendungen aus die ich aber manchmal zum Testen benötige.Warum der Reisende unbedingt Titel und Thema entfernen will, verstehe ich nicht. Wenn andere User einen Nutzen davon haben, kann sie doch bleiben.!!!
Nein. Weil history.db eine rein programm-interne Datenbank und nicht dafür vorgesehen ist, von Nutzern angefasst zu werden. Sie dient rein zur Implementierung einer Gesehen/Ungesehen Funktionalität die nicht den Arbeitsspeicher belastet. Und dazu sind die beiden Spalten völlig überflüssig. Aber den Hintergrund zur DB habe ich dir schon in diversen anderen Posts erklärt.
-
Was mich am allermeisten an der ganzen Diskussion amüsiert:
Normalerweise gibt es einen massiven shitstorm wenn man entdeckt das ein Programm den Nutzer quasi überwacht und viele seiner Aktionen protokolliert obwohl das für die Funktion unnötig ist.
Hier ist es genau umgekehrt: Es kommt der Aufschrei weil das Programm die Speicherung für die Funktion unnötiger Daten unterlässt…Wenn man nach eurer Logik vorgeht kann ich ja auch in Zukunft die von mir (aus Datenschutzgründen) verworfene Funktion vorsehen, sämtliche Downloads der clients an unsere Server zu senden um z.B. eine Beliebtheitsanzeige der Downloads zu realisieren.
Open source developers do NOT have to:
- Make your issue a priority, just because you say so.
- Give you any sort of "timetable", or explanation for why it´s "taking too long".
Check your entitlement. Nobody owes you anything.
-
@derreisende77 sagte in DL's von MV in DB Sqlite Eintrag erfolgt nicht immer automatisch:
Es kommt der Aufschrei weil das Programm die Speicherung für die Funktion unnötiger Daten unterlässt…
Das liegt sicherlich daran, dass die Funktion schon da war. Sonst hätte es niemanden interessiert, was in der DB steht. Performance ist natürlich wichtiger als eine lesbare DB. Sollte sich später zeigen, dass sich MediathekView durch Abarbeiten der umfangreicheren DB verlangsamt, so kann man das technisch begründen und die DB verschlanken.
-
Im Grunde liefert MV doch die benötigte Information. Sie steht halt nicht mehr in einer einzelnen Datei. Und bei Sendern wie ZDF, die alle naselang die URLs ändern, hilft doch alles nichts. Das ist übrigens mit ein Grund, warum ich ein Fan der eingebauten Mediensammlung bin, die leider in 13.8 weg fällt.
