ARD: vier Wochen EPG!

Tatsache und die Sat1-Pro7-Gruppe schafft es nicht mal bis Sonntag!

Naja die Privaten werden uns insofern helfen, das sie irgendwann die ÖR verklagen weil sie es "zu gut machen" - soll heissen sich angeblich aus irgendeinem Grund nicht an den Rundfunk/Medien Staatsvertrag halten

Na, das ist mal ein Unterschied. Suchtimer bis Mitte September! Und EPG-Menü und Live-Plugin-EPG ächtzt mit über 1000 Programmeinträgen! Da müssen wir doch wohl mal ein wenig optimieren müssen!

Gruß,

Udo

Ich wäre mal froh, wenn sich Sat1/Pro7 mal an RTL angleichen würde, aber so ist das echt nervig, zumal ich die "Alternative" auch nicht zum Laufen bekomme.

Hallo, ich will ja nicht unken, aber: vllt. isses ja nur ein Testballon wegen der IFA ?

Grüße,
lolldroll

Also von mir gibts dafür einen

Werte mitlesende ARD-Chefs,

feine Sache, die ihr da angeleiert habt.
Bitte aufs ZDF ausdehnen und den Privaten als Superfeature präsentieren, damit die das nachmachen können.
Fragen können gerne hier im Forum gestellt werden.

Vielen Dank,
Faudeer

Zitat von Urig

Na, das ist mal ein Unterschied. Suchtimer bis Mitte September! Und EPG-Menü und Live-Plugin-EPG ächtzt mit über 1000 Programmeinträgen! Da müssen wir doch wohl mal ein wenig optimieren!

ACK

Zitat

Na, das ist mal ein Unterschied. Suchtimer bis Mitte September! Und EPG-Menü und Live-Plugin-EPG ächtzt mit über 1000 Programmeinträgen! Da müssen wir doch wohl mal ein wenig optimieren!

sqlite ?

Zitat von hotzenplotz5

sqlite ?

Ich finde auch, dass man vielleicht an SQLite denken sollte. Insbesondere komplexe Suchanfragen lassen sich damit gut bewerkstelligen.

Fürs EPG auf jeden Fall ...

Könnte man die Daten nicht auch online zwischen den Usern sharen? Z.B. über Google Fusion Tables?

Meines Wissens sind EPG-Daten urheberrechtlich geschtützt. Also einfach sharen ist sicherlich nicht so einfach. Es sei denn man verfässt eine eigene EPG-Bibliothek, was vermutlich nicht weiter problematisch sein sollte bei den vielen Wiederholungen auf den einzelnen Sendern.

Gibt es so etwas schon? Also ein EPG nach dem Wiki-Prinzip?

Da die EPG-Daten nur selten mal auf Disk geschrieben werden, wäre ein permanentes Schreiben in eine sqlite-Datenbank wohl eher ein Performance-Rückschritt. Die Struktur scheint auch angemessen schnell zu sein, sonst würde der permanente EPG-Scan mehr CPU-Last erzeugen.

Ich denke eher, das Erzeugen und Verwalten von Menüs mit über 1000 Zeilen bremst hier deutlich.

Gruß,

Udo

Zitat von steffen_b

Fürs EPG auf jeden Fall ...

Klaus hat sich klar dagegen ausgesprochen, da für ihn EPG eine Kernfunktin von DVB ist und deshalb von VDR selbst erledigt werden soll.

Mich würde es nicht stören, aber dann bitte auch gleich die Aufnahmen in eine Datenbank um sie nach mehreren Kriterien durchsuchen zu können. So wie es jetzt ist, erinert mich das immer an die User, die ihre MP3 Sammlung unbedingt selbst in Ordnern einsortieren und von Hand auf ihren Player kopieren wollen, anstatt das intelligent von Programmen erledigen zu lassen.

Zitat von Urig

Da die EPG-Daten nur selten mal auf Disk geschrieben werden, wäre ein permanentes Schreiben in eine sqlite-Datenbank wohl eher ein Performance-Rückschritt. Die Struktur scheint auch angemessen schnell zu sein, sonst würde der permanente EPG-Scan mehr CPU-Last erzeugen.

Ich denke eher, das Erzeugen und Verwalten von Menüs mit über 1000 Zeilen bremst hier deutlich.

