Es hat seine Gründe warum hier bewusst auf das absolute Minimum gesetzt wurde.
Kein Thema, es hat aber auch seine Gründe warum ich gerne einen gepatchden VDR nutze und in dem Fall von der Vorgabe abweiche und somit nicht mehr für den Standard um was es hier geht kompatibel bin.
Vielleicht findet sich noch jemand, dem der Weg taugt, ist ja alles noch möglich 
Seit solchen Aussagen, die immer wieder mal im Umlauf waren, baue ich selbst:
Für meinen eigenen Bedarf baue ich via "repo-make" mein eigenes Repository. Dies ist auch weiterhin der empfohlene Weg um ein Repository für den eigenen Bedarf zu erstellen.
In Zukunft wird sich "VDR-Entwickler-Patch für Arch bereitstellen" von meiner Seite auf "ins VDR-GIT einchecken" beschränken.
Über das VCS-Paket kann sich das dann jeder bei Bedarf selber neu kompilieren.
Das PKGBUILD für "vdr" dagegen ist ab jetzt immer das aktuellste stabile Release. Über kleinere Patches kann man ggf. noch reden (nur Patches von Klaus! Eigentlich würde ich am liebsten auch MainMenuHooks loswerden. Weitere "nichtoffizielle" Patches aber auf garkeinen Fall!), aber dort werden keine Patches landen die irgendwelche Header verändern und somit ein Plugin-Neukompilieren erfordern.
was dem eigenen Einsatzzweck als reines Backend mit Kodi als Frontend geschuldet ist, sieht man ja das kein einziges Ausgabeplugin in der obigen Liste ist.
Ich nutze den VDR immer noch als VDR mit Bildausgabe sowie allem was dazu gehört mit speziellen Erweiterungen und einem gepatchten VDR sowie Plugins, diese baue ich zudem nicht als TAG Versionen sondern per COMMIT und das mitunter bei Änderungen mehrmals die Woche. Das ist immer noch annähernd der Weg wo damals dem geneigten Arch User mitgegeben wurde (siehe Zitate), deshalb versteh ich die aktuelle "Aufregung" dazu nicht da es meiner Meinung nach ein "hausgemachtes" Problem ist.
Trotzdem Danke was bisher für arch im Bezug auf den VDR gemacht wurde.
Das finde ich genau richtig so. Ist ein separater Entwicklungsbranch, und der hat noch keine Versionsnummer oder Tag (mehr s.u.).
War nur ein Gedanke, in der osdteletext.c steht nämlich dazu: *VERSION = "2.1.0.beta.2";. Liegt wohl an der Strategie die sich mir auch noch nicht so ganz erschließt
Natürlich steht die Weiterentwicklung an erster Stelle, dafür ebenfalls ein Danke von mir 
Wenn man das Repo von markad mal nimmt als Beispiel, da ist der Master Zweig und wenn erweitert wird der Zweig V02 der wo entwickelt wird, wenn es passt kommt es nach Master rüber gemerged.
Hat jetzt nichts mit Zoo oder so zu tun, ist schlicht, einfach, funktionell. Kann auch sein dass du es nicht so machen willst sondern einen eigenen Weg hast, dann eben diesen
So, mein 2.1.0 branch ist nun im offiziellen "milestone-2.1.0" Branch reinmigriert
Naja, meldet sich wieder mit 2.0.2_38_gb2f5e02 als Version weil kein Tag vorhanden ist. Nach welcher Grundlage werden die großen Sprünge in kurzer Zeit der jeweiligen Versionen hier eigentlich geändert?
Soweit weg kannst Du ja nicht sein, von einer Funktionsweise im Umgang mit dem GIT damit das Pushen und Taggen passt. Wenn es wo klemmt wird dir sicher hier geholfen und eine Frage ist ebenfalls kein Beinbruch
Du müsstest auch nicht die Version als "beta" umschreiben, es reicht doch zu jedem Tag (also neues Release) die Version anzupassen. Die Stände dazwischen sind "Entwicklungsstände", das machen doch alle anderen auch so. In der obigen Zeile wäre es dann der 38igste Commit nach dem Release 2.0.2
Welche Distri nutzt du zum entwickeln, testen ?
Es gibt ja genug Plugins wo man aus einem Repo sowohl die Tags und die Commits raus bauen kann, wie man will. Bei diesem Plugin hier ist halt das "gewurschtel" zwischen den beiden "Adressen" sehr groß wie bereits beschrieben
Release erstellt
Die beiden GIT Stände sind aber nicht per Commit auf den Stand 2.0.2.
Hab gerade beide GIT Stände gebaut vom Plugin aber keinen Tag....
Bei SKY gab es bisher auch keine Meldungen oder HD Plus, die sind ja auch verschlüsselt.
192.168.0.0/24 # any host on the local net
192.168.0.0/24 # any host on the local net
Mach mal 192.168.188.0/24 jeweils daraus
außer ihr packt mir die ganze Entwicklungsumgebung/Toolchain zum Download !
Das Alles selbst aufzusetzen und zu konfigurieren übersteigt meine Fähigkeiten ....
Aber genau das bringt überhaupt nix, dann frägst wie das und das zu bauen ist. Da hilft nur, hinsetzen und machen, haben andere nicht anders gemacht und wenn man das von Grund auf selbst umsetzt dann kommen irgendwann die Ergebnisse.
Das geht nicht weil du über die Senderliste keine Aktion generieren kannst zum abspielen wie es das hbbtv Plugin macht welches das File dem Browser übergibt.
Warum lässt Du das nicht einfach per cron.daily laufen? Das mache ich schon X-Jahre so bei jedem Linux System was ich nutze, noch nie ein Problem damit gehabt und ob ich den letzten Stand bei runterfahren oder den nach dem Start, wenn cron-daily ausgelöst wird ist im Grunde total egal und wenn sich was gravierend ändert kann man den Job "händisch" laufen lassen.
Wenn man aus https://github.com/pbiering/vdr-plugin-osdteletext baut bekommt man über git describe --tags | sed 's/-/_/g;s/v//' die Version 0.9.7_132_g1f96b51.
Kannst Du da bitte die Tags entsprechend setzen, tut man sich leichter beim Paketbau - Danke!
Könnte ein Plugin sein das in die setup.conf nicht schreiben kann beim beenden.
Geht eigentlich um den aktuellen Stand, nicht um Tags bzw. Releases. Ich baue gern den Momentan zur Verfügung stehenden Stand, darum die Frage wo dieser zu finden ist.
es wäre nett wenn Du ein GIT Repo nutzen würdest zur Entwicklung oder eben beide aktuell halten auf gleichen Stand. Kürzlich war das Repo in deinem Account das Aktuelle gegenüber dem Repo in vdr-project, jetzt ist es wieder anders herum. Aus welchem soll man nun die Pakete bauen in Zukunft um den jeweils aktuellen Stand zu bekommen?
Zu 2, Filesystemcheck, einfach nach fsck mal googeln.
mpv zum Testen
Das wurde nicht beim Plugin hier geändert sondern im Frontend: https://github.com/jojo61/vdr-…15a770fa1e3fea2a5d2db04a5
Das ist dann bei deinem System anders wie beim normalen VDR.
