[ANNOUNCE] VDR developer version 1.7.34

    Zitat von kamel5

    Ich habe das jetzt mal probiert, das Verhalten hat sich leider nicht geändert.


    Kannst du bitte mal folgenden Patch einbauen (zusätzlich zu dem in vdr.c):


    und damit das Fehlerszenario nochmal durchspielen?
    Bitte dann das Log posten.


    Klaus

    Folgendes Log hat sich mit den beiden Patches ergeben:


    VDR ist auch frisch gestartet.



    In der letzten Zeile dann das Programm wieder händisch eingestellt.


    Was mir jetzt noch aufgefallen ist:
    Diesmal habe ich gleich bei der ersten Wiedergabe etwas länger gewartet, ca. 4min, und das Problem trat dann auf.


    kamel5

    VDR 2.6.6: ASUS Prime X470-PRO, Ryzen 7 5700X, 64GB, 6TB HD, GT1030, Fedora 39 Kernel 6.8 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5

    Zitat von kamel5

    Folgendes Log hat sich mit den beiden Patches ergeben:


    VDR ist auch frisch gestartet.



    OK, also HasProgramme() liefert schonmal den richtigen Wert.


    Jetzt bitte noch folgendes:


    Und wiederum die Ausgaben posten (kann evtl. etwas mehr sein, du kannst dann gleiche Sequenzen gerne rauslöschen).
    Genau genommen interessiert mich nur die erste solche Sequenz nach dem Beenden der Wiedergabe.


    Gruß
    Klaus

    Hier das aktuelle Log:



    Zum Schluss wieder das händische Umschalten



    kamel5

    VDR 2.6.6: ASUS Prime X470-PRO, Ryzen 7 5700X, 64GB, 6TB HD, GT1030, Fedora 39 Kernel 6.8 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5

    Zitat von kamel5

    Hier das aktuelle Log:


    Code
    Feb 15 14:05:39 home-05 vdr: [29971] dvbplayer thread ended (pid=29920, tid=29971)
Feb 15 14:05:39 home-05 vdr: [29920] no programme
Feb 15 14:05:39 home-05 vdr: [29920] check
Feb 15 14:05:39 home-05 vdr: [29920] channel 0
Feb 15 14:05:40 home-05 vdr: [29920] no programme
Feb 15 14:05:40 home-05 vdr: [29920] A: 0 1360933540 1360933539 1
Feb 15 14:05:41 home-05 vdr: [29920] HasProgramme: 0 0 0


    Nächster Schritt:

    Diff
    --- device.c    2013/02/01 12:00:09     2.71
