Hi,
mich würde interessieren ob das Permashift-Plugin von Ein Eike dämnächst in den Unstable VDR einfließt.
Gruß Santos
Hi,
mich würde interessieren ob das Permashift-Plugin von Ein Eike dämnächst in den Unstable VDR einfließt.
Gruß Santos
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
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
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.
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
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
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.
ZitatIch 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.
ZitatAlles anzeigenWen 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
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
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
Soweit ich weiss ist das vdr-dev was momentan in stable ist schon vorbereitet für neue Makefiles.
Ah, Missverständnis. Das mit dem alten Makefile hat sich jetzt nicht auf yaVDR bezogen.
Ich geh mal davon aus, dass ihr im Entwicklungsbereich schon umgestiegen seid.
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.
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!