Kann man bei yaVDR 0.7 den VDR und die Plugins auch selbst lokal bauen?
Gibt es dazu schon ein Tutorial?
Kann man bei yaVDR 0.7 den VDR und die Plugins auch selbst lokal bauen?
Gibt es dazu schon ein Tutorial?
Hallo,
mir hat da ein Post von User Lars/mini73 damals sehr weiter geholfen:
Patch für Live-Plugin: Offene Knoten im Aufnahmen-Baum persistent machen
Grusz!
Kann man bei yaVDR 0.7 den VDR und die Plugins auch selbst lokal bauen?
Ja, das hat ein ganz normales Ubuntu als Unterbau und jeder hat die Freiheit, sich das System so hinzubiegen, wie er es haben will.
Wenn es nur darum geht ein paar Plugins an der Paketverwaltung vorbei selber zu bauen, dann reicht es für Plugins mit einem modernen Makefile das Paket vdr-dev für die VDR-Header, die pkg-config Konfiguration usw. und die sonstigen für den Bau nötigen Abhängigkeiten zu installieren und dann make gefolgt von make install aufzurufen. Damit der VDR das Plugin lädt, muss dann ggf. noch eine Konfigurationsdatei im ARGSDIR (/etc/vdr/conf.d/) angelegt werden, wo man dem Plugin auch Argumente mitgeben kann (vgl. https://www.yavdr.org/document…on.html#vdr-configuration)
Die Hintergründe zum Paketbau für Ubuntu/Debian werden in https://www.debian.org/doc/manuals/maint-guide/index.de.html recht ausfühlich beschrieben, für Details gibt es dann noch das Debian Policy Manual
Wenn man an der ABI des VDR durch Patches herumbastelt, muss man im Zweifelsfall alle Plugins neu bauen und da hilft es, wenn man die abi-Versionsnummer im VDR-Paket hochsetzt, damit die Paketverwaltung meckert, wenn man da noch Rester herumliegen hat.
Grundsätzlich tut sich IMHO leichter, wenn man Debian-Pakete baut, die man entweder in eine eine eigene Paketquelle packt oder das gleich über ein PPA auf Launchpad macht - das yavdr-ansible Playbook erwartet, dass man gewisse Pakete über die Paketverwaltung installieren kann - aber das lässt sich ja nach Belieben anpassen, was das macht und es zwingt einen auch niemand das nach der Erstkonfiguration erneut laufen zu lassen, wenn man am Playbook bzw. der Paketverwaltung vorbei arbeiten will.
Zum Anwenden der Patches auf die Sourcen für ein Debian-Paket nutze ich quilt, das man mit der in https://wiki.debian.org/UsingQuilt#Encapsulated gezeigten Konfigurationsdatei dazu bringt sich im Verzeichnis für ein Debian-Quellpaket richtig zu verhalten - ich hatte mal einen kleinen Screencast gemacht, der das anhand des Zapcockpit-Patches demonstriert, wie man so einen Patch in den VDR einpflegt:
Wenn man Pakete aus einem PPA erneut in einem PPA bauen lassen will, kann das yalptool (ist für yaVDR schon paketiert) dabei helfen, damit man nicht alles von Hand herunterladen, die Versionsnummer erhöhen und wieder hochladen lassen muss, sondern das für die gewünschten Pakete automatisieren kann.
Abhängig davon, was man vorhat ist das ein weites Feld, das man schlecht in einem Post erschlagen kann - wenn du da Fragen hast, helfe ich gerne weiter.
ZitatWie viele Programmierer braucht man, um eine Glühbirne zu wechseln?
..also vielleicht solltest du nach deiner Frage noch einmal deine Signatur überarbeiten. *g*
uff
Da muss ich mich umfangreich damit beschäftigen... Glaube nicht, dass ich das mal eben so hin bekomme....
Ich würde gerne auch den VDR selbst patchen und bauen.
Ich würde gerne auch den VDR selbst patchen und bauen.
Alles machbar, du musst dir nur überlegen, ob du dabei an der Paketverwaltung vorbei arbeiten möchtest oder nicht - im einfachsten Fall kompilierst du den VDR und die Plugins und installierst sie in ein anderes Verzeichnis und passt den Pfad für den VDR in der Systemd-Unit vdr.service an. Für das Frontend-Skript (das zum Umschalten zwischen VDR, KODI und anderen Anwendungen genutzt wird) braucht es das dbus2vdr-Plugin, ansonsten hast du da freie Auswahl.
..also vielleicht solltest du nach deiner Frage noch einmal deine Signatur überarbeiten. *g*
Sorry. Dachte nicht, dass das jemanden stört... Hab's gegen ein Zitat ersetzt
In dem Video sieht das noch relativ einfach aus. Aber da wird ja noch nichts gebaut. Und zum hochladen muss ich doch erst mal Zugriff auf das PPA haben?
Beim VDR fehlt mir nur der menuselection-Patch. Den habe ich schon seit ich den VDR habe (1.6) drin und der hat auch immer wunderbar funktioniert. Der zweite Punkt wäre das SkinFlatPlus, das im PPA noch die Version 0.6 hat. Vermutlich wird hier noch die obsolete URL verwendet. In dem GIT aus meiner Signatur ist die Version, die ich verwende, und die auch mit Graphicsmagic und IM6 und IM7 läuft. Auch das Wetter wird bei der Version nun von OpenWeathermap geholt.
Beim VDR fehlt mir nur der menuselection-Patch
Der wäre im VDR aus diesem PPA dabei: https://launchpad.net/~seahawk…/ubuntu/vdr-2.4.6-patches - IIRC macht der die Darstellung einiger Plugins mit dem Skindesigner (z.B. systeminfo-Plugin) kaputt.
Zum Austauschen des VDR-PPAs am besten zuerst das neue PPA hinzufügen und dann die Pakete aus dem alten mittels ppa-purge abräumen, dann werden die installierten Pakete ersetzt:
sudo apt install ppa-purge
sudo add-apt-repository ppa:seahawk1986-hotmail/vdr-2.4.6-patches
sudo ppa-purge ppa:yavdr/experimental-vdr
Vermutlich wird hier noch die obsolete URL verwendet. In dem GIT aus meiner Signatur ist die Version, die ich verwende, und die auch mit Graphicsmagic und IM6 und IM7 läuft. Auch das Wetter wird bei der Version nun von OpenWeathermap geholt.
Ich finde die vom VDR abweichende Tuner-Nummerierung (der VDR zählt wie Linux beginnend bei 0) etwas verwirrend, aber ich kann das gerne in die PPAs bringen.
IIRC macht der die Darstellung einiger Plugins mit dem Skindesigner (z.B. systeminfo-Plugin) kaputt.
Nicht mehr, Systeminfo 0.1.5 funktioniert zumindest unter arch damit im Bezug auf die Darstellung der Belegung.
Ich finde die vom VDR abweichende Tuner-Nummerierung (der VDR zählt wie Linux beginnend bei 0) etwas verwirrend,
Ich finde es genau umgekehrt verwirrend bei 0 zu beginnen. Ich sehe das alles aus "Anwender"-Sicht.
Ich habe das geändert. weil es in Skindesigner (https://projects.vdr-developer…e18f226a865e77f47613c30ac) auch geändert wurde und ich das einfach "gut" fand.
Wenn ich wüsste wie, würde ich das einfach einstellbar machen... Damit könnte sich jeder das so drehen wie er oder sie das gerne möchte.
PS: wenn es geht, dann bitte das Logo im Makefile auf vdrlogo_yavdr setzen:
# define vdrlogo for menu topbar
# if not defined vdrlogo_default will be used
# define here or use make VDRLOGO=\"vdrlogo_default\"
# available logos are
# vdrlogo_debian
# vdrlogo_default
# vdrlogo_easyvdr
# vdrlogo_gen2vdr
# vdrlogo_shine
# vdrlogo_xubuntu
# vdrlogo_xubuntu2
# vdrlogo_yavdr
SKINFLATPLUS_VDRLOGO = vdrlogo_default
Alles anzeigen
Edit:
Das PPA werde ich nächste Woche tauschen. Vielen Dank für den Hinweis und die Anleitung!
Hmm, du hättest gerne in logfiles vom VDR die Bezeichnung 'device 0', die du in der GUI als 'device 1' siehst?
Ich finde es genau umgekehrt verwirrend bei 0 zu beginnen. Ich sehe das alles aus "Anwender"-Sicht.
Hmm, du hättest gerne in logfiles vom VDR die Bezeichnung 'device 0', die du in der GUI als 'device 1' siehst?
Das ist genau das Problem - die reinen Anwender schauen erfahrungsgemäß nicht in die Logs und stehen wie der Ochs vorm Berg, wenn es darum geht den VDR davon abzuhalten nicht angeschlossene Tuner zu nutzen ...
https://imgs.xkcd.com/comics/donald_knuth.png[Blockierte Grafik: https://imgs.xkcd.com/comics/donald_knuth.png]
Ich habe das geändert. weil es in Skindesigner (https://projects.vdr-developer…e18f226a865e77f47613c30ac) auch geändert wurde und ich das einfach "gut" fand.
Kein Stress , das Obige betrifft nicht die Log-Ausgaben!
Es ging bei dieser Änderung nur darum, die Anzeige des Skins, z.B. im Hauptmenü, mit einer 1 für das erste Device zu beginnen. LCARS macht das übrigens genau so.
Klar, man hätte das auch im jeweiligen Skin machen können, allerdings hätte man dazu wieder jeden einzelnen Skin anfassen müssen und wo das hinführt wissen wir ja...
Grüße
kamel5
Ich mach das die Tage konfigurierbar! Ich denke das ist machbar.
Mir ist schon klar, dass intern mit 0 begonnen wird.
Aber man sagt ja auch nicht mein 0. Auto fahre ich und das 1. meine Frau...
Das ist genau das Problem - die reinen Anwender schauen erfahrungsgemäß nicht in die Logs und stehen wie der Ochs vorm Berg, wenn es darum geht den VDR davon abzuhalten nicht angeschlossene Tuner zu nutzen ...
Wäre das nicht etwas, das man in den VDR einbauen könnte? Also "Device x angeschlossen an: Nicht verwenden"
Wäre das sinnvoll?
PS: Hier wird übrigens "Benutzerfreundlich" gezählt!
PPS: Device müsste auch übersetzt werden durch Empfänger oder ähnliches.
Hi,
Das Problem des nicht Findens von Tunerkabeln wäre ja mit einem dynamite-Plugin ähnlichen Weg am Besten zu lösen und dann auch ein Schlafen legen möglich.
Mfg Stefan
PS: wenn es geht, dann bitte das Logo im Makefile auf vdrlogo_yavdr setzen:
Ich lasse die Pakete gerade in den PPAs bauen.
Ich habe mal was gebastelt. Im Zweig "displaytuner" kann man es testen.
https://github.com/MegaV0lt/vd…plus/commits/displaytuner
Ich habe aber noch keine Gelegenheit gehabt es zu testen. Bin erst ab Montag wieder in der nähe meines VDR...
Ich gebe hier bescheid, wenn ich das geprüft habe---
Danke, ich lasse das Plugin gleich im PPA bauen. Es gibt jetzt auch ein PPA für den VDR 2.4.7 mit dem menuselection Patch: https://launchpad.net/~seahawk…/ubuntu/vdr-2.4.7-patches
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!