Ich habe "Urig"s Patch jetzt mal auf beiliegende Weise einfließen lassen, wobei ich nur das übernommen habe, was VDR auch wirklich braucht.
Ich hoffe, ich habe nichts übersehen.
Bitte probiert es mal aus, und testet insbesondere, ob damit das ursprüngliche EPG-Problem auch wirklich behoben ist.
Klaus
Ich würde gerne demnächst VDR Version 2.0.1 mit einigen Fixes freigeben. Falls der Patch aus dem vorigen Posting hier drin sein soll, dann bräuchte ich wenigstens ein paar Rückmeldungen, ob das denn nun das ursprüngliche Problem tatsächlich löst, und ob damit VDR mit allen DVB API Versionen seit 5.0 baut und läuft.
Sollte ich keine entsprechenden Rückmeldungen bekommen werde ich den Patch nicht aufnehmen.
Klaus
Bin am WE nicht dazu gekommen, sorry.
Ich denke ich komme im Laufe der Woche dazu, wenn Dir das reicht?
Regards
fnu
Ich denke ich komme im Laufe der Woche dazu, wenn Dir das reicht?
Das wäre nett.
@"Björn": Interessant wäre natürlich auch, ob es das Problem für dich löst.
@"Urig": Ist das auch aus deiner Sicht so OK?
Klaus
Da scheint noch was nicht ganz so gut zu passen gegen den 2.6.32er Stockkernel, DVBAPI 5.0:
g++ -g -O3 -Wall -Werror=overloaded-virtual -Wno-parentheses -fPIC -c -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -DREMOTE_KBD -DLIRC_DEVICE=\"/var/run/lirc/lircd\" -DVIDEODIR=\"/srv/vdr/video.00\" -DCONFDIR=\"/var/lib/vdr\" -DCACHEDIR=\"/var/cache/vdr\" -DRESDIR=\"/usr/share/vdr\" -DPLUGINDIR=\"/usr/lib/vdr/plugins\" -DLOCDIR=\"/usr/share/locale\" -I/usr/include/freetype2 -o nit.o nit.cnit.c: In member function ‘virtual void cNitFilter::Process(u_short, u_char, const u_char*, int)’:nit.c:339: error: ‘GUARD_INTERVAL_1_128’ was not declared in this scopenit.c:339: error: ‘GUARD_INTERVAL_19_128’ was not declared in this scopenit.c:339: error: ‘GUARD_INTERVAL_19_256’ was not declared in this scopenit.c:341: error: ‘TRANSMISSION_MODE_1K’ was not declared in this scopenit.c:341: error: ‘TRANSMISSION_MODE_16K’ was not declared in this scopenit.c:341: error: ‘TRANSMISSION_MODE_32K’ was not declared in this scopemake[2]: *** [nit.o] Fehler 1grep GUARD_INTERVAL_1_128 *dvbdevice.c: GUARD_INTERVAL_1_128 = GUARD_INTERVAL_AUTO + 1,dvbdevice.c: { 128, GUARD_INTERVAL_1_128, "1/128" },nit.c: static int T2GuardIntervals[] = { GUARD_INTERVAL_1_32, GUARD_INTERVAL_1_16, GUARD_INTERVAL_1_8, GUARD_INTERVAL_1_4, GUARD_INTERVAL_1_128, GUARD_INTERVAL_19_128, GUARD_INTERVAL_19_256, 0 };
Regards
fnu
Da scheint noch was nicht ganz so gut zu passen gegen den 2.6.32er Stockkernel, DVBAPI 5.0:
...
Hmm, ich hätte das zwar gerne auf dvbdevice.c beschränkt, aber was soll's.
Hier ein neuer Versuch.
Klaus
Hier ein neuer Versuch.
Sehr gut, vielen Dank, funktioniert*, gib mir 2 Tage um die Nummer zu beobachten.
Regards
fnu
*) soll heißen der VDR baute, wird sicher auch laufen, ob fehlerfrei, das muß eben erst testen und überwachen
Mir ist jetzt noch aufgefallen, daß in cDvbDevice::QueryDeliverySystems() die ersten beiden memset()-Aufrufe eigentlich in die 'if (!DvbApiVersion)'-Klammer hinein sollten, da das sonst im laufenden Betrieb unnötigerweise immer zweimal gemacht wird.
Leicht veränderter Patch anbei.
Klaus
Klaus, das ist aber nur ein "Schönheitsfehler" und kein eigentlich Funktionaler, oder?
Weil die ersten Eindrücke der Version "-2" sind sehr vielversprechend, keine Meldung im syslog, PIDs wurden recht schnell nach dem Start wieder aktualisiert, EPG gab's auch Updates. Letzteres wollte ich mir bis morgen anschauen, bis dahin schonmal: 
Gruß
Frank
Kernel 2.6.32? Wieso? Das Teil ist von 2009!
Diese uralte Kernelversion wird nicht mal mehr auf der kernel.org Startseite erwähnt.
Das hat doch sicher wieder was mit Debian zu tun 
Edit: Wow. Hab ichs mir doch gedacht. Das letzte Stable Release von Debian ist mehr als 2 Jahre alt und nimmt den damals schon über ein Jahr alten Kernel 2.6.32. 
Das hat doch sicher wieder was mit Debian zu tun
Es gibt auch Leute die lassen den VDR auf Hardware laufen, die von aktuellen Kerneln nicht mehr unterstützt wird. Und da der VDR auch auf dieser Hardware sauber läuft gibt es keinen Grund den Kram wegzuwerfen nur weils uncool ist alte Kernel zu nutzen 
cu
Klaus, das ist aber nur ein "Schönheitsfehler" und kein eigentlich Funktionaler, oder?
Ja, sollte funktionell keine Auswirkungen haben.
Weil die ersten Eindrücke der Version "-2" sind sehr vielversprechend, keine Meldung im syslog, PIDs wurden recht schnell nach dem Start wieder aktualisiert, EPG gab's auch Updates. Letzteres wollte ich mir bis morgen anschauen, bis dahin schonmal:
Wunderbar!
Klaus
Das hat doch sicher wieder was mit Debian zu tun
Nein, nicht nur. Diese Kernelversion ist bis heute eine der verbreitesten Versionen in langzeitstabilen Linux Distributionen, Debian, Ubuntu, Fedora, RedHat, SuSE, es ist nichts falsch dran wenn stable VDR 2.0.0 auch noch gegen diese Stockkernel baut. Zur nächsten stable VDR hat sich das Thema von alleine erledigt.
Und ausserdem muß man für neuere Kernelversion ebenso Haken schlagen, steht weiter oben, ich vermute Du hast Dir wie so oft nicht die Mühe gemacht den Rest des Threads zu lesen ... 
Da Klaus hier eh was machen wollte/mußte war er wohl wohl so nett und hat den extra Haken für DVBAPI 5.0 auch noch eingegebaut, ich selbst hatte mich schon mit s2apiwrapper abgefunden, aber so finde ich es saustark .. 
Regards
fnu
Meiner läuft auch noch auf einem aufgebohrtem 2.6.32. Warum? Nun, er läuft. Mit einem aktuelleren Kernel könnte ich es auch versuchen, nur weiß ich jetzt schon, dass die alten Lirc-Module (iMON PAD emuliert über eine Harmony, die wird heute ganz anders angebunden) auf neueren Kerneln nicht mehr gehen, also wird auch noch ein Update des gesamten Lirc-Systems fällig, falls ein aktuelles LIRC überhaupt noch zum laufen zu bringen ist. Plus DVB-Treiber, die müssen ja auch passend rein. Und dann wieder ganz von vorne anfangen, meine Fernbedienung zum laufen zu kriegen.
Ich denke, ich spar mir das Wochenende an Arbeit, bis Wheezy fertig ist, das ist früh genug.
Don’t have an account yet? Register yourself now and be a part of our community!
