Da muß ich direkt mal schauen ob meiner den ich vor ein paar Monaten ausgeschlachtet habe, ebenfalls nur wegen der Batterie nicht mehr funktioniert.
Posts by Frodo
-
-
-
Ich würde Inverto nehmen, super Preis-/Leistungsverhältnis.
Ausserdem würde ich gleich Richtung Unicable/Jess wechseln. Je nach Gerät kann man noch einige Legacy LNB Anschlüsse nutzen.
Einziges Problem um mehr als eine Satteliten Position zu nutzen muß man die LNBs auf Wide LNB umstellen und die sind aktuell nicht vernünftig einmessbar (nur Pegel), d.h. die Empfehlung ist mit Quad LNB ausrichten und dann wechseln. Schön dabei man braucht nur noch 4 Kabel anstelle von vorher 8.
-
Das Paket wurde nicht gebaut da eine Abhängigkeit nicht erfüllt wurde:
Quoteamd64 build of vdr-plugin-skinenigmang 0.1.3+git20180501-20-995b108-2yavdr0~bionic in ubuntu bionic RELEASE
- experimental-vdr
- amd64 build of vdr-plugin-skinenigman...
created 15 hours ago
Build status
[Blocked Image: https://launchpad.net/@@/build-depwait] Dependency wait on lcy01-amd64-018 Retry this build
- Missing build dependencies: libfreetype-dev
- Started 15 hours ago
- Finished 15 hours ago (took 2 minutes, 10.3 seconds)
- buildlog (8.3 KiB)
-
Die letzten 3 mal ging es und natürlich gehen noch andere Wege. Die alle zu erklären würde aber die meisten überfordern.
Das genannte Skript ist im übrigen auch auf meinen Mist gewachsen, nur funktioniert auch das nur solange die Sourcen minimal verändert wurden.
Mir ging es erst einmal darum, dass man einen Einstieg zum selbst bauen bekommt.
Spätestens wenn man mehr damit herumspielt wird man sich ein eigenes Repository im Launchpad erstellen und so weiter.
-
Sorry, wenn es etwas länger dauert. Ich habe meine VDR Installationen nur noch zum Spaß und nutze seit geraumer Zeit VU+ Receiver in meiner Familie.
Deshalb merke ich Probleme erst spät.
Egal die neue Version baut gerade.
Es ist aber sicherlich von Vorteil zu wissen wie man ein Paket baut.
Als erstes möchte ich auf folgen Beitrag verweisen der schoneinmal für die Grundvorraussetungen sorgt:
[gelöst] [0.4] VDR selbst übersetzen (für Patch von kls)?
Der ist schon etwas älter war aber mein Einstieg und funktioniert noch heute.
Als erstes muß man seinem Ubuntu beibringen das es auch Source Pakete aus den Repositories bekommt.
Das geht auf zwei Wege entweder man geht in die entsprechende Datei unter /etc/apt/source.list bzw. /etc/apt/source.list.d/... und aktiviert bzw. fügt die Zeilen deb-src hinzu oder im Fall von Bionic und der Ansible Installation führt man die folgenden Befehle aus:
Code# Sourcen von meinem Paket z.B. vdr-epg-daemon sudo add-apt-repository ppa:frodo-vdr/experimental-main-yavdr -s -y # Sourcen vom Ansible vdr-epg-daemon sudo add-apt-repository ppa:yavdr/experimental-main -s -y # Sourcen vom VDR und dessen Plugins (Für vdr-epg-daemon wird das nicht benötigt aber für Plugins) sudo add-apt-repository ppa:yavdr/experimental-vdr -s -y
Das -s fügt die Sourcen in das Verzeichnis /etc/apt/source.list.d/ hinzu.
Nun brauchen wir eine Build Umgebung:
Code# Nötige Pakete für den Paketbau installieren sudo apt-get install ubuntu-dev-tools build-essential # Bau-Abhängigkeiten des Pakets vdr installieren (Für Plugins) sudo apt-get build-dep vdr
Nun haben wir die Vorraussetzungen geschaffen um uns der Beschaffung der Sourcen zu widmen.
Jetzt benötigen wir ein Verzeichnis in den wir die Sourcen installieren möchten, da das schnell unübersichtlich wird sollte man sich dieses im Homeverzeichnids erstellen.
Jetzt holen wir uns die passenden Sourcen zum einen das alte mit dem tvm Patch und das neue von der ansible Installation.
Dazu schauen wir ersteinmal nach welche Versionen es gibt
Die Ausgabe des Befehls sieht wie folgt aus:
Code
Display Morevdr-epg-daemon: Installiert: (keine) Installationskandidat: 1.1.157-0yavdr0~bionic Versionstabelle: 1.1.157-1frodo0~bionic 500 500 http://ppa.launchpad.net/frodo-vdr/experimental-vdr-yavdr/ubuntu bionic/main amd64 Packages 500 http://ppa.launchpad.net/frodo-vdr/experimental-vdr-yavdr/ubuntu bionic/main i386 Packages 1.1.157-0yavdr0~bionic 1000 1000 http://ppa.launchpad.net/yavdr/experimental-main/ubuntu bionic/main amd64 Packages 1000 http://ppa.launchpad.net/yavdr/experimental-main/ubuntu bionic/main i386 Packages 1.1.155-1frodo0~bionic 1000 1000 http://ppa.launchpad.net/frodo-vdr/experimental-main-yavdr/ubuntu bionic/main amd64 Packages 1000 http://ppa.launchpad.net/frodo-vdr/experimental-main-yavdr/ubuntu bionic/main i386 Packages 1.1.134+git20180216-3-b2fb1c3-0yavdr0~bionic 1000 1000 http://ppa.launchpad.net/yavdr/experimental-main/ubuntu bionic/main amd64 Packages 1000 http://ppa.launchpad.net/yavdr/experimental-main/ubuntu bionic/main i386 Packages
In diesem Fall müssten wir nichts tun ausser dafür sorgen das vdr-epg-daemon aus meinem PPA installiert wird und nicht aus dem von YaVDR. Im Beispiel ist das PPA von YaVDR priorisiert auf 1000 während mein PPS nur 500 hat, das nur am Rande.
Für das weitere Vorgehen holen wir uns nun die Sourcen für 1.1.157-0yavdr0~bionic und 1.1.155-1frodo0~bionic.
Code# Das zu modifizierende Paket holen apt-get source vdr-epg-daemon=1.1.157-0yavdr0~bionic # Das Paket mit den Passenden Patches holen apt-get source vdr-epg-daemon=1.1.155-1frodo0~bionic
Wenn ihr nun in eurem build Verzeichnis schaut habt ihr zwei unterschiedliche Versionen von vdr-epg-daemon.
Die neuere wollen wir nun so modifizieren das sie die Eigenschaften (tvm, tvsp) der alten bekommt, hierzu kopieren wir aus dem debian/patches Ordner das plugin.patch von der alten auf die neue Version.
Jetzt müssen wir noch dafür sorgen das der Patch auch verwendet wird das müssen wir in der neuen Version die Datei debian/patches/series um den Dateinamen des Patches erweitern.
Die Datei sollte dann so aussehen:
Nun können wir uns ans Paketbauen machen. Um nachher auch noch zu erkennen ob das Paket vom Repository oder von euch kommt empfiehlt es sich die debian/changelog Datei anzupassen. Dazu wechsekln wir in das Source Verzeichnis und führen dch -i aus.
Das Kommando fügt automatisch einen neuen Eintrag hinzu, den passen wir entsprechend an
Code
Display Morevdr-epg-daemon (1.1.157-1yavdr0~bionic) bionic; urgency=medium * meine Anpassungen -- root <root@mail.com> Sat, 22 Feb 2020 10:57:58 +0100 vdr-epg-daemon (1.1.157-0yavdr0~bionic) bionic; urgency=medium * new upstream version -- Alexander Grothe <seahawk1986@gmx.de> Mon, 17 Feb 2020 19:36:01 +0100 vdr-epg-daemon (1.1.156-0yavdr0~bionic) bionic; urgency=medium ...
Wichtig ist das die Syntax der ersten Zeile der letzten entspricht, durch das hochzählen der Zahl vor yavdr wird verhindert das das Paket gleich wieder überschrieben wird bei einem Update.
Nun könnten wir mit dem Paket bauen loslegen allerdings fehlen uns hierzu noch diverse dev-Pakete.
Die installieren wir einfach nach entweder mit trial and Error
Codedpkg-buildpackage -tc -uc -us dpkg-source: Information: plugins.patch wird angewandt dpkg-checkbuilddeps: Fehler: Nicht erfüllte Bauabhängigkeiten: dh-exec dh-systemd libarchive-dev libcurl4-openssl-dev libimlib2-dev libjansson-dev libjpeg-dev libmariadb-dev-compat (>= 10.3.13) | libmariadbclient-dev libmicrohttpd-dev libsystemd-dev libxml2-dev libxslt1-dev python-dev python2.7-dev rhino uuid-dev dpkg-buildpackage: Warnung: Bauabhängigkeiten/-konflikte nicht erfüllt; Abbruch dpkg-buildpackage: Warnung: (Verwenden Sie -d, um sich darüber hinwegzusetzen.)
oder eleganter
Jetzt können wir unser Paket erstellen
Jetzt nur noch in das Verzeichnis darüber wechseln und die Lorbeeren ernten
Codeepgd_1.1.157-1yavdr0~bionic_amd64.deb epgd-dbg_1.1.157-1yavdr0~bionic_amd64.deb epghttpd_1.1.157-1yavdr0~bionic_amd64.deb epghttpd-dbg_1.1.157-1yavdr0~bionic_amd64.deb mariadb-plugin-epglv_1.1.157-1yavdr0~bionic_amd64.deb
Dort liegen nun die Pakete welche mit dpkg -i [paketname].deb installiert werden können.
Ich hoffe das hilft dem ein oder anderen zukünftig das Problem selbst zu lösen.
-
Ich habe mein Paket gerade aktualisiert.
-
Ich habe meine epgd Packete aktualisiert - ich habe heute erst bemerkt, dass das EPG nicht mehr aktualisiert wurde.
Ein droppen der Datenbank ist nicht nötig.
Ich bin mir nicht einmal sicher ob man das VDR Plugin aktualisieren muß, bei mir ging es auch mit dem alten.
-
-
Meine zwei YaVDR Ansible VDRs starten wie folgt:
1. VDR i5-2500T (4 DVB Tuner)
CodeStartup finished in 3.150s (kernel) + 19.596s (userspace) = 22.747s graphical.target reached after 11.399s in userspace
Code
Display More# systemd-analyze blame 11.355s apt-daily.service 6.771s systemd-networkd-wait-online.service 2.292s vdr.service 1.152s dev-mapper-vdr4\x2d\x2dvg\x2droot.device 1.128s systemd-resolved.service 1.005s x@vt7.service 1.000s postfix@-.service 880ms udisks2.service 877ms lircd-setup.service 787ms apparmor.service 787ms networkd-dispatcher.service 709ms lxd-containers.service 653ms systemd-timesyncd.service 638ms systemd-journal-flush.service 616ms apt-daily-upgrade.service 549ms accounts-daemon.service 521ms motd-news.service 487ms snapd.service 456ms systemd-logind.service 449ms rsyslog.service 412ms grub-common.service 367ms ebtables.service 365ms wpa_supplicant.service 335ms user@666.service 311ms srv-ppa.mount 279ms srv-vdr-video.mount 275ms console-setup.service 275ms srv-audio.mount 233ms nfs-server.service 204ms autofs.service 195ms srv-video.mount 184ms munin-node.service 184ms srv-picture.mount 184ms polkit.service 178ms networking.service 174ms nmbd.service 168ms systemd-journald.service 160ms nfs-idmapd.service 146ms lvm2-monitor.service 146ms proc-fs-nfsd.mount 144ms keyboard-setup.service 139ms smbd.service 129ms alsa-restore.service 127ms apport.service 125ms lm-sensors.service 114ms nfs-config.service 110ms xymon-client.service 90ms systemd-modules-load.service 89ms systemd-sysctl.service 84ms run-rpc_pipefs.mount 81ms plymouth-quit-wait.service 81ms plymouth-quit.service 76ms systemd-tmpfiles-setup-dev.service 75ms systemd-udev-trigger.service 72ms dev-mqueue.mount 71ms ssh.service 71ms rpcbind.service 68ms snapd.seeded.service 68ms srv-video-Secure.mount 66ms nfs-mountd.service 65ms xinetd.service 65ms nfs-blkmap.service 60ms lvm2-pvscan@8:1.service 60ms systemd-remount-fs.service 60ms setvtrgb.service 59ms systemd-update-utmp.service 59ms dev-hugepages.mount 59ms hddtemp.service 58ms sys-kernel-debug.mount 54ms systemd-random-seed.service 51ms systemd-udevd.service 48ms srv-vdr-video-Bea_und_Ingo.mount 47ms user@0.service 44ms srv-video-vsecure.mount 42ms systemd-networkd.service 40ms kmod-static-nodes.service 39ms ufw.service 27ms dev-mapper-vdr4\x2d\x2dvg\x2dswap_1.swap 18ms systemd-tmpfiles-setup.service 14ms plymouth-start.service 13ms plymouth-read-write.service 13ms blk-availability.service 13ms systemd-tmpfiles-clean.service 10ms ureadahead-stop.service 10ms systemd-update-utmp-runlevel.service 7ms systemd-user-sessions.service 6ms nvidia-persistenced.service 4ms sys-kernel-config.mount 3ms sys-fs-fuse-connections.mount 3ms yavdr-xorg.service 2ms postfix.service 2ms lxd.socket 1ms snapd.socket
2. VDR i3-6100 (nur SAT-IP) UEFI
CodeStartup finished in 9.566s (firmware) + 1.888s (loader) + 2.829s (kernel) + 17.592s (userspace) = 31.876s graphical.target reached after 11.135s in userspace
Code
Display More# systemd-analyze blame 9.602s apt-daily.service 5.318s systemd-networkd-wait-online.service 1.773s vdr.service 1.418s keyboard-setup.service 1.363s x@vt7.service 1.211s postfix@-.service 1.089s dev-mapper-vdr1\x2d\x2dvg\x2droot.device 1.089s networkd-dispatcher.service 958ms lircd-setup.service 845ms snapd.service 818ms systemd-journal-flush.service 719ms motd-news.service 578ms udisks2.service 566ms grub-common.service 564ms accounts-daemon.service 557ms systemd-logind.service 539ms lxd-containers.service 534ms apt-daily-upgrade.service 410ms systemd-resolved.service 399ms networking.service 375ms munin-node.service 373ms srv-vdr-video.mount 368ms srv-audio.mount 347ms rsyslog.service 346ms lm-sensors.service 320ms smbd.service 303ms srv-video.mount 289ms srv-ppa.mount 281ms apparmor.service 278ms systemd-timesyncd.service 273ms srv-picture.mount 261ms systemd-rfkill.service 244ms nfs-server.service 244ms user@666.service 238ms autofs.service 214ms systemd-networkd.service 209ms proc-fs-nfsd.mount 204ms apport.service 203ms nfs-mountd.service 195ms wpa_supplicant.service 193ms polkit.service 189ms run-rpc_pipefs.mount 182ms lvm2-monitor.service 179ms systemd-modules-load.service 179ms systemd-journald.service 154ms systemd-tmpfiles-setup-dev.service 141ms nmbd.service 134ms alsa-restore.service 108ms xinetd.service 104ms systemd-random-seed.service 103ms sys-kernel-debug.mount 101ms dev-hugepages.mount 100ms dev-mqueue.mount 96ms systemd-remount-fs.service 96ms snapd.seeded.service 85ms xymon-client.service 78ms systemd-sysctl.service 75ms srv-vdr-video-Bea_und_Ingo.mount 71ms srv-video-vsecure.mount 69ms systemd-udevd.service
-
Ich würde mich freuen wenn der VDR ein Ausgabe Plugin hätte, das problemlos Audio und Video syncron in FullHD und UHD ausgeben könnte.
Mit den aktuellen Plugins ist das ein ständiges herumgebastel mit ALSA, Pulseaudio oder den diversen Grafikkarten Herstellern.
Was auch sehr schön wäre wenn man mit dem AppleTV wie zur VU+ direkt auf den VDR zugreifen könnte.
Da all das nicht geht habe auch ich angefangen einen Teil meiner VDR Installationen gegen einen VU+ Receiver auszutauschen. Dort gibt es mit den zuvor genannten Wünschen keine Probleme. Auch ein Kodi Plugin gibt es, welches alles kann was man braucht.
Dennoch finde ich den VDR als DVB Receiver genial, ein besseres Werkzeug zum scheiden von Aufnahmen gibt es nicht, auch die Bedienung ist Kinderleicht, das ist bei einer VU+ leider nicht der Fall.
-
Es geht nicht um Letsencrypt es geht um ein abgelaufenes Zertifikat das mal wieder nicht rechtzeitig getauscht wurde.
-
Eigentlich ist es egal woher das Zertikat kommt, nur einspielen muß man es rechtzeitig. Hier hilft einem Letsencrypt recht gut.
Man kann sich aber auch einen Termin in den Kalender schreiben...
-
Ich nutze gitea und bin hiermit vollauf zufrieden.
gitlab benötig zu viele Ressourcen.
-
Das habe ich gesehen.
Es gibt aktuell noch ein Probleme mit den Imon Displays
1. Für yavdr-ansible/roles/autoinstall-imonvfd/tasks/main.yml habe ich einen Pull request gestellt weil die Zeile imon_vfd_device: '{{ "imon_0044" if "15c2:0044" in usb else "imon_0036" }}'
im git noch falsch ist.
Das andere hat sich gerade gelöst die udev Regeln für die imonlcd Devices 0038 und ffdc waren verschwunden. Nachdem ich das Paket vdr-plugin-imonlcd nochmals installiert habe
apt install --reinstall vdr-plugin-imonlcd
sind sie wieder da.
-
Bei den Änderungen zu den imon Geräten sind irgendwo die udev Regeln für das imonlcd Display verloren gegangen.
-
Bei mir ist das Problem mit der zweiten Fernbedienung auch behoben. Beide funktionieren wie es sein soll.
-
Mit meinem 0036 Device habe ich es getestet, es funktioniert
Das 0044 kann ich erst heute Abend prüfen, da ist aber immer noch eine 0 zuviel in dem String imon_00044 der sollte doch sicherlich wie folgt aussehen: imon_0044
-
Ohne das ich es probiert habe in der Zeile ist was falsch:
imon_vfd_device: '{{ "imon_00044" if "15c2:0044" in usb else "imon_0044" }}'
Die 0 von imon_00044 dürfte zu viel sein und für das 0036 USB Device wird die Variable gar nicht gesetzt.
Sollte das nicht wie folgt aussehen?
imon_vfd_device: '{{ "imon_0044" if "15c2:0044" in usb else "imon_0036" }}'
-
Ich hatte noch keine Zeit das zu testen. Ich schau mir das heute Abend an.