ZitatOriginal von HolgerR
Klasse! Vielen Dank! Ich hoffe ich komme heute abend zum Testen. Das mit dem VDR User ist für mich kein Problem: Schmutzig hin oder her; meine VDRs laufen aus anderen Gründen bereits unter root
Na ja, wenn ich dir schon helfe, dann gehe ich ja davon aus das ich davon auch was habe, also teste das bitte auch mit dem User vdr.
Gerald
ZitatOriginal von gda
Na ja, wenn ich dir schon helfe, dann gehe ich ja davon aus das ich davon auch was habe, also teste das bitte auch mit dem User vdr.
Hmmm... ich hatte eigentlich nur vor, mich mit dem Posten des fertigen Schnipsels für die entsprechende Stelle im Quelltext erkenntlich zu zeigen, aber weil du's bist. 
Ich hab auch nicht soviel Zeit - vielleicht mal am WE - was ich vorhin sagen wollte ist das ein busy-wait keine Lösung für das Problem ist. 
In Ermangelung besseren Wissens hatte ich nur angemerkt, das andere dieses Problem auch lösen müssen ;).
Eine wie auch immer geartete Lösung um ne Message aus dem Plugin zu emitten hört sich gut an, am besten so dass es upstream genutzt werden kann
ZitatOriginal von steffen_b
Eine wie auch immer geartete Lösung um ne Message aus dem Plugin zu emitten hört sich gut an, am besten so dass es upstream genutzt werden kann
Ich schätze wenn man es richtig machen will, dann muss man wohl dbus benutzen, aber damit kenne ich mich gar nicht aus und ich weiß auch nicht ob upstart irgendwie mit dbus kommuniziert. Vielleicht ein Dbus-Daemon erstellen, der unter root Läuft und die empfangenen dbus-Signale in emits umsetzt? Ich habe es gerade gefunden, mindestens upstart >= 0.5 kommuniziert mit dbus und in Karmic ist 0.6.3. Ich schätze das wäre die perfekte Lösung. Freiwillige vor!
Gerald
Hallo Leute,
ich würde das lieber mit Hausmitteln des VDR machen.
dbus ist mir zu "desktop"-lastig und ich bin mir nicht sicher, dass es auf allen Plattformen vorhanden ist, auf denen der VDR läuft.
Was haltet Ihr davon, ein Script zu starten, welches den event auslöst?
Wenn dieses das Superuser-Bit hat, müsste das auch als normaler Benutzer ausführbar sein.
Das script könnte dann "/sbin/initctl emit ..." enthalten und wäre anpassbar für Systeme, auf denen es kein Startup gibt. Dies Konzept könnte man sogar soweit ausbauen, dass der VDR für jedes geladene Plugin so ein event auslöst.
Somit wäre es nur ein kleiner Patch, kein Plugin müsste geändert werden und trotzdem gäbe es für jedes Plugin einen event ...
Jetzt vielleicht das Ganze noch per Konfigurations-Parameter ein- bzw. ausschaltbar machen ...
Nur so ein Gedanke 
Gruß Geronimo
ZitatOriginal von geronimo
dbus ist mir zu "desktop"-lastig und ich bin mir nicht sicher, dass es auf allen Plattformen vorhanden ist, auf denen der VDR läuft.
In dem Thread geht es um upstart, alle Plattformen die upstart haben, haben dbus. Dbus wird vom Desktop stark benutzt hat aber wenig damit zu tun. Da hal wohl demnächst komplett durch udev und dbus ersetzt wird, wird es wohl schwierig werden in Zukunft komplett auf dbus zu verzichten.
Mir gefällt die Dbus-Version ganz gut. Nur mal als Merker, die Funktion dbus_g_proxy_send () macht wohl das wesentliche.
ZitatOriginal von geronimo
Was haltet Ihr davon, ein Script zu starten, welches den event auslöst?
Wenn dieses das Superuser-Bit hat, müsste das auch als normaler Benutzer ausführbar sein.
Ich dachte immer, dass das Superuser-Bit bei Skripten nicht zieht und man deshalb ein Wrapper-Binary braucht, aber ich lerne immer gerne dazu.
Gerald
ZitatOriginal von geronimo
Das script könnte dann "/sbin/initctl emit ..." enthalten und wäre anpassbar für Systeme, auf denen es kein Startup gibt. Dies Konzept könnte man sogar soweit ausbauen, dass der VDR für jedes geladene Plugin so ein event auslöst.
Was natürlich auch mit dbus ginge
ZitatOriginal von geronimo
Somit wäre es nur ein kleiner Patch, kein Plugin müsste geändert werden und trotzdem gäbe es für jedes Plugin einen event ...
Nur käme dieses Event theoretisch zu früh, der Start des Threads für das Plugin ist noch nicht der Zeitpunkt an dem das Plugin auch bereit ist und wenn ich wieder mit sleeps arbeiten muss, dann habe ich nichts gewonnen.
Gerald
> Ich dachte immer, dass das Superuser-Bit bei Skripten nicht zieht und man deshalb ein Wrapper-Binary
> braucht, ...
Wenn Du das sagst, ist das sicher so. Ich glaube nicht, dass ich mehr Ahnung von Linux habe, als Du! Bin bloß ein Mausschubser
> Was natürlich auch mit dbus ginge
Mein Einwand sollte nicht heißen, dass es mit dbus nicht geht, sondern ich hatte die kleinen Settop-Boxen im Sinn, die vielleicht keinen fetten Desktop drauf haben. Mag ja sein, dass Startup bei denen dann auch nicht geht, aber die Idee mit den events gefällt mir trotzdem ...
... ebenso wie die Einsatzzwecke, die Holger schon angerissen hat.
> Nur käme dieses Event theoretisch zu früh ...
Naja, es gibt doch auch bei den Treibern verschiedene events, wie z.B. before start und after start oder so ...
Die Plugins haben ja auch div. Einsprungstellen, sodass man unterschiedliche events auch für die Plugins generieren könnte. Wenn man will, ließe sich das Konzept allgemeingültig implementieren - und nur darum ging es mir.
Ich bin kein Verfechter von externen Scripts - mir ist auch lieber, wenn es ohne geht. Aber flexibler ist es allemal und ich fände es gut, wenn die events nicht nur für HD-Boxen angedacht würden ...
Gruß Geronimo
in den Sourcen von upstart ist ja auch die Quelle für initctl enthalten. Die Funktionen emit_action und Abhängige in initctl.c lassen sich relativ leicht herauslösen und dann vom Plugin heraus aufrufen. Dann machst du die Funktion von "initctl emit" ohne das initctl-Programm zu benutzen und gehst der User-Problematik aus dem Weg. Vielleicht komme ich dazu das mal vorzubereiten. Da die Funktionalität mit dem System-Call weiter oben im Thread aber die Selbe ist, kannst du das erstmal verwenden.
Kleine Randnotiz: initctl benutzt dbus.
Gerald
Nur mal so gesponnen ... wäre es nicht am besten cPlugin::Service zu benutzen und ein DBus plugin was ja nicht groß sein muss die Arbeit erledigen zu lassen ? Dann wäre der Impact für alle die es nicht interessiert nicht groß - müsste freilich zuerst gestartet werden das plugin. Fehlt freilich wieder jemand der's programmiert
ZitatOriginal von steffen_b
Nur mal so gesponnen ... wäre es nicht am besten cPlugin::Service zu benutzen und ein DBus plugin was ja nicht groß sein muss die Arbeit erledigen zu lassen ? Dann wäre der Impact für alle die es nicht interessiert nicht groß - müsste freilich zuerst gestartet werden das plugin. Fehlt freilich wieder jemand der's programmiert
Hättest du mal ein beispielhaftes Plugin parat, bevor ich selbst auf die Suche gehe?
Ich glaube ich habe schon was gefunden.
Gerald
Hatte das im Hinterkopf:
http://www.vdrportal.de/board/thread.php?postid=596600
Ist ja nen bischen anders gelagert, aber doch ähnlich genug ...
epgsearch sollte das auch implementiert haben, war damals einer die Initiatoren.
Hi,
mal ein schnelles erstes Feedback: Das funktioniert ganz wunderbar! 
So sieht's dann im Log aus:
ZitatAlles anzeigenOct 28 18:26:42 kueche vdr: [4768] [xine..put] cXinelibServer priority set successful SCHED_RR 2 [1,99]
Oct 28 18:26:42 kueche vdr: [4768] [xine..put] Binding server to 127.0.0.1:37890
Oct 28 18:26:42 kueche vdr: [4768] [xine..put] Listening on port 37890
Oct 28 18:26:42 kueche vdr: [4768] [xine..put] Listening for UDP broadcasts on port 37890
Oct 28 18:26:42 kueche vdr: [4768] [xine..put] Event 'xineliboutput-is-ready' sent
Oct 28 18:26:42 kueche vdr: [4768] [xine..put] BROADCAST: VDR xineliboutput DISCOVERY 1.0^M Server port: 37890^M Server address: 127.0.0.1^M Server version: xineliboutput-1.0.4^M ^M
Oct 28 18:26:42 kueche vdr: [4764] [xine..put] cXinelibDevice::StartDevice(): Device started
Einzige Änderung: Die von gda gepostete Zeile in der "frontend_svr.c" (+ eine zweite optionale für's Log):
ZitatLOGMSG("Listening for UDP broadcasts on port %d", m_Port);
system("/sbin/initctl emit xineliboutput-is-ready");
LOGMSG("Event 'xineliboutput-is-ready' sent");
}
Vielen Dank Gerald für die Hilfe! Der versprochene "non root" Test dauert wohl ein Weilchen; der selbstgebaute VDR wurde von root für root gebaut.
Gruß
Holger
und startet das ganze jetzt auch schneller ?
und bitte die scripte 
ZitatOriginal von HolgerR
Der versprochene "non root" Test dauert wohl ein Weilchen; der selbstgebaute VDR wurde von root für root gebaut.
Lass man auch, mir gefällt die Idee von steffen_b ein Plugin dafür zu bauen, der Quellcode ist da und muss nur noch zusammen kopiert werden ;). Jetzt muss ich nur noch einen Zeit-Slot finden, der mit einem Motivations-Peek zusammenfällt.
Gerald
Hi Holger,
Schneller? Nun ja: Es startet jetzt halt genau dann, wenn es frühestens möglich ist. Bisher musste ich die "Sleeps" eher konservativ ansetzen. Und selbst dann schlug das eine oder andere Mal noch der "Respawn" zu. Es startet auf jeden Fall jetzt "sauber"
Das Script ist ja sehr einfach gestrickt. Du brauchst es halt nur als nicht ausführbare Textdatei in /etc/event.d/ abzulegen. Hier ist mal meins als Beispiel:
# vdr-sxfe
start on xineliboutput-is-ready
stop on runlevel 0
stop on runlevel 1
stop on runlevel 4
stop on runlevel 5
stop on runlevel 6
respawn
exec xinit -e /usr/bin/vdr-sxfe --buffers=1000 xvdr+tcp://localhost --reconnect -f --audio=alsa --video=vdpau -- :1Gruß
Holger
PS: Die "stop on"s kann man evtl. noch anders lösen.
ZitatOriginal von gda
Lass man auch, mir gefällt die Idee von steffen_b ein Plugin dafür zu bauen, der Quellcode ist da und muss nur noch zusammen kopiert werden ;). Jetzt muss ich nur noch einen Zeit-Slot finden, der mit einem Motivations-Peek zusammenfällt.
Gerald
Jo, danke. Die Idee mit dem Plugin hat mir auch gut gefallen. Nicht, dass ich die Idee nicht auch gehabt hätte, aber als "Nicht-Coder" geht mir selbst das Äußern der Idee nicht so schnell durch die Finger.
ZitatOriginal von HolgerR
Jo, danke. Die Idee mit dem Plugin hat mir auch gut gefallen. Nicht, dass ich die Idee nicht auch gehabt hätte, aber als "Nicht-Coder" geht mir selbst das Äußern der Idee nicht so schnell durch die Finger.
Jetzt müsste mir ein C++-Hacker nur noch erklären, wie ich vom Plugin aus die Klasse cPlugin so überlade, dass ich an das Starten aller Plugins rankomme, dann könnte ich schon mal automatisch bei jedem Plugin-Start emitten.
Gerald
ZitatOriginal von HolgerR
Code# vdr-sxfe start on xineliboutput-is-ready
eigentlich war der Name "xineliboutput-is-ready" nur als albernes Beispiel, als Platzhalter für den richtigen Namen gemeint. Witzig das so was dann einfach überlebt.
Gerald
kümmer dich nicht um sowas, du könntest schon längst das plugin fertig haben
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!