tvscraper holt falsche Infos

Damit muss man leider leben, da der tvscraper nicht mehr weiterentwickelt wird.

Gesendet von meinem GT-I9100 mit Tapatalk 2

Wenn ich louis richtig verstanden habe kann dies beim tvscraper immer wieder vorkommen. Ich meine mich zu erinnern das die gesuchten IDs nicht zu 100% eindeutig sind.
Dies war ja einer der Gründe für den Neubeginn mit epgd, epg2vdr und scraper2vdr.

Auch scraper2vdr kann mal daneben greifen, dafür gibts dann für Aufnahmen das scrapinfo file, um das ganze manuell zu überschreiben.

Zitat von Asta

Damit muss man leider leben, da der tvscraper nicht mehr weiterentwickelt wird.

So pauschal falsch. Worst-Case müsste man den tvscraper halt forken aber weiterentwickeln kann man ein Open-Source-Projekt immer.

In dem Fall dürfte der Kreis der möglichen Entwickler durch "Sky" aber zusätzlich eingegrenzt sein.

nein das hat nichts mit Sky und nur etwas mit dem tvscraper zu tun.

Der tvscraper nutzt halt die IDs der Sender, und die sind halt nur innerhalb eines Kanals unique. Wenn du jetzt plain epg oder aber auch epgimages mit xmltv oder dem alten tvmovie nutzt dann werden Objekte immer relativ zur ID angezeigt. Vermutlich gibt es hier genau ein Objekt "Ritter aus Leidenschaft" welches gescraped wurde, zu jedem Objekt mit genau dieser ID werden die Infos nun angezeigt.

Es jetzt nur im tvscraper zu ändern wäre jetzt auch nicht zielführend, um es konsistent zu halten müsste überall wo externer Inhalt an das Event gehängt wird nachgebessert werden, Also Live, vdradmin, graphtft, scraper etc.

In epgd werden halt in der Verwaltung der Events eigene unique IDs erzeugt und damit kommt das dann an der Stelle nicht mehr durcheinander.

Christian

Eigentlich müsste man nur den Kanal mit in die ID nehmen und schon wäre das ganze eindeutig, oder?

joo, so ist es im DVB Standard definiert - so richtig schön ist das halt trotzdem nicht weil einiges Sender immer die IDs von ihren Events schon kurz vor dem Sendetermin ändern und die selbe ID 10 Minuten später auf einem anderen Event wiederverwerten. Ist zwar noch im Standard, hat aber eine ganz andere Bedeutung. Machen quasi alle Sender, einige aber im ganz großen Stil - Ich hab bei diesen Kanälen bei mir sogar das Mischen abgestellt und nehm nur externes, sonste mischt er die alle paar Minuten um (wechselt von Ext nach DVB nach Ext Event im vdr )

aktuell bei diesen hier:
root@ProLiant:~# grep ':0 =' /etc/epgd/channelmap.conf

tvm:69:0 = S19.2E-1-1053-21107  //      NICK HD
tvm:14:0 = S19.2E-1-1053-21107  //      Comedy Central HD
tvm:48:0 = S19.2E-1-1091-31220  //      EuroNews
epgdata:127:0 = S19.2E-1-1026-10067     //      Bloomberg Europe TV
tvm:42:0 = S19.2E-1-1068-28522  //      CNN Int.
tvm:177:0 = S19.2E-133-10-125   //      AXN HD
tvm:54:0 = S19.2E-1-1053-21103  //      QVC HD

machen entweder so komische Sachen oder senden gar kein DVB EPG

Wir brauchens zB jetzt aber auch nicht, nicht für den scraper, nicht für epgd und nicht für graphtft...

Christian

Zitat von dippes

Würdet ihr trotzdem umsteigen?

Nein.

Ich hatte es einige Zeit am Laufen. Für den Zweck, für den es gemacht ist, mag es ganz nett sein, aber für Standalone-Geräte total überdimensioniert.
Ich fahre eigentlich mit dem Standard-EPG sehr gut. Für manche Sender habe ich epgfixer-Regeln erstellt, damit Serienaufnahmen dort besser möglich sind.

Wenn ich das richtig verstehe ist es ja nur ein kleiner Bug und eine mögliche Lösung hat M-Reimer auch schon aufgezeigt. louis hat das Plugin geschrieben, es sollte für ihn ein Leichtes sein, diese Mini-Änderung zu machen. (Wenn es denn so einfach ist, wie es bei M-Reimer klingt)

gerade im scraper ist es eben keine kleine Änderung, und es zieht auch Änderungen in nOpacity/tvguide nach sich

Es ist in der Tat nicht für stand alone vdr entwickelt, kann aber bei Vorhandensein eines 24/7 Rechners für die DB (zB ein reines NAS) auch standalone vdrs sinnvoll bedienen.

Christian

Ich will aber kein 24/7-System!

Man müsste sich das im Detail anschauen, aber eine Channel-ID vor die Event-ID zu stellen scheint mir jetzt zumindest von der Idee her nicht allzu kompliziert zu sein.

Moin,

ich kenne den Herrn "man" und die Frau "jemand"...und die sind stinkfaul

Ciao Louis

Muss denn im tvguide, bzw. nopacity überhaupt etwas angepasst werden? Liefert die neue API, die mit scraper2vdr gekommen ist, nicht bereits die nötigen Infos? Muss ja eigentlich so sein, denn sonst gäbe es das Problem beim scraper2vdr ja auch. Anpassaufwand also nur im tvscraper?

Moin,

Zitat von M-Reimer

Muss denn im tvguide, bzw. nopacity überhaupt etwas angepasst werden? Liefert die neue API, die mit scraper2vdr gekommen ist, nicht bereits die nötigen Infos? Muss ja eigentlich so sein, denn sonst gäbe es das Problem beim scraper2vdr ja auch. Anpassaufwand also nur im tvscraper?

Jo so wäre das...den Servicecalls wird ja immer ein cEvent oder ein cRecording Objekt übergeben, anhand dessen dann tvscraper intern den passenden gescrapten Content sucht. Ob der tvscraper nun intern mit einer Kombination aus eventID und channelID (die aus dem cEvent Objekt ableitbar ist) oder nur mit der eventID als "primary key" sucht, ist nach außen hin transparent.

Also nochmal kurz: aus meiner Sicht sollten auch nur Änderungen im tvscraper notwendig sein, die anzeigenden Plugins sind nicht betroffen.

Ciao Louis