ARD: vier Wochen EPG!

halbfertiger: Ja ich weiss, ich habe auch kaum etwas dazu gesagt ... Weiterhin muss ich kls Meinung nicht unbedingt teilen - externes EPG kommt halt in seinem Use-Case nicht vor. Auch wenn ich meinen Willen nicht bekomme, muss ich davon nicht sterben.

Urig: Wir hatten die Diskussion ja schon - und die von dir gemachte Aussage kann man SO nicht so einfach treffen (Für mich klingt das nach "Nachts ists kälter als draussen"). Ansonsten gebe ich dir recht es gibt auch weitere Ecken die verbessert werden könnten. Es freut mich wenn Probleme die ich hab so eine breitere Sichtbarkeit bekommen. Umschalten und Geräteverfügbarkeit war damals die andere Ecke die diskutiert wurde was Performanceprobleme angeht (braucht manchmal mehrere Sekunden bis er umgeschaltet hat).

Letztenendes ist jede Verbesserung am VDR gut

Zitat von gda

Realistischer ist sowas:

Code

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.

Au ja, lass uns ein wenig kindisch sein und uns mit Benchmarks kloppen!

Als kleiner quick hack, ein Benchmark auf svdrp-Basis. Der fairness halber lenke ich die komplette EPG-Ausgabe auch nach /dev/null, statt über svdrp.