Hallo,

Würde man trotzdem etwas gewinnen können, wenn man den In-Memory Ansatz von sqlite benutzen würde?
http://www.sqlite.org/inmemorydb.html

Gruß
hepi

Zitat von hepi

Würde man trotzdem etwas gewinnen können, wenn man den In-Memory Ansatz von sqlite benutzen würde?
http://www.sqlite.org/inmemorydb.html

Nicht wirklich, weil dann nur wieder ein Programm drauf zugreifen könnte. Was mir bei der Sqlite-Lösung am Besten gefällt ist ja die Möglichkeit von mehreren Programmen aus zuzugreifen.

Gerald

Zitat von gda

Nicht wirklich, weil dann nur wieder ein Programm drauf zugreifen könnte. Was mir bei der Sqlite-Lösung am Besten gefällt ist ja die Möglichkeit von mehreren Programmen aus zuzugreifen.

Gerald

Vielleicht ist eine Mischlösung möglich:
http://old.nabble.com/Saving-a…e-to-disk-td20401712.html
http://www.sqlite.org/lang_attach.html
http://sqlite.org/pragma.html

Gruß
hepi

Irgendwie ist mein Kommentar verloren gegangen, dann eben nochmal: SQLite bietet eine sehr umfangreiche API, die auch in-memory-Tabellen auf Basis eigener Datenquellen erzeugen kann und dann exakt wie SQLite-Tabellen agieren. Diese sind natürlich flüchtig und müssen beim Starten des VDRs neu angelegt werden, aber der Overhead ist gering, da lediglich die Struktur neu aufgebaut wird und lesen bzw. schreiben (falls nötig) direkt auf die Datenbasis erfolgt. Der VDR wäre weiterhin Master aber es gäbe eine flüchtige Abstraktionsschicht für andere Programme, die mit SQL arbeiten wollen. Daten die permanent verfügbar sein müssen, können dann in eine persitierende Tabelle geschrieben werden.

Weil es mir auf den Senkel geht, dass die Bremser hier immer das Totschläger-Argument Geschwindigkeit gegen Sqlite zum Einsatz bringen, habe ich mal auf die Schnelle ein paar Zahlen besorgt. Ich habe dazu aus meinen aktuellen EPG-Daten von Wilhelm-Tel eine zugegeben nicht komplette Datenbank gebaut um mal ein Gefühl für die "Langsamkeit" zu bekommen. Bitte kein nitpicking, es geht um das Prinzip. Die Zeiten habe ich auf einer Zbox HD-ID 40 ermittelt mit einer eher langsamen Platte: WD5000BUDT.

Das Schema der Datenbank:

sqlite> .schema
CREATE TABLE epgdata (
  ChannelID, ChannelName, EventID, StartTime, Duration, TableID, Title);
CREATE UNIQUE INDEX epgdata_idx on epgdata (ChannelID,StartTime);

Anzahl der Sätze:

sqlite> select count(*) from epgdata;
49473

Sicher, andere werden viel mehr haben, aber das wird im Wesentlichen linear langsamer werden.

Alle Sätze holen, ich gebe nach /dev/null aus, weil wir sonst die Geschwindigkeit des Ausgabe-Devices messen:

time sqlite3 vdrdatabase <<EOF >/dev/null
select * from epgdata;
EOF


real    0m0.410s
user    0m0.370s
sys     0m0.030s

Darüber brauchen wir erst gar nicht diskutieren, das ist zu langsam, ABER das brauchen wir ja auch niemals.

Realistischer ist sowas:

time sqlite3 vdrdatabase <<EOF >/dev/null
select * from epgdata where ChannelID='C-1-1101-28106';
EOF


real    0m0.019s
user    0m0.010s
sys     0m0.010s

Das reicht ja wohl völlig.

Sicher wäre die endgültige Datenbank komplexer und es wird eventuell auch Zugriffe geben, die problematisch sind. Es ist richtig, dass eine Lösung im Speicher immer schneller sein wird.
Wer aber jetzt immer noch behauptet eine normale sqlite-Datenbank im Filesystem wäre generell zu langsam, ohne dafür einen Beweis zu liefern ist ein Märchenonkel.

Gerald