[Announce] Permashift 1.0 - Permanenter Timeshift im RAM (AKA Livebuffer)

  • Hallo!


    Das im Vergleich zu den 0.5er-Versionen komplett umgeschriebene Permashift 1.0 ist fertig.


    Auf vielfachen Wunsch nimmt es nun nicht mehr vorsorglich auf Festplatte auf, sondern in den Hauptspeicher. So ist das Timeshift tatsächlich rund um die Uhr permanent (wenn man seinen VDR durchlaufen lässt) und die Festplatte wird nur noch in Anspruch genommen, wenn man den Timeshift auch tatsächlich nutzt.


    Ich habe außerdem die Rewind-Taste im Live-Modus gekapert, so dass man direkt zurückspulen kann. An dieser Stelle sollten sich die Nutzer des alten Permashift nicht wundern: Pause oder Rewind reagiert jetzt nicht mehr sofort, weil nun ja das Zwischengespeicherte erstmal auf die Festplatte gebracht werden muss. Das kann wahlweise komplett geschehen - was bei vollem Puffer 10 Sekunden und länger brauchen kann - oder on-the-fly. Letzteres ist voreingestellt.


    Auch Permashift 1.0 braucht einen VDR-Patch, und zwar einen anderen als Permashift 0.5. Der ist also vorher zu entfernen, oder man nimmt einen Vanilla-VDR. (Vorsicht bei den allerneusten Versionen, die haben anscheinend ein ungepatchtes Problem, siehe Frameratenerkennung ab Version 2.0.6).


    Danke an alle, die Feedback zu den Testversionen abgegeben haben! Die letzte Betaversion hatte noch einen Fehler bei Puffern mit mehr als 2 GB Inhalt, der jetzt behoben ist.


    Plugin und VDR-Patch habe ich angehängt.


    Die Homepage zum Plugin findet sich hier: http://ein-eike.de/vdr-plugin-permashift/


    Ciao,
    Eike

  • Hi Eike


    vielen Dank für die neue Version.


    Habe sie gerade in die MLD eingebaut :)



    Gruß
    MegaX

    Gruß MegaX


  • Die Version schaue ich mir auch gerne mal an. Vielen Dank dafür. :thumbsup:

    Dr. Brömme grübelt:
    Acht Wochen, nachdem man ihm beim Kölner Straßenkarneval einen Gratiskorn angeboten hatte,
    dämmert ihm langsam, dass er einem hinterlistigen Alaafisten aufgesessen ist.

  • Vielen Dank!


    VG, Nix

    • Server: Gigabyte H67-Board, i3-2120, 8GB Ram, 12 TB Video-Part., ca. 5000 Aufnahmen, 5x DVB-S (2x Cine S2, 1x USB), easyVDR 2.0 headless

    • WoZi-Client: Zotac ZBox ID86, Hama-MCE mit Harmony, keine Tuner, reiner Streaming-Client, easyVDR 2.0

    • zur Zeit wegen Pay-TV-Problematik leider nur E2-Infrastruktur

  • Nur eine Verständnisfrage: Kann man statt im RAM trotzdem noch auf Festplatte "shiften" ? ich würde dann meine System SSD-dafür nehmen, oder belastet das das System oder die SSD zu stark?


    Dumpfbacke

    VDR1: Asus q1900 Pro M, 2GB, Cine2 Dual DVB S2,Atric USB, yaVDR 0.6 stable, Gehäuse Modushop CD21

    VDR2: RaspBerry Pi2 mit MLD 5.3 als Client
    Ausgemustert: VDR: ASUS M2N-SLI,2GB, TT1600, Zotac GT210, yaVDR 0.4 im Mozart SX Gehäuse, Atric
    Ausgemustert: VDR: Activy 300 , FF Fusi 1.3 + , Celeron 1100, Gen2Vdr AE (momentan defekt)

    Ausgemustert: VDR: Lintec Senior Gehäuse,Technotrend 1.6, Siemens D1215 Mainboard mit Celeron 1000,Pabst Lüfter, EasyVDR 0.5, KäptnKoma Display 260x64,Schäfer Front (ausgemustert)

  • Hallo,


    das "Shiften"auf Festplatte ist nicht mehr drin (nur, wenn man das Geshiftete dann tatsächlich nutzt, kommt die Festplatte zum Zuge). Ich hab vermutet, dass das keiner mehr haben will, wenn er das RAM nehmen kann. :) Wenn es zu viele vermissen sollten, kann ich's wieder einbauen. Die SSD-Belastung ist tragbar, aber man nimmt halt schon diverse GB pro Tag auf, viele wollen das ihren Platten und erst recht ihren SSDs nicht zumuten. Die Auslastung für's restliche System sollte in beiden Fällen nicht riesig sein, ich hab sie mir aber ehrlich gesagt gar nicht angekuckt.


    Ciao,
    Eike

  • Hi Eike.
    Ich nutze einen Headless-Server und Clients ohne eigene DVB Karten rein über Streamdev.
    Bei dieser Konstellation wird es vermutlich nicht möglich sein das zu nutzen???


    Gruß Patrick

    Gruß Patrick


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


    vectra --- glasslike ---

  • Hallo!


    Es werden derzeit keine Client-Server-Szenarien unterstützt. Jedenfalls hab ich nichts in der Art eingebaut - es wird also nicht laufen.
    Du bist aber nicht der erste, der danach fragt (@MegaX: Das, was du machen wolltest, ist das auch StreamDev?). Wenn sich Leute finden,
    die solche Systeme und am besten auch Ideen haben, wie man das umsetzen kann, würde ich vorschlagen, dazu einen Thread aufzumachen.
    (Meines Erachtens will man in so einem System Permashift auf dem kräftigeren Rechner, dem Server, laufen lassen, oder?)


    Ciao,
    Eike

  • Warum auf dem Server laufen lassen?
    Wenn der Client nicht an ist, welches Programm soll denn der Server "shiften"? Müsste das Plugin nicht einfach auf dem Client installiert werden und es merkt sich dann die Daten, die über streamdev reinkommen? streamdev-client ist doch auch nur ein ganz normales Empfangsdevice.


    Lars.

  • Ich hätte noch vorausschicken sollen, dass ich von solchen System keine Ahnung habe. :)


    Also, ich stell mir auf Client-Seite tendenziell sowas wie einen Raspi vor - wenig Speicher, müsste unter Umständen auf SD-Karte speichern, sowas halt. Während der Server genug Speicher haben sollte. Und weiß der Server nicht eh, was er dem Client liefert, und dass das dann halt das zu shiftende wäre? Und ob überhaupt ein Client dranhängt? Aber wenn das ganze viel einfacher auf dem Client laufen könnte, wär mir das recht...!


    Ciao,
    Eike

  • Ich würde das Client-Server-Konzept aus diesem Feature komplett raushalten. Wenn der Client nicht stark genug für Timeshift ist, dann hat der halt Pech gehabt.
    Wenn der Client allerdings keine eigenen Timer verarbeitet, sondern nur remotetimers benutzt, wird's mit dem spontanen anlegen einer Aufnahme ja noch verzwickter. Ich will es dir nicht ausreden, aber freiwillig würde ich es an deiner Stelle nicht tun. :)


    Wie viel GB RAM soll denn so ein Server haben, wenn man drei bis vier Clients (nicht unüblich in Familienhaushalten) bedient? Und wenn er zu wenig hat, bringt die halbe Minute Timeshift ja auch kaum noch einen Vorteil...


    Es ist ja nun mal so, dass der vdr als solches nicht für einen Client/Server-Betrieb gedacht ist, sondern nur durch eine handvoll Plugins dafür zurecht "gefrickelt" wird.


    Lars.

  • Ich würde es nur auf dem Client installieren.
    Nur frag ich mich ob dann noch Sofortaufnahmen auf dem Server möglich sind, oder ob es sich mit dem Plugin nicht verträgt.

    YaVDR Server: Intel DH67BL B3 + Intel G1610/ 4x1GB Kingston RAM/64GB SSD/2TB HDD/CineS2 V6/Netzteil Be Quiet Pure Power BQT L7-300W 300Watt / YaVDR- 0.5.0a Headless
    Client 1: Intel DH67CF-B3/ 2x2GB Kingston/ 64 GB SSD/Zotac GeForce GT 640/Origenae M10/ Yavdr 0.5.0
    Client 2: Macbook xbmc
    Client 3: Andoid Tablet Ainol Novo 7 Elf XBMC
    Client 4: Raspberry PI: Openelec Gotham

  • "Sofortaufnahme auf den Server" ist ja eine Funktionalität eines anderen Plugins. Ob man das alles vernünftig unter einen Hut bekommt, ist eine Menge Aufwand.
    Wenn die Clients das Aufnahmeverzeichnis z.B. über NFS eingebunden haben und selbst Aufnahmen machen können (wenn auch nicht standardmäßig), dann könnte es mit timeshift auf dem Client evtl. funktionieren, weil dann kein anderes Plugin involviert ist. Und das Speichern des aktuellen Livesignals inkl. Timeshiftbuffer ist ja vermutlich auch eher eine Ausnahme, oder?


    Lars

  • schön das sich wieder was tut und auch alle langsam aus dem Sommer(urlaub) zurückkehren :mua


    Christian

    CKone: yavdr-ansible/18.04 LTS/2.4.1/kodi18 auf Intel DH67BL, Intel Celeron G540, 2x 2GB Kingston DDR3, Zotac GT630 1GB, S2-1600, Ocz Agility 3 60GB, LG GH24NS DVD, 15.6" Selbstbau TFT, Harmony 665, CIR Selbstbau - das Ganze im Silverstone SST-SG03B
    CKtwo: yavdr-ansible/18.04 LTS/2.4.1/kodi18 auf Intel DH67BL, Intel Celeron G1610, 2x 2GB Corsair DDR3, Zotac GT630 1GB, TT S2-1600, Ocz Vertex 2 50 GB, 92 Kanal Seduatmo, Harmony 665, atric USB
    CKthree: yavdr-ansible/22.04 LTS/2.6.1/kodi19.3 auf Intel NUC, Celeron J4005, UHD Graphics 600, 4GB Crucial DDR4, Ocz Vertex2 50 GB, Harmony 350

    PowerEdge: Ubuntu Server 16.04 LTS / VDR 2.4.1 auf Dell PowerEdge T20, Xeon E3-1225 v3, 16GB ECC DDR3, 2x Cine S2 V6 mit Duoflex, Samsung 840 EVO 120GB, 3x WD White WD80EZAZ 8TB in SW Raid5



  • HI ich hab da eine Frage zu RAM/HDD/SSD. Wie viel RAM kann man denn für Livebuffer so nehmen, wenn man einen embedded VDR hat, der 4GB RAM besitzt? Eine Aufnahme von ZDF-HD hat bei mir ca. 2GB, bei 30Minuten Laufzeit. Wenn das möglich wäre, ohne dass das System träge wird, dann würde mir das reichen. Wenn allerdigns nur 15min (1GB) möglich sind, dann wäre mir die Option für Livepuffer auf HDD auch lieber.


    Moderne SSDs schaffen ja teilweise 1Petabyte an geschriebenen Daten. Das sind bei durchschnittlich 4h Fernsehen/Tage (32GB bei HD) 32768 Tage. Das sind fast 10 Jahre. Selbst 5 Jahre würden mir reichen ;)


    Und zum Thema Server-Client habe ich auch noch eine Bemerkung. Bei mir ist das Aufnahmeverzeichnis vom Server per NFS am Client eingebunden. Der Client hat also kein lokales Aufnahmeverzeichnis. Wenn Permashift die Daten durchs Netzwerk rödelt, ist das bestimmt auch nicht optimal. Könnte man da etwas schaffen, dass ein Verzeichnis auf dem lokalen Client als Pluginoption eingestellt wird?

  • HI ich hab da eine Frage zu RAM/HDD/SSD. Wie viel RAM kann man denn für Livebuffer so nehmen, wenn man einen embedded VDR hat, der 4GB RAM besitzt? Eine Aufnahme von ZDF-HD hat bei mir ca. 2GB, bei 30Minuten Laufzeit. Wenn das möglich wäre, ohne dass das System träge wird, dann würde mir das reichen. Wenn allerdigns nur 15min (1GB) möglich sind, dann wäre mir die Option für Livepuffer auf HDD auch lieber.


    Je nachdem was noch so auf dem System läuft könntest du theoretisch bis 3GB für den LiveBuffer reservieren.


    Und zum Thema Server-Client habe ich auch noch eine Bemerkung. Bei mir ist das Aufnahmeverzeichnis vom Server per NFS am Client eingebunden. Der Client hat also kein lokales Aufnahmeverzeichnis. Wenn Permashift die Daten durchs Netzwerk rödelt, ist das bestimmt auch nicht optimal. Könnte man da etwas schaffen, dass ein Verzeichnis auf dem lokalen Client als Pluginoption eingestellt wird?


    Bei mir das gleiche.


    Frage an Eike.
    Wieso muss denn überhaupt vom RAM auf die Platte geschrieben werden bevor der LiveBuffer benutzt werden kann? Würde es nicht reichen wenn dies nur dann geschieht, wenn eine Aufnahme rückwirkend aus den LiveBuffer Daten gebildet/gestartet werden soll?



    Gruss
    tec

  • Hallo!

    HI ich hab da eine Frage zu RAM/HDD/SSD. Wie viel RAM kann man denn für Livebuffer so nehmen, wenn man einen embedded VDR hat, der 4GB RAM besitzt? Eine Aufnahme von ZDF-HD hat bei mir ca. 2GB, bei 30Minuten Laufzeit. Wenn das möglich wäre, ohne dass das System träge wird, dann würde mir das reichen. Wenn allerdigns nur 15min (1GB) möglich sind, dann wäre mir die Option für Livepuffer auf HDD auch lieber.

    Schau dir mal die Ausgabe von free -h an. Bei mir sieht das (auf dem Desktop) so aus:


    total used free shared buffers cached
    Mem: 7,8G 3,3G 4,4G 0B 121M 1,0G
    -/+ buffers/cache: 2,2G 5,6G
    Swap: 7,9G 0B 7,9G


    Der Eintrag in der ersten Zeile unter free (hier 4,4 GB) ist komplett ungenutzt. Das kannst du Permashift geben.
    Das in der zweiten Zeile unter free (hier 5,6 GB) könnte wohl freigeschaufelt werden, würde aber dann andere Dinge verdrängen.
    Wenn du da außer dem VDR nichts laufen hast, sollten 2 GB locker gehen.

    Quote

    Und zum Thema Server-Client habe ich auch noch eine Bemerkung. Bei mir
    ist das Aufnahmeverzeichnis vom Server per NFS am Client eingebunden.
    Der Client hat also kein lokales Aufnahmeverzeichnis. Wenn Permashift
    die Daten durchs Netzwerk rödelt, ist das bestimmt auch nicht optimal.
    Könnte man da etwas schaffen, dass ein Verzeichnis auf dem lokalen
    Client als Pluginoption eingestellt wird?

    Also, eine Option für ein Verzeichnis, in dem das Plugin seine Aufnahme ggf. speichert, sollte nicht soo schwierig sein.


    Ciao,
    Eike


    PS: Kann man hier etwas vorformatiert reinpasten?

  • Hallo!

    Wieso muss denn überhaupt vom RAM auf die Platte geschrieben werden bevor der LiveBuffer benutzt werden kann? Würde es nicht reichen wenn dies nur dann geschieht, wenn eine Aufnahme rückwirkend aus den LiveBuffer Daten gebildet/gestartet werden soll?

    Weil sich noch keiner angeboten hat, den Player umzuschreiben! :o)


    Ist technisch natürlich denkbar. Man könnte die "Vergangenheit" im Speicher lassen und aus diesem heraus abspielen und die Gegenwart auf Festplatte aufnehmen. Da war tatsächlich eine der Möglichkeiten, über die ich nachgedacht habe, aber es war so schon ziemlich komplex und ich denke, dass es damit noch komplexer geworden wäre.


    Ciao,
    Eike

  • Also bei meiner Frage bezüglich Streamdev dachte ich wirklich wie Eike vermutet an einen Raspi als Client. Ein Timeshift auf dieser "Möhre" ist natürlich unmöglich. Aber der Einwand mit der Größe des Arbeitsspeichers des Servers ist auch gerechtfertigt. Soweit hab ich garnicht gedacht das sich die Timeschift-Aufnahmen addieren. Und bei mir hängen mittlerweile schon drei Clients dran, tendenz steigend.


    Also müsste als erstes der Arbeitsspeicher "ausreichend" sein, das ist die erste vorraussetzung. Ich bin zwar kein Programmierer, aber ich stelle mir das jetzt (für euch :D ) nicht so schwer vor den Server erkennen zu lassen was der Client guckt, und diesen Sender zwischenzuspeichern. Problematisch wird dann wohl eher das Zurückspulen. Da müsste der gespeicherte Stream dann übers Netzwerk an den Client übermittelt werden. Das wird dann wohl seine Zeit dauern. Ob das dann Spaß macht wage ich zu bezweifeln. Und was wenn zwei Clients den Selben Kanal sehen, dann müsste der Server den Stream an einen Client schicken, aber für den zweiten weiter aufnehmen.


    Ich denke, nach genauerem Nachdenken soll das Permashift wohl doch eher ein "Standalone" Luxus bleiben auf den "Clients" aktuell noch verzichten sollten ;-)


    Aber trotzdem find ich es eine Grandiose Leistung von dir Eike :tup


    Gruß Patrick

    Gruß Patrick


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


    vectra --- glasslike ---

  • Also, eine Option für ein Verzeichnis, in dem das Plugin seine Aufnahme ggf. speichert, sollte nicht soo schwierig sein.


    Da klingt doch schon mal gut :) Wenn das soweit ist und ich Zeit habe (vlt September) kann ich dir Rückmeldung geben, wie es mit einem PC-Client und Streamdev aussieht.