[ANNOUNCE] VDR developer version 1.7.25

Moin!

Zitat von CafeDelMar

Wenn ich Klaus richtig verstanden habe, dann wird leider immer nach der Startzeit gesucht und nicht nach der Event-ID. Genau das Problem wollte ich in diesem Zusammenhang ja aufzeigen.

Ein schneller Blick in eit.c und epg.c scheint es zu bestätigen, dass immer nach Startzeit gematcht wird. Das wusste ich nicht.
Hm... Was hat das wohl für einen Grund?

Das Einlesen per PUTE übergibt aber Startzeit und EventID an GetEvent, wenn also da die Startzeit "0" benutzt wird, wird anhand der EventID herausgesucht.
Allerdings würde dann cEvent::SetStartTime auch die Null in das Event setzen, was nicht schön wäre. Da müsste also noch eine Abbruchbedingung rein:

void cEvent::SetStartTime(time_t StartTime)
 {
+  if (StartTime == 0)
+     return;
   if (startTime != StartTime) {
      if (schedule)
         schedule->UnhashEvent(this);
      startTime = StartTime;
      if (schedule)
         schedule->HashEvent(this);
      }
 }

Aber ich hab noch nicht viel Überblick über das EPG-Handling, bin noch am Lesen und Lernen...

Lars.

Moin!

Zu den "linked channels" weiß ich noch gar nichts, deshalb schreibe ich mal nichts dazu, aber gut, dass du es erwähnst.

Zitat von Maniac

Dazu fällt mir noch etwas weiteres auf. Derzeit nutze ich den noEPG-Patch im Whitelist-Modus, da ich mehrere Sateliten ansteuere, wo aber auch viele unnütze Kanäle bei sind die kein EPG zeigen sollen. Das EPG gebe ich derzeit nur manuell über die Whitelist für die Kanäle frei, die ich nicht extern befülle und die mich trotzdem Interessieren.
Dadurch verhindere ich ein unnötiges Aufblähen der epg.data
Gibt es mit der neuen Version eine Möglichkeit auch sowetwas zu realisieren?

Du kannst natürlich Events für solche Kanäle mit einer Table-ID 1 regelmäßig anlegen, die "sehr lange" dauern (damit es nicht zu viele sind).

Was mir aber in diesem Fall "in den Kopf springt" wäre, die DeviceHooks aufzubohren um eine weitere Methode. Denn vor ein paar Versionen wurde cDevice um ProvidesEIT erweitert, so dass Geräte dem vdr melden können, dass er mit diesen gar nicht erst versuchen muss, einen EPG-Scan zu starten. Das müsste man "nur" um den aktuell zu scannenden Kanal erweitern und dann könnte sich ein Plugin darum kümmern, welche Kanäle gescannt werden und welche nicht. Ist jetzt aber nur ganz schnell hingeschrieben und nicht weiter überprüft...

Lars.

Zitat von mini73

Ein schneller Blick in eit.c und epg.c scheint es zu bestätigen, dass immer nach Startzeit gematcht wird. Das wusste ich nicht.
Hm... Was hat das wohl für einen Grund?

Evtl. irgendein Workaround für einige Sender? Ich meine mich dunkel zu erinnern (Doppeltes EPG Problem bei den Pro7Sat.1 Sendern) das es da auch Sender gab die die EventID bei EPG Updates gerne mal lustig geändert haben.

cu

Moin!

Zitat von Keine_Ahnung

Evtl. irgendein Workaround für einige Sender? Ich meine mich dunkel zu erinnern das es da auch Sender gab die die EventID bei EPG Updates gerne mal lustig geändert haben.

Sowas schreibt Klaus dann meistens als Kommentar in den Code.
Aber den Sendern traue ich sowas durchaus zu...

Lars.

Zitat von mini73

Du kannst natürlich Events für solche Kanäle mit einer Table-ID 1 regelmäßig anlegen, die "sehr lange" dauern (damit es nicht zu viele sind).

Als vorläufiger Workaround finde ich die Idee nicht schlecht, allerdings schafft das u.U. Probleme mit anderen Plugins die in EPG-Übersichten nur die Sender anzeigen zu denen auch EPG vorhanden ist.

