Permashift in VDR 1.7.40 ???

  • Hi,
    mich würde interessieren ob das Permashift-Plugin von Ein Eike dämnächst in den Unstable VDR einfließt.


    Gruß Santos

    VDR1
    - Yavdr 0.5 - Zotac D2700 Atom 2X2.13GHZ - GT520 Onboard- 4GB Speicher - 32GB CF- Technotrend TT S2-4100 - Alphacool Display - YaUsbIr 2- Technotrend Fernbedienung - Gehäse Plexiglas (Stable)


    VDR2
    - Yavdr 0.5- AsRock 77 mit i3-3220T 2X2.8GHZ- 4GB Speicher- GT 440 Passiv - 64GB SSD 2,5"- DigitalDevices Cine S2- LG Bluray - 10" Monitor - YaUsbIr 2 - T Home Fernbedienung - uMouse Cardreader - Gehäse Bitfenix Prodigy M (Unstable)

  • Hi,
    mich würde interessieren ob das Permashift-Plugin von Ein Eike dämnächst in den Unstable VDR einfließt.


    Wenn ich KLS richtig verstanden habe, dann wird das ganz bestimmt nicht passieren. Er wird ganz sicher nicht größere Änderungen unmittelbar vor dem bevorstehenden Release von 2.0.0 machen.


    Gerald


    HP Proliant MicroServer Gen8, Xeon E3-1230, 12 GB RAM, 3xWD red 2TB im RAID 5, 2xSundtek MediaTV Home DVB-C/T, L4M TWIN-C/T, Ubuntu Server 14.04.1, Plex Media Server
    Samsung UE55H6470

  • Hi gda,
    Ich meine ja nicht ins Core, sondern als Plugin.
    Habe wegen der Aussage in diesem Thread gefragt.
    Bis VDR 2.0 da ist.


    [Permashift] Tester für (fast) permanenten Timeshift gesucht


    Gruß. Santos

    VDR1
    - Yavdr 0.5 - Zotac D2700 Atom 2X2.13GHZ - GT520 Onboard- 4GB Speicher - 32GB CF- Technotrend TT S2-4100 - Alphacool Display - YaUsbIr 2- Technotrend Fernbedienung - Gehäse Plexiglas (Stable)


    VDR2
    - Yavdr 0.5- AsRock 77 mit i3-3220T 2X2.8GHZ- 4GB Speicher- GT 440 Passiv - 64GB SSD 2,5"- DigitalDevices Cine S2- LG Bluray - 10" Monitor - YaUsbIr 2 - T Home Fernbedienung - uMouse Cardreader - Gehäse Bitfenix Prodigy M (Unstable)

  • Moin!


    Noch sind wir mit Finetuning am neuen vdr-Paket beschäftigt, da war noch keine Zeit für neue Patches.
    Ich kann noch nicht sagen, ob ich ihn einbaue - oder ob wir auf das von Klaus angekündigte Feature nach vdr 2.0 warten. Das entscheidet die Menge der verfügbaren Freizeit.


    Lars.

  • Santos


    Das glaube ich nicht, da unstable-vdr ein Bereich für das yaVDR Team und nicht für Nutzer ist, dort bereiten wir uns aktuell auf 2.0 vor und keinen 1.7.40 für für yaVDR Nutzer.


    Wenn ihr das unbedingt nutzen wollt, Euer Problem, es werden keinerlei Fragen, Wünsche oder Feedback von ausserhalb des yaVDR Teams beachtet, dazu pflegen wir stable-vdr/testing-vdr. Klar wegen dem bevorstehenden 2.0 kommt es zu "interessanten" Konstellation.


    Und ich bin offen, umso mehr Fragen zu unstable-vdr kommen umso mehr neige ich zu Team-internen Copperhead'ismus.


    Heißt aber nicht das dieses Plugin irgendwann bei uns in testing-vdr auftaucht, wenn 2.0 verfügbar ist. Vorraussetzung, beeinträchtigt in keinster Weise den Betrieb für Nutzer die den Quatsch nicht benötigen und ist komplett abschaltbar. Sollte permashift in Upstream VDR Development irgendwann auftauchen, wird das wieder erst Team-intern in unstable-vdr eruiert und findet bestimmt seinen Weg zu Euch ...


    Regards
    fnu

    HowTo: APT pinning

    3 Mal editiert, zuletzt von fnu ()

  • Vor dem Plugin steht der Patch den der VDR dazu benötigt (der lässt sich prinzipiell auf den VDR 1.7.40 ohne rejects anwenden).
    Und vor dem Patch sind für uns erst mal die ganzen anderen Besonderheiten, die die neuen VDR-Pakete so mit sich bringen wichtiger. IMHO reichen da erst mal die bisherigen etablierten Patches um zu sehen wo es aktuell noch Probleme gibt, bevor man neue potentielle Fehlerquellen einbaut.
    Was dem Plugin noch fehlt ist ein Makefile, das dem neuen System für VDR > 1.7.36 entspricht, damit man es ohne unnötige Turnereien in ein Paket packen kann.


    Ich hab es mal kurz mit dem VDR 1.7.40 ausprobiert (unter Arch Linux, nicht unter yaVDR) und es scheint zu tun was es soll. Nachteil sind prinzipbedingt etwas höhere Umschaltzeiten und die ständige Festplattenaktivität (ist ja eine Sofortaufnahme + ggf. markad-Prozess, falls das Plugin aktiv ist). Das Plugin scheint das Abschalten des Timeshifts zu erlauben.


    Wen es wirklich interessiert, der kann sich ja ein eigenes PPA erstellen, den entsprechend gepatchten VDR aus unstable-VDR dort hochladen und die Plugins neu dagegen bauen lassen (einfach aus unstable-vdr rüberkopieren). Ist wirklich nicht schwer (benötigt halt etwas Zeit und Einsatz) und die permashift-Interessierten können endlich mal zeigen dass sie genauso wie Ein Eike mehr können als das Klischee zu erfüllen, das sich ihnen unterstellt habe :versteck

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Hallo!


    Ich würd mich natürlich auch freuen, wenn das Plugin früher oder später in Distributionen einfließt...

    Vor dem Plugin steht der Patch den der VDR dazu benötigt (der lässt sich prinzipiell auf den VDR 1.7.40 ohne rejects anwenden).
    Und vor dem Patch sind für uns erst mal die ganzen anderen Besonderheiten, die die neuen VDR-Pakete so mit sich bringen wichtiger. IMHO reichen da erst mal die bisherigen etablierten Patches um zu sehen wo es aktuell noch Probleme gibt, bevor man neue potentielle Fehlerquellen einbaut.
    Was dem Plugin noch fehlt ist ein Makefile, das dem neuen System für VDR > 1.7.36 entspricht, damit man es ohne unnötige Turnereien in ein Paket packen kann.

    Die Makefile-Anpassung wollte ich demnächst machen. Spätestens, wenn die neue stabile VDR-Version da ist.
    Hängt auch bei immer ein bisschen von der zur Verfügung stehenden Freizeit ab, ist ja klar.

    Zitat

    Ich hab es mal kurz mit dem VDR 1.7.40 ausprobiert (unter Arch Linux,
    nicht unter yaVDR) und es scheint zu tun was es soll. Nachteil ist
    prinzipbedingt die ständige Festplattenaktivität (ist ja eine
    Sofortaufnahme + ggf. markad-Prozess, falls das Plugin aktiv ist). Das
    Plugin scheint das Abschalten des Timeshifts zu erlauben.

    Weil ich wusste, dass das Feature umstritten ist, hab ich wirklich penibel darauf geachtet, dass niemand gestört wird, der es nicht haben will.

    Ach, du warst das. Danke für den Motivationsschub damals. ;)


    Ciao,
    Eike

  • Die Makefile-Anpassung wollte ich demnächst machen. Spätestens, wenn die neue stabile VDR-Version da ist.
    Hängt auch bei immer ein bisschen von der zur Verfügung stehenden Freizeit ab, ist ja klar.


    Ist ja keine unüberwindbare Hürde (mit dem eleganten vdr-dev Paket unter yaVDR noch weniger ein Problem als unter Arch) und sowieso alles Hobby :)

    Ach, du warst das. Danke für den Motivationsschub damals.


    Trotzreaktionen zu provozieren ist wie man sieht eine sehr effektive Methode :thumbup:

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Hallo!


    Ich hab mir gestern mal die 1.7.40 runtergeladen und per newplugin ein neues Makefile gemacht.
    Gewundert hat mich, dass die Versionsnummer nicht mehr im so-File auftaucht, der VDR aber weiterhin
    nach einem .so mit Nummer sucht. Ich hab mir mit einem Symlink geholfen - passt das so?


    Das neue Makefile hat mich auch genötigt, eine Pot-Datei anzulegen und mich um die Übersetzungs-
    makros zu kümmern. Ein bisschen verwirrend an der Stelle ist, dass bei den beiliegenden Plugins die
    "DESCRIPTION" zum Teil mit trNOOP umschlossen ist, zum Teil nicht. Aber es macht ja anscheinend
    inhaltlich keinen Unterschied.


    Ich vermute mal, es gibt keine Möglichkeit, das neue Makefile-System zu verwenden, und trotzdem
    in alten VDR-Versionen out of the box zu bauen? Dann würd ich wohl das alte als Makefile.old oder so
    danebenlegen, für die, die noch eine ältere VDR-Version verwenden.


    Ciao,
    Eike

  • Moin!


    Ich vermute mal, es gibt keine Möglichkeit, das neue Makefile-System zu verwenden, und trotzdem
    in alten VDR-Versionen out of the box zu bauen? Dann würd ich wohl das alte als Makefile.old oder so
    danebenlegen, für die, die noch eine ältere VDR-Version verwenden.


    Doch, die gibt es. Der alte vdr muss nur eine passende /usr/lib/pkgconfig/vdr.pc bereitstellen, dann bauen Plugins mit neuen Makefiles wunderbar mit einem alten vdr.
    So geschehen mit unseren vdr-Paketen in testing (1.7.33) und stable (1.7.27).


    Die vdr.pc ist bloß distributionsabhängig wegen der Pfade. Bei meinen Plugins hab ich einfach das alte Makefile in Makefile-1.7.33 umbenannt. Wenn jemand einen alten vdr einsetzt, muss er eben aktiv werden. :)


    Lars.

Jetzt mitmachen!

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