Das würde mich auch interessieren, wie verhält es sich denn generell mit BlueTooth Fernbedienungen ? Werden die Über Lirc eingebunden oder wie bekommt man Kodi dazu mit der FB zu kommunizieren ?
Eine FunkFB ohne Airmouse Funktion ist schon fast eine Seltenheit.
Oder gibt es eine Möglichkeit die Airmouse Funktion OS seitig ( debian 9/10 ) zu deaktivieren und somit die Auswahl der Möglichkeiten an FB zu vergrößern ?
Zum Kompilieren von Plugins benötigst du die Header-Dateien (und pkgbuild-Informationen) der installierten VDR-Version. Die stecken bei den Debian-Paketen seit jeher im Paket vdr-dev, das bei deinem Paketbauversuch auch als fehlend angemeckert wurde.
Um die Bau-Abhängigkeiten eines Paketes aufzulösen, kannst du entweder einen Blick in debian/control des Quellpakets werfen oder mk-build-deps -i (aus dem devscripts Paket) aufrufen (vgl. https://manpages.debian.org/st…s/mk-build-deps.1.en.html ), das dir ein Paket baut, das die benötigten Build-Dependencies als Abhängigkeiten hat und das Paket zusammen mit diesen installiert.
Danke für die Info: mk-build-deps -i <packetname>. Die Installation von vdr-dev als Sourcecodebasis habe ich erfolgreich vorgenommen ( und die der anderen Kompilertools )
Dann solltest du vermeiden die Versionen des VDR und von Plugins durcheinander zu werfen. Wenn epgsearch die Version 2.4.0 hat und der VDR die Version 2.4.1 stört das nicht, solange die API des VDR auf Quellcodeebene noch passt.
Das ist mir seit dem letzten Umsteig von Debian 8 auf 9 klar geworden. Darum wunderte ich mich ja über die Angabe des vdr-plugin-epgsearch Quellcodes aus den o.g. Quellen auf Basis des VDR 2.4.0 und dann wurde vdr-dev 2.4.1 statt 2.4.0 verlangt. 2.4.1 ist aber nicht in den Repos verfügbar und bevor ich mein System wieder mit zig Quellen überlade dachte ich mir es muss auch mit vdr-dev 2.4.0 gehen ( was es mit dem Quellcode link von wolfi-m auch tat. ).
Die Suche nach dem Passenden Quellcode war nicht so einfach.
Das virtuelle Paket vdr-abi-<VERSION> ist an das VDR-Paket gebunden (wird über debian/abi-version im Quellpaket für den VDR und https://salsa.debian.org/vdr-t…b/master/debian/rules#L38 f. festgelegt) und Pakete für Plugins, die dagegen gebaut wurden, werden auf exakt diese ABI-Version festgelegt, weil alles andere nicht sicher binärkompatibel wäre. Das hat den (beabsichtigten) Effekt, dass man nicht wahllos Plugins aus anderen Paketquellen installieren kann, sondern sie im Zweifelsfall neu aus den Sourcen bauen muss.
Intern hängt die ABI aber vor allem von der VDR-Version und den zusätzlich auf den VDR-Quellcode angewendeten Patches ab, daher sollte man die ABI-Version immer ändern, wenn man das VDR-Paket mit ABI-brechenden Änderungen neu baut.
Darum suchte ich ja eine gepachte vdr-plugin-epgsearch Version die kompatibel zum vdr-dev 2.4.0 ist. Und daran scheiterte es dann. Die VDR ABI zu ändern habe ich seit dem letzten update gelernt möglichst zu vermeiden, da in Folge dessen noch mehr Fehler auftraten.
Ich kann dir nur empfehlen endlich mal die verfügbare Debian-Dokumentation zum Paketbau zu lesen und mit dem Wissen nachzuvollziehen, was in den Quellpaketen für den VDR und der Plugins passiert, statt sich jahrelang immer wieder zu wundern, warum es nicht funktioniert, wenn man versucht Probleme mit blindem Aktionismus zu lösen statt die Problemstellung mal ordentlich durchzuarbeiten und zu verstehen wie das ganze funktioniert.
Nimm es mir nicht übel aber das habe ich vor knapp 3 Jahren schon einmal gemacht und es klappte auch alles wunderbar - Nur leider ist mein Hirn kein USB Stick oder Kristallspeicher und verliert daher die ein oder andere Information in Abhängigkeit des Faktors Zeit. Analytisch bin vorgegangen, einfach nach dem "Try and Error" Prinzip vorzugehen endet beim Kompilieren meist in Chaos.
In dem Sinn Danke für Infos.
EDIT : Ein Test Ergab gerade Folgendes Szenario :
EPG Konflikte werden genau 1 mal im Live Plugin angezeigt, aktualisiert man den Browser nach der Anzeige wird kein Konflikt mehr angezeigt - Timerkonflikt besteht allerdings weiterhin.
Klickt man im Live Plugin auf den Timerkonflikt wird dieser nicht angezeigt. DAS fenster und der Header der Liste wird angezeigt, aber nicht der Timerkonflikt selbst.
Solange der Rest stabil läuft kann ich damit leben.
Display MoreHallo,
da musst du das aktuelle Paket mit "dget -xu" holen.
Gruss
Wolfgang
wie bist du an den Link gekommen ? Unter "https://launchpad.net/~yavdr" fand ich nichts ?!
funktioniert :
Ich habe den Überblick verloren und stehe hier grad total aufm Schlauch. Ich konnte anhand der Logfiles des VDR das vdr-plugin-epgsearch als Segmentaion fault verursachendes Plugin Identifizieren. Aber jetzt geht der Mist wieder los ( Debian 10 / vdr 2.4.0 aus main Repos )
Nachgelesen = o.g. Plugin hat im Programmcode eine Fehler in einem Loop => selbst kompilieren
Dann bin ich nach o.g. Anweisungen vorgegangen ( dget -xu https://launchpad.net/~yavdr/+…9ba796-0yavdr0~bionic.dsc ) => Datei Offline
Dann habe ich auf GIT Hub nach e-Tobis code gesucht, in der Repoliste steht eien gepachte version drin, aber ich diese nicht herunterladen.
Als auch das nicht erfolgreich war habe ich nach einer Debian 10 Quelle für das EPG search Plugin gesucht : (https://packages.e-tobi.net/vd…ch/binary/vdr-multipatch/
Wie fast immer bei den verfluchten VDR Kompilations Horror lief auch das nicht wirklich.
Es ist jede mal der gleich Mist : Beim VDR Update läuft danach erstmal nichts stabil und richtig.
Hier auch : https://salsa.debian.org/vdr-team/vdr-plugin-epgsearch: lt VDR version läuft alles auf vdr 2.4.0.. Die Kopilation endet dann wieder mit :
Warum wird vdr-dev 2.4.1 verlangt wenn doch 2.4.0 als Code Grundlage genutzt wird ?
Es wäre nett wenn mir helfen könnte, wie ich das vdr-plugin-live kompilieren kann, was ich außer den Standartkpompilertools noch brauche und wo ich welche Software herbekomme, was ich genau an Paketen installieren muss.
Gibt es keine Möglichkeit, das System anhand des installierten VDR kompilierbereit zu machen ( apt install "alles was zum kompilieren von $(dpgk -l | grep vdr ) nötig ist ) , dann den aktuellen passenden Plugin Quellcode von "keine was wozu wie passt" laden und kompilieren. Was bei viele anderen Programmen recht Problemlos klappt endet beim VDR jedes mal in Tagelangen Read-Compile-Frustration Horror.
EDIT : lt. :
ist jetzt eine 2te Version des Plugins installiert worden. Ist das EPG Search Confict Programmteil deaktiviert worden ? Der VDR läuft zwat jetzt ( stabil ??? ) auch mit dem epg search plugin, meldet nur keine Timerkonflikte mehr. Wäre für mich akzeptabe solange der vdr denn endlich stabil läuft und die Suchtimer laufen.
Grad getestet : In Version :
wurde der epg conflict check deaktiviert. Der VDR läuft stabil, Timer etc läuft alles, Timerkonflikte werden ignoriert. Frei nach dem Prinzip " Wer zuerst kommt mahlt zuerst" werden die Timer abgearbeitet.
Bin mal gespannt ob der VDR länger 1-2 Stunden läuft ....
Oft bezahlt man gerade bei Komplettlösungen, wie es die Massen NAS Systeme nun mal sind, mit eingeschränkten Konfigmöglichkeiten. Gern werden auch sinnlose Features ( oder teils sogar Bugs ) als ach so tollen Zusatz beworben. So hab ich auf Minirealwasser auch schon groß gelesen : "Neu ! Jetzt Laktosefrei und für Veganer geeignet". Ist in der IT Welt nicht anders - Alle bekloppt *fg
Ergo : Alles muss man selber machen !
Ich verfahre folgendermaßen : NAS unverschlüsselt ( macht bei 24/7 auch nicht so viel Sinn ) dafür liegen auf dem NAS LUKS Container für alles Mögliche. Die LUKS Container werden via sshfs auf den jeweiligen Clients entschlüsselt. Hat den Vorteil, dass bei einem Kompromittieren NAS keine Schlüsseleingaben abgefangen werden können und das NAS nicht entschlüsseln muss.
Alternativ könnte man eine Prüfsumme aus fest verbauten ( also Geräte, die immer online sind wie z.b. der Router ) Netzwerkgeräten genieren. Damit hätte man einen Schlüssel der Automatisch erzeugt wird und das System entschlüsselt. Startet man das NAS in einem anderen Netzwerk ( NAS wurde geklaut und steht beim Dieb zu Hause ) wird kein oder der falsche Schlüssel generiert. Man könnte auch ein Altes Handy nehmen und nur wenn dieses im WLAN ist wird nach dem o.g. Muster der Schlüssel generiert - das wäre auch DAU tauglich.
Ob das allerdings mit den "DAU" Systemen der Hersteller möglich ist bezweifle ich allerdings.
Quick n Dirty : Verlinke die .Xauthority im /home/ user des users mit dem du dich via ssh -X verbindest in /root. Es geht auch irgendwie über Configs, da bin ich aber auch überfragt.
Vvdrctl ist bequem aber das geht zur noch manuell. Wichtig ist das Zusammenspiel der conf Dateien deren Verlinkung und Inhalt. Funktioniert wie beim Apache, find' ich klasse.
In dem Sinne : Danke 
PS : für versierte User wäre ein Hinweis "Configaufbau wie beim Apache" sehr hilfreich.
Das muss man erstmal wissen. THX 4 Info
Dank https://www.yavdr.org/documentation/0.6/de/ch01s06.html sind alle Unklarheiten beseitigt
"Dann lies doch endlich mal die Dokumentation..."
bin dabei
=> s. Verständnisfrage zu /etc/vdr/conf.d
Hätte ich das mal eher gefunden : https://www.yavdr.org/documentation/0.6/de/ch01s06.html
Die Seite hatte ich gestern auch des öfteren aufm Schirm. (https://github.com/yavdr/vdr/blob/master/debian/vdr.service ). Nach 6 Stunden Server einrichten dachte ich, mal eben vdr noch einrichten und fertig - war wohl nix :/. Habs gestern noch mit nem cronjob gelöst, allerdings griffen die Configs dann nicht mehr. Die Datei /etc/default/vdr ist damit überflüssig wenn ich das richtig verstanden habe.
Die vdr Konfiguration erfolgt jetzt z.B. in /etc/vdr/conf.avail/vdr.conf und wird dann in gegen /etc/vdr/conf.d/00-vdr.conf verlinkt ( sieht lt. vdr Dateistruktur so aus). Die genaue vdr.conf Struktur ist mir allerdings nicht so ganz klar. Im Netz finden sich zig Infos zu den Startparametern aber keine wie die vdr.conf auszusehen hat und ob die Startparameter mit der gleichen Syntax dort definiert werden wie im VDR Wiki gelistet ( http://www.vdr-wiki.de/wiki/index.php/VDR_Optionen ).
Die vielen Infos sind teils widersprüchlich und verwirrend. Lt. http://www.vdr-wiki.de/wiki/index.php/Struktur sind die Configs in /var/lib/vdr statt in /etc/vdr. Lt. aktuellen Infos sind die Configs aber doch in /etc/vdr. Bei den ganzen VDR Anleitungen und Wikis fehlt in vielen Fällen die Versionsangabe was eine Strukturzuordnung nicht ermöglicht.
Eine kurze Info zum Aufbau der vdr.conf wäre hilfreich
EDIT : s. Verständnisfrage zu /etc/vdr/conf.d
Die Rechte der Aufnamen scheinen auch anders vergeben zu sein.
Unter Debian 9 vdr v? waren die Aufnahmen mit vdr.vdr gesetzt. Jetzt mit Debian 10 und vdr v2.4 ist es root.root
Ich hatte den Ordner /var/lib/video damals versuch via Link umzumappen, dies scheiterte allerdings oft an den Rechten. Jetzt ist die Verlinkung als root von
/var/lib/video -> /mnt/fstab_UUID_System_storage/vdr_recdir/ ohne Fehler möglich.
den VDR Starte ich jetzt einfach über ein @reboot cronjob
"Systemd ist nicht mal so eben nebenbei..."
ja das ist mir auch aufgefallen 
. Ich werd mich wohl die Tage mit Systemd auseinandersetzen müssen.
Aber noch mal zum VDR : Werden die Startparameter nicht mehr über den Startbefehl sondern über Konfigdatein in /etc/vdr/conf.d festgelegt ?
systemd - bisher konnte ich mich davor erfolgreich drücken. Nach dem vdr Update von Debian 8 auf 10 steh ich nun ratlos da.
Das Liveplugin sowie sämtliche in der /etc/vdr/default befindlichen Startparameter werden nicht geladen. Wie kann ich Debian 10n dazu bringen den VDR direkt zu starteb ( kein crontab oder /etc/rc.local, sondern mit sytemd )
Wo muss ich nachgucken um dem Grund für den Fehler im Live Plugin zu finden ?
Nachdem ich meine VDR Basis von Debian 8 auf 10 aktualisiert habe, greift das init Script nicht mehr, ich kann den VDR nur noch direkt per Befehl vdr oder über SystemD starten. Allerdings werden Startparameter konsequent ignoriert.
etc/default/vdr inhalt :
vdr start mit direkter Angabe der Paramerter wird auch ignoriert :
Wie kann ich den vdr wieder beim Systemstart mit den o.g. Paramertern starten ?
Hallo, in Kodi 18.1 ist per default nun eine spiele Sektion dabei. Find ich klasse nur wie nutzt man diese ? Ich habe mich mit Emulatoren bisher nicht befasst.
Aktiviere ich unter addons "Spiele anbieter" das Addon "Internet Archiv Rom Launcher" und geöffnet. Es sind dort eine Menge Emulatoren und Spiele vorhanden Wähle ich jedoch z.B. ein SNES Spiel aus und klicke auf "Launch" wird das Spiel heruntergeladen aber dann kommt immer die Nachricht das kein passender Emulator gefunden wurde. Müssen die EMulatoren nativ im Hostsystem ( in meinem Fall Debian 9 ) installiert werden oder kann das über Kodi realisiert werden ?
ich habe unter Debian mal retroarch mit sämtlichen Emulator paketen installiert jeder kann ich in RetroArch nichts auswählen, ich vie Pfeiltasten durch die Menüs zappen aber keine Punkt auswählen.
Hat jmd. von euch die Emulatoren am Laufen ?
mfg
INFOUPDATE
Nachdem sich auf mysteriöse weise meine X10 Konfiguration verabschiedet hat kam ich um ein erneutes einrichten der X10 nicht herum.
nach der aktuellen lirc Installation unter Debian 9.7 kann man sich o.g. Verlinkung von des lircd Sockets sparen. Kernel Treiber blacklisten und Alternativtreiber in /etc/lirc/lirc_options.conf eintragen reicht aus
bis auf Kodi läuft die X10 wieder. ~/.lircrc wird ausgeführt und alle Tasten der X10 werden via irw korrekt erkannt.
Es ist zwar mit der Option -l möglich Kodi eine andere Lirc Gerätedatei anzugeben, allerdings erfordert dies ein wenig Bastelei an den Startparametern und wenn kodi via kodi-standalone gestartet wird kann man dort die Startparameter ändern. Bis zum nächsten Update funktioniert das dann auch.
Eine einfache Verlinkung zum alten Pfad beim Systemstart ist da mMn Update resistenter :
hmm sind doppelt geschirmte 120db Kabel ca 2m lang, direkt am Kathein Multiswitsch angeschlossen.
vllt sollt ich doch mal neue Kabel testen ...
komischer weise liefen o.g. Sender anfangs ohne Probleme, auch die hd Varianten
die channels.conf ... wusste nicht das es darüber auch geht
Konkret handelt es sich um den Sender DMAX. 3sat und ZDFinfo sind als HD server ebenfalls nicht übermittelbar und WDR steigt am Tag ca immer 4-5 Stunden aus. Andere Geräte die Am gleichen Multiswitch hängen empfangen alles Programme einwandfrei.
Ich denke es liegt an der TBS Karte ( TBS 68 irgendwas , Multimedia video controller: Conexant Systems, Inc. CX23885 PCI Video and Audio Decoder (rev 04) ). Die Karte kostete damals die Hälfte einer DD Karte und es gab eine Anleitung vom Hersteller für linux Treiber ( aktuell ist der Treiber mittlerweile im Kernel ).
Ich hatte damals schon ewig herumprobiert wie ich die og. SD Sender als HD Variante ans laufen bekomme, allerdings hat nichts wirklich funktioniert ( Kabeltausch, Schüssel neu ausgerichtet und Frequenzen nach oben und unten korrigiert.
Zwingend erforderlich sind die o.g. Sender in HD nicht auch DMAX nicht, TV allg. eigentlich nicht *gg - aber der Vollständigkeit halber wollte ich DMAX zumindest mit relativ wenig Aufwand wieder lauffähig bekommen. Das Tauschscript ist die schnellste Möglichkeit für mich gewesen, da ich mich mit den anderen Dingen ( Sattechnik VDR Frequenzen etc is ne Wissenschaft für sich ) nicht so gut auskenne.
Man kann dem vdr nicht sagen, welchen Tuner er zuerst nehmen soll. Die vernünftige Lösung ist, den defekten Tuner zu deaktivieren oder gleich die ganze Karte auszutauschen.
Lars
verdammt ;/
Kabel tauschen bringt nix ( gleicher Fehler ). Der Fehler tritt nur bei EINEM Sender auf und nur beim Tuner 1. Mit dem EINEN defekten Kanal auf EINEM Tuner kann ich leben. O.g. Script funktioniert allerdings zuverlässig und tauscht die Tuner nach jedem Systemstart. Scheinbar scheint die Reihenfolge mit der Tuner unter /dev/dvb/adapterX gelistet werden doch von der Reihenfolge der Hardwaretuner bzw. deren Anschluss abzuhängen.
o.g. script funktioniert jedenfalls und das Geld für neue Karte brauche ich erstmal nicht ausgeben