+++ device.c    2013/02/15 14:50:51
@@ -336,6 +336,7 @@
       if (cDevice *d = cDevice::GetDevice(i)) {
          if (d->IsTunedToTransponder(Channel))
             return d; // if any device is tuned to the transponder, we're done
+         dsyslog("GetDeviceForTransponder %d %d %d %d %d %d", i, d->ProvidesTransponder(Channel), d->Occupied(), d->MaySwitchTransponder(Channel), d->Priority(), Priority);
          if (d->ProvidesTransponder(Channel)) {
             if (d->MaySwitchTransponder(Channel))
                Device = d; // this device may switch to the transponder without disturbing any receiver or live view


    Klaus

    Zitat von kls

    Nächster Schritt:

    Aktueller Log:



    Mmmh, eine Logmeldung mit "GetDeviceForTransponder" tritt aber auch sonst nicht auf.


    Beim Testen ist mir jetzt noch eingefallen, das hatte ich wohl bisher nicht erwähnt:
    Wenn eine Aufnahme im Hintergrund läuft, tritt das Problem nicht auf.



    kamel5

    VDR 2.6.6: ASUS Prime X470-PRO, Ryzen 7 5700X, 64GB, 6TB HD, GT1030, Fedora 39 Kernel 6.8 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5

    Zitat von kamel5

    Aktueller Log:



    Mmmh, eine Logmeldung mit "GetDeviceForTransponder" tritt aber auch sonst nicht auf.


    Das wundert mich aber, denn in der Zeile


    Feb 15 17:33:32 home-05 vdr: [1697] channel 0


    stammt die '0' vom Aufruf cDevice::GetDeviceForTransponder(Channel, LIVEPRIORITY).
    Bist du sicher, daß du den Patch angewendet, neu übersetzt und VDR neu gestartet hast?


    Zitat


    Beim Testen ist mir jetzt noch eingefallen, das hatte ich wohl bisher nicht erwähnt:
    Wenn eine Aufnahme im Hintergrund läuft, tritt das Problem nicht auf.


    Hmm, weiß noch nicht, wie ich das einordnen soll.
    Erstmal sehen, ob mit dem jüngsten Patch noch was rauskommt.


    Klaus

    Hallo Klaus,


    Zitat von kls

    Bist du sicher, daß du den Patch angewendet, neu übersetzt und VDR neu gestartet hast?


    ja, das hatte ich eigentlich gedacht, aber ich kann mich auch irren.
    Ich habe das Ganze jetzt nochmal neu gemacht.


    Jetzt gibt es auch ein paar Logausgaben:



    kamel5

    VDR 2.6.6: ASUS Prime X470-PRO, Ryzen 7 5700X, 64GB, 6TB HD, GT1030, Fedora 39 Kernel 6.8 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5

    Zitat von kamel5


    Hmm, die Priority von -1 für das erste Device erscheint mir problematisch.
    Kannst du bitte mal die Zeilen

    Code
    if (IsPrimaryDevice() && !Replaying() && ActualDevice() == PrimaryDevice())
     priority = TRANSFERPRIORITY; // we use the same value here, no matter whether it's actual Transfer Mode or real live viewing


    in cDevice::Priority() (device.c, Zeile 1540-1541) auskommentieren und den Versuch nochmal machen?
    Das wäre zwar noch nicht die endgültige Lösung, weil das wieder andere Seiteneffekte haben könnte, aber zumindest würde es meine momentane Theorie stützen, wenn es dadurch für diesen Fall besser würde.
    Bitte wieder das Log der betreffenden Stelle posten.


    Klaus

    Zitat von kls

    in cDevice::Priority() (device.c, Zeile 1540-1541) auskommentieren und den Versuch nochmal machen?
    Das wäre zwar noch nicht die endgültige Lösung, weil das wieder andere Seiteneffekte haben könnte, aber zumindest würde es meine momentane Theorie stützen, wenn es dadurch für diesen Fall besser würde.
    Bitte wieder das Log der betreffenden Stelle posten.

    Hier das Log dazu:



    Nach dem Auskommentieren dieser beiden Zeilen konnte ich dieses Problem nicht mehr reproduzieren.
    Das hatte aber den Nebeneffekt, das der Kanal alle paar Sekunden neu getunt wird und dann irgendwann das Bild schwarz bleibt.
    Zum Schluss dann der watchdog, bei mir auf 2min eingestellt.
    Das retunen mit watchdog auch, wenn vorher keine Aufnahme abgespielt wurde, nach einem Neustart vergehen so 2min bis das Bild schwarz bleibt.


    kamel5

    VDR 2.6.6: ASUS Prime X470-PRO, Ryzen 7 5700X, 64GB, 6TB HD, GT1030, Fedora 39 Kernel 6.8 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5


    OK, mit Seiteneffekten hatte ich schon gerechnet.


    Inzwischen glaube ich, daß folgende Änderung helfen sollte:


    Der Typecast ist nur wegen des fehlenden 'const' bei cDevice::HasProgramme(), das werde ich in der nächsten Version noch ändern (ebenso bei cDevice::HasLock()).


    Bitte probier es damit nochmal, ich hoffe mal, daß es das dann war.


    Evtl. könnten auch andere, die dieses Problem haben, diesen Patch testen.


    Klaus

    Zitat von kls

    Bitte probier es damit nochmal, ich hoffe mal, daß es das dann war.


    Evtl. könnten auch andere, die dieses Problem haben, diesen Patch testen.


    Klaus

    Wunderbar, bei ersten Tests trat das Problem nicht mehr auf. Ich werde das Verhalten in den nächsten Tagen nochmal intensiv Testen und gebe dann eine Rückmeldung dazu.


    Nur der Vollständigkeit halber hier nochmal die letzten Logs:



    Wenn ich allerdings die Wiedergabe kurz nach dem Start wieder beende gibt es keine Meldungen mit "GetDeviceForTransponder" und die channel-Nummer ist eine Andere, das ist wohl OK so?


    Code
    Feb 16 16:01:27 home-05 vdr: [6578] resuming replay at index 67626 (0:45:05.02)
Feb 16 16:01:27 home-05 vdr: [6579] non blocking file reader thread started (pid=6071, tid=6579, prio=high)
Feb 16 16:01:31 home-05 vdr: [6579] non blocking file reader thread ended (pid=6071, tid=6579)
Feb 16 16:01:31 home-05 vdr: [6578] dvbplayer thread ended (pid=6071, tid=6578)
Feb 16 16:01:31 home-05 vdr: [6071] no programme
Feb 16 16:01:31 home-05 vdr: [6071] check
Feb 16 16:01:31 home-05 vdr: [6071] channel 36990128
Feb 16 16:01:31 home-05 vdr: [6071] switching to channel 1
Feb 16 16:01:31 home-05 vdr: [6071] switched A
Feb 16 16:01:33 home-05 vdr: [6071] HasProgramme: 0 2902 2901


    Klaus, vielen Dank für die Mühen


    Gruß
    kamel5

    VDR 2.6.6: ASUS Prime X470-PRO, Ryzen 7 5700X, 64GB, 6TB HD, GT1030, Fedora 39 Kernel 6.8 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5


    Kurz nach dem Start hat wohl der EPG-Scan noch nicht zugeschlagen, daher das unterschiedliche Verhalten.
    Die "channel-Nummer" ist ein Pointer, daher kann der jedesmal anders sein. War nur ausgegeben um zu sehen, ob ein Kanal da ist oder nicht.


    Zitat
    Code
    Feb 16 16:01:27 home-05 vdr: [6578] resuming replay at index 67626 (0:45:05.02)
Feb 16 16:01:27 home-05 vdr: [6579] non blocking file reader thread started (pid=6071, tid=6579, prio=high)
Feb 16 16:01:31 home-05 vdr: [6579] non blocking file reader thread ended (pid=6071, tid=6579)
Feb 16 16:01:31 home-05 vdr: [6578] dvbplayer thread ended (pid=6071, tid=6578)
Feb 16 16:01:31 home-05 vdr: [6071] no programme
Feb 16 16:01:31 home-05 vdr: [6071] check
Feb 16 16:01:31 home-05 vdr: [6071] channel 36990128
Feb 16 16:01:31 home-05 vdr: [6071] switching to channel 1
Feb 16 16:01:31 home-05 vdr: [6071] switched A
Feb 16 16:01:33 home-05 vdr: [6071] HasProgramme: 0 2902 2901


    Klaus, vielen Dank für die Mühen


    Danke für die Hilfe beim Debuggen!
    Falls du in HISTORY/CONTRIBUTORS genannt werden möchtest, bitte eine Email mit vollem Namen an mich.


    Klaus

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden