Lars Danke, ich habe diese Einstellungen gefunden nur mich hat DVB verwirt.
Bei mir ist es so rpihddevice default eingestellt:
PrimaryDVB = 3Da weiß ich nicht wie man Ladereihenfolge unter systemd (Archlinuxarm) anpassen soll.
Mein /etc/vdr/conf.d/ hat 50-pluginname.conf egg:
50-rpihddevice.conf -> ../conf.avail/50-rpihddevice.conf50 - soll bedauten runlevel5.target, graphical.target + runlevel0.target, poweroff.target
50 - soll bedauten runlevel5.target, graphical.target + runlevel0.target, poweroff.target
Nein, das hat mit systemd nichts zu tun - bei vdr4arch werden für alle Plugins Konfigurationsdateien mit der Priorität 50 installiert. Du kannst die Symlinks in der /etc/vdr/conf.d/ auf die eigentlichen Dateien in der /etc/vdr/conf.avail/ aber umbenennen, um die Reihenfolge zu verändern. Die Dateien mit der niedrigsten Zahl am Anfang werden zuerst eingelesen.
Danke für die Erklärung, hab gedacht das ist systemd nummerierung.
Könnte der Lock in cDevice::SetPrimaryDevice nicht noch in den if-Block rutschen? Dann wäre er kürzer, und danach wird er ja auch nicht benötigt.
Lars
Könnte der Lock in cDevice::SetPrimaryDevice nicht noch in den if-Block rutschen? Dann wäre er kürzer, und danach wird er ja auch nicht benötigt.
Ja, das sollte möglich sein, habe ich nicht daran gedacht.
Gruss
Thomas
Moin,
ich werde das am WE auch mal testen wollen...aus dem Ausgabeplugin heraus habe ich ja keine Chance, auf ein geöffnetes OSD zu reagieren. Ich würde dann das High Level OSD im SHD so lassen wie es ist...
Wäre das dann die "neue" allgemein akzeptierte Lösung, um die TV Ausgabe für den Wechsel auf eine andere Anwendung (muss ja nicht nur Kodi sein) zu beenden, die dann auch in den Distris benutzt werden sollte?
Ciao Louis
Wäre das dann die "neue" allgemein akzeptierte Lösung, um die TV Ausgabe für den Wechsel auf eine andere Anwendung (muss ja nicht nur Kodi sein) zu beenden, die dann auch in den Distris benutzt werden sollte?
Das wäre zumindest mein Vorschlag. Ich bin nicht sehr begeistert von der Attach-/Detach-Variante, da es in meinen Augen für die Ausgabeplugins schwer zu handeln ist, jedenfalls wenn man das sauber umsetzen will.
Gruss
Thomas
Hi,
Wäre das dann die "neue" allgemein akzeptierte Lösung, um die TV Ausgabe für den Wechsel auf eine andere Anwendung (muss ja nicht nur Kodi sein) zu beenden, die dann auch in den Distris benutzt werden sollte?
ich fand bisher seit langer Zeit die ATTACH/DETACH Befehle von SHD sehr praktisch, habe SHD immer gleich detached gestartet, damit kein User eingeloggt sein muß, falls der VDR bloß für einen Timer aufgewacht ist. ATTACH habe ich dann on demand per Fernbedienung ausgelöst. Deswegen fragte ich Reufer mal in einen anderen Thread, ob sowas auch in rpihdd / amlhdd möglich wäre, aber er hat es ja abgelehnt und auf Umschalten des primären Device verwiesen.
Ciao,
Lucian
Moin,
ich fand bisher seit langer Zeit die ATTACH/DETACH Befehle von SHD sehr praktisch
Praktisch vielleicht, aber bei der Benutzung eines High Level OSD ergeben sich da gewisse "Henne Ei" Probleme. Wenn ich SHD detache, muss ich den OpenGL Kontext aufräumen, da mir die Verbindung zum X Server flöten geht. Ist zu diesem Zeitpunkt des detachens allerdings das OSD geöffnet, kann ich den OpenGL Kontext nicht sauber aufräumen, da er durch das offene OSD "blockiert" ist. Im Ausgabeplugin weiss ich aber nicht, ob ein OSD geöffnet ist, da der OsdProvider ein cOsd Objekt an den "Benutzer" (also z.B. einem Skin oder einem anderen Plugin) übergibt und damit aber auch die Verantwortung für dieses Objekt abgibt. Der Anforderer muss sich um die Lebenszeit des Osd Objekts kümmern. Das Osd aus dem Ausgabeplugin heraus zu schließen ist auch keine Option, da hiervon der externe Benutzer nichts mitbekommen würde.
Mit der hier diskutierten Methode habe ich dieses Problem nicht, da (so wie ich es verstehe, ohne mich genauer damit beschäftigt zu haben) das Ausgabeplugin "normal" weiterläuft und ich gar nix aufräumen muss...
Ciao Louis
Ich hab in dem Zusammenhang ne Frage zu dem dummydevice.
Ist es nicht so, dass das dummydevice (wie jedes andere Ausgabe Device auch) den Kanal den es "ausgeben" soll fest hält? Dass also z.B. das vnsiserver Plugin nicht auf einen anderen Transponder wechseln kann, wenn nur ein DVB Device zur Verfügung steht?
Beim streamdev-server Plugin kann man ja z.B. einstellen, dass dieses bevorzugt bedient werden soll. Beim vnsiserver Plugin kann man dies nicht, oder habe ich da etwas übersehen?
Wie handhabt Ihr dieses Problem?
Claus
PS.: Ich finde die Idee mit den Doppelpunkten als Trenner auch besser, weil sich das leicht pasen lässt und andere svdrp Ausgaben dies bereits verwenden.
Praktisch vielleicht, aber bei der Benutzung eines High Level OSD ergeben sich da gewisse "Henne Ei" Probleme. Wenn ich SHD detache, muss ich den OpenGL Kontext aufräumen, da mir die Verbindung zum X Server flöten geht. Ist zu diesem Zeitpunkt des detachens allerdings das OSD geöffnet, kann ich den OpenGL Kontext nicht sauber aufräumen, da er durch das offene OSD "blockiert" ist. Im Ausgabeplugin weiss ich aber nicht, ob ein OSD geöffnet ist, da der OsdProvider ein cOsd Objekt an den "Benutzer" (also z.B. einem Skin oder einem anderen Plugin) übergibt und damit aber auch die Verantwortung für dieses Objekt abgibt. Der Anforderer muss sich um die Lebenszeit des Osd Objekts kümmern. Das Osd aus dem Ausgabeplugin heraus zu schließen ist auch keine Option, da hiervon der externe Benutzer nichts mitbekommen würde.
Mit der hier diskutierten Methode habe ich dieses Problem nicht, da (so wie ich es verstehe, ohne mich genauer damit beschäftigt zu haben) das Ausgabeplugin "normal" weiterläuft und ich gar nix aufräumen muss...
Verstehe, das scheint ein neues Problem zu sein, welches es vor der Existenz des High Level OSD ( 
dafür) nicht gab. Ich kam erst gestern abend dazu, es bei mir einzurichten, und fand es nicht schlimm, noch vor dem Detachen des Softdevice über dbus2vdr dem skindesigner DLIC zu sagen, funktioniert einwandfrei, falls ich es richtig gedeutet habe und es sich genau um diese Problematik handelt. Da das Skin ein Benutzer, ein Konsument des cOsdProvider ist, könnte man sich überlegen, in dem Fall ein Detach im Skin anzubieten, welches sich dann kümmert, selbiges im Ausgabeplugin aufzurufen. Es führen natürlich sehr viele Wege nach Rom, ich stecke momentan nicht so tief im Code, also bloß als meine 0,02€ werten 
Ciao,
Lucian
Ich hätte prinzipiell nichts gegen die Variante mit dem Wechsel des Ausgabegeräts, weil dann alles sauber von der Stelle abgeräumt wird, die Bescheid weiß. Man muss dann noch mal ein wenig überlegen, wie man es garantieren kann, dass beim Start z.B. immer ein ganz bestimmtes Device aktiv ist (wenn man detached starten will, muss es ja das dummydevice sein), aber das sollte machbar sein.
Ja, das dummydevice empfängt dann den aktuellen Live-Kanal. Es verwirft ja einfach nur alle Daten, die der vdr an es schickt.
Ich hab noch nie in das vnsiserver-Plugin geschaut, hab also keine Ahnung, was es tut. Aber wenn es mit streamdev-server geht, sollte es prinzipiell auch mit vnsiserver gehen. Man muss da sicherlich irgendwie mit den Prioritäten rumspielen, d.h. das Live-Signal muss eine niedrigere Priorität als vnsiserver bekommen.
Alternativ bleibt eigentlich nur, das dummydevice auch fit als Empfangsdevice zu machen, so dass es einen Dummy-Kanal empfängt. Auf den müsste man den headless-vdr dann umschalten, damit die DVB-Karte nicht blockiert wird. Klingt aber nicht richtig, das mit den Prioritäten klingt besser, denn dafür sind sie da.
Lars.
Hi Lucian,
Ich kam erst gestern abend dazu, es bei mir einzurichten, und fand es nicht schlimm, noch vor dem Detachen des Softdevice über dbus2vdr dem skindesigner DLIC zu sagen, funktioniert einwandfrei, falls ich es richtig gedeutet habe und es sich genau um diese Problematik handelt.
Nein, das ist nochmal ein anderes Thema, hängt eher indirekt mit dem Thema in diesem Thread zusammen. Es geht darum, dass das detachen vom softhddevice-openglosd Fork aktuell gar nicht funktioniert, wenn zum Zeitpunkt des detachens das OSD geöffnet ist.
Da das Skin ein Benutzer, ein Konsument des cOsdProvider ist, könnte man sich überlegen, in dem Fall ein Detach im Skin anzubieten, welches sich dann kümmert, selbiges im Ausgabeplugin aufzurufen.
Blos nicht...ein Skin ist ein Skin und stellt dar. Das müsste dann ja auch jedes Plugin installieren, das eine eigene Ausgabe macht. Das ist nicht gut 
Ciao Louis
Ja, das dummydevice empfängt dann den aktuellen Live-Kanal. Es verwirft ja einfach nur alle Daten, die der vdr an es schickt.
Ich hab noch nie in das vnsiserver-Plugin geschaut, hab also keine Ahnung, was es tut. Aber wenn es mit streamdev-server geht, sollte es prinzipiell auch mit vnsiserver gehen. Man muss da sicherlich irgendwie mit den Prioritäten rumspielen, d.h. das Live-Signal muss eine niedrigere Priorität als vnsiserver bekommen.
Alternativ bleibt eigentlich nur, das dummydevice auch fit als Empfangsdevice zu machen, so dass es einen Dummy-Kanal empfängt. Auf den müsste man den headless-vdr dann umschalten, damit die DVB-Karte nicht blockiert wird. Klingt aber nicht richtig, das mit den Prioritäten klingt besser, denn dafür sind sie da.
Vielleicht klingt das nun OT, aber es scheint mir erwähnenswert. Es gibt ja hier im Forum Anfragen, wie man denn einen zentralen VDR am "gescheitesten" im LAN sharen kann, und seit einiger Zeit ist ja auch SAT>IP in Mode, und wird von vielen praktisch gefunden. Ich denke es wurde auch gefragt, ob VDR selber als SAT>IP-Server fungieren könnte, meines Wissens fehlt so eine Funktionalität, aber wie wäre es mit einem Plugin welches genau das tut, aber die ganze Priorisierung der Empfangsdevices (ob belegt von dummy, VNSI, XVDR, Streamdev oder ein Ausgabeplugin direkt an jenem VDR) so vornimmt (oder vom VDR selber machen lässt), dass nicht unnötig Empfangsdevices belegt werden, oder belegt bleiben? Vielleicht müsste man dann die ganze ursprünglich hier diskutierte Thematik in einem "größeren" Kontext betrachten.
Gruß,
Lucian
Blos nicht...ein Skin ist ein Skin und stellt dar. Das müsste dann ja auch jedes Plugin installieren, das eine eigene Ausgabe macht. Das ist nicht gut
Recht hast Du, gut ist das nicht 
wie man denn einen zentralen VDR am "gescheitesten" im LAN sharen kann
Ein reiner headless-vdr hat kein Ausgabeplugin und dementsprechend würde auch kein Kanal belegt werden.
Und falls man aus irgend welchen Gründen dort ein Ausgabeplugin braucht, kann man zusätzlich noch suspendoutput benutzen, um die Ausgabe abzuschalten. Es sieht so aus, als ob das eine Dummy-Aufnahme abspielt (schwarzes Video), damit der vdr die DVB-Karten freigibt.
Vielleicht kann man die beiden auch so miteinander verschmelzen, dass dummydevice bei Aktivierung auch immer sowas tut wie suspendoutput, so dass beide Seiten im vdr freigegeben werden.
Das sind jetzt aber nur spontane Gedanken, zu mehr hab ich tagsüber keine Zeit...
Vielleicht sollte vnsiserver aber auch nur einfach mit einer Priorität arbeiten können, mal sehen, ob ich in den Code in der Mittagspause mal reinschauen kann...
Lars.
Ist es nicht so, dass das dummydevice (wie jedes andere Ausgabe Device auch) den Kanal den es "ausgeben" soll fest hält?
Diese Aussage ist so nicht korrekt, nicht das Ausgabedevice belegt einen Kanal, sondern VDR. Um die Empfangsdevices freizugeben gibt es das suspendoutput-Plugin, welches einen Dummy-Player implementiert, der einfach ein schwarzes Bild ausgibt. VDR selbst ist nicht dafür ausgelegt, nichts auszugeben, d.h. entweder ist ein Player aktiv (Wiedergabe) oder ein Transfer (Live-TV). Aber das ist eine andere Diskussion, die mit der hier wenig gemeinsam hat.
Gruss
Thomas
Da das Skin ein Benutzer, ein Konsument des cOsdProvider ist, könnte man sich überlegen, in dem Fall ein Detach im Skin anzubieten, welches sich dann kümmert, selbiges im Ausgabeplugin aufzurufen. Es führen natürlich sehr viele Wege nach Rom, ich stecke momentan nicht so tief im Code, also bloß als meine 0,02€ werten
Ich finde, hier werden oftmals die Zuständigkeiten eines VDRs missachtet oder durcheinander gebracht, und dazu braucht es nicht einmal tiefes Code-Verständnis. Einzig und alleine der VDR-Core bestimmt, was wann und wo ausgegeben wird, sowohl bei Audio/Video als auch beim OSD. Die Plugins sind bloss für das "wie" zuständig, und sollten meiner Ansicht nach auch nichts anderes tun. Klar kann, technisch betrachtet, ein Skin das OSD schliessen, oder ein Ausgabeplugin die Ausgabe verweigern. Aber das ist schlicht nicht im Sinne des Erfinders und auf lange Sicht nicht zielführend, weil nicht universell.
Im Kontext des eigentlichen Themas bedeutet dies, dass sich alleine im Main-Loop des VDRs allfällig offene OSDs sauber schliessen lassen, weshalb Klaus das Umschalten des Ausgabedevices auch dort implementiert hat.
Gruss
Thomas
Dass also z.B. das vnsiserver Plugin nicht auf einen anderen Transponder wechseln kann, wenn nur ein DVB Device zur Verfügung steht?
Schau bitte mal in die Einstellungen des vnsiclients in Kodi, denn daher bekommt das vnsiserver-Plugin seine Priorität. Wenn die höher als Live-TV ist, dann sollte das Streamen funktionieren, wenn keine Aufnahme mit höherer Priorität läuft.
Die Priorität von Live-TV kann man bestimmt irgendwo im vdr einstellen.
Lars.
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!
