Argh...hatte gar nicht mehr auf dem Schirm, dass es ja noch die Funktion gibt.
[tvscraper] Fehlende Scrapings
-
-
Mal etwas in die andere Richtung, also False Positives:
mir fallen immer mal wieder kurze EPG-Einträge (10-30min) auf, die Filme mit 80+min Länge zugeordnet bekommen, weil deren Titel identisch oder teilidentisch war.
Aktuelles Beispiel: Zurück zur Natur auf ORF 2 Europe.
Wäre es evtl. eine Idee, ab einer gewissen Laufzeitabweichung (z.B. weniger als 50% der Länge, außer wenn keine Laufzeit vorhanden ist) nicht nur ein Match von 0,00000 sondern einen negativen Match-Wert zu erzeugen?
-
Das wäre relativ einfach, ich könnte die Gewichtung der Übereinstimmung bei Laufzeit erhöhen.
Aber dann werden korrekte Zuordnungen nicht mehr gefunden, bei denen die Laufzeit nicht stimmt.
Wenn es insgesamt zu viele false positives gibt, kann ich natürlich den Schwellenwert für akzeptierte Treffer erhöhen. Was dann wieder zu zu wenigen korrekten Treffern führt.
-
> Aber dann werden korrekte Zuordnungen nicht mehr gefunden, bei denen die Laufzeit nicht stimmt.
Das Matching progressiv/degressiv zu gestalten wäre nicht möglich?
Also, dass sich bei bis +/-30% an der bisherigen Bewertungen nichts ändert, aber wenn es es eben 30min vs. 90min-Laufzeit es sogar einen negativen Matching-Wert ergibt? Ich hatte auch mal den Extremfall beobachtet, wo ein 10min-Kurzfilm einen 125min Kinofilm aus den 50ern zugewiesen bekam.
Mir geht es letztlich nur darum, dass man diese Laufzeit-Extremabweichungen abfangen und zum besseren Aussieben nutzen könnte. Das ganze sollte natürlich nicht greifen, wenn überhaupt keine Laufzeit vorhanden ist.
-
Man könnte das, wenn möglich, auch nur auf Filmzuordnungen beschränken.
Serien in 45min und 10min-Ausgaben kommen vor, da würde man verlieren, das stimmt.
Filme dagegen mit 90min in der DB existieren nur in den seltensten Fällen als 30min-Ausgabe.
-
> Filme dagegen mit 90min in der DB existieren nur in den seltensten Fällen als 30min-Ausgabe.
Außer der Sender splittet den Film in 3 Teile ...
Oder die Daten der externen Datenbank sind falsch ...
Oder ...
Das Problem ist hier nicht, 3 Zeilen Code zu schreiben.
Die Herausforderung ist, den Code so zu schreiben, dass das Ergebnis insgesamt besser wird.
Im git ist ein Update, das
ergänzt. Damit kannst Du dann direkt einen Float Wert setzen, sollte zwischen -1 und 1 sein. Negative Werte >-1 müssten funktionieren, ist aber ungetestet.
Die Änderung kannst Du in searchEventOrRec.c implementieren, so um Zeile 869 für Movies:
Codeint movie_runtime = sql_movieEnhance.getInt(0); int durationDistance = searchEventOrRec.m_sEventOrRecording->DurationDistance(movie_runtime); if (searchEventOrRec.m_num_parts > 0) durationDistance = std::min(durationDistance, searchEventOrRec.m_sEventOrRecording->DurationDistance(movie_runtime/searchEventOrRec.m_num_parts)); sR.setDuration(durationDistance);
movie_runtime ist die in der externen DB gepflegte Laufzeit in min.
z.B. mit sR.setDurationMatch(-0.5); (anstelle von sR.setDuration(durationDistance);)
kannst Du einen negativen match setzen.
DurationDistance funktioniert so:
Codeint csEventOrRecording::DurationDistance(int DurationInMin) { int durationInMinLow, durationInMinHigh; if (DurationInMin <=0 || !DurationRange(durationInMinLow, durationInMinHigh) ) return -2; // no data if (DurationInMin > durationInMinHigh) return DurationInMin - durationInMinHigh; if (DurationInMin < durationInMinLow) return durationInMinLow - DurationInMin; return 0; }
DurationRange schätzt hier die Länge des vom Sender gesendeten Films aufgrund von Daten im Event. Es ist ein Bereich, weil unklar ist, wie viel Werbung der Sender sendet. Und dann schneiden Sender den Abspann des Filmes noch gerne weg, ...
Du kannst mal probieren, das so zu verändern, dass das Ergebnis insgesamt besser wird, also für alles, was so im EPG kommt ...
~ Markus
-
Du könntest auch in searchResultTvMovie.c die Zeile
ändern in z.B.
oder auch 3.0. Das ändert die Gewichtung der Längenabweichung.
Wäre einfacher, und irgendwie konsistenter. Falls das dann wegen einem Bug in der TheTVDB API zu Fehlern führt, kann man ja dafür noch etwas einbauen.
~ Markus
-
Es ist ein Bereich, weil unklar ist, wie viel Werbung der Sender sendet. Und dann schneiden Sender den Abspann des Filmes noch gerne weg, ...
Ich muss zugeben, dass ich den Aspekt bisher Null bedacht habe, da ich hauptsächlich im ÖRR-Bereich unterwegs bin.
ÖRR ist üblicherweise Netto-Laufzeit + 2min für Vorschau-Gedöns.
Dass das bei den Privaten durch die Werbung natürlich komplett verfälscht, ist klar.
-
Hi rüsseltier ,
ich habe:
https://api4.thetvdb.com/v4/search?query=baja%20california%20&type=series
https://api4.thetvdb.com/v4/search?query=das%20andere%20kalifornien&type=series
im Swagger UI getestet. Keine dieser Suchanfragen liefert einen Treffer, "data" ist [].
Liegt daran, dass das ein Spielfilm ist, und tvscraper TheTVDB nur für Serien verwendet.
~ Markus
-
OK - ich vergesse das immer wieder...
Verfolgst Du eigentlich den Querverweise-Ansatz über die gegenseitige ID- bzw. IMDB-Verlinkung noch?
Du hattest da glaube ich vor 3 Monaten mal extra eine DB-Tabelle für zukünftige Zwecke hinzugefügt.
-
Noch was anderes: ich habe heute morgen die aktuelle Git-Version installiert und seitdem ist mein syslog von 40 auf 100MB angeschwollen.
Gab es da in letzter Zeit eine Änderung bei der Verbosity? Ich bin bislang nie über 60MB pro Woche gekommen und jetzt habe ich +60MB in 10 Stunden.
Was ich sehe, sind sehr viele vermeintliche "Doppeluntersuchungen":
Code
Alles anzeigenFeb 23 18:53:55 vdr vdr: [3086] tvscraper: TVtv "japan's top inventions", episode "The fascinating stories and secrets behind hit Japanese products, plus parts and machines that boast" successfully scraped, id -346731 season 0 episode 0 Feb 23 18:53:55 vdr vdr: [3086] tvscraper: searchResultTvMovie::log, id: -346731, title: "japan's top inventions" Feb 23 18:53:55 vdr vdr: [3086] tvscraper: searchResultTvMovie::log, i: 0, match: 1,000000, weight 0,600000, desc: Text Feb 23 18:53:55 vdr vdr: [3086] tvscraper: searchResultTvMovie::log, i: 1, match: 0,300000, weight 0,100000, desc: Year Feb 23 18:53:55 vdr vdr: [3086] tvscraper: searchResultTvMovie::log, i: 2, match: 0,075000, weight 0,150000, desc: Vote, .. Feb 23 18:53:55 vdr vdr: [3086] tvscraper: searchResultTvMovie::log, i: 3, match: 1,000000, weight 0,200000, desc: Duration Feb 23 18:53:55 vdr vdr: [3086] tvscraper: searchResultTvMovie::log, i: 4, match: 0,000000, weight 0,300000, desc: Actors Feb 23 18:53:55 vdr vdr: [3086] tvscraper: searchResultTvMovie::log, i: 5, match: 0,000000, weight 0,100000, desc: Director Writer Feb 23 18:53:55 vdr vdr: [3086] tvscraper: searchResultTvMovie::log, i: 8, match: 1,000000, weight 0,000100, desc: PositionInExternalResult Feb 23 18:53:55 vdr vdr: [3086] tvscraper: searchResultTvMovie::log, i: 9, match: 1,000000, weight 0,200000, desc: TranslationAvailable Feb 23 18:53:55 vdr vdr: [3086] tvscraper: searchResultTvMovie::log, getMatch(): 0,631083, delim: Feb 23 18:53:55 vdr vdr: [3086] tvscraper: searchResultTvMovie::log, id: -346731, title: "japan's top inventions" Feb 23 18:53:55 vdr vdr: [3086] tvscraper: searchResultTvMovie::log, i: 0, match: 1,000000, weight 0,600000, desc: Text Feb 23 18:53:55 vdr vdr: [3086] tvscraper: searchResultTvMovie::log, i: 1, match: 0,300000, weight 0,100000, desc: Year Feb 23 18:53:55 vdr vdr: [3086] tvscraper: searchResultTvMovie::log, i: 2, match: 0,075000, weight 0,150000, desc: Vote, .. Feb 23 18:53:55 vdr vdr: [3086] tvscraper: searchResultTvMovie::log, i: 3, match: 1,000000, weight 0,200000, desc: Duration Feb 23 18:53:55 vdr vdr: [3086] tvscraper: searchResultTvMovie::log, i: 4, match: 0,000000, weight 0,300000, desc: Actors Feb 23 18:53:55 vdr vdr: [3086] tvscraper: searchResultTvMovie::log, i: 5, match: 0,000000, weight 0,100000, desc: Director Writer Feb 23 18:53:55 vdr vdr: [3086] tvscraper: searchResultTvMovie::log, i: 8, match: 0,500000, weight 0,000100, desc: PositionInExternalResult Feb 23 18:53:55 vdr vdr: [3086] tvscraper: searchResultTvMovie::log, i: 9, match: 1,000000, weight 0,200000, desc: TranslationAvailable Feb 23 18:53:55 vdr vdr: [3086] tvscraper: searchResultTvMovie::log, getMatch(): 0,631053, delim: :
Bei tieferer Betrachtung: es scheint, wie wenn das 14-tägliche Komplett-Rescraping läuft, dabei aber gescrapte Einträge nicht mehr "abgehakt" werden. Ich hatte heute 5 oder 6 Hardware-Neustarts und er fängt jedes Mal wieder komplett von vorne an, ebenso bei vdr restarts mit scep auf Shell-Ebene.
-
Gerade die Probe aufs Exempel gemacht:
CodeFeb 23 19:07:04 vdr vdr: [3086] tvscraper: Cleanup Done Feb 23 19:07:04 vdr vdr: [3086] tvscraper: epg scraping done Feb 23 19:07:04 vdr vdr: [3086] tvscraper: access /var/cache/vdr/plugins/tvscraper/tvscraper2.db for write Feb 23 19:07:05 vdr vdr: [3086] tvscraper: access to /var/cache/vdr/plugins/tvscraper/tvscraper2.db finished, rc = 0
Dann eben Neustart und er fängt wieder von vorne an (mittlerweile 110MB syslog).
-
Neustart? Nur VDR, oder Reboot des Rechners?
-
> Neustart? Nur VDR, oder Reboot des Rechners?
Reboot des Rechners um 19:20 nachdem das Scraping laut Log um 19:07 durch war.
-
Nach zwei systemctl vdr restart && svdrpsend PLUG tvscraper scep mittlerweile 129MB syslog.
-
Im git ist ein update.
Damit werden die Einträge in cache korrekt geschrieben, d.h. der erste Scan nach dem Update wird noch genauso lang sein wie bisher.
Der 2. Scan sollte dann mit den (jetzt richtigen) Einträgen im cache wieder kürzer sein.
Bitte testen.
~ Markus
-
Hat es behoben. Erster Durchgang noch ~10MB Logzuwachs, zweiter Durchlauf nur mehr 126KB.
-
tvscraper löscht ja gescrapte Einträge aus dem Cache, wenn deren EPG-Beginn in der Vergangenheit liegt.
Dadurch ergibt sich aber mitunter das Problem, dass aktuell noch laufende Sendungen in der Live-Oberfläche ohne Bild und Scraping-Daten angezeigt werden. (wenn währenddessen ein Scraping-Durchgang mit anschließendem Cache-Aufräumen stattfand)
Könnte man das evtl. verhindern? Im Zweifel würde auch ein rustikales jetzt + 6h als Löschgrenze genügen.
-
Hi,
Im git ist ein Update.
- Events werden jetzt erst 5 Stunden nach EndTime() gelöscht.
- Ich habe die Gewichtung von Vote ... noch mal reduziert. Hier gesendete deutsche Serien habe oft gering Votes, und eigentlich ist das kein wirkliches Kriterium.
Bitte testen.
~ Markus
-
Gerade getestet: Scraping-Durchlauf gemacht und nach dem Cleanup sind noch alle laufenden 20:15-21:45-Sendungen in Live mit den Daten vorhanden.
Jetzt mitmachen!
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!