Permashift 1.0.4 für VDR 2.4, Betaversion

  • Hallo!


    Ich habe nach Ewigkeiten mal wieder eine Version meines Plugins für permanenten Timeshift "Permashift" zusammengepackt.

    Abgesehen von Codecleanup ist nur ein Patch für den aktuellen VDR 2.4.6 dazugekommen.

    Da meine Testmöglichkeiten *hüstel* eingeschränkt sind, hoffe ich auf den einen oder anderen Neugierigen.


    Hier gibt's den Quellcode: https://github.com/eikesauer/P…/releases/tag/v1.0.4-beta


    Und eine Erklärung, worum es überhaupt geht: https://ein-eike.de/vdr-plugin-permashift/


    Gesundheit!

    Eike

  • Hallo Eike


    Leider gibt’s eine Fehler beim Kompilieren:

    Hab's versucht mit vdr-2.4.6 und vdr-2.5.1


    Gruss


    Carel

  • Hallo Carel,


    Leider gibt’s eine Fehler beim Kompilieren:

    Hab's versucht mit vdr-2.4.6 und vdr-2.5.1


    dein Compiler scheint strenger zu sein als meiner.


    Kannst du mal folgendes probieren?


    In vdr.c, ca. Zeile 1360, sollte folgendes stehen:


    Code
    // Pausing live video:
    case kFastRew:
      // test if there's a live buffer to rewind into...
      LOCK_CHANNELS_READ;
      if (cDevice::ActualDevice()->GetPreRecording(Channels->GetByNumber(cDevice::CurrentChannel())) == NULL) {
        break;
      }
    // fall through to pause
    case kPlayPause:


    Ersetze das mal bitte durch dieses hier (also einfach zwei geschweifte Klammern mehr):


    Code
    // Pausing live video:
    case kFastRew:
    {
      // test if there's a live buffer to rewind into...
      LOCK_CHANNELS_READ;
      if (cDevice::ActualDevice()->GetPreRecording(Channels->GetByNumber(cDevice::CurrentChannel())) == NULL) {
        break;
      }
    }// fall through to pause
    case kPlayPause:


    Gesundheit!

    Eike

  • Wer Probleme damit hatte, spreche jetzt oder schweige für immerdar.

    :huh:Dann muss ich wohl mal was schreiben...


    Bei mir ist es bei der neuen Version so:

    1. Wenn ich auf Pause drücke, bekomme ich jetzt ein schwarzes Bild (das war vorher nicht so) und der Buffer wird abgespeichert. Warte ich jetzt bis das zu Ende ist, funktioniert permashift normal mit Start, Stop und Spulen.

    2. Wenn ich nicht warte bis der Buffer abgespeichert ist und ich auf Play oder Spulen drücke, springe ich sofort zurück ins LiveBild. Die Timeshift-Aufnahme läuft aber im Hintergrund weiter.

    Außerdem startet dann im Fall 1 die Wiedergabe nicht, wie erwartet, bei der aktuellen Stopzeit, sondern immer am Anfang der Aufnahme.


    Ich bin allerdings noch nicht dazu gekommen, mal zu schauen, woran das liegen könnte.


    Grüße

    kamel5

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

    Git-Repo: gitlab.com/kamel5

  • Hallo,


    ich hab mal ein kurzes diff zur alten Version gemacht. Dabei ist mir das in menu.c cRecordControls::PauseLiveVideo von der alten auf die neue Version aufgefallen:


    Code
    -  if (Start(Timers, NULL, true, &reused)) {
    +  if (Start(Timers, NULL, true)) {

    Kurz geändert und es geht wieder.


    Was mir allerdings noch aufgefallen ist, auch schon bei der alten Version.

    Die Timeshift-Aufnahme wird nicht immer zuverlässig beendet, wenn man den Modus verlässt.

    Dazu habe ich aber noch keine Systematik erkannt.


    Grüße

    kamel5

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

    Git-Repo: gitlab.com/kamel5

  • Hallo!


    Dann muss ich wohl mal was schreiben...


    Man muss nur drohen, dann klappt es auch! ;)


    Nein, im Ernst: Du hast deinem Namen keine Ehre gemacht - wenn der Fehlermelder die Lösung gleich mit findet, kann er kein Kamel sein... ;)

    Ich werd's in Release 1.4 einbauen.

    Danke!


    Was mir allerdings noch aufgefallen ist, auch schon bei der alten Version.

    Die Timeshift-Aufnahme wird nicht immer zuverlässig beendet, wenn man den Modus verlässt.

    Dazu habe ich aber noch keine Systematik erkannt.


    Ich bin da grad ehrlich gesagt nicht mal sicher, wie das Sollverhalten ist. Ich schau nochmal rein.

    Die Debugausgaben sollten in der aktuellen Version erweitert sein, aber mir scheint, für diesen Fall gibt das noch nicht viel her. Kannst ja bei Gelegenheit trotzdem mal schauen, was das Log sagt.


    Danke nochmal!

    Eike

  • Nein, im Ernst: Du hast deinem Namen keine Ehre gemacht

    8)


    Ich bin da grad ehrlich gesagt nicht mal sicher, wie das Sollverhalten ist. Ich schau nochmal rein.

    Aus meiner Sicht wäre das erwartete Verhalten: wenn man den Timeshift-Mode verlasst sollte auch alles bereinigt werden.

    Das funktioniert ja auch manchmal, aber eben nicht immer und diese übrig bleibenden Aufnahmen beenden sich dann erst, wenn die eingestellte Zeit für Direktaufnahmen erreicht ist. So sammeln sich dann die nicht bereinigten Timeshift-Aufnahmen und müssen händisch gelöscht werden. Besondere Log-Meldungen gibt es dazu leider nicht.


    Nachtrag:

    Wünschenswert wäre ein Timeshift, bei dem nach Beenden des Modus der Buffer nicht verworfen wird, außer man wechselt den Kanal oder startet eine "normale" Wiedergabe. Also nach Beenden des Modus und erneutem Drücken von Pause sollte der ursprüngliche Buffer erneut in gesamter Länge zur Verfügung stehen.

    Mir ist es schon öfters passiert, das ich aus Versehen (weil ich nicht mehr daran gedacht habe, das der Modus aktiv ist) auf Beenden gedrückt habe und das was ich noch sehen wollte, war dann weg. Hier half auch nur manchmal, das die Timeshift-Aufnahme im Hintergrund fälschlicherweise weiter lief.


    Viele Grüße

    kamel5

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

    Git-Repo: gitlab.com/kamel5

  • Beim Testen für den skindesigner ist mir noch folgendes aufgefallen:

    Die Zeiten die bei der Timeshift-Wiedergabe angezeigt werden, stimmen nicht.

    Sie zeigen ca. das Doppelte von den tatsächlichen an und zählen auch bei normaler Wiedergabe doppelt so schnell hoch.


    Grüße

    kamel5

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

    Git-Repo: gitlab.com/kamel5

  • Im Anhang mal ein Update für den permashift patch für VDR-2.5.4.


    Bei mir gab es mit dem patch für VDR-2.4, angewendet auf VDR-2.5.4, einen segfault beim Beenden des VDR. Im Betrieb mit VDR-2.5.4 konnte ich vorerst keine Auffälligkeiten feststellen.


    Der neue patch sollte diesen segfault beheben. Das Ganze aber ohne Gewähr.


    Grüße

    kamel5

  • md_berlin


    Sollte es nicht


    sein, um


    zu vermeiden?


    Wegen: http://git.tvdr.de/?p=vdr.git;…ac2d9fcb5607c;hb=HEAD#l22


    EDIT:

    https://github.com/eikesauer/Permashift/issues/4

  • Schön, das Du da noch was hinsichtlich Rückspulen machen willst.


    Ich habe da noch 2 andere Dinge, die mich stören:


    - wenn eine Aufnahme mit der "roten Record-Taste"ausgelöst wird, wird immer eine Aufnahme mit der Dauer einer Direktaufzeichnung angelegt. Hier würde ich es besser finden, eine Aufnahme der gerade aktuellen Sendung zu machen, d.h. am Anfang den Permashift-Buffer mit zu nutzen, die Endzeit aber nach der aktuellen Sendung zu setzen. Möglicherweise kann das auch im Setup als wählbare Option angeboten werden.


    - Zum Anzeigen des Live-Buffers von Permashift wird nicht nur die Pausentaste benutzt, sondern auch die Rückspultaste (kFastRew). Diese Taste nutze ich auch in TVGuide um Seitenweise in der Zeit rückwärts zu navigieren. Das geht nicht mehr, wenn man den Permashift-Patch in vdr.c anwendet. Hier würde ich mir wünschen, das die Rückspultaste nur dann von Permashift ausgewertet wird, wenn kein OSD offen ist. Der angehängte 2-zeilige Patch löst dieses Problem.


    Grüße

    kamel5

  • Hi,

    Nur mal reingegrätscht: wenn die Abfrage auf offenes OSD so einfach ist, warum kann man dann im VDR selbst nicht auch m und s abfangen, so dass die nur dann Menü bzw. Mute bei Keyboard Bedienung machen, wenn kein OSD offen ist? So kann man nämlich keine Worte damit eintippen, ohne dass er sofort das Menü öffnet und man von vorne anfängt. Uralter VDR Bug der Standardtastaturbelegung. Ja ich weiß dass man die für sich ändern kann...

    MfG Stefan

    Test-VDR1: HP rp5700 Fertigsystem, Core2Duo E6400, 2GB RAM, FF-SD C-2300, nvidia Slim-GT218 x1 | easyVDR 2.0 64Bit
    VDR3: in Rente

    VDR4: MSI G31M2 v2, Digitainer2-Geh., t6963c 6" gLCD, E5200, 2GB, 3TB WD Red, GT730, 2x TT S2-3200; easyVDR 3.5 64bit
    VDR5: Gigabyte
    GA-G31M-S2L, Intel E2140, Zotac GT730 passiv, Digitainer2-Geh., t6963c 6 " gLCD, 2 TB WD Red, 2x TT S2-3200 (an 1 Kabel) easyVDR 3.5 64bit
    VDR6:
    Intel E5200, GT630 passiv, F1 750 GB, t6963c gLCD, 2x TT S2-3200 | easyVDR 3.5 64bit
    VDR-User #1068
    www.easy-vdr.de

  • Nö, wird bei Distris mitgeliefert, anlernen geht natürlich. M öffnet das Menü und S deaktiviert den Ton. Da hatte ich vor Jahren schon mit Klaus drüber geschrieben, wurde aber nie angepasst, da ja wenige VDR mit Tastatur bedienen.

    MfG Stefan

    Test-VDR1: HP rp5700 Fertigsystem, Core2Duo E6400, 2GB RAM, FF-SD C-2300, nvidia Slim-GT218 x1 | easyVDR 2.0 64Bit
    VDR3: in Rente

    VDR4: MSI G31M2 v2, Digitainer2-Geh., t6963c 6" gLCD, E5200, 2GB, 3TB WD Red, GT730, 2x TT S2-3200; easyVDR 3.5 64bit
    VDR5: Gigabyte
    GA-G31M-S2L, Intel E2140, Zotac GT730 passiv, Digitainer2-Geh., t6963c 6 " gLCD, 2 TB WD Red, 2x TT S2-3200 (an 1 Kabel) easyVDR 3.5 64bit
    VDR6:
    Intel E5200, GT630 passiv, F1 750 GB, t6963c gLCD, 2x TT S2-3200 | easyVDR 3.5 64bit
    VDR-User #1068
    www.easy-vdr.de

Jetzt mitmachen!

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