Hallo brabax22,
Und die hier:
http://habichthugo.vdr-develop…/avards.htm#_Toc169254482
beschriebenen Vorraussetzungen für avards sind auch erfüllt, vor allem was Treiber und FW angeht?
Dann fällt mir auch nichts mehr ein.
Markus
Hallo brabax22,
Und die hier:
http://habichthugo.vdr-develop…/avards.htm#_Toc169254482
beschriebenen Vorraussetzungen für avards sind auch erfüllt, vor allem was Treiber und FW angeht?
Dann fällt mir auch nichts mehr ein.
Markus
Witzigerweise hat das alles schon mal funktioniert. Die einzige Änderung war der Einbau einer neuen (DVB-S2) Karte und Installation eines CVS-Treibers...
Die Voraussetzungen sollten erfüllt sein:
Dann liegt es mit Sicherheit an dem CVS-Treiber.
Die Fehlermeldung tritt auf wenn Avards versucht dem Treiber das WSS Format zu setzen:
struct v4l2_format fmt;
memset(&fmt, 0, sizeof fmt);
fmt.type = V4L2_BUF_TYPE_SLICED_VBI_OUTPUT;
fmt.fmt.sliced.service_set = V4L2_SLICED_WSS_625;
if (ioctl(vbi_device, VIDIOC_S_FMT, &fmt) < 0) {
esyslog("avards Error: Can't init vbi device '%s' (%s)\n", szvbiDevice, strerror(errno));
Offenbar versteht dein Treiber das V4L2_SLICED_WSS_625 nicht und antwortet deshalb mit "invalid argument" ...
Danke für die Hilfe. Ich habe das Problem inzwischen an einer anderen Stelle lokalisieren können: Ich hatte die falsche Firmware im Einsatz
mit Fehler:
Jan 5 08:58:17 video kernel: [ 677.812000] dvb-ttpci: info @ card 0: firm f0240009, rtsl b0250018, vid 71010068, app 80002622
^^^^^
Jan 5 08:58:17 video kernel: [ 677.812000] dvb-ttpci: firmware @ card 0 supports CI link layer interface
ohne Fehler:
Jan 5 09:03:11 video kernel: [ 972.552000] dvb-ttpci: info @ card 0: firm f0240009, rtsl b0250018, vid 71010068, app 80f12623
^^^^^
Jan 5 09:03:11 video kernel: [ 972.552000] dvb-ttpci: firmware @ card 0 supports CI link layer interface
Ich habe überhaupt keine Ahnung, wieso da plötzlich eine andere Firmware auf dem Rechner war, ansich hatte ich Anfang 07 die letzte Änderung... Vielleicht mit einem Update des Standard Ubuntu Kernels...
Egal: Geht wieder !
ZitatOriginal von udobroemme
Wäre es evtl. möglich, den Patch für die neue Avards-Version anzupassen? Ich habe es selbst versucht, bekomme es aber wegen fehlender Programmierkenntnisse nicht hin.
Ok, ich habe die Patches angepaßt. Ich habe aber ein paar Probleme mit der System-Last. Mit der alten Variante (atmo-0.1.1 und avards-0.1.2 verpatcht) braucht der VDR ca. 18% der CPU auf meinem System. Mit den neuen Patches sind es zwischen 25% und 40%. Momentan habe ich noch keine Erklärung dafür.
Gruß
e9hack
Bei 16:9 anamorph liegt die Last bei mir bei ca 9%.
Wird auf 4:3 oder letterboxed umgeschaltet, liegt sie bei ca. 15%.
Ich weiß allerdings nicht, ob es bei der alten Version auch schon so war.
Erst einmal vielen Dank für den Patch.
Hi,
da es bei der Entwicklung vom aurora-Plugin ungünstig ist, wenn die kontinuierlich arbeitende und multithreadfähige GrabImage()-Schnittstelle im atmo-Plugin angesiedelt ist, habe ich alles direkt in den Vdr verlagert. Atmo- und Avards-Plugin brauchen damit nur noch auf GrabImage() zugreifen. Einen kleinen Haken hat der Patch momentan noch: Neben der vollen Auflösung werden nur die Skalierungen für VdrAdmin und Atmo-Plugin unterstützt.
Gruß
e9hack
Danke für die neuen Patches.
Klappte bei mir prima mit vdr 1.4.7 und avards 0.1.4. Das Atmo brauche ich nicht. Kann deshalb darüber nichts berichten.
Hauptsache ich kann VDRAdmin und Avards gleichzeitig nutzen.
Gruss Kauli
Hi,
da es wohl Programme gibt, die bei laufendem Vdr zeitweilig oder dauerhaft Zugriff auf /dev/videoX haben wollen, habe ich den Patch nochmal geändert. Das Video-Device wird erst geöffnet, wenn GrabImage() aufgerufen wird. Das Video-Device wird wieder geschlossen, wenn 3 Images 'gegrabbt' wurden und die keiner haben wollte. Am Avards- bzw. Atmo-Patch ändert sich nichts.
Gruß
e9hack
Hi,
da es gestern eine neue Version vom Avards-Plugin gab, schiebe ich mal eine neue Version vom Patch nach. Der Vdr-Patch unterstützt jetzt beliebige Auflösungen von GrabImage(), sodaß auch das TV-Bild vom Live-Plugin angezeigt wird.
Gruß
e9hack
dankeschön
hi,
erstmal danke für den patch.
kann mir vielleicht jemand sagen, wie ich die patche
in den "00List" mechanismus von Tobis vdr-paketen eingebaut bekomme
oder wie habt ihr eure vdr's mit den grabimage.diff versehen?
danke und gruß
caspar
Hallo,
Wäre der Einbau des Patchteils des VDRs nicht direkt im VDR sinnvoll? Dann hätten das alle direkt im VDR und nicht nur eine kleine Zahl an Selber-VDR-Kompilierern!
mfG,
Stefan
ZitatOriginal von SurfaceCleanerZ
Wäre der Einbau des Patchteils des VDRs nicht direkt im VDR sinnvoll? Dann hätten das alle direkt im VDR und nicht nur eine kleine Zahl an Selber-VDR-Kompilierern!
Irgendwann sollte das schon direkt in den VDR integriert werden. Demnächst werden zwangsweise Änderungen an GrabImage notwendig werden, da der Kernel-Support für v4l1 ausläuft und GrabImage momentan darauf aufbaut. Ich bin gerade dabei, den Patch auf v4l2 umzustellen. Da kann dann auch das 'Double-Buffering' entfallen, da man beliebig viele 'Capture-Buffer' anfordern kann.
Gruß
e9hack
Hi,
Cool, danke schon mal dafür!
Avards für xineliboutput und em84 wär noch was
mfG,
Stefan
Gibt es eigentlich schon Neuigkeiten bzgl. des Patches? Ich würde gern vdr-1.7.4 mit dem neuen Aufzeichnungsformat testen. Da aber mit vdr-1.7.3 die GrabImage-Schnittstelle auf v4l2 umgestellt wurde, lässt sich der Patch nicht mehr anwenden. Und trotz Testumgebung verzichte ich nur ungern auf avards oder atmo-Licht.
ZitatOriginal von udobroemme
Gibt es eigentlich schon Neuigkeiten bzgl. des Patches? Ich würde gern vdr-1.7.4 mit dem neuen Aufzeichnungsformat testen.
Kein Problem, bei mir läuft vdr 1.7.4 seit Mitte Januar.
Gruß
e9hack
Vielen Dank. Läuft auch hier bisher problemlos.
Hi,
da der VDR ab 1.7.11 den Support für die FF's in ein Plugin ausgelagert hat, muß auch der Grab-Image-Patch angepaßt werden. Für alle Plugins, die auf GrabImage() zugreifen, ändert sich nichts.
Gruß
e9hack
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!