VDR-2.6.6 ohne Kanal starten lassen

An meinem Test-VDR verwende ich das xineliboutput-Plugin mit "Remote" frontend auf der gleichen Kiste.

Das Frontend wird nur gestartet, wenn der Bildschirm an ist bzw. wird beides mit der Fernbedienung angeschaltet.

Bisheriges "vanilla" Verhalten war, das eine Minute nach dem Start vom VDR grundsätzlich alle SAT>IP Tuner dauerbelegt sind bis "in alle Ewigkeit" bzw. bis der VDR wieder abgeschaltet wird, leider unabhängig der "äußeren" Bedingungen:

• Automatischer Start wegen Aufnahme (erstmal kein Kanal benötigt)
• manueller Start um sich per ssh einzuloggen (erstmal kein Kanal benötigt)
• manueller oder automatischer Start, zusätzlich Start des Frontends per Fernbedienung (Kanal benötigt)

Mein Patch von hier führt schonmal dazu das nicht ständig sämtliche Tuner in Verwendung sind und der EITScan nach dem ersten Durchlauf ein Päuschen einlegt. Dadurch kann der vtuner diese SAT>IP-Tuner freigeben.

Mit diesem kruden "Holzhammer"-Patch habe ich meinen vdr dazu bekommen gänzlich ohne Kanal zu starten:

diff --git a/vdr.c b/vdr.c
index 1bdc51ab..fd8d82c1 100644
--- a/vdr.c
+++ b/vdr.c
@@ -913,10 +913,13 @@ int main(int argc, char *argv[])
      }
   if (Setup.InitialVolume >= 0)
      Setup.CurrentVolume = Setup.InitialVolume;
+
+/*
   {
     LOCK_CHANNELS_READ;
     Channels->SwitchTo(Setup.CurrentChannel);
   }
+*/

   // Restore volume:

