Primäres Device per SVDRP-Kommando umschalten

Moin,

Zitat von reufer

allfällig

da du dieses Wort in diesem Thread nun schon zum zweitenMal benutzt...was bedeutet das denn?

Ciao Louis

Zitat von clausmuus

Dass also z.B. das vnsiserver Plugin nicht auf einen anderen Transponder wechseln kann, wenn nur ein DVB Device zur Verfügung steht?

Man kann das vnsiserver-Plugin mit dem Argument -d starten, damit es ein Ausgabegerät bereitstellt - wenn ich das richtig verstehe macht das Sinn, wenn der VDR keine anderen Ausgabegeräte besitzt oder man beim Detachen eines anderen Ausgabeplugins darauf umschaltet. In dem Fall wäre dummydevice eigentlich überflüssig, oder?

Zitat von reufer

Ich gelobe Besserung, aber man möge mir allfällige Ausrutscher in Zukunft verzeihen.

Passt schon, ist ja auch mal nicht schlecht, was neues zu lernen. Könnte ja allfällig mal in nem Urlaub hilfreich sein. Sorry für das OT.

Ciao Louis

Zitat von reufer

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.

Nicht so ganz. Da es ja da drum geht, dass Ausgabe Device frei zu geben um andere Programme zu starten, würde es ja durchaus Sinn machen, in dem Zusammenhang gleich auch das DVB Devices frei zugeben, damit dieses von anderen (Plugins) genutzt werden kann. Wenn ich dafür dann zusätzlich das suspendoutput Plugin benötige habe ich nichts gewonnen.

Zwar lässt sich das auch über Prioritäten steuern, was aber nicht alle denkbaren Fälle abdeckt. Es sei denn, die Priorität des dummydevice lasst sich so niedrig einstellen, dass alle anderen Plugins grundsätzlich Vorrang haben (und auch z.B. der epg scan). Ich hätte das also gerne so, dass das vnsi Plugin Vorrang vor dem dummidevice hat, aber nachrangig gegenüber dem rpihddevice behandelt wird.
Ließe sich das machen? Ich hatte mich mit dem Thema Prioritäten bisher nie befasst.

Claus

Zitat von clausmuus

Zwar lässt sich das auch über Prioritäten steuern, was aber nicht alle denkbaren Fälle abdeckt. Es sei denn, die Priorität des dummydevice lasst sich so niedrig einstellen, dass alle anderen Plugins grundsätzlich Vorrang haben (und auch z.B. der epg scan). Ich hätte das also gerne so, dass das vnsi Plugin Vorrang vor dem dummidevice hat, aber nachrangig gegenüber dem rpihddevice behandelt wird.
Ließe sich das machen? Ich hatte mich mit dem Thema Prioritäten bisher nie befasst.

Nein, die Ausgabedevices haben keine Priorität, nur die Empfangsseite. Live-TV-Empfang hat eine Priorität und Timer bzw. laufende Aufnahmen haben Priorität. Wenn es einen Konflikt gibt (zu wenig Devices für alle Timer/Live-TV), dann werden die mit der niedrigsten Priorität nicht ausgeführt bzw. beendet. Dazu gehört eben auch Live-TV.

Welche Prio vnsiserver benutzt (um Live-TV zu übersteuern, muss sie > 0 sein), hängt von der Einstellung in Kodi ab. Schau da bitte mal nach, ob es da eine Einstellung gibt. Ich bin mir da ziemlich sicher (zumindest sagt mir das der Code von vnsiserver).

Das, was du vor hast (streamen können, wenn dummydevice aktiv, nicht streamen können, wenn rpihddevice aktiv), geht nicht. Es sei denn, du schaltest mit dem primären Device gleichzeitig die Live-Priorität um. Ich glaube aber, das geht zur Zeit nicht.

Lars.

LIVEPRIORITY ist zur Zeit eine Konstante (default ist 0), die zur Compilezeit festgelegt wird.
Das müsste man erst noch einbauen, dass man das während der Laufzeit umschalten kann.

Lars.

Ich hab dbus2vdr mal um einen Parameter "--nulldevice" erweitert, es erstellt dann ähnlich wie dummydevice ein Ausgabedevice, welches nichts tut, und gleichzeitig wie suspendoutput bzw. softhddevice im detach-mode einen null-player startet, der nichts wiedergibt, so dass der vdr auch die Tuner freigeben sollte (bzw. den EPG-Scan durchziehen kann). Ist ja evtl. auch für die ein oder andere headless-Installation interessant.

Vielleicht kann das jemand gebrauchen, dann braucht man keine zusätzlichen Plugins laden (zumindest wir bei yavdr nicht, weil wir dbus2vdr voraussetzen).

https://github.com/flensrocker…dbus2vdr/releases/tag/v29

Lars.

Hi Lars.
Danke für das Nulldevice. Coole Sache.
Bekomme es aber irgendwie nicht so richtig ans laufen.
Wenn ich mit

--nulldevice

starte dann wird der VDR richtig mit aktivem nulldevice gestartet.
Wenn ich den Parameter beim Start allerdings weglasse dann bekomme ich als Antwort auf

GetNullDevice

ein "-1" zurück.
Hab ich was übersehen?

Zu dem von crow angesprochenden Themenkomplex geht es hier weiter: dbus2vdr, nulldevice und cecremote

Regards
fnu

Hi fnu.
Aber mein Problem gehört doch eher hier hin. Das andere geht wenn ich es richtig mitbekommen habe doch eher um cecremote.

Lars
Wollte noch erwähnen das es sich um einen Raspberry mit rpihddevice handelt

dbus2vdr erzeugt nur dann das nulldevice, wenn man es mit dem Parameter startet, ansonsten nicht. Dadurch kann man es auch weglassen, falls man es nicht braucht bzw. man lässt es nur dann erzeugen, wenn man es braucht.

Wenn du es mit --nulldevice startest und dann auch noch vor rpihddevice, und in der setup.conf die Einstellung des primären device nicht änderst, dann bekommt das nulldevice die Nummer vom rpihddevice und deshalb ist es aktiv. Wenn du die setup.conf oder die Öadereihenfolge änderst, dann ist wieder rpihddevice nach dem Start aktiv. Kann man auch im OSD unter DVB oder so einstellen, welches das Standard-PD sein soll.

Lars

Ah. Ok. Soweit hatte ich nicht gedacht. Dachte der nulldevice Parameter würde nur angeben ob es Standard ist oder nicht.
Dann teste ich es so nochmal. Danke Dir.