Zitat von mini73

Was mir aber in diesem Fall "in den Kopf springt" wäre, die DeviceHooks aufzubohren um eine weitere Methode. Denn vor ein paar Versionen wurde cDevice um ProvidesEIT erweitert, so dass Geräte dem vdr melden können, dass er mit diesen gar nicht erst versuchen muss, einen EPG-Scan zu starten. Das müsste man "nur" um den aktuell zu scannenden Kanal erweitern und dann könnte sich ein Plugin darum kümmern, welche Kanäle gescannt werden und welche nicht. Ist jetzt aber nur ganz schnell hingeschrieben und nicht weiter überprüft...

Ohne da jetzt schon tiefergehend geforscht zu haben hört sich das sehr gut an. Damit müsste sich dann ja eine Art noEPG-Plugin realisieren lassen.

Zitat von Copperhead

"channel 3" steht in diesem Fall für RTL HD

Es gibt noch eine andere Änderung, die Klaus ohne Probleme übernehmen kann. Programme, die nur Digitalton aussenden, führen zu einer falschen ChangedPids-Meldung. Die Änderung wäre:

--- a/channels.c
+++ b/channels.c
@@ -628,6 +628,8 @@ bool cChannel::Parse(const char *s)
                  }
            apids[NumApids] = 0;
            atypes[NumApids] = 0;
