mach doch n shortname: "T Steel Buddies" bei Constabel, dann ist das auch nicht so lang
epgd / epg2vdr / scraper2vdr
-
-
Es geht nicht um die Länge Christian, es sind mehrere Serien wo der Bindestrich "wechselt" und folglich von neuem aufgenommen wird.
-
Du kannst z.B. in der xsl-Datei des Plugins für die EPG-Daten mit dem Befehl translate Zeichen im Titel ersetzen.
-
Das wäre wohl der passende Ansatz, es scheint nämlich so zu sein dass der Unterschied am Anbieter "Plugin" liegt.
Nur da jedes mal "händisch" einzugreifen nach dem Neubau ist auch nicht die optimale Lösung
-
Nur da jedes mal "händisch" einzugreifen nach dem Neubau ist auch nicht die optimale Lösung
Deswegen baut man ja Pakete - damit ist es kein Problem wiederholt Patches auf den Upstream-Code anzuwenden.
-
Wo wir gerade bei Patches für epgd sind - ich habe am Wochenende mal den Bilder-Download für epgdata.com hingebogen: fix_epgdata_image_download.diff
-
Ich kann schon einen Patch erstellen usw. wenn ich weiß was zu ändern ist. Dafür fehlen mir aber leider die Grundlagen in diesem Fall.
-
Alles was du wissen musst, ist welche Zeichen du in welchem Tag ersetzen willst - also z.B. statt <title><xsl:value-of select="title"/></title> mit Ersetzung <title><xsl:value-of select="translate(title, '–', '-')"/></title>
Edit: Bei nicht-ASCII-Zeichen muss man ggf. je nach Encoding etwas tricksen, Versuch macht klug...
-
Genau das Plugin ist es auch
Ich habe mal die Datei angepasst und den EPGD komplett neu gestartet. Es scheint als ob die Zeichen wohl doch ein anderes Format haben wie ASCII oder ich bin zu ungeduldig. Von folgender Sendung kommen die Daten von diesem Plugin
Hier sieht man schön das Problem:
-
Wurden die Timer neu angelegt (im Zweifelsfall mal die Tabelle für EPG-Daten und Timer droppen)? Passt es dann in den EPG-Daten?
Ansonsten ermittle mal das exakte Zeichen für den längeren Bindestrich (es muss ja nicht zwingend ein Halbgeviertstrich sein) - in einer Python-Shell geht das z.B. mit ord():
-
Genau jetzt mischt er alles vom "anderen" Plugin mit rein, da wo es passt ...
War ja fast klar
-
Dann mach die Ersetzung doch auch noch in der xsl-Datei des anderen Plugin, der Tag für <title> sollte leicht zu finden sein.
-
Das andere Plugin macht das Problem nicht, zumindest fiel mir es da noch nie auf.
-
Dann habe ich vermutlich nicht ganz verstanden, was das Problem ist - funktioniert die Ersetzung für das Plugin, das den abweichenden Bindestrich liefert, nicht oder woran scheitert es?
-
Im Moment mischt EPGD die Daten mit TVM und nicht mit TVSP wo dieses Problem mit dem Bindestrich besteht. Bei TVM gibt es also das Problem nicht, nur wenn die Daten von TVSP kommen.
-
ich habe am Wochenende mal den Bilder-Download für epgdata.com hingebogen:
wird horchi den Patch übernehmen?
Gruss
Wolfgang
-
Ich habe ihm am Sonntag eine Mail geschrieben, aber noch keine Antwort darauf bekommen.
-
Wo wir gerade bei Patches für epgd sind - ich habe am Wochenende mal den Bilder-Download für epgdata.com hingebogen: fix_epgdata_image_download.diff
Super, vielen Dank schonmal dafür.
Allerdings funktioniert das bei mir noch nicht so richtig. Das Speichern der Bilder in der DB funktioniert, aber dann bekomme ich wenn epg2vdr versucht das Image ins Filesystem zu schreiben folgende Fehler im Log:
Code... Dec 14 19:14:50 vdr vdr: epg2vdr: Can't write image to '/var/cache/vdr/epgimages/images/https://cellular.images.dvbdata.com/1234567/1234567_320x240.jpg', error was 'Datei oder Verzeichnis nicht gefunden' ...
In der DB wird der Imagename ja mit Pfad eingetragen
Codemysql> select * from imagerefs limit 1; +-----------+-----+------------+------------+---------+-------------------------------------+-----------------------------------------------------------------+ | eventid | lfn | inssp | updsp | source | fileref | imagename | +-----------+-----+------------+------------+---------+-------------------------------------+-----------------------------------------------------------------+ | 123397323 | 0 | 1513275001 | 1513275001 | epgdata | 20171215_20171214_de_qy.zip-1269542 | https://cellular.images.dvbdata.com/1234567/1234567_320x240.jpg | +-----------+-----+------------+------------+---------+-------------------------------------+-----------------------------------------------------------------+ 1 row in set (0,00 sec)
Ist das richtig so? Sollte er nicht aufgrund der angepassten XSL beim Filenamen in der DB die "/" durch "|" ersetzen? Beim Download scheinst du das ja (verständlicherweise) wieder rückgängig zu machen.
Mir ist noch nicht so ganz klar wie das File am Ende im Filesystem heißen soll. Wenn das File "/" im Dateinamen hat, dann ist es aus meiner Sicht verständlich, dass das bei mir noch nicht funktioniert.
Hast du hier eine Idee oder bin ich völlig verkehrt mit meinen Überlegungen?
Grüße,
Alex
P.S. Habe den Pfad mal unkenntlich gemacht.
-
Schau mal in die /etc/epgd/epgdata.xsl, ob da die Änderung schon drin ist. Wenn man den vdr-epg-daemon mit make install installiert, wird die epgdata.xsl (wegen der Abfrage in https://projects.vdr-developer…GINS/epgdata/Makefile#n30 ) nicht überschrieben.
Es ist in der tat so, dass ich im <imagename>-Tag den Slash durch ein Pipe-Zeichen ersetze (eventuell wäre ein @ besser, wenn man auch an NTFS und FAT Dateisysteme denkt), damit epg2vdr den Dateinamen anlegen kann.
-
Au man, genau das war es.
Ich dachte, dass ich das gestern Abend kontrolliert hätte. Sorry, das war dann ein klassisches "Wald vor lauter Bäumen nicht gesehen".
Danke und Grüße,
Alex
Jetzt mitmachen!
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!