--- svdrp.c.bak	2011-09-03 13:35:58.000000000 +0200
+++ svdrp.c	2011-09-03 14:19:01.000000000 +0200
@@ -1020,13 +1020,19 @@
         }
      int fd = dup(file);
      if (fd) {
-        FILE *f = fdopen(fd, "w");
+        FILE *f = fopen("/dev/null", "w");
         if (f) {
+           timeval t0;
+           gettimeofday(&t0, NULL);
            if (Schedule)
               Schedule->Dump(f, "215-", DumpMode, AtTime);
            else
               Schedules->Dump(f, "215-", DumpMode, AtTime);
            fflush(f);
+           timeval t1;
+           gettimeofday(&t1, NULL);
+           int t = (t1.tv_sec - t0.tv_sec)*1000000+t1.tv_usec-t0.tv_usec;
+           Reply(-215, "time: %i us", t);
            Reply(215, "End of EPG data");
            fclose(f);
            }

Ergibt bei mir - natürlich mit dem langen ARD-EPG - folgendes:

#>svdrpsend.pl lste 1
220 hdreceiver SVDRP VideoDiskRecorder 1.7.20; Sat Sep 3 14:11:31 2011; UTF-8
215-time: 7141 us
215 End of EPG data

D.h. 0.007 Sekunden, auf einem Celeron E3400. Zur Sicherheit habe ich das ganze auch mit einer 1000-Durchläufe Schleife getestet, und kam auf die zu erwartenden 7.15 Sekunden. Von den 7ms entfallen übrigens 6.7ms auf die Ausgabe mittels fprintf nach /dev/null, und 0.3ms auf den Zugriff auf die Datenstruktur.

Nichts gegen sqlite, die sind schon beeindruckend schnell. Aber da sqlite auch nur in C/C++ geschrieben ist, können sie auch nicht schneller als ein gut geschriebenes C++-Programm sein. Davon abgesehen, spart man sich bei einer nativen C++-Datenstruktur die hin- und herkonvertierung zwischen SQL-Tabelle und C++-Struktur. Das KISS-Prinzip spricht hier klar gegen SQL.

In jedem Fall sollte jetzt klar sein, dass das EPG-Menü nicht schneller wird, wenn wir eine sqlite-Anbindung in VDR einbauen. Und ich kann ruhig schlafen, falls mal ein Sender einen Film "); drop table recordings; -- nennt.

Gruß,

Udo

Zitat von Urig

Und ich kann ruhig schlafen, falls mal ein Sender einen Film "); drop table recordings; -- nennt.

Wobei bei der sqlite-Lösung die Sender ihre Episoden dann mal wieder mit "|" trennen dürften

Der Vorteil der Datenbanklösung wäre eine flexiblere Feldstruktur (nicht mehr Regie, Schauspieler usw. aus dem Text rausparsen) und die Möglichkeit mehere EPG Quellen zu importieren und dann bei der Abfrage (nach Priorität) das best passende rauszugeben (wenn für Sender/Zeitpunkt kein Eintrag von epgdata.com dann den vom Sender EPG liefern).
Ferner könnten dann mehere VDRs im LAN eine gemeinsame EPG Datenbank nutzen (wenn man die Datenbankanbindug flexibel übern Wrapper gestaltet auch gerne mit mySQL).

Aber die Aussichten das so was in den vanilla VDR kommt... Aber schön wäre sowas schon.

Ansonsten fehlt in der VDR OSD API wohl noch einiges, z.B. den Plugins die Möglichkeit zu bieten übern Callback nur die aktuell benötigten Menüzeilen mit Inhalt zu füllen. Ist ja schon nen Unterschied ob man 1000 Zeilen Menü aufbaut oder 18

cu

Zitat von Urig

Au ja, lass uns ein wenig kindisch sein und uns mit Benchmarks kloppen!

Amen...
(Vielleicht hilft es ja)

Das war nie die Aussage, dass SQLite alles schneller machen soll (von meiner Seite aus gesehen, und auch bei den anderen Kommentaren war das keine Aussage). Aber SQlite macht es AUCH nicht wesentlich langsamer. Sinn des ganzen ist einfach nur, dass man Daten aggregieren kann, die man sich sonst mit komplizierten Regelwerken über alle Strukturen zusammensuchen muss.

Die VDR-Daten sind und bleiben die Datenbasis und daran möchte ich auch nicht rütteln. Alle Daten, die über den hier besprochenen SQLite-Ansatz verarbeitet werden sollen, sind virtuelle in-memory-Tabellen.

Das KISS-Prinzip sehe ich nicht verletzt. Im Gegenteil. Wenn ich mir erst über alle Elemente eines Containers iterieren muss, um einzelne Attribute zu erfragen, wovon mich dann unter Umständen nicht mal ein bestimmtes Detail interessiert, sondern nur die Anzahl der Erscheinungen á la SELECT count(genre) FROM xxx, dann bin ich mit den meisten einfachen C++-Mitteln am Ende. Dafür wurden Metasprachen entwickelt, weil eben C++ dafür eben nicht gedacht ist.

Wobei IMHO ein Lesen des EPG aus dem Arbeitsspeicher (wenn ich das richtig verstehe geschieht das beim Benchmark von Urig, da die epg.data schon beim Start des VDR eingelesen wird) gegenüber einer (gecachten?) Datenbankabfrage von der Platte (bei gda) nur eine bedingte Aussagekraft hat - interessanter wäre ein Anwendungsfall wie beim epgsync-Plugin, wo es ja zu recht deutlichen Wartezeiten kommt, wenn das gesamte EPG per SVDRP durch die Gegend geschoben wird - da wäre eine unabhängige Datenbankquelle schon praktischer, weil es den VDR nicht zwingend interessieren muss, wenn ein anderer Client an die EPG-Daten will.

Urig: Zuerst hatte ich mich gefreut, weil es so aussah als würdest du eine ernsthafte Diskussion anfangen wollen, aber die Enttäuschung kam schnell. Eine völlig überflüssige Antwort auf meinen Post.
Einem aufmerksamen Leser meines Beitrags wäre schnell aufgefallen, dass ich die Antwort auf Posts wie deinen schon vorweg genommen hatte. Ich habe von vornherein gesagt, dass es schnellere Lösungen gibt.
In meinem Beitrag geht es um die Aussage sqlite ist schnell genug, dein Beitrag als Antwort schießt leider völlig ins Leere. Schade um die vergeudete Zeit.

Gerald

Zitat von gda

Urig: Zuerst hatte ich mich gefreut, weil es so aussah als würdest du eine ernsthafte Diskussion anfangen wollen, aber die Enttäuschung kam schnell. Eine völlig überflüssige Antwort auf meinen Post.

Völlig überflüssig ist diese Diskussion schon seit langem, denn - ich zitier mich mal einfach selbst:

Zitat von Urig

Und EPG-Menü und Live-Plugin-EPG ächtzt mit über 1000 Programmeinträgen!

Zitat von Urig

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

Ich hab hier noch keinen Beitrag gesehen, der sich mit der Frage beschäftigt, WARUM das EPG-Menü langsam ist, oder Live so lange für den Seitenaufbau braucht. Statt dessen wird nur wieder die Datenbank als Allheilmittel angepriesen.
Sqlite ist nicht die Antwort auf das ursprüngliche Problem, und keine Zeitmessung ändert das.

Gruß,

Udo

Zitat von Urig

Sqlite ist nicht die Antwort auf das ursprüngliche Problem, und keine Zeitmessung ändert das.

Das ist absolut richtig. Ich habe nur die Schnauze voll von dem grundlosen Sqlite gebashe, deshalb mein Beitrag. In sofern also OT, sorry dafür.

Gerald

Zitat von Urig

Ich hab hier noch keinen Beitrag gesehen, der sich mit der Frage beschäftigt, WARUM das EPG-Menü langsam ist,

EPG locken, Eintrag holen, Prüfen ob der gerade aufzeichnet, prüfen ob der davor nen Timer hat, prüfen ob der danach nen Timer hat, prüfen ob er VPS hat, runnig Flag Prüfen, Zeile anhand des Templates formatieren. -> nächster Eintrag x 1000. Müsste man in epgsearch einfach mal Debugausgaben mit Timestamps einbauen.

Ist aber alles schon nen alter Hut, epgsearch hat nicht umsonst die Option die Kanalliste auf die ersten X Sender zu beschränken.

Edit: Gerade mal probiert, epg geht auf ARD verzögerungsfrei auf (skinenigma), also doch der Skin!?

Bei Live wirds das Rendering der Seite im Browser sein. Wobei die Seite bei mir Ruck Zuck da ist (normale Surfgeschwindigkeit). (Pentium M 1,6GHz, WinXP, aktueller Opera)

Wenn wir hier shcon beim benchmarken sind

root@dirk-vdr:~# time wget http://dirk-vdr:6001/schedule.html?channel=1
--2011-09-03 18:07:34--  http://dirk-vdr:6001/schedule.html?channel=1
Auflösen des Hostnamen dirk-vdr... 127.0.0.1
Verbindungsaufbau zu dirk-vdr|127.0.0.1|:6001... verbunden.
HTTP-Anforderung gesendet, warte auf Antwort... 200 OK
Länge: 1204789 (1,1M) [text/html]
In »schedule.html?channel=1« speichern.


100%[==============================================================================>] 1.204.789   --.-K/s   in 0,02s


2011-09-03 18:07:34 (70,8 MB/s) - »schedule.html?channel=1« gespeichert [1204789/1204789]




real    0m0.510s
user    0m0.004s
sys     0m0.011s

Der Browser muss dann 1,14 MB an HTML parsen und rendern.

Zum Vergleich, Apache mit meiner Portalseite (nur 2 Links ohne alles)

root@dirk-vdr:~# time wget http://dirk-vdr
--2011-09-03 18:10:18--  http://dirk-vdr/
Auflösen des Hostnamen dirk-vdr... 127.0.0.1
Verbindungsaufbau zu dirk-vdr|127.0.0.1|:80... verbunden.
HTTP-Anforderung gesendet, warte auf Antwort... 200 OK
Länge: 122 [text/html]
In »index.html« speichern.


100%[==============================================================================>] 122         --.-K/s   in 0s


2011-09-03 18:10:18 (11,6 MB/s) - »index.html« gespeichert [122/122]




real    0m0.011s
user    0m0.001s
sys     0m0.006s

Also live ist mit dem tnt Templatesystem echt flott. Die Webinterfacelösungen in Peal (die das dann noch schlimmstenfalls über svdrp holen (und das ascii dann nochmal extra parsen)) kämpfen da wohl schon eher mit

cu

Live dürfte Javascript performance sein, da sämtliche events als Mouse-Over schon in der Seite sind aber nicht sichtbar - einzelne Events auf Mouse-Over oder Klick erst zu holen dürfte hier Schwung in die Sache bringen. Zur EPG-Ansicht im OSD müsste man wie es Keine_Ahnung gemacht hat verschiedene Skins ersteinmal probieren um auszuschliessen das es das Skin ist - Ausserdem ist hier die Gefahr gross das man garnicht die normale Programmvorschau benutzt, sondern zB epgsearch, nordlicht-epg etc pp. Auch hier dürfte optimale Performance bringen nur die sichtbaren Bereiche zu holen und zu rendern. Wie man das macht, keine Ahnung.

Man könnte in der Tat die ganzen Plugins performanter machen. Es ist schade, dass es so viele geniale Plugins gibt, die jeweils für sich arbeiten.

Es gibt das RESTful-Plugin, das Streamdev-Plugin, das DLNA-Plugin, das Live-Plugin usw. und was bieten alle an? eine Webschnittstelle, die alle mehr oder weniger das gleiche bieten.

Ich werde im Remake des DLNA-Plugins für die verpflichtende (laut Standard) Webschnittstelle auf Restful setzen. Aber da Streamdev keine Aufnahmen unterstützt, muss ich doch wieder selber Aufnahmen streamen.

Was hat das hiermit zu tun?

Ganz einfach: wenn man die Seitengröße von 6MB je Seite auf vielleicht 1MB reduzieren könnte und dann nur doch per Ajax oder JSON notwendige Daten lädt, dann kann man die Ladezeiten deutlich reduzieren. Die RESTful-API des Plugins ist dafür sehr gut geeignet.