@@ -980,9 +983,10 @@ int main(int argc, char *argv[])
                  LOCK_CHANNELS_READ;
                  const cChannel *Channel = Channels->GetByNumber(cDevice::CurrentChannel());
                  if (Channel && (Channel->Vpid() || Channel->Apid(0) || Channel->Dpid(0))) {
+                        /*
                     if (cDevice::GetDeviceForTransponder(Channel, LIVEPRIORITY) && Channels->SwitchTo(Channel->Number())) // try to switch to the original channel...
                        ;
-                    else if (LastTimerChannel > 0) {
+                    else */ if (LastTimerChannel > 0) {
                        Channel = Channels->GetByNumber(LastTimerChannel);
                        if (Channel && cDevice::GetDeviceForTransponder(Channel, LIVEPRIORITY) && Channels->SwitchTo(LastTimerChannel)) // ...or the one used by the last timer
                           ;

Das führt nun zu folgendem Verhalten: VDR startet und belegt erstmal keine SAT>IP-Tuner, nach einer Minute wird der EPG-Scan auf allen SAT>IP-Tunern gestartet. Nach dem ersten Durchlauf werden alle SAT>IP-Tuner von vtuner wieder freigegeben (Erkennung nur Section-Pids mit Timeout 60 Sekunden), der VDR selbst lässt die SAT>IP-Tuner lustig weiter senden. Startet eine Aufnahme wurde bei mir ein SAT>IP-Tuner belegt und nach der Aufnahme nie wieder freigegeben

Einziger Nachteil: Fernsehbild erscheint nun erst nach einmaligem Umschalten, da ja von Haus aus erstmal kein Kanal angewählt ist. Die Frage ist ob ein Ausgabeplugin (xineliboutput) dem VDR mitteilen kann das sich ein Ausgabefrontend verbunden hat und damit dann auf den zuletzt verwendeten Kanal geschaltet wird.

So wie ich es bis jetzt sehe gibt es nur ein "anschalten" von allem, aber kein "abschalten". Im Endeffekt läuft alles über cDevice::SetChannel, dort wird vor dem Umschalten der alte Kanal abgeschaltet. Ein cDevice::UnSetChannel oder cDevice::ClearChannel das die SectionHandler beendet und beim PrimaryDevice zusätzlich StopReplay aufruft gibt es leider nicht

MarkusE Danke für den Link

Ich möchte aber nix kastrieren, sondern im Endeffekt bestehendes verbessern. Eine sowohl-als-auch-Lösung. Also Sektionhandler nach einem EPGScan stoppen. Transfermode und Sektionhandler nach einer Aufnahme oder nach Abschalten des Ausgabeplugins stoppen. Das müsste ja dann ebenso bei Servern ohne Ausgabeplugin funktionieren.

Zitat von MarkusE

Also kastrieren tut mein Patch nichts, mit Ausgabeplugin ändert der Patch nichts. Und ohne Ausgabeplugin werden dir TS Daten ja nicht benötigt.

Achso, tut mir leid dann habe ich das falsch verstanden

Zitat von MarkusE

Da bräuchte man:

- Patch in VDR, der ein Interface zum Ein/Ausschalten der TS Daten beim primary device nachrüstet

- Patch in den Ausgabeplugins, die dieses Interface aufrufen.

Ja und zusätzlich eben eine Funktion die im cDevice den Kanal "abwählt" cDevice::ClearChannel gefällt mir da gut als Bezeichnung

Zitat von SurfaceCleanerZ

Siehe meine Frage zum Einbau des dynamite-Plugin-Patches in VDR im 2.6.6 Thread

Ja, persönlich finde ich dynamite als Plugin + Patch auch nicht den Hit. Viel zu invasiv. Core-Funktionalität wandert in ein Plugin das mit der Brechstange arbeitet (Device Array komplett füllen). Die Ladereihenfolge ist plötzlich wichtig, neue dynamite-Schnittstellen, usw. usf. Das alles ist schon etwas "weird"... Klar das das nicht akzeptiert wird.

Im Endeffekt geht es darum dem cDvbDevice abzugewöhnen nur im Konstruktor das Frontend- und ggf. CA-Device zu öffnen. Also eine Verhaltensweise wie eben Demux- und dvr-Device.

Mein Ansatz ist eben so wenig wie möglich zu ändern um das gewünschte Ergebnis zu bekommen. Anstatt "litescan patch" der das Originalverhalten des vdrs per #ifdefs "ersetzt" minimale Änderungen in eitscan die das Originalverhalten beibehalten und das gewünscht Verhalten hinzufügen.

So ähnlich habe ich mir das auch für cDevice::SwitchChannel gedacht. Eine neue Funktion virtual bool CanViewProgramme(void) const; die standardmäßig true zurückgibt und die dann vom PrimaryDevice auf false gesetzt werden kann wenn das Ausgabeplugin "schläft"
In SwitchChannel aber auch in der Mainloop kann das mit abgefragt werden.

Ok, nach einigem Gesuche im Quellcode ist es viel einfacher als gedacht: CanReplay einfach auf false lassen solange z.B. der Fernseher aus ist.

Mit folgender Änderung in device.h vom xineliboutput - Plugin

    virtual bool CanReplay(void) const {
            if (m_local) return true;
            if (!m_server) return false;
            if (m_server->HasClients()) return true;
            return false;
    };

und dieser Anpassung in frontend.h vom xineliboutput - Plugin

virtual bool HasClients(void) { return true; };

erhält man fast das gewünschte Verhalten. Ist ein lokales Frontend aktiv wird immer true zurückgemeldet, bei einem remote Frontend nur wenn mindestens ein Client aktiv ist.

Das führt nun dazu das beim Start vom vdr / xineliboutput auf keinen Kanal umgeschaltet und damit auch kein SAT>IP-Tuner belegt wird. Umschalten ist in diesem Zustand für das PrimaryDevice nicht möglich ("Error switching to channel x"). Aktiviert man nun ein xineliboutput-Frontend wird der SAT>IP-Tuner belegt und das zuletzt angewählte Programm angezeigt.

Schaltet man nun das Frontend wieder ab, bleibt der SAT>IP-Tuner leider dauerbelegt weil es kein "Abschalten" gibt. Nur über einen Trick wird der SAT>IP-Tuner wieder freigegeben: Man versucht erneut einen Kanal anzuwählen was scheitert. Dabei wird dann aber der SAT>IP-Tuner freigegeben.