VDR aus Repo durch selbst-kompilierte Version ersetzen?

  • Hallo zusammen,


    mein erster Beitrag :)


    Ich hab bisher den vdr (2.2.0) aus dem ppa:yavdr/stable-vdr auf Ubuntu installiert. Nun möchte ich mich - im ZUge eines Updates auf vdr 2.3.1 - daran wagen, den vdr und Plugins selbst zu kompilieren.


    Was mir dabei nich nicht ganz klar ist:
    Muss ich die alte Version vorher mit apt-get remove oder sogar apt-get purge (vollständig) entfernen, oder kann ich mit make install da drüber installieren (hab die Pfade in Make.config so eingestellt, dass das vdr binary im selben Pfad installiert wird: /usr/bin)?
    Wie kann ich ggfs. verhindern, dass durch ein apt-get update/upgrade meine selbst-kompilierte Version wieder überschrieben wird?


    Und sind die Konfig Files aus vdr 2.2.0 auch mit vdr 2.3.1 weiter nutzbar?


    Danke vorab


    Grumpy

  • Die einfachste Variante ist, sich bei Launchpad ein eigenes PPA anzulegen, sich mit Debian-Paketbau auseinander zu setzen und dort dann die eigenen Pakete abzulegen. Dieses PPA kann man dann per Pinning priorisieren und dann wird bei dist-upgrade der eigene vdr installiert und auch nicht mehr überschrieben.


    Was es u.a. beim Debian-vdr-Paket zu beachten gibt:
    - Am besten die Make.config aus dem alten Paket übernehmen, damit auch wirklich alles passt.
    - Nach einer Änderung der ABI (im Prinzip nach Änderung eines Headers) muss die Datei debian/abi-version angepasst werden.
    - Solltest du Patches anpassen (definitiv notwendig beim Wechsel zu 2.3.1), müssen diese mit "debian/rules accept-patches" dem Paket bekannt gemacht werden (in meinem git für das yavdr-vdr-Paket gibt es auch einen branch für 2.3.1). [1]
    - Nach Aktualisieren des vdr-Pakets mit neuer ABI-Version müssen alle Plugins neu gebaut werden (die bekommen eine virtuelle Abhängigkeit zur abi-version, so dass man nicht aus Versehen die falschen Plugins installieren kann).
    - und sicherlich noch ein paar andere Dinge, die mir spontan nicht einfallen. :)


    Oder:
    Alle vdr-Pakete entfernen und direkt aus dem Source kompilieren und per "make install" installieren, dann aber besser nach /usr/local. Das lässt sich später dann leichter wieder entfernen, solltest du doch wieder auf fertige Pakete wechseln wollen.


    Die conf-Dateien sind zwischen den Versionen kompatibel.


    Überlege dir vorher, welche Plugins du mindestens brauchst. Es gibt für einige viel genutzte immer noch keine vollständige Portierung auf vdr 2.3.1 (z.B. epgsearch, live). Wenn du Spaß am Programmieren hast und schon immer mal in die vdr-Coding-Welt eintauchen wolltest, ist das sicherlich eine Möglichkeit, aber rechne mit ordentlichen Schwierigkeiten. Zwischen den Versionen ist ein ordentlicher Schritt, und ich erwarte weitere bei den folgenden Dev-Versionen.


    Lars
    [1] https://github.com/flensrocker/vdr-debian/tree/vdr-2.3.x
    Dieser branch ist aber noch nicht ganz fertig auf systemd umgestellt.

  • Hi,


    ich baue seit nun 14 Jahren meine VDR Versionen immer selbst (scheiße ist das lang her...). Und dabei nutze ich die althergebrachte Methode unter /usr/local/src ein Verzeichnis mit der jeweiligen Version anzulegen und dort auch zu bauen. Die VDR binaries bleiben ebenfalls dort und werden nicht per make install über das system verteilt. Ein symlink VDR zeigt dann auf die jeweils aktive Version. Will ich dann eine neue Version testen dann ändere ich nur den symlink.


    Dieses Vorgehen setzt aber wie auch die Paketmethode ausreichende Kenntnis in Linux Administration und zumindest grundlegende Kenntnisse wie man binaries baut bzw das make file anpasst voraus. Eine gute Anleitung gibt es hier von Hubertus.


    Dieses Vorgehen hat sich bei mir bewährt, da eine Liste der installierten Debian Pakete des laufenden Systems, eine Kopie des /etc und /usr/local/src ausreichen um mit minimalem Aufwand die Installation umzuziehen (hab ich in den Jahren bestimmt drei oder vier mal so gemacht wenn ein neuer Server her musste). So sind auch meine Raspi Clients alle aus der gleichen Installation gecloned die auf dem VDR Server läuft. Überall sind alle Sourcen vorhanden, das war vor allem wichtig als noch reichlich patches notwendig waren.


    Gerade wenn 2.3 testen gewollt ist würde ich für die produktive Nutzung noch eine 2.2 er Version parallel halten, wie oben schon gesagt sind noch nicht alle Plugins bereit für 2.3. Wenn dann im Herbst evtl. Klaus wieder mehr Zeit hat und neue Versionen kommen ist die parallel Installation auch hilfreich um zwischen verschiedenen Varianten hin und her zu switchen und nachher, dem häuslichen Frieden willen immer ein lauffähiges System zu behalten, wenn man kein dediziertes Testsystem hat.


    bye
    Sven


    Link: Richtig fragen

  • Vielen Dank, mini73 und SvenS, schon mal für Eure schnellen und hilfreichen Tipps. Die idee mit dem eigenen PPA klingt spannend, bisher hatte ich schon ein Pinning auf yavdr, damit ich immer von dort aus meine Updates ziehen konnte.


    Das Kompilieren scheint bereits zu funktionieren, zumindest konnte ich vdr 2.3.1. und einige Plugins erfolgreich erzeugen. epgsearch aus dem entsprechenden tree für vdr-2.3.1 war auch darunter Ich hoffe, dass es dann auch tut. Dass live noch nicht mit vdr 2.3.1 läuft ist echt ärgerlich.


    Leider erwartet das vdr/vniserver addon für Kodi Krypton nun offenbar vdr 2.3.1 um alle Funktionen anbieten zu können. Daher erscheint, der Vorschlag von SvenS auch interessant, um mehrere Versionen parallel halten zu können.


    Auf jeden Fall ist mir die Vorgehensweise nun klarer. Ich werde dann wohl am Wochenende mal die nächsten Schritte angehen und mich hier zurück melden.

  • Leider erwartet das vdr/vniserver addon für Kodi Krypton nun offenbar vdr 2.3.1 um alle Funktionen anbieten zu können. Daher erscheint, der Vorschlag von SvenS auch interessant, um mehrere Versionen parallel halten zu können.


    Du kannst ja auch mehrere PPAs anlegen und darin verschiedene Versionen halten.


    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

  • So denn, nachdem ich mich am Wochenende etwas mehr mit dem Buildsystem auseinander gesetzt habe, läuft nun VDR 2.3.1 auf meinem System, zusammen mit Kodi 17 beta 1 als Front-End. Leider werden in der Kodi Beta noch nicht alle Funktionen sauber unterstützt, aber es sieht zumindest schon mal "verheißungsvoll" aus.


    Beim Kompilieren benötigte ich noch libsystemd-dev, um mit Schalter SDNOTIFY=1 kompilieren zu können. Ohne SDNOTIFY wurde VDR immer wieder beendet, was aber an der "type=notify" EInstellung in meinem vdr.service Datei lag. Überhaupt bin ich so vorgegangen, dass ich mir zunächst VDR 2.2.0 aus dem Default Ubuntu PPA installiert und eingerichtet habe. Dort waren auch die benötigten zusätzlichen Files, wie z.B. für die recording-hooks, enthalten, die ich für mein Setup nutze.


    Nach dem Kompilieren habe ich /usr/bin/vdr und svdrp als symbolischen Link auf meine selbstkompilierten Binaries zeigen lassen und ähnlich hab ich es für das Plugin-Verzeichnis unter /usr/lib/vdr gemacht. Damit konte ich über das Umsetzen von drei symlinks und Neustart ggfs. schnell wieder auf die Vorgänger-Version zurückwechseln. War aber nicht nötig, da es damit nach Anpassung der vdr.service bzw. nach Kompilieren mit SDNOTIFY=1 rund lief.


    In Kodi gewinnt man mit VDR 2.3.1. nun die Möglichkeit EPG basierte TImer einzurichten. Damit wird epgsearch wohl dann auch nicht mehr benötigt.


    Statt des live Plugins habe ich mir vdradmin-am installiert, was mit SVDRP arbeitet. Ist zwar schon etwas betagt, aber scheint auch mit VDR 2.3.1 anstandslos zu arbeiten, sofern man kein streamdev benötigt. Per http remote auf die EPG Daten zuzugreifen und einen Timer zu erstellen, hat auf jeden Fall einwandfrei funktioniert.


    Danke für Eure Tipps und Unterstützung.

  • Du solltest dir das Paket auf "hold" setzen (auch die Plugin-Pakete), damit nicht aus Versehen ein Update installiert wird und deine Dateien überschrieben werden.


    Lars