[Skindesigner] Fortschrittsbalken fehlt immer noch, aber Spur vorhanden

    Hallo Zusammen (und Karl M.),


    bei mir tritt das Phänomen des gelegentlich fehlenden Fortschrittsbalkens (Balken da, aber Schnittmarken weg) auf.

    Ich bin weiter gekommen: aus Nostalgie nehme ich jeden Tag Raumschiff Enterprise auf. Schaue ich die Folge von gestern,

    verschwinden die Marken, sobald die heutige Aufnahme startet. Sie kommen sofort wieder, sobald die heutige Aufnahme zu Ende

    ist.

    Ausserdem wechselt die Zeitanzeige (beim Ansehen der alten Aufnahme) auf den Modus: Timeshift aktiv


    Ich habe ein wenig gedebugt und timeShiftActive wechselt von 0 auf 1, sobald die neue Aufnahme startet.

    Ich bin da aber leider nicht so richtig weiter gekommen :(


    Meine Vermutung ist, dass zur Entscheidung (timeshift oder nicht) nicht der komplette Name der Sendung genommen wird, sondern nur "Raumschiff Enterprise".

    Die Anzeige im Log zeigt jedenfalls den richtigen Pfad (der geladenen Marks) beim Start der Anzeige der alten Aufnahme an.


    Mit LCRAs tritt der Fehler übrigens nicht auf!


    Vielleicht kann sich Karl freundlicherweise das mal anschauen. Vielen Dank!



    Falls ich noch helfen kann, das Problem weiter einzukreisen oder Infos fehlen, bitte melden :)


    LG,

    Michael


    VDR: V2.4.7, skindesigner: V1.2.15, skin: angepasster blackhole oder auch estuary4vdr

    VDR 2.7.2 (oben): Asus M4N68T-M-LE-V2, 2GB RAM, 120GB SSD, 1TB HD, AMD Athlon(tm) II X4 640 @ 3GHz, NVIDIA GT530 (V390.157), FFMPEG 7.0.2, OpenSuse Leap 15.5 (X-Server) Kernel 5.14.21, 2x Budget + 1x Hauppauge WinTV-DualHD, VDPAU (Softhddev.)

    VDR 2.7.2 (unten): Asus P8H77-V LE, 8GB RAM, 120GB SSD, 2TB HD, Intel(R) Celeron(R) G1620 @ 2.70GHz, NVIDIA GT630 (V470.223.02), FFMPEG 7.0.2, OpenSuse Leap 15.1 (X-Server) Kernel 5.6.8, DD Cine V6.1 Dual + Hauppauge WinTV-quadHD, VDPAU (Softhddev.)


    Hallo Karl,


    vielen Dank!


    Zusatzinfo:

    Wenn man die Tagesschau alle Stunde in der ARD aufnimmt, kann man das auch sehen.


    Ich habe mir in viewelementsdisplayreplay.c in der Funktion cVeDrCutMarks::Parse() die Variable timeShiftActive anzeigen lassen.

    Ich habe die alte Aufnahme laufen lassen und mit OK die Info eingeblendet.

    timeShiftActive ist false (0).

    Sobald die neue Aufnahme startet, wechselt timeShiftActive auf true (1).

    Mir ist nur nicht so ganz klar, wo diese Variable gesetzt wird. Dort ist dann der Check auf die Aufnahme

    unvollständig (erwischt die neue Aufnahme und nicht die abgespielte Aufnahme).


    herzliche Grüße,

    Michael

    VDR 2.7.2 (oben): Asus M4N68T-M-LE-V2, 2GB RAM, 120GB SSD, 1TB HD, AMD Athlon(tm) II X4 640 @ 3GHz, NVIDIA GT530 (V390.157), FFMPEG 7.0.2, OpenSuse Leap 15.5 (X-Server) Kernel 5.14.21, 2x Budget + 1x Hauppauge WinTV-DualHD, VDPAU (Softhddev.)

    VDR 2.7.2 (unten): Asus P8H77-V LE, 8GB RAM, 120GB SSD, 2TB HD, Intel(R) Celeron(R) G1620 @ 2.70GHz, NVIDIA GT630 (V470.223.02), FFMPEG 7.0.2, OpenSuse Leap 15.1 (X-Server) Kernel 5.6.8, DD Cine V6.1 Dual + Hauppauge WinTV-quadHD, VDPAU (Softhddev.)


    Quote from Mike838

    Ich habe mir in viewelementsdisplayreplay.c in der Funktion cVeDrCutMarks::Parse()

    Das ist schon zu weit gedacht.

    Wir müssen erst einmal prüfen, ob die richtige Aufnahme benutzt wird.

    Quote from Mike838

    Mir ist nur nicht so ganz klar, wo diese Variable gesetzt wird.

    Die Variable wird hier "coreengine/viewdisplayreplay.c" in der Funktion "cViewReplay::SetTimeShiftValues" definiert.

    Im Anhang findest Du einen kurzen Patch der ein paar Informationen über die Aufnahme, die gerade benutzt wird, ausgibt.

    Normalerweise sollte sich beim Abspielen einer Aufnahme und aktivem Fortschrittsbalken keine Änderung bzgl. der angezeigten Aufnahme ergeben, wenn eine neue Aufnahme startet.


    Bitte benutze zum Testen auch den letzten git-Stand vom Plugin, man weiß ja nie.


    Bisher konnte ich das Verhalten hier noch nicht nachvollziehen, ich bleibe aber dran.


    Grüße

    kamel5

    Vielen Dank,


    ich habe es eingebaut, kann aber erst morgen compilieren. Ich melde mich.


    Ich hatte in "cViewReplay::SetTimeShiftValues" schon eine Ausgabe eingebaut.

    Dort wird beim Start der neuen Aufnahme timeShiftActive=1 (vorher ist es 0)

    Wahrscheinlich weil nur auf "recording->Name()" getestet wird und dort steht nur der

    Hauptname (zB Raumschiff Enterprise) und nicht der gesamte Pfad (wie in "Recording->FileName()" )


    Schönen Abend und bis Morgen!


    LG,

    Michael

    VDR 2.7.2 (oben): Asus M4N68T-M-LE-V2, 2GB RAM, 120GB SSD, 1TB HD, AMD Athlon(tm) II X4 640 @ 3GHz, NVIDIA GT530 (V390.157), FFMPEG 7.0.2, OpenSuse Leap 15.5 (X-Server) Kernel 5.14.21, 2x Budget + 1x Hauppauge WinTV-DualHD, VDPAU (Softhddev.)

    VDR 2.7.2 (unten): Asus P8H77-V LE, 8GB RAM, 120GB SSD, 2TB HD, Intel(R) Celeron(R) G1620 @ 2.70GHz, NVIDIA GT630 (V470.223.02), FFMPEG 7.0.2, OpenSuse Leap 15.1 (X-Server) Kernel 5.6.8, DD Cine V6.1 Dual + Hauppauge WinTV-quadHD, VDPAU (Softhddev.)


    Moin und einen schönen 1.Mai,


    Ich vergaß: natürlich habe ich die letzte Version aus dem Git (master).


    So hier das Ergebnis:


    1. Ansehen der abgeschlossenen Aufnahme (Tagesschau) vom 1.5.,12:50,

    keine weitere Aufnahme parallel oder parallele Aufnahme irgendeiner anderen Sendung:

    Fortschrittsbalken zeigt Marks an


    May 01 14:15:29 vdr-oben vdr[1139]: [1139] replay /video/Tagesschau/2021-05-01.12.50.1-0.rec

    May 01 14:15:29 vdr-oben vdr[1139]: [1139] loading /video/Tagesschau/2021-05-01.12.50.1-0.rec/marks

    May 01 14:15:29 vdr-oben vdr[1139]: [1139] skindesigner: displayreplay.c SetRecording 16 /video/Tagesschau/2021-05-01.12.50.1-0.rec Tagesschau

    May 01 14:15:29 vdr-oben vdr[1139]: [1139] skindesigner: displayreplay.c SetRecording 18 /video/Tagesschau/2021-05-01.12.50.1-0.rec/marks


    2. Start der Aufnahme einer weiteren Sendung (Tagesschau) 1.5., 16:05:

    May 01 16:01:34 vdr-oben vdr[1139]: [1139] executing '/usr/local/src/scripts/rec_led.sh before "/video/Tagesschau/2021-05-01.16.05.1-0.rec"'

    May 01 16:01:35 vdr-oben vdr[1139]: [1139] record /video/Tagesschau/2021-05-01.16.05.1-0.rec


    3. Ansehen der alten Aufnahme (Tagesschau) vom 1.5.,12:50, Fortschrittsbalken ist leer

    May 01 16:04:53 vdr-oben vdr[1139]: [1139] skindesigner: displayreplay.c SetRecording 16 /video/Tagesschau/2021-05-01.12.50.1-0.rec Tagesschau

    May 01 16:04:53 vdr-oben vdr[1139]: [1139] skindesigner: displayreplay.c SetRecording 18 /video/Tagesschau/2021-05-01.12.50.1-0.rec/marks

    May 01 16:04:53 vdr-oben vdr[1139]: [1139] skindesigner: coreengine/viewdisplayreplay.c SetTimeShiftValues 198 /video/Tagesschau/2021-05-01.12.50.1-0.rec Tagesschau 1


    Ich hoffe das hilft weiter.


    LG,

    Michael

    VDR 2.7.2 (oben): Asus M4N68T-M-LE-V2, 2GB RAM, 120GB SSD, 1TB HD, AMD Athlon(tm) II X4 640 @ 3GHz, NVIDIA GT530 (V390.157), FFMPEG 7.0.2, OpenSuse Leap 15.5 (X-Server) Kernel 5.14.21, 2x Budget + 1x Hauppauge WinTV-DualHD, VDPAU (Softhddev.)

    VDR 2.7.2 (unten): Asus P8H77-V LE, 8GB RAM, 120GB SSD, 2TB HD, Intel(R) Celeron(R) G1620 @ 2.70GHz, NVIDIA GT630 (V470.223.02), FFMPEG 7.0.2, OpenSuse Leap 15.1 (X-Server) Kernel 5.6.8, DD Cine V6.1 Dual + Hauppauge WinTV-quadHD, VDPAU (Softhddev.)


    Quote from Mike838

    Ich hoffe das hilft weiter.

    Ja, das zeigt uns, das hier nicht die falsche Aufnahme benutzt wird, "SetTimeShiftValues" aber die richtige Stelle ist. Das mit den Schnittmarken ist nur ein Folgefehler.

    An dieser Stelle spielt auch Remotetimer eine Rolle, deshalb noch die Frage, ist das ein lokaler Timer oder ein Remotetimer?


    Ich werde versuchen, das mal mit der Tagesschau nachzuvollziehen.

    So richtig Zeit zum darüber Nachdenken habe ich aber erst kommende Woche.


    Grüße

    kamel5

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

    Git-Repo: gitlab.com/kamel5

    Es ist ein lokaler Timer.


    Kein Problem, es eilt ja nicht. Vielen dank fürs Anschauen.


    Ich benutze Markads, hatte es aber auch mal deaktiviert, ohne Änderung des Verhaltens.


    Übrigens sagt das Live-Plugin unter Programme auch, dass es zB die Enterprise-Aufnahmen schon hat

    ("Vorhandene Aufnahme"), obwohl es nicht die gleiche Folge ist. Vielleicht geht das in die gleiche Richtung

    (wäre aber ein anderer Thread ;))?


    LG,

    Michael

    VDR 2.7.2 (oben): Asus M4N68T-M-LE-V2, 2GB RAM, 120GB SSD, 1TB HD, AMD Athlon(tm) II X4 640 @ 3GHz, NVIDIA GT530 (V390.157), FFMPEG 7.0.2, OpenSuse Leap 15.5 (X-Server) Kernel 5.14.21, 2x Budget + 1x Hauppauge WinTV-DualHD, VDPAU (Softhddev.)

    VDR 2.7.2 (unten): Asus P8H77-V LE, 8GB RAM, 120GB SSD, 2TB HD, Intel(R) Celeron(R) G1620 @ 2.70GHz, NVIDIA GT630 (V470.223.02), FFMPEG 7.0.2, OpenSuse Leap 15.1 (X-Server) Kernel 5.6.8, DD Cine V6.1 Dual + Hauppauge WinTV-quadHD, VDPAU (Softhddev.)


    ofenheizer ,


    wenn Du das hier [markad] überarbeiteter Decoder meinst, dann eher nicht.

    In diesem Falle wird das Timeshiftflag falsch gesetzt. Das mit den Schnittmarken ist dann nur ein Folgefehler. Man müsste das auch sehen, den dadurch wird die Anzeige in den Timeshift-Mode gesetzt und dann passen halt ein paar Anzeigen nicht mehr.


    Das mit den Hängern oder Zeitlupe am Ende der Aufnahme oder an der letzten Schnittmarke kenne ich auch von meiner TT6400, nicht immer, aber manchmal. Da dauert das aber, gefühlt zwar eine Ewigkeit, in Wirklichkeit nur ca. 2-3 sec. Damit kann ich leben.

    Wenn ich mich richtig erinnere, sind vor Ewigkeiten mal irgendwelche Buffer im VDR vergrößert worden und danach ist das spürbar aufgetreten.


    Grüße

    kamel5

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

    Git-Repo: gitlab.com/kamel5

    ofenheizer ,


    ja. OK. Das könnte dann die gleiche Ursache haben.

    Zum Glück kann ich das ja jetzt reproduzieren und habe auch schon einen Lösungsansatz.

    Allerdings verstehe ich noch nicht ganz, warum das so wie es bisher an dieser Stelle implementiert ist, in diesem speziellen Falle nicht funktioniert.


    Grüße

    kamel5

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

    Git-Repo: gitlab.com/kamel5

    Mike838 , ofenheizer ,


    ich habe im git mal einen fix commited, der dieses Problem wahrscheinlich lösen sollte.

    Das Problem war, das zum Vergleich von vorhandener Aufnahme und dem laufenden Timer nicht genug Informationen herangezogen wurden.

    Da das Problem in cGlobalTimers::IsRecording() verursacht wird, kann ich allerdings nicht abschätzen, ob es durch diese Änderung evtl. Probleme mit der Erkennung bei Benutzung von epg2vdr oder remotetimers geben könnte, da ich beides hier nicht einsetze. Gegebenenfalls müsste ich da nochmal nachsteuern.


    Grüße

    kamel5

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

    Git-Repo: gitlab.com/kamel5

    Hallo Karl,


    super, vielen Dank, es funktioniert!


    Leider kann ich epg2vdr und remotetimers auch nicht testen.


    Schön dass auch die Vereinfachungen in listelements.c übernommen wurden, dann hat sich die Arbeit gelohnt ;)


    Herzliche Grüße,

    Michael

    VDR 2.7.2 (oben): Asus M4N68T-M-LE-V2, 2GB RAM, 120GB SSD, 1TB HD, AMD Athlon(tm) II X4 640 @ 3GHz, NVIDIA GT530 (V390.157), FFMPEG 7.0.2, OpenSuse Leap 15.5 (X-Server) Kernel 5.14.21, 2x Budget + 1x Hauppauge WinTV-DualHD, VDPAU (Softhddev.)

    VDR 2.7.2 (unten): Asus P8H77-V LE, 8GB RAM, 120GB SSD, 2TB HD, Intel(R) Celeron(R) G1620 @ 2.70GHz, NVIDIA GT630 (V470.223.02), FFMPEG 7.0.2, OpenSuse Leap 15.1 (X-Server) Kernel 5.6.8, DD Cine V6.1 Dual + Hauppauge WinTV-quadHD, VDPAU (Softhddev.)


Participate now!

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

Register Yourself Login