+           if (!apids[0])  // channels with only digital sound
+              atypes[0] = 0;
            if (dpidbuf) {
               char *p = dpidbuf;
               char *q;

kls

Die Version läuft soweit gut, danke!

@all

Mit welchem EPG Import-Modul kann man denn Bilder in den EPG einbinden?

cu gromit

Zitat von gromit

Mit welchem EPG Import-Modul kann man denn Bilder in den EPG einbinden?

EPG Bilder werden (von dem Programm was sie aus dem Internet läd) nach einem Namensschema (wurde weiter vorne gepostet) in irgendein Verzeichnis kopiert. Den Programmen die sie nutzen sollen sagst du dann einfach in welchen Verzeichnis sie zu finden sind. Der VDR hat damit nix zu tun. Und es gibt auch keine Importmodule oder irgendwas spezielles.

cu

Zitat

EPG Bilder werden (von dem Programm was sie aus dem Internet läd)

Ich wollte den Namen des Programms wissen was Bilder importieren kann. Das es verschiedene Skripte und Plugins gibt ist mir bekannt, nur kenne ich die im Detail nicht.

cu gromit

Zitat von gromit

Ich wollte den Namen des Programms wissen was Bilder importieren kann. Das es verschiedene Skripte und Plugins gibt ist mir bekannt, nur kenne ich die im Detail nicht.

[ Rein technisch gibt es kein Importieren von EPG Bildern. ]

Z.B. das tvm2vdr Plugin kann beim EPG dowanload auch gleich die Bilder runterladen und ins gewünschte Verzeichnis kopieren.

cu

Oder noch deutlicher ausgedrückt: Es gibt Skin-Plugins, die anhand der EPG-ID des VDR in einem Verzeichnis nach Bildern suchen und sie darstellen - mehr nicht. Die Kunst ist es dann für eine Erweiterung, die zur jeweiligen EPG-ID gehörenden Bilder bereitzustellen.

Oh man, es muss einem ja nicht gefallen - dann antwortet man nicht ...

gromit: tvm2vdr , epgdata2vdr (kostenpflichtiges Abo) , tvmovie2vdr konnte es wohl auch ist aber wohl des längeren obsolet. Alles andere sind wohl eher handgestrickte Lösungen.

Anzeigen lassen kann man das in vdr-plugin-live, in text2skin Skins (zB anthra, NarrowHD, aber auch skinenigma plugin und pearlHD plugin)

Zitat von steffen_b

Oh man, es muss einem ja nicht gefallen - dann antwortet man nicht ...

Hier hat doch niemand was degegen. Ist IMHO nur wichtig das man klarstellt wie es funktioniert (Es gibt halt kein "EPG Import Modul"). Sonst hat der Fragensteller nix davon.

cu

Das hier finde ich auch schön:

Zitat von steffen_b

Meine Traumvorstellung wäre das man das EPG in einer externen Instanz (wie auch immer die aussieht) liegen hat und der VDR das sowohl abfragen als auch füttern kann. In einem für mich normalen Setup gibt es immer 2-3 Programme die das EPG des VDR synchronisieren (z.B. xbmc) , ausserdem gefiele mir daran, das man extern zum VDR die Einträge konkret ändern könnte. (Also z.B. ein update auf bestimmte Einträge machen könnte) Wenn man mehrere VDRs hätte könnte man 1 EPG pflegen und es wäre in allen Instanzen im Haushalt sauber. XBMC könnte sofort die Informationen abfragen. Für den Otto-Normal-VDR-User kann ja gerne die jetzige Funktionsweise erhalten bleiben, aber wenn man das über ein Plugin ersetzen könnte wäre es Klasse.

hat das nach so vielen Posts noch eine Relevanz?
Ich formulier hier mal weiter "in die Tüte":
Die EPG-EInträge in dieser externen Instanz erhalten zum einen u.U zusätzliche Felder wie z.B Bildnamen/Bilderchen
Die VDR's bekommen ein Plugin "ExtEPG" welches diese externe Instanz nach konfigurierbaren Regeln füttern/updaten kann.
Ebenso müsste es ein externes Progrämmelchen geben, welches DIE zentrale Schnittstelle zu dieser Instanz für a
Das Plugin "ExtEPG" würde per Trigger (SVDRP?) auch den/die internen im VDR abgelegten EPG updaten können, bzw mittels des Plugins könnte der VDR erkennen, dass er "alte Daten" hat wenn in der externen Instanz entsprechend ein Change-Date geführt würde.
Es müsste dann konfigurierbare Regeln geben, welche Datenfelder durch welche Priorität geändert werden dürften

Als externe Instanz kann ich mir ein xml oder aber mysql vorstellen - bei ersterem müsste man sich mehr Gedanken um das Locking machen

Zitat von magicamun

Als externe Instanz kann ich mir ein xml oder aber mysql vorstellen - bei ersterem müsste man sich mehr Gedanken um das Locking machen

Wäre das nicht eher was für CouchDB? XML ist keine Datenbank und gegen MySQL habe Vorurteile. Im Zweifelsfall würde ich PostgreSQL vorziehen.

Gerald

Zitat von gda

Wäre das nicht eher was für CouchDB? XML ist keine Datenbank und gegen MySQL habe Vorurteile. Im Zweifelsfall würde ich PostgreSQL vorziehen.

DAS ist eine Geschmacksfrage oder - schlimmer - könnte zu einer Glaubensfrage werden...

Zitat von kls

Ich vermute, daß da noch ein Problem ist, wenn es nur gebondete Devices gibt und ein EPG-Scan einsetzt oder auf Timer-Transponder geschaltet werden soll.
Werd's mir anschauen.

Zur Info: Das gleiche Problem in ähnlicher Form hatte ich hier gestern auch! Wenn ich den EPG-Scan deaktiviere, habe ich diese Probleme nicht mehr.
Ich nutze eine FF HD 6400 gebondet über 1 SAT Kabel (LNB-Sharing), sowie eine Twin S2 DVB Karte, wo jeder Tuner ein eigenes SAT Kabel hat.

Viele Grüße, Uwe

Zitat von magicamun

Das Plugin "ExtEPG" würde per Trigger (SVDRP?) auch den/die internen im VDR abgelegten EPG updaten können, bzw mittels des Plugins könnte der VDR erkennen, dass er "alte Daten" hat wenn in der externen Instanz entsprechend ein Change-Date geführt würde.
Es müsste dann konfigurierbare Regeln geben, welche Datenfelder durch welche Priorität geändert werden dürften

Warum so umständlich? Der VDR hätte in meiner Traumvorstellung gar keine internen EPG Daten mehr sondern würde bei Bedarf direckt den EPG Daemon über UDP Abfragen. Ferner schiebt er einfach das DVB EPG was er empfängt per UDP zum EPG Daemon.

Und der EPG Daemon liefert DAS fertige EPG. Wie das EPG zustandekommt (Mischung aus verschiedenen Quellen oder das mit der höchsten Priorität) hat den VDR nicht zu interesseieren.

Das wäre meine Wunschvorstellung.

Zitat von magicamun

Als externe Instanz kann ich mir ein xml oder aber mysql vorstellen - bei ersterem müsste man sich mehr Gedanken um das Locking machen

XML als Datenbank ist Wahnsinn, sowas macht man nicht.

cu

Zitat von Keine_Ahnung

Warum so umständlich? Der VDR hätte in meiner Traumvorstellung gar keine internen EPG Daten mehr sondern würde bei Bedarf direckt den EPG Daemon über UDP Abfragen. Ferner schiebt er einfach das DVB EPG was er empfängt per UDP zum EPG Daemon.

Hmm, das fände ich aber nun kompliziert. Wäre es nicht einfacher, wenn der DVB EPG in einer passenden Form gespeichert würde, sagen wir z.B. per embedded sqlite und man dort die Einträge direkt mit SQL Befehlen aufhübschen könnte? Und nicht noch ein Daemon, noch ein Daemon, noch ein Daemon ...

Regards
fnu

Zitat von fnu

Hmm, das fände ich aber nun kompliziert. Wäre es nicht einfacher, wenn der DVB EPG in einer passenden Form gespeichert würde, sagen wir z.B. per embedded sqlite und man dort die Einträge direkt mit SQL Befehlen aufhübschen könnte?

Und dann? Kommt das externe TV Movie EPG in ner zweiten Tabelle dazu und schon braucht der VDR wieder Programmcode um seine Tabelle und die TV Movie Tabelle bei der Abfrage sinnvoll zu verknüpfen. Dann kommt epgdata.con dazu und der VDR braucht wieder nen Patch... Ich dachte davon wollen wir alle weg?

Zitat von fnu

man dort die Einträge direkt mit SQL Befehlen aufhübschen könnte?

An Einträgen rummurksen hat deutliche Schwächen. Die verschiedenen EPG Datenquellen müssen RAW gespeichert werden und erst bei der Abfrage aufgehübscht werden. Sonst verliert man ja wieder die Historie. Oder wie merkst du ob sich das DVB EPG eines Senders geändert hast wenn du dram rumgemacht hast?

Bei der Daemon Lösung könnte der Daemon z.B. recht einfach Programmänderungen des DVB EPG Erkennen *) und für diesen Fall dem Sender EPG (für diesen Sender und diesen Zeitbereich) Priorität über alle externen geben.

