[Beta-Test] Permashift Episode II - Die Rückkehr der Ringspeicher

  • Der Raspi hat wahnsinnige 512MB
    Davon wird allerdings auch die GPU versorgt. Ich denke mehr als max 100MB werde ich da nicht abgreifen können.

    Gruß Patrick


    [size=8]* Meine NeverEndingProjects ;-) *


    vectra --- glasslike ---

  • So, erster kurzer Erfahrungsbericht:
    Plugin start verläuft fehlerfrei. Der RAM scheint auch zuverlässig genutzt zu werden. Jedenfalls geht nach dem start des VDR der RAM relativ schnell um ca 100MB runter.
    Jedoch hab ich folgendes Problem:
    Sobald ich die Rückspul-Taste betätige erhalte ich folgende LOG Ausgabe:

    Code
    1. Mar 30 20:10:52 rpi1 vdr: [15663] ERROR: attempt to drop wrong frame from ring buffer!
    2. Mar 30 20:10:58 rpi1 vdr: [15804] ERROR: attempt to drop wrong frame from ring buffer!
    3. Mar 30 20:10:58 rpi1 vdr: [15804] ERROR: attempt to drop wrong frame from ring buffer!


    Von da an ist der VDR nicht mehr bedienbar und verweilt bis irgendwann der Watchdog anschlägt.
    Kannst du noch weitere Angaben gebrauchen?


    Gruß Patrick


    EDIT:
    Es handelt sich um einen Streamdev-Client

    Gruß Patrick


    [size=8]* Meine NeverEndingProjects ;-) *


    vectra --- glasslike ---

  • Quote

    Es handelt sich um einen Streamdev-Client

    Oh. Ich weiß gar nicht, ob und wie das mit Streamdev laufen kann.
    Ich hab auch keine Ahnung, wie Streamdev arbeitet.
    Ich würde jetzt vermuten, dass bei dir der Client die Aufnahme zwischenspeichert,
    die dann aber vom Server abholen will. Kann das sein?


    Wer kennt sich mehr mit Streamdev aus und weiß, ob das Permashift-Konzept
    dazu passen könnte?

  • Ja da müsstest du recht haben. Die Aufnahmen werden auf dem Server programmiert. Der Client holt nichts selbst auf. Da wird dann auch der Knackpunkt sein.

    Gruß Patrick


    [size=8]* Meine NeverEndingProjects ;-) *


    vectra --- glasslike ---

  • Habe es gerade mal mit gen2vdr v4 mit vdr 2.11 versucht.
    Der Patch harmoniert nicht mit dem opt-24_jumpplay.patch.
    Ohne diesen lässt es sich kompilieren.
    Nachdem ich erstmals tvguide und nopacity auf den neusten Stand bringen musste und dann noch einiges anderes gemacht habe, bin ich nicht mehr richtig zum testen gekommen.
    Was mir aufgefallen ist:

    Die Zeitangabe in der Liveaufnahme stimmt nicht und läuft zu schnell.
    Ansonsten funktioniert es echt super. Vielen Dank schon mal.
    Ich habe es mit einer Speichergröße von 1 GB versucht. Insgesamt sind 4 GB Ram vorhanden.
    Apropos: Was passiert eigentlich wenn mein Ram komplett voll (also der komplette Arbeitsspeicher) ist und ich keine swap partition habe? Schmiert mir mein System ab? Wie behandelt linux diesen Fall.



    VDRHD-System: Intel Celeron E3200 Dualcore 2,4GHZ; MB GIGABYTE GA-P31-ES3G; G-Skill PC-800 DDR Ram 2GB; VGA Gainward Bliss Geforce GT 9500 1024MB; Technotrend Budget S2-1600; Technotrend Skystar 2; Ausgabe über HDMI

  • Hallo!

    Quote

    Habe es gerade mal mit gen2vdr v4 mit vdr 2.11 versucht.
    Der Patch harmoniert nicht mit dem opt-24_jumpplay.patch.

    Hm, muss man mal kucken, wie man sich da aus dem Weg gehen kann.
    Wir machen ja glaub ich was Ähnliches, das aufgenommene Video nicht von Anfang an abspielen...

    Die Zeitangabe in der Liveaufnahme stimmt nicht und läuft zu schnell.

    Also, beim Anschauen stimmen die angezeigten Zeiten nicht?
    Söltsam. Ist das Verhältnis irgendwie auffällig? Vielleicht zeigt er ja für 30 fps an?

    Quote

    Ich habe es mit einer Speichergröße von 1 GB versucht. Insgesamt sind 4 GB Ram vorhanden.
    Apropos:
    Was passiert eigentlich wenn mein Ram komplett voll (also der komplette
    Arbeitsspeicher) ist und ich keine swap partition habe? Schmiert mir
    mein System ab? Wie behandelt linux diesen Fall.

    Wenn der Speicher knapp wird, kann ziemlich viel Mist passieren, glaub ich.
    Im Idealfall weigert sich aber das System, dem Plugin sein GB zu geben.
    Ist mir während der Entwicklung passiert, als der davor angeforderte Speicher,
    auch ein GB, nicht freigegeben wurde. :) Wenn das passiert, wird es vom Plugin
    auf dem OSD angezeigt.


    Ciao,
    Eike

  • Die fehlerhaften Zeitangaben sind nur vorhanden, wenn ich während dem normalen Fernsehschauen auf die Zurückspultaste drücke und dann mit der Taste "OK" die Zeitinformationen anzeigen lasse. Und die Zeit läuft circa 3 mal zu schnell.
    Behalte ich die Aufnahme nach Beendigung bei und spiele sie ganz normal vom Aufhnahmemenü des VDR ab, dann stimmen die Zeitangaben.

    VDRHD-System: Intel Celeron E3200 Dualcore 2,4GHZ; MB GIGABYTE GA-P31-ES3G; G-Skill PC-800 DDR Ram 2GB; VGA Gainward Bliss Geforce GT 9500 1024MB; Technotrend Budget S2-1600; Technotrend Skystar 2; Ausgabe über HDMI

  • Ich muss dir einfach danken. Das Plugin ist wirklich der Knaller und ich finde es von der Funktionsweise stimmig. Darauf habe ich schon lange gewartet. Umschaltzeiten sind auch perfekt!

    VDRHD-System: Intel Celeron E3200 Dualcore 2,4GHZ; MB GIGABYTE GA-P31-ES3G; G-Skill PC-800 DDR Ram 2GB; VGA Gainward Bliss Geforce GT 9500 1024MB; Technotrend Budget S2-1600; Technotrend Skystar 2; Ausgabe über HDMI

  • Hallo Eike


    dein Plugin verrichtet jetzt seit einigen Wochen stabil und unauffällig seinen Dienst, vielen Dank noch mal dafür.


    Ein Feature würde ich mir allerdings noch wünschen: Eine Option, dass eine durch das Plugin beim Zurückspulen angelegte Sofortaufnahme beim Kanalwechsel von selbst gestoppt und gelöscht wird.
    Siehst du eine verträgliche Möglichkeit?


    Grüße, Peter

    KODI, tvh, arch x86_64, Octopus net 2 x Duoflex C/C2/T2 , NUC7i3BNH, Crucial MX300 2TB, LG LM 669S

    Linux is the best OS I have ever seen -- Albert Einstein

  • Hallo!

    dein Plugin verrichtet jetzt seit einigen Wochen stabil und unauffällig seinen Dienst, vielen Dank noch mal dafür.

    Freut mich!

    Quote

    Ein Feature würde ich mir allerdings noch wünschen: Eine Option, dass
    eine durch das Plugin beim Zurückspulen angelegte Sofortaufnahme beim
    Kanalwechsel von selbst gestoppt und gelöscht wird.
    Siehst du eine verträgliche Möglichkeit?

    Technisch wird die Aufnahme nicht anders behandelt, als wenn du ohne Plugin Pause drückst.
    Ob solche Aufnahmen automatisch gelöscht werden, lässt sich in den Optionen des VDR einstellen.
    Sollte also schon möglich sein.


    Ciao,
    Eike

  • Ob solche Aufnahmen automatisch gelöscht werden, lässt sich in den Optionen des VDR einstellen.
    Sollte also schon möglich sein.


    Ah, war mich nicht klar, dass man auch das schon VDR einstellen kann.


    Jetzt funktioniert es so wie ich mir das vorgestellt habe :-))

    KODI, tvh, arch x86_64, Octopus net 2 x Duoflex C/C2/T2 , NUC7i3BNH, Crucial MX300 2TB, LG LM 669S

    Linux is the best OS I have ever seen -- Albert Einstein

  • So,


    es gibt wieder etwas zum Ausprobieren.


    Mit der neuen Version soll das im ersten Posting beschriebene Problem gelöst sein, dass bei gut gefülltem großen Speicher
    das direkte Zurückspulen (Rewind Drücken während des live Fernsehens) schon mal 10 oder mehr Sekunden auf sich warten
    lassen konnte.
    Es wird jetzt ein kleines Wettrennen veranstaltet: 50 MB werden beim Drücken der Rewind-Taste gespeichert, ab dann wird
    zurückgespult, während gleichzeitig der Rest der Daten rückwärts auf die Platte gebracht wird (und natürlich das neu auflaufende
    aktuelle Video ebenfalls gespeichert wird). Bei den Festplatten, die ich hier so habe, geht das locker gut. Wer eine ziemlich
    langsame Platte hat, kann ja mal probieren, ob es geht (je größer die Rückspulgeschwindigkeit, desto größer natürlich die
    Möglichkeit, dass das Spulen das Speichern überholt) und berichten. Ein paar Informationen, wie es so läuft, werden ins
    Syslog geschrieben.


    Ich habe jetzt auch Puffergrößen bis 6 GB freigeschaltet. Ich hab aber keinen Rechner, bei dem ich das ausprobieren kann.
    In der Theorie sollte es auch mit 4 GB und mehr gehen, aber wie das so ist, wenn Code nicht getestet ist... Auch hier sind
    Ausprobierer eingeladen, wenn sie denn 8 GB oder mehr installiert haben. Besonders interessant wäre, wenn man den Puffer
    komplett volllaufen lässt. Mit 2 Stunden HD oder 'ner Nacht SD müsste man da auf der sicheren Seite sein.


    Bei wem das schnelle Rückspulen die Hardware überfordert, der kann es natürlich abschalten. Das gilt auch für die Speichergröße:
    Wenn der VDR durch einen zu großen Pufferspeicher zickig wird, einfach weniger Speicher einstellen.


    Benötigt wird Patch vdr-patch-0.6.0.b1.diff für den VDR aus dem ersten Post sowie das angehängte Plugin. Alte VDR-Patches von
    Permashift (0.5.x) dürfen nicht enthalten sein. Wenn keine Probleme auftreten, soll das Permashift 1.0 werden.


    Viel Spaß,
    Eike

  • @ Ein Eike,


    ich habe es mal kurz getestet


    Wenn ich im Setup 2 GB, oder mehr einstelle, kommt beim Stoppen folgende Meldung:


    Code
    1. Jun 14 16:33:23 [vdr] [5844] Permashift out of memory!
    2. Jun 14 16:33:23 [vdr] [5844] ERROR: Nicht genug Speicher für Permashift verfügbar!


    Ich denke mal, dass das bei verbauten 16GB RAM fast nicht sein kann, oder?

  • Hallo!


    Das mit den 2 GB konnte ich reproduzieren und reparieren, ich hab die Version im vorigen Posting ausgewechselt. Danke!


    Ciao,
    Eike

  • Hallo!

    also bei mir scheint es zu funktionieren:

    Juhu! Bin ich also doch nicht der einzige, bei dem es klappt. ;o)

    Die Aufnahme läuft in dem Moment ja schon auf Festplatte. Wenn man Stop drückt, könnte man die weiterlaufen lassen, bis umgeschaltet wird. Man ist dann ja im Live-Modus, bei erneutem Rewind müsste dann in eine Festplattenaufnahme gespult werden - also genau das, was das alte Permashift gemacht. Ich hab das nur derzeit ausgebaut, weil ich dachte, das braucht keiner mehr. :) Also, ja, ich glaube, das ginge, aber nicht umgehend.

    Quote

    Und nochwas:
    beim Einsatz einer TT6400 wird die
    automatische Hintergrundaufzeichnung nur bei Sendern, die sich schon im
    Transfermode befinden, gestartet. Bei unverschlüsselten Sendern, die ja
    ohne Transfermode angezeigt werden, startet die Aufzeichnung erst bei
    Drücken der Zurück-Taste.

    Wenn ich das richtig verstehe, verlässt bei so einer Karte das Video im Normalfall gar nicht die Video-Hardware, richtig?
    Auch hier: Ich hab solche Hardware nicht, ich kann da nicht rumprobieren. Ich hab aber im Code eine verdächtige Methode gefunden, "ForceTransferMode".
    Wenn du mutig sein willst, kannst du in permashift.c folgendes einbauen und es mal probieren (alles andere bis auf die eine zusätzliche Zeile bleibt unverändert):



    3PO wrote:

    Ich glaube, dass es bei mir in Verbindung mit dem SAT>IP_Plugin auftritt.


    Ich werde das mal bei Gelegenheit verfolgen....

    Danke schon mal im Voraus!


    Ciao,
    Eike

  • Also, ja, ich glaube, das ginge, aber nicht umgehend.

    Kein Stress, es ist ja nur ein Komfort-Feature.


    Wenn du mutig sein willst, kannst du in permashift.c folgendes einbauen und es mal probieren (alles andere bis auf die eine zusätzliche Zeile bleibt unverändert):

    Das probiere ich aus.


    Gruß
    Karl

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

    Git-Repo: gitlab.com/kamel5

  • Hallo.


    So, ich habe die Zeile mal eingebaut und jetzt ein wenig getestet und Timshift geht jetzt auch bei unverschlüsselten Sendern.
    Der Transfermode wird, wie erwartet, beim Umschalten aktiviert (gut zu sehen im LCARS-Skin).
    Nebeneffekte konnte ich bisher keine feststellen, ich werde das Ganze aber weiter beobachten.


    Gruß
    Karl

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

    Git-Repo: gitlab.com/kamel5

  • Hallo!

    So, ich habe die Zeile mal eingebaut und jetzt ein wenig getestet und Timshift geht jetzt auch bei unverschlüsselten Sendern.
    Der Transfermode wird, wie erwartet, beim Umschalten aktiviert (gut zu sehen im LCARS-Skin).
    Nebeneffekte konnte ich bisher keine feststellen, ich werde das Ganze aber weiter beobachten.

    Wenn ich das richtig verstehe, ist ForceTransferMode() für Nicht-Fullfeatured-Karten harmlos,
    und für FF-Karten ist es ja das, was man haben will, wenn man Permashift aktiviert.
    Ich würde das also fest einbauen (nicht optional). Danke für den Hinweis und das Ausprobieren!


    Ciao,
    Eike