Probleme mit Aufnahmeprioritäten und wahrscheinlich Devicebonding

  • Hallo Klaus,


    Ja ich weiß, der schon wieder mit Devicebonding .


    Ich habe hier gestern noch ein Problem mir der Priorität bei Aufnahmen festgestellt. Wenn ich nicht zufällig auch gerade Live geschaut hätte, wäre es mir wohl nie aufgefallen.


    Also folgendes Szenario:
    2 Aufnahmen programmiert, die sich überlappen, die zweite Aufnahme mit höherer Priorität ( die Erste 50, die Zweite 60) mit unterschiedlicher Polarität oder Band, hier im Fall Das Erste und Das Erste HD


    Wenn jetzt die Zeit für die zweite Aufnahme heran ist, dann wird die zweite Aufnahme ordnungsgemäß gestartet, allerdings scheint die erste Aufnahme nicht korrekt beendet zu werden. Sichtbar wird das, indem das Livebild schwarz wird und dann kein Kanalwechsel mehr möglich ist. Danach folgt dann nach timeout (bei mir 2min) ein emergency exit.



    Kanal 2 ist Das Erste HD
    Kanal 3 ist Das Erste


    Möglicherweise tritt solch ein Problem auch in einer "normalen" Konfiguration ohne Devicebonding auf, das kann ich leider hier nicht testen, wenn eine weitere Aufnahme mit höherer Priorität kein freies Device findet und dann eine andere Aufnahme abbrechen müßte.


    Getestet mit PlainVDR 1.7.40 + remote + dvbhddevice


    Falls wieder Testbedarf besteht, stehe ich gern zur Verfügung.


    Gruß
    kamel5

    VDR 2.6.0: ASUS Prime X470-PRO, Ryzen 7 2700, 64GB, 6TB HD, GT1030, Fedora 35 Kernel 5.15 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5


  • Ich hatte hier neulich diesen Vorschlag bekommen


    wollte den aber nicht mehr für die Version 2.0 aufnehmen, da ich einen konkreten Vorteil nicht direkt nachvollziehen konnte.
    Kannst du diese Änderung mal in deinem Szenario ausprobieren? Falls es da hilft, dann würde ich es doch noch übernehmen.


    Klaus

  • Mit dem Patch ist das Problem noch nicht behoben, eine geringfügige Änderung gab es aber trotzdem: Das Live-Bild blieb nach dem Start der zweiten Aufnahme nicht schwarz, sondern es wurde auf den neuen Kanal umgeschaltet, so wie man es erwarten würde.
    Das Problem des emergency exit bleibt aber bestehen.



    Wie man unten im Log sieht, fehlen jetzt die 2min timeout. Ich denke das "ERROR: video data stream broken" kommt von der ersten Aufnahme, denn es fehlt im Log auch so was wie "recording thread ended" für die erste Aufnahme.


    kamel5

    VDR 2.6.0: ASUS Prime X470-PRO, Ryzen 7 2700, 64GB, 6TB HD, GT1030, Fedora 35 Kernel 5.15 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5

  • Mit dem Patch ist das Problem noch nicht behoben, eine geringfügige Änderung gab es aber trotzdem: Das Live-Bild blieb nach dem Start der zweiten Aufnahme nicht schwarz, sondern es wurde auf den neuen Kanal umgeschaltet, so wie man es erwarten würde.


    OK, dann scheint der Patch schon mal was zu bringen und ich werde ihn noch für die Version 2.0 übernehmen.


    Quote


    Das Problem des emergency exit bleibt aber bestehen.


    Das untersuche ich gerade.
    Wie sind denn deine Devices genau gebondet?


    Klaus

  • Wie sind denn deine Devices genau gebondet?

    Alle 4 zusammen über einen 4fach-Verteiler auf ein Kabel.


    Kannst Du mir noch sagen, ob das OK ist, wenn er für die erste Aufnahme Device 4 nimmt und für die zweite Aufnahme Device 2, obwohl Device 3 auch noch frei ist.


    Bei mir ist Device 1 und 2 die TT6400, Device 3 und 4 sind die beiden Anderen (Signatur).


    kamel5

    VDR 2.6.0: ASUS Prime X470-PRO, Ryzen 7 2700, 64GB, 6TB HD, GT1030, Fedora 35 Kernel 5.15 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5


  • Das untersuche ich gerade.
    Wie sind denn deine Devices genau gebondet?


    Egal, ich glaube, ich habe das Problem gefunden.
    Probier bitte mal folgendes (zusätzlich zu dem vorherigen Patch):


    Damit schaltet er bei mir in dem geschilderten Fall richtig zwischen den Timern um, und es kommt auch gleich wieder ein Live-Bild.
    Bitte ganz intensiv testen, denn das werde ich noch in die Version 2.0 aufnehmen.


    Klaus

  • Alle 4 zusammen über einen 4fach-Verteiler auf ein Kabel.


    Kannst Du mir noch sagen, ob das OK ist, wenn er für die erste Aufnahme Device 4 nimmt und für die zweite Aufnahme Device 2, obwohl Device 3 auch noch frei ist.


    Device 3 und 4 sind ja unterschiedlich (Hauppauge Nova HD-S2, SkyStar HD2). Evtl. haben die unterschiedliche Eigenschaften, und VDR "verschont" die mit mehr Eigenschaften so lange es geht.


    Quote


    Bei mir ist Device 1 und 2 die TT6400, Device 3 und 4 sind die beiden Anderen (Signatur).


    Ich sollte mir wohl angewöhnen, die Signaturen in solchen Fällen zu lesen... ;-)


    Klaus

  • Ich sollte mir wohl angewöhnen, die Signaturen in solchen Fällen zu lesen... ;-)


    Kein Problem, dann weist Du ja trotzdem noch nicht, in welcher Reihenfolge die sind, wenn es drauf an kommt.


    Device 3 und 4 sind ja unterschiedlich (Hauppauge Nova HD-S2, SkyStar HD2). Evtl. haben die unterschiedliche Eigenschaften, und VDR "verschont" die mit mehr Eigenschaften so lange es geht.

    Laut Log können alle 4 Karten das Gleiche.


    Der erste Test ist gerade fertig. das sieht schon mal gut aus, auch das Umschalten des Live-Kanales klappt dann so wie erwartet.


    Log:



    Am Ende dann nochmal ein paar Umschaltungen des Live-Kanales, das geht auch ohne Probleme.


    OK, ich werde das die nächsten Tage noch intensiv testen und gebe dann eine Info dazu.


    Gruß
    kamel5

    VDR 2.6.0: ASUS Prime X470-PRO, Ryzen 7 2700, 64GB, 6TB HD, GT1030, Fedora 35 Kernel 5.15 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5

  • Nach mehreren Tests habe ich jetzt doch noch einen Nebeneffekt bezüglich der letzten Änderung festgestellt:
    Nur die hier:



    Wenn also jetzt keine Aufnahme läuft und ich einfach nur Kanalwechsel mache, dann wird ständig zwischen 2 Devices (hier 1 und 4) hin- und her gewechselt, das macht zumindest bei einer FF-Karte wenig Sinn (ständiger Wechsel zwischen Transfermode und Nichttransfermode).
    Die Gegenprüfung ohne diese Änderung zeigt keinen Devicewechsel.


    Log:



    Gruß
    kamel5

    VDR 2.6.0: ASUS Prime X470-PRO, Ryzen 7 2700, 64GB, 6TB HD, GT1030, Fedora 35 Kernel 5.15 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5

  • Nach mehreren Tests habe ich jetzt doch noch einen Nebeneffekt bezüglich der letzten Änderung festgestellt:
    Nur die hier:



    Wenn also jetzt keine Aufnahme läuft und ich einfach nur Kanalwechsel mache, dann wird ständig zwischen 2 Devices (hier 1 und 4) hin- und her gewechselt, das macht zumindest bei einer FF-Karte wenig Sinn (ständiger Wechsel zwischen Transfermode und Nichttransfermode).
    Die Gegenprüfung ohne diese Änderung zeigt keinen Devicewechsel.


    Versuch es bitte stattdessen mal hiermit:


    Bei der Gelegenheit ist mir aufgefallen, daß da ja auch noch ein Lock auf bondMutex gefehlt hat.


    Klaus

  • kls


    Hallo,


    ich will kurz hierzu nochmal eine Rückmeldung geben:
    Bezüglich des oben besprochenen Problems konnte ich keine weiteren Auffälligkeiten feststellen.


    Allerdings habe ich bei den Tests noch eine Ungereimtheit bei der Prioritätenauswertung festgestellt.


    Folgendes zur Veranschaulichung: Aufnahme 1 und 3 sind gleichzeitig möglich, Aufnahme 2 nicht


    Das Minus bedeutet Aufnahme, das x keine Aufnahme.



    In der Version 1 werden Aufnahme 1 und 3 komplett aufgenommen, Aufnahme 2 wird zum Zeitpunkt B unterbrochen.
    In der Version 2 wird die Aufnahme 2 zum Zeitpunkt C unterbrochen, das ist soweit OK. Aufnahme 1 wird aber nicht zum Zeitpunkt C aufgenommen, wie man es erwarten würde, sondern erst zum Zeitpunkt D.
    Es scheint, das unter bestimmten Umständen nicht alle Aufnahmeprioritäten erneut hinsichtlich der Aufnahmefähigkeit geprüft werden.


    Gruß
    kamel5

    VDR 2.6.0: ASUS Prime X470-PRO, Ryzen 7 2700, 64GB, 6TB HD, GT1030, Fedora 35 Kernel 5.15 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5

    The post was edited 2 times, last by kamel5 ().


  • Kann es sein, daß du das mit einem Proportionalfont geschrieben hast? Da ist die Ausrichtung immer Glückssache.
    Kannst du es bitte in ein <code>...</code> Tag (mit eckigen statt spitzen Klammern) setzen, damit es auch wirklich so rüberkommt, wie du es meinst?


    Klaus

  • OK, ich habe das oben mal versucht zu ändern. Leider geht in meinem Editor im Firefox keine Schrifteinstellung, woran das auch immer liegen könnte.


    Ich hoffe, es ist jetzt zu lesen, sonst muß ich es nochmal irgendwie anders versuchen.



    kamel5

    VDR 2.6.0: ASUS Prime X470-PRO, Ryzen 7 2700, 64GB, 6TB HD, GT1030, Fedora 35 Kernel 5.15 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5

  • OK, ich habe das oben mal versucht zu ändern. Leider geht in meinem Editor im Firefox keine Schrifteinstellung, woran das auch immer liegen könnte.


    Du kannst es in einem richtigen Texteditor (die haben ja Schrift mit fester Breite) schreiben und dann per C&P in das Quellcodefenster (im Tab von "Editor" auf "Quellcode" wechseln) packen. Dann passt das auf alle Fälle.


    cu

  • Keine_Ahnung


    OK, Danke.


    So was in der Art hatte ich bei meinem letzten Versuch oben ja schon versucht. Ich kann es hier bei mir bloß nicht verifizieren, bei mir hier im Browser sah auch der erste Versuch schon gut aus.


    Kann man es oben denn jetzt gut lesen, oder passt es immer noch nicht?


    kamel5

    VDR 2.6.0: ASUS Prime X470-PRO, Ryzen 7 2700, 64GB, 6TB HD, GT1030, Fedora 35 Kernel 5.15 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5


  • Ich vermute das Problem in cTimers::GetMatch(time_t t).
    Vom Zeitpunkt C bis D sind sowohl Timer 1 als auch 2 "pending". Da Timer 2 eine höhere Priorität hat als Timer 1 wird hier immer Timer 2 ausgewählt.
    Um das zu durchbrechen könnte folgende Änderung dienen:


    "Pending" bedeutet ja, daß der Timer eigentlich schon "dran" wäre, aber aus irgendwelchen Gründen (noch) nicht aufnehmen kann. Somit muß jeder "pending" Timer immer mal wieder zur Auswahl kommen, unabhängig von seiner Priorität.


    Probier bitte obigen Patch mal mit deinen beiden Test-Szenarien aus.


    Es wäre schön, wenn auch möglichst viele andere diesen Patch testen könnten bzw. einen Kommentar dazu abgeben würden, ob er irgendwelche negativen Seiteneffekte haben könnte. Abhängig davon würde ich entscheiden, ob das noch in die finale Version 2.0.0 mit reinkommt oder nicht.


    Klaus

  • Moin!


    Der letzte Patch betrifft ja nicht nur Device-Bonding, oder?
    Geht es ansonsten um die Patches aus Post 10 und 18?


    Lars.

  • Moin!


    Der letzte Patch betrifft ja nicht nur Device-Bonding, oder?


    Richtig, diese Situation kann auch ohne Device-Bonding auftreten.


    Quote


    Geht es ansonsten um die Patches aus Post 10 und 18?


    Der aus Post 10 ist bereits seit Version 1.7.41 im Test.
    Der Patch aus Post 18 ist der, um den es aktuell geht, und der unabhängig vom Device-Bonding ist.


    Klaus