die Bilder im *.rec Folder sind nur für Anwendungen, die das plugin service interface von tvscraper nicht nutzen, also z.B. für KODI.
live und die VDR skins nutzen das plugin service interface von tvscraper und ignorieren diese Bilder.
Wäre es nicht sinnvoll für KODI und auch allgemeine Archivierungszwecke die Bilddateien in die geschnittene "mitzunehmen"?
Ich mein, wenn sie eh schon im Ursprungsordner liegen...
Also, ich kann hier wieder zurückrudern und die Startzeit der Aufnahme ignorieren. Es ist doch recht selten, dass 2 Aufnahmen das gleiche Event haben, aber unterschiedliche Sendungen sind.
Das würde ich als die beste Lösung ansehen.
Wäre es nicht sinnvoll für KODI und auch allgemeine Archivierungszwecke die Bilddateien in die geschnittene "mitzunehmen"?
Ich mein, wenn sie eh schon im Ursprungsordner liegen...
Das würde bedeuten, das der Core-VDR gepatcht werden müsste, hmm...
Andererseits nutzen ja nicht alle Skins diese Bilder, so das es dann immer noch Probleme gibt.
Eine Lösung im tvscraper wäre hier sicherlich die allgemeinere.
Grüße
kamel5
Im git ist ein update.
Damit sind die scraper Daten für geschnittene Aufnahmen über das VDR interne Service Interface wieder sofort verfügbar.
Sollte mit live und den Skins funktionieren.
Bitte testen.
~ Markus
Im git ist ein update.
Damit sind die scraper Daten für geschnittene Aufnahmen über das VDR interne Service Interface wieder sofort verfügbar.
Sollte mit live und den Skins funktionieren.
Bitte testen.
Hier mit Live getestet, funktioniert es wie es soll.
Vielen Dank!
In den getesteten Skins funktioniert es auch.
Grüße
kamel5
Hallo,
ich habe seit einiger Zeit (weiß aber nicht seit wann) Probleme mit dem Scraping von Aufnahmen.
Hier mal ein Beispiel aus der Serie Sherlock:
vdr ~ # ll /video/videos/_Sherlock/04_Sherlock_-_Ein_Skandal_in_Belgravia/2016-07-18.20.15.24-0.rec/
insgesamt 4221988
19358570948 0 drwxrwxrwx 2 root root 204 3. Apr 13:39 .
21477350616 0 drwxr-xr-x 3 root root 47 28. Mar 07:50 ..
19358594250 2048048 -rw-rw-rw- 1 root root 2097199032 18. Jul 2016 00001.ts
19358594251 2048172 -rw-rw-rw- 1 root root 2097327060 18. Jul 2016 00002.ts
19358594252 123908 -rw-rw-rw- 1 root root 126878568 18. Jul 2016 00003.ts
19358570955 660 -rw-r--r-- 1 root root 675061 30. Aug 2022 fanart.jpg
19358594253 1052 -rw-rw-rw- 1 root root 1074352 18. Jul 2016 index
19358570980 4 -rw-rw-rw- 1 root root 1196 7. Oct 2022 info
19358594255 4 -rw-rw-rw- 1 root root 1676 18. Jul 2016 markad.log
19358619130 4 -rw-r--r-- 1 root root 51 14. Jun 2020 marks
19358570954 132 -rw-r--r-- 1 root root 132155 30. Aug 2022 poster.jpg
19358594256 4 -rw-r--r-- 1 root root 9 14. Jun 2020 resumevdr ~ # cat /video/videos/_Sherlock/04_Sherlock_-_Ein_Skandal_in_Belgravia/2016-07-18.20.15.24-0.rec/info
C S19.2E-1-1051-28722 Einsfestival
E 37700 1468865700 5400 4E F
T Sherlock - Ein Skandal in Belgravia
S Spielfilm Großbritannien 2011 (Sherlock - A Scandal in Belgravia)
D Sherlock und Watson werden von der Regierung mit einem äußerst delikaten Fall betraut: Die Domina Irene Adler hat heimlich kompromittierende Fotos von einem Mitglied der britischen Königsfamilie gemacht. Nun sollen die beiden Privatermittler das belastende Bildmaterial sicherstellen. Was auf den ersten Blick wie keine große Herausforderung erscheint, entwickelt sich sehr schnell zu einem der schwierigsten Fälle, mit dem Sherlock je konfrontiert wurde. Denn nicht nur kommt er durch Irene einem mörderischen Komplott auf die Spur - der unnahbare Ermittler beginnt auch, sich in die schöne und gefährliche Frau zu verlieben.|Produziert in HD
G 10
X 1 03 deu 16:9
X 2 03 deu stereo
X 4 44 deu Dolby Digital 5.1
X 3 01 deu
X 2 48 deu mit Audiodeskription
X 2 03 mis
V 1468865700
F 25
P 50
L 99
X 2 05 mis Dolby Digital 5.1
@ <epgsearch><channel>24 - Einsfestival</channel><update>0</update><eventid>37700</eventid><bstart>0</bstart><bstop>0</bstop><start>1468865700</start><stop>1468871100</stop></epgsearch>
O 0Apr 3 13:45:21 vdr vdr[3082]: [3287] SVDRP vdr < 127.0.0.1:41864 client connection accepted
Apr 3 13:45:21 vdr vdr[3082]: [3287] SVDRP vdr > 127.0.0.1:41864 server created
Apr 3 13:45:21 vdr vdr[3082]: [3148] tvscraper: scanning video dir
Apr 3 13:45:21 vdr vdr[3082]: [3287] SVDRP vdr < 127.0.0.1:41864 connection closed
Apr 3 13:45:21 vdr vdr[3082]: [3287] SVDRP vdr < 127.0.0.1:41864 server destroyed
Apr 3 13:45:21 vdr vdr[3082]: [3148] tvscraper: Scrap recording "/video/videos/_Sherlock/04_Sherlock_-_Ein_Skandal_in_Belgravia/2016-07-18.20.15.24-0.rec"
Apr 3 13:45:21 vdr vdr[3082]: [3148] tvscraper: touch "/var/cache/vdr/plugins/tvscraper/.recordingsUpdate"
Apr 3 13:45:21 vdr vdr[3082]: [3148] tvscraper: scanning video dir done
Apr 3 13:45:21 vdr vdr[3082]: [3148] tvscraper: start scraping epg
Apr 3 13:45:21 vdr vdr[3082]: [3148] tvscraper: Schedule was not changed, skipping scan
Apr 3 13:45:21 vdr vdr[3082]: [3148] tvscraper: epg scraping done
Das Seltsame ist, dass manche im Verzeichnis Nummerierte Folgen sauber gescrapt werden:
Apr 3 14:07:44 vdr vdr[3082]: [3287] SVDRP vdr < 127.0.0.1:54804 client connection accepted
Apr 3 14:07:44 vdr vdr[3082]: [3287] SVDRP vdr > 127.0.0.1:54804 server created
Apr 3 14:07:44 vdr vdr[3082]: [3148] tvscraper: scanning video dir
Apr 3 14:07:44 vdr vdr[3082]: [3287] SVDRP vdr < 127.0.0.1:54804 connection closed
Apr 3 14:07:44 vdr vdr[3082]: [3287] SVDRP vdr < 127.0.0.1:54804 server destroyed
Apr 3 14:07:44 vdr vdr[3082]: [3148] tvscraper: Scrap recording "/video/videos/_Sherlock/06_Sherlock_-_Der_Reichenbachfall/2016-08-01.20.15.24-0.rec"
Apr 3 14:07:44 vdr vdr[3082]: [3148] tvscraper: touch "/var/cache/vdr/plugins/tvscraper/.recordingsUpdate"
Apr 3 14:07:44 vdr vdr[3082]: [3148] tvscraper: scanning video dir done
Apr 3 14:07:44 vdr vdr[3082]: [3148] tvscraper: start scraping epgManchmal werden dann, nach mehrfachen Versuchen, des Scrapens einzelner Aufnahmen, die Daten doch angezeigt.
Irgendwie funktioniert das gerade bei mir recht unzuverlässig.
Aber das hatte doch schon mal alles gut funktioniert.
Browser Cache löschen und reload habe ich natürlich gemacht.
MarkusE hast Du eine Idee, was bei mir schief läuft?
Auch habe ich das Problem, dass manche neuen Aufnahmen, die eigentlich schon einen Bezug zu tvscraper hatten, irgendwann nach einem reboot in live wieder ungescrapt erscheinen.
Wenn ich die Aufnahme dann manuell scrape, kommen meist wieder die Einträge.
Kann das auch mit dem API-Fehler zusammenhängen?
Hi,
Im git ist ein Update. Damit reagiert tvscrapper besser auf den Fehler in der TheTVDB API:
Also, ich kann nicht zaubern: Wenn TheTVDB API die Namen der Episoden in deutsch nicht liefert, kann ich auch die Episoden nicht identifizieren 
.
Außerdem:
Bitte testen.
heifisch , ich hatte bereits mit dem letzten git commit einen Fehler gefixed, aufgrund von dem die Zuordnung von geschnittenen Aufnahmen zum Film verloren ging. Bitte teste doch mal das neueste git ...
~ Markus
Bitte testen.
heifisch , ich hatte bereits mit dem letzten git commit einen Fehler gefixed, aufgrund von dem die Zuordnung von geschnittenen Aufnahmen zum Film verloren ging. Bitte teste doch mal das neueste git ...
Danke MarkusE .
Leider bekomme ich damit ein Segfault:
(gdb) bt
#0 0x00007f314487822c in std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::operator= (__s=Python Exception <class 'gdb.MemoryError'>: Cannot access memory at address 0x8
#1 cTVDBSeries::ParseJson_Series (this=this@entry=0x7f3121fa8060, jSeries=..., displayLanguage=displayLanguage@entry=0x0) at thetvdbscraper/tvdbseries.c:60
#2 0x00007f31448a43ee in cTVDBScraper::StoreSeriesJson (this=0x7f30f4079950, seriesID=seriesID@entry=387540, forceUpdate=forceUpdate@entry=true) at thetvdbscraper/thetvdbscraper.c:173
#3 0x00007f31448d1180 in cTvDbTvScraper::enhance1 (this=this@entry=0x7f30f407ace0, searchResultTvMovie=..., lang=<optimized out>) at /usr/local/src/vdr-plugin-tvscraper/searchResultTvMovie.h:51
#4 0x00007f31448896f5 in cSearchEventOrRec::enhance1 (sR=..., searchEventOrRec=...) at /usr/local/src/vdr-plugin-tvscraper/searchEventOrRec.c:849
#5 0x00007f314487b6b1 in cSearchEventOrRec::selectBestAndEnhanceIfRequired (this=this@entry=0x7f3121fa8bf0, begin=Python Exception <class 'gdb.error'>: value has been optimized out
, end=end@entry=..., new_end=..., minDiff=minDiff@entry=0.200000003, func=func@entry=0x7f3144889680 <cSearchEventOrRec::enhance1(searchResultTvMovie&, cSearchEventOrRec&)>) at /usr/local/src/vdr-plugin-tvscraper/searchEventOrRec.c:805
#6 0x00007f314488ff43 in cSearchEventOrRec::ScrapFind (this=this@entry=0x7f3121fa8bf0, searchResults=std::vector of length 83, capacity 128 = {...}, foundName=..., episodeSearchString=...) at /usr/lib/gcc/x86_64-pc-linux-gnu/13/include/g++-v13/bits/stl_iterator.h:1076
#7 0x00007f31448a9b55 in cSearchEventOrRec::ScrapFindAndStore (this=this@entry=0x7f3121fa8bf0, movieOrTv=...) at /usr/local/src/vdr-plugin-tvscraper/searchEventOrRec.c:348
#8 0x00007f31448aa337 in cSearchEventOrRec::Scrape (this=this@entry=0x7f3121fa8bf0, statistics=@0x7f3121fa89ec: 0) at /usr/local/src/vdr-plugin-tvscraper/searchEventOrRec.c:238
#9 0x00007f31448ae87f in cTVScraperWorker::ScrapEPG (this=this@entry=0x562e87a65a60) at /usr/local/src/vdr-plugin-tvscraper/worker.c:238
#10 0x00007f31448b2c28 in cTVScraperWorker::Action (this=0x562e87a65a60) at /usr/local/src/vdr-plugin-tvscraper/worker.c:589
#11 cTVScraperWorker::Action (this=0x562e87a65a60) at /usr/local/src/vdr-plugin-tvscraper/worker.c:561
#12 0x0000562e8768fd15 in cThread::StartThread (Thread=0x562e87a65a60) at thread.c:293
#13 0x00007f315926a1d3 in ??? () at /lib64/libc.so.6
#14 0x00007f31592eb80c in ??? () at /lib64/libc.so.6
(gdb) Wann der Segfault auftritt, konnte ich noch nicht nachvollziehen.
Sieht danach aus, das keine Benutzerinteraktion nötig ist.
Am Anhang noch bt full
Im git ist ein update.
Damit sind die scraper Daten für geschnittene Aufnahmen über das VDR interne Service Interface wieder sofort verfügbar.
Sollte mit live und den Skins funktionieren.
Bitte testen.
~ Markus
Hallo MarkusE .
Seit einiger Zeit habe ich das Verhalten, dass wieder keine Scraper-Daten den frisch geschnittenen Aufnahmen zur Verfügung stehen.
Man muss die geschnittene Aufnahme manuel scrapen, damit sie wieder verfügbar sind.
Hast Du das Verhalten wieder geändert?
Gruß und Danke.
Heiko
Kann ich hier nicht reproduzieren,
Ein paar Minuten nach dem Start der Aufnahme sind die scraper Daten auch bei der Aufnahme.
Kann ich hier nicht reproduzieren,
Ein paar Minuten nach dem Start der Aufnahme sind die scraper Daten auch bei der Aufnahme.
Es geht nicht um neue Aufnahmen, sondern um geschnittene Aufnahmen.
Ich glaube die Daten muss man im 'Recodring_Hook' kopieren.
Beispiel im Abschnitt 'edited':
edited) # Nach dem editieren einer Aufnahme
# echo "Edited recording $2"
# echo "Source recording $3"
# Dateien von TVScraper und epg2vdr zur editierten Aufnahme kopieren
files=(banner.jpg fanart.jpg poster.jpg tvscraper.json tvscrapper.json) # TVScraper
files+=(info.epg2vdr) # epg2vdr
for file in "${files[@]}" ; do
[[ -e "${3}/${file}" ]] && cp --archive --update "${3}/${file}" "${2}"
doneIch glaube die Daten muss man im 'Recodring_Hook' kopieren.
Danke für den Tipp. Das hatte aber schon mal ohne Hook funktioniert.
Landet dann die Aufnahme auch in der Datenbank?
Aber man könnte auch das scrapen der geschnittenen Aufnahme durch den Hook starten.
Es geht nicht um neue Aufnahmen, sondern um geschnittene Aufnahmen.
Sorry, hattest Du geschrieben, habe ich überlesen .
Ich werde da eine Lösung suchen.
> Aber man könnte auch das scrapen der geschnittenen Aufnahme durch den Hook starten.
Hört sich gut an, müsste funktionieren.
Dieser Recording-Hook funktioniert bei mir soweit.
#!/bin/bash
#set -x
if [ $1 == "edited" ]; then
svdrpsend PLUG tvscraper SCRE $2;
fi> Aber man könnte auch das scrapen der geschnittenen Aufnahme durch den Hook starten.
Hört sich gut an, müsste funktionieren.
Klar kann man vieles machen, das Anzeigen von Scraper-Informationen bei geschnittenen Aufnahmen ist aber schon mal gegangen. Ein kurzer Test mit Version 1.2.12 zeigt, das es damit noch geht. Es scheint also einer der letzten commits nach V1.2.12 dafür verantwortlich zu sein, das es nicht mehr funktioniert.
Grüße
kamel5
Don’t have an account yet? Register yourself now and be a part of our community!