Mit ner richtigen Datenbank (egal welche) und nem Daemon wären auf einmal viele Sachen ganz einfach die jetzt unmöglich sind.
Und der Daemon könnte auch auf nem NAS laufen und alle VDRs im Haus bedienen. Und externes EPG könnte einfach per Cron Daily in den Daemon gepumpt werden ohne das überhaupt irgendein VDR laufen muss.
Postprocessing könnte unabhängig davon per Daemon eigenen EPG-Mod-Plugins geschehen. Z.B. wenn EPGsearch einen Serientreffer hat wird er als "Serientreffer für VDR Nr.1 geflaggt" und das postprocessing Plugin könnte das EPG (welches dieser VDR bekommt) modifizieren (Staffel-Episode ins EPG eintragen). Die anderen VDRs bekommen weiterhin ihr unmodifiziertes EPG.

Im Grundsetup können EPG Daemon und VDR auf dem selben Rechner laufen um im langweiligen "alles funktioniert wie bissher auch" Modus laufen. D.h. wer kein Interesse daran hat merkt den Unterschied zum Jetzt nicht (ob da ein Daemon mehr oder weniger läuft ist doch egal).

cu

*) Wenn über den VDR reinkommendes DVB EPG plötzlich nicht mehr mit dem bereits gespeicherten Übereinstimmt gabs ne Programmänderung und der Daemon weiss für das mischen mit dem externen (on the Fly bei der Abfrage) das externe bei Unterschieden zu verwerfen ist.