[Patch] Unbenutzte Frontends schließen

  • Hi,


    Ich kann den Fehler hier immer noch nicht reproduzieren.


    Ich habe jetzt mit

    Quote

    VDR 2.6.7 + vdr-2.6.7-2.6.8pre-01.diff + sectionHandler.txt

    getestet. Keine anderen Patches. Und nur 1 Plugin: softhddevice


    DVB Karte:


    Syslog, start:

    Warum der Timeout (while tuning to channel 2) hier kommt ist mir unklar. Kann eigentlich nichts mit meinem Patch zu tun haben, der macht hier noch nichts. Ist kein reales Problem, ich kann ZDF prima sehen.


    Code
    2024-07-04T17:53:37.643236+02:00 vdr1 vdr: [71447] pause EPG scan
    2024-07-04T17:53:37.643896+02:00 vdr1 vdr: [71447] closing frontend 1/0
    2024-07-04T17:53:38.613280+02:00 vdr1 vdr: [71454] device 2 section handler thread ended (pid=71447, tid=71454)

    Dann starte ich eine Wiedergabe, und stoppe die Wiedergabe:

    Auch hier stört der Timeout nicht, ich kann nach wenigen Sekunden ZDF sehen.


    ~Markus

    Client1: ASUS P5QC, Dual Core 3G, Cine S2, Ext. Board von TBE, Xubuntu 20.04, VDR 2.6x

    Client2: RPI3

    Server: RPI4, Sundtek SkyTV Dual 2x

  • Dass der Timeout bei dir "nicht stört" mag sein, aber er sollte auf keinen Fall vorkommen.

    Noch ein Test mit plain vdr-2.6.7, ohne irgendwelche Patches, nur ein Plugin (softhddevice). Syslog direkt bein Start:


    Also, da steht jetzt auch

    Quote

    2024-07-04T21:25:25.691978+02:00 vdr1 vdr: [108555] frontend 0/0 timed out while tuning to channel 2 (ZDF HD), tp 111361


    Sollte das wirklich nicht vorkommen? Ich denke, wenn wir hier die Ursache für den timeout verstehen, hilft und das auch an der anderen Stelle weiter.

    Client1: ASUS P5QC, Dual Core 3G, Cine S2, Ext. Board von TBE, Xubuntu 20.04, VDR 2.6x

    Client2: RPI3

    Server: RPI4, Sundtek SkyTV Dual 2x

  • Ich finde diesen Timeout im Log auch, aber nur bei einem anscheinend nicht mehr vorhandenen Kanal:

    frontend 6/0 timed out while tuning to channel 2944 (Xplore_alt), tp 212699

    Insbesondere hab ich den nicht sofort beim Start, so wie du.


    Schauen wir mal, was der Test mit Treiber 0.9.39 bringt.

  • Ich hab jetzt den DD-Treiber 0.9.39 installiert, aber der Fehler tritt auch damit auf:

    Nach Beenden der Wiedergabe bleibt der Bildschirm schwarz, und auch Umschalten bringt nichts.

  • Ich habe nur 2 Frontends, Du scheinst mehr zu haben. Ev. kannst Du auch mal VDR nur zwei Devices nutzen lassen

    Client1: ASUS P5QC, Dual Core 3G, Cine S2, Ext. Board von TBE, Xubuntu 20.04, VDR 2.6x

    Client2: RPI3

    Server: RPI4, Sundtek SkyTV Dual 2x

  • Mit nur 2 Devices: keine Änderung.

    Mit sectionHandler_3.txt: keine Änderung.


    Ich habe mal in cDvbTuner::Action() ein paar Ausgaben eingebaut. tunerStatus geht von tsIdle über tsSet und tsPositioning nach tsTuned, aber dann liefert GetFrontendStatus() kein FE_HAS_LOCK und es kommt zum Timeout. Irgend etwas fehlt also zu diesem Zeitpunk noch, das beim normalen Betrieb vorhanden ist.

  • Ich komme übrigens zu der Überzeugung, dass es, anstatt SetChannelDevice(NULL, false) aufzurufen, eine dedizierte Funktion geben sollte, die ein Device in einen "power save" Modus versetzt. Etwa


    virtual void cDevice::SetPowerSaveMode(bool On);


    Dann kann jedes Device, das das kann, diese implementieren und es kommt nicht zu unvorhergesehenen Seiteneffekten durch eine plötzliche API-Änderung. Hätte mir eigentlich gleich aufstoßen sollen... ;-).

    Ich baue den Patch mal entsprechend um und poste ihn dann hier. Der erste Teil wird die neue virtuelle Funktion und deren Aufruf bringen, im zweiten Teil können wir dann die Implementierung in cDvbDevice weiter verfolgen.

  • Unsere Systeme sind so ähnlich, und bei mir kommt immer ein Bild, bei Dir nicht.

    Der einzige Unterschied, der mir noch einfällt, ist die Performance. Ich habe ein recht altes System, immerhin schon dual core.

    Möglicherweise ist es ein Timing Problem?

    Client1: ASUS P5QC, Dual Core 3G, Cine S2, Ext. Board von TBE, Xubuntu 20.04, VDR 2.6x

    Client2: RPI3

    Server: RPI4, Sundtek SkyTV Dual 2x

  • Mit meinem aktuellem i3 System QuadCore und 8 Tunern habe ich nicht das Problem von kls reproduzieren können. OS ist Fedora 40. Anzeige ist softhddevice. device ist ne Digital Devices Max SX8 (4/8) Basic Kernel ist selbstgebacken und die dd-Treiber sind immer aus dem aktuellen Master git-Zweig übersetzt.

  • Möglicherweise ist es ein Timing Problem?

    Möglich, halte ich aber eher für unwahrscheinlich.


    Anbei die modifizierte Version des Patches.

    vdr-2.6.7-power-save-mode-01.diff.txt implementiert die allgemeine Schnittstelle,

    vdr-2.6.7-power-save-dvbdevice-01.diff.txt aktiviert es für cDvbDevice - oder versucht es zumindest, denn es funktioniert auch damit bei mir nicht. Kannst du bitte mal verifizieren, ob es damit bei dir noch funktioniert? Wenn ja, dann würde ich weiter debuggen, warum es bei mir nicht geht.

  • Was ist eigentlich mit


    /dev/dvb/adapter<M>/dvr<N> und

    /dev/dvb/adapter<M>/demux<N>


    Solange die nicht ebenso geschlossen sind, sollte das device gar nicht wirklich schlafen gehen können.

    Hat jemand von euch nachgemessen, ob dieser Patch aktuell wirklich Strom spart?

  • Ja meine Kiste hängt an einem fritzbox dect 200 die LNB Spannung war aus. Sauber sowie ich es von tvheadend kenne das ja auch die device schlafen legt.

  • Schon mal eine gute Info.


    Dann spart das also *nur* bei DVB-S(2) Strom, weil es den LNB schlafen legt?

    Und spart wahrscheinlich selbst dort weniger als es könnte?

  • Schon mal eine gute Info.


    Dann spart das also *nur* bei DVB-S(2) Strom, weil es den LNB schlafen legt?

    Und spart wahrscheinlich selbst dort weniger als es könnte?

    Denke das es nur bei DVB-S(2) devices so ist. Idle habe ich 28 Watt und wenn alle 8 Tuner loslegen 44 Watt. Wie es bei anderen Empfangsarten ist weis ich nicht.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!