Posts by wfaust

    Ich leite z.B. ssh Zugriffe aus den Netzen meiner VDR Clients mittels iptables an den per OpenVPN angebundenen VDR Server weiter. Nun will ich mittels Lifeguard einige Zeit verhindern, daß der VDR Client ausschaltet, wenn Daten über bestimmte Ports weitergeleitet werden. Dabei habe ich ein Problem:


    Wie kann man in einem Bash Script einfach erkennen, daß mittels iptables Pakete weitergeleitet werden? Mittels ss scheint man keine weitergeleiteten Pakete erkennen zu können. Mir reicht es, wenn ich nur mitbekomme, daß Daten auf einem Port weitergeleitet werden. Es muss also nicht unbedingt der "Status" einer weitergeleiteten Verbindung ermittelt werden.

    Da meine yaVDR Installation etwas aufwendiger ist (ich tue wpagui, Filezilla, OpenVPN u.a.m. hinzufügen), clone auch ich einfach das fertige System auf die vorhandenen Rechner. Es kamen bislang mehrere Zotac ND22 und M4N87 Pro Motherboards zum Einsatz (siehe meine Signatur). Auch bei yaVDR 0.6 brauchte ich eigentlich nur wenig anzupassen (das mit den unterschiedlichen Netzwerkdevices löse ich einfach per init.d Script, Bildschirmeinstellung muss neu per webconfig eingelesen werden, das M4N78Pro Motherboard braucht nomsi bei grub).


    Jetzt habe ich zusätzlich zwei Zotac ID42 mit dedizierter NViidia GT610 Grafik auf dem Motherboard anstatt die ältere NVIdia Grafik der oben erwähnten Rechner. Auf dem Zotac ID42 bekomme ich nach dem Clonen einfach kein HDMI Audio Device. Ich habe den nvidia Treiber schon gepurged und neu installiert. doch kein HDMI Audio bei aplay -L.. Irgendeine Idee, was ich noch ausprobieren könnte? Die komplette Neuinstallation für den ID42 wäre echt grausam viel Arbeit. Ansonsten schein alles zu funktionieren (inkl. Bild). Die verwendete NVidia Treiberversion liefert bei einer yaVDR Neuinstallation durchaus HDMI Sound.


    Nebenbei: Ich clone auch immer die installierten Systeme auf einen USB Stick und füge Backup/Restore Optionen im VDR Menü hinzu. Hat mir und meinen Users schon öfters das Leben gerettet. Vielleicht sollte ich mal ein Tutorial dafür hier reinstellen...

    gary : Mit der Stabilität von VDR gab es eigentlich bei mir und meinen Usern keine großen Probleme trotz teilweise recht problematischer Hardware. Bei VDR selbst gab es nur ab und zu Hänger beim Umschalten der Kanäle, meistens in den ersten 30 Minuten nach einem Kaltstart, doch dies scheint ein Problem der Sat-Karten/Empfang zu sein. In den letzten 15 Jahren ließen sich meine meisten schweren Probleme mit VDR Hängern auf die Sat-Karten zurückführen (Treiber, Probleme im Zusammenspiel mit dem Motherboard).


    iso : Auch bei mir gibt es massiven Ärger, wenn ich das Netzwerkkabel vom yaVDR 0.6 Rechner ziehe. Der Bildschirm wird schwarz und das System friert komplett ein. Der M4N78 Pro Motherboard Speaker piept nach einiger Zeit (wohl der Linux Kernel). Danach scheint sich der Rechner durchaus teilweise wieder zu fangen. Lt. syslog war ein CPU Kern für mindestens 22 Sekunden eingefroren. VDR wird dann neu gestartet, aber frontend u.a.m. geht nicht mehr. Ich hatte noch keine Zeit mir das genauer anzuschauen, aber es ist das letzte ernste Problem, daß ich kenne. Einen Hardwarefehler halte ich für sehr unwahrscheinlich in meinen Fall. Ich denke, ich werde mal mit den acpi/noapic Settings spielen. Ich musste schon nomsi bei Grub hinzufügen, da sonst yaVDR 0.6 hier dauernd abstürzt. War bei yaVDR 0.3 - 0.5 nie nötig. Mal sehen....

    Nur zur Info:


    Ich weis nicht, inwieweit die Probleme mit 8200 auch auf 8300 zutreffen, aber auch ich hatte Probleme mit einem Asus M4N78 Pro MB. Zuerst schien der 304 die Lösung zu sein, doch ein glücklicher Umstand brachte mich auf eine andere Spur und bei mir scheint der 340 zu laufen, wenn ich in grub pci=nomsi benutze. Dies war bei bei älteren Kerneln die ich benutzt hatte nie nötig, doch bei 0.6 mit 3.13 kernel scheint es notwendig zu sein.

    Ok, ich habe mal in /var/lib/vdr/plugins/menuorg.xml nachgeschaut, was passiert, wenn man Kodi via dem VDR Menü startet und verwende nun genau den gleichen Befehl. Das sollte auch bei Änderungen/Updates sicherer sein. Desweiteren habe ich mal getestet, wie man das mit dem Resume machen sollte. Hier scheint man neben Resume auch wieder auf das Starten von VDR/Frontend warten zu müssen, da sonst Kodi gestartet wird, bevor der VNSI Server von VDR da ist. Den sleep Befehl habe ich entfernt, da bei während 6-7 Testdurchgängen keine Probleme auftauchten.


    Folgendes /etc/init/kodi-start.conf Script scheint bei mir beim Booten und auch Resume zu funktionieren und dürfte recht updatesicher sein. Wenn Du keine Probleme damit hast, werde ich es wohl auch meinen beiden Kodi Usern einspielen.


    Tja, das kommt davon wenn man ohne Tests sowas veröffentlicht. Das vdr-frontend abzuschalten ist evtl. auch eine Lösung, aber zumindest wohl nicht updatesicher (gibt es überhaupt so ein Wort? :D ). Das andere Problem könnte beim Ausschalten auftretten, da Deine Lösung ja das Frontend komplett abschaltet und was soll dann passieren, wenn Du Kodi beendest? Das Problem meines Scripts scheint ja nur das Starten von Kodi zu sein. Per service kodi Befehl geht es also so schon einmal nicht und ich habe zu wenig Ahnung von den yaVDR upstart Scripts. Ich schlage daher vor, bei dem /etc/init/kodi-start.conf Script einfach service kodi start durch svdrpsend hitk Back Back Back Back Back Menu 6 2 1 zu ersetzen. Jetzt sollte Kodi genauso gestartet werden, wie es der User per FB tut. Damit sollte dann auch das Frontend usw. ausgeschaltet werden und es dürfte updatesicher sein. Ich habe mein altes Posting oben entsprechend geändert.


    Sobald ich etwas Zeit habe, werde ich auch mal schauen, was man tun muss, damit das auch bei einem Resume funktioniert. Ich habe hier zwei yaVDR Clients wo die User eigentlich nur Kodi nutzen und nur ab und zum VDR-Frontend für die Konfiguration und andere Programme (wpa_gui, Filezilla,...) müssen. Eine Lösung wäre auch für diese User praktisch, auch wenn das Drücken der gelben Taste zum Start von Kodi nicht gerade Muskelkater verursachen sollte. Falls Du es vorher rausfindest, bitte melden ;-)

    Meine Erfahrungen was Upstart angeht gehen leider auch gegen Null. Mir fehlt jetzt die Zeit um alles durchzutesten, aber vielleicht hilft Dir erstmal schnell folgende Lösung weiter:


    Erstelle eine Datei /etc/init/kodi-start.conf mit folgenden Inhalt:



    Das sollte es gewesen sein. Jetzt wird Kodi beim Booten einmal gestartet und nur nachdem vdr/vdr-frontend gestartet sind (bei mir dauert der Start von vdr wegen eines Plugins deutlich länger als das Frontend, weshalb ich bei start on beide Möglichkeiten berücksichtige. Der sleep Befehl soll einfach nur vdr, frontend und anderen Diensten etwas Zeit geben, daß alles korrekt gestartet ist. Evtl. unnötig... bzw. bei Zuverlässigkeitsproblemen Zeit erhöhen.


    Noch etwas: Solltest Du Suspend to Ram benutzen, wirst Du wohl zumindest den start on Befehl am Anfang auch noch um denn Fall resume erweitern müssen. Mangels Zeit konnte ich das jetzt nicht testen. Melde Dich, falls Du es nicht hinbekommst.

    @indi:


    1. OpenElec gibt es doch auch für x86 und die Performance ist vermutlich besser als bei yaVDR, da einiges an Ballast fehlt. Allerdings, ob Du auch Skypen kannst, weiss ich nicht, da OpenElec kein umfangreiches Repository hat. Da mußt Du nachschauen. Und es ist auch letzteres, weshalb OpenElec oft keine Alternative ist, wenn man zusätzliche Software braucht. Insofern kann ich Deinen Wunsch nach yaVDR nachvollziehen.


    2. Du solltest kein Problem haben, einfach Kodi nach dem Start von VDR zu starten. Da gibt es mehrere Möglichkeiten (z.B. via Upstart). Aber vielleicht reicht es Dir ja auch wie meinen Usern, einfach Kodi in VDR auf eine Taste zu legen. Dann reicht eine Taste anstatt Menü 6 2 1. So habe ich die eher selten verwendete gelbe Taste in VDR in /etc/vdr/keymacros.conf zweckentfremdet:



    Nach dem Start von yaVDR also einfach die gelbe Taste drücken und man landet in Kodi (das VDR Menü darf beim Drücken der Taste nicht auf sein).


    3. Das Ausschalten via Inaktivität ist bei korrekter Einstellung auch kein Problem und geht OOTB. Problematischer wird eigentlich erst wieder das Ausschalten per FB. Ich habe das hier für meine User über /etc/lirc/lircrc gelößt. Wenn Du keine Taste auf Deiner FB frei hast, kannst Du es wie ich bei der Hama FB machen und durch das mehrfache Drücken einer Taste das Ausschalten starten. Hier mal meine /etc/lirc/lircrc Datei mit diversen nützlichen Befehlen. Beachte den letzten Block mit der e-Taste:



    PS: Die sleep und der vdr-dbus-send /Remote remote.Enable Befehle am Ende sollen sicherstellen, daß nach dem Beenden von Kodi der VDR Frontend genug Zeit zum Starten hatte und auch die Fernbedienung funktioniert (damit gab es mal hin und wieder Probleme). Falls nicht, kann svdrpsend hitk power ins Leere laufen.

    mini73 :


    Welche Skin ist denn nach Deiner Meinung ein ebenbürtiger Ersatz? Mir ging es wie Heiko, die default skin nach der yaVDR Installation ist verspielt und meineserachtens sehr unübersichtlich. Eine wirklich gute Alternative habe ich nicht gefunden, aber ich habe auch nicht alle Skins installiert/ausprobiert. Derzeit verwende ich noopacity anstatt anthra. Aber schon bei den Untermenüs bekomme ich bei noopacity Probleme, daß diese wegen der großen Schrift nicht lesbar sind (vermutlich kann man die Schrift verkleinern, doch das sieht noch dümmer aus, als es jetzt schon der Fall ist; Teilweise fehlen die Menü-Piktogramme bei yaVDR).


    noopacity hat also durchaus so seine Design-Probleme, die man in der Größe von anthra nicht kannte, aber derzeit geht es mir da wie Heiko, nur daß ich wegen des mangelnden Supports jetzt meines User zwinge auf noopacity umzusteigen, wenn ich keine bessere Alternative finde.

    nasenbär :


    Wenn ich das richtig mitbekommen habe, wird bei Linux-fremden Dateiformaten wie vfat oder NTFS damit gesteuert, daß das gemountete Laufwerk für user/gruppe vdr lesbar ist. Wenn Du es also jetzt ohne su -c cmd vdr als root mountest, kann der User vdr z.B. nicht korrekt auf NTFS/vfat Medien zugreifen, falls Du diese mal anschliesst. Damit dürfte auch die Lösung zu meiner obigen Frage interessant werden, wie man die Lese- und Schreibzugriffe auflockert:


    udisks wird bei yaVDR via /etc/udisks-glue/config eingestellt. Im Extremfall kannst Du hier mit


    Code
    1. automount_options = { noatime, "dmask=0000", "fmask=0000" }


    unter match disks den Lese- und Schreibzugriff für alle erweitern.


    Doch merkwürdig ist die Lösung schon bei Dir. Kann es sein, daß das Verzeichnis wo Du die Festplatte hinmountest schon existiert und/oder keine Schreibrechte für den User vdr hat? Dann würde es nur ohne su -c klappen....

    Bei mir klappt das Mounten bislang, jedoch wird ein NTFS formatiertes Laufwerk nur für den User vdr schreibend gemountet. Das Problem ist, daß mein normaler User und der proftpd Server (user proftpd) damit nicht schreibend zugreifen können. Irgendein Tipp, wo ich was ändern muss, damit das NTFS Laufwerk auch für die Gruppe vdr schreibend gemountet wird? Ich finde die Beschränkung auf den User vdr vielleicht etwas übertrieben.

    Ich hatte schon das Problem unter yaVDR 0.5, doch damals konnte ich xine oder xinelibout verwenden. Letzteres funktioniert bei mir mit yaVDR 0.6 hier nicht mehr (wieso??) und nun muss ich wohl auf softhddevice umstellen. Doch beim Empfang von IPTV (Telekom) gibt es sowohl mit SD als auch HD Sendern nach wenigen Minuten:

    Code
    1. Dec 27 20:24:31 myzotac vdr: video: decoder buffer empty, duping frame (320/6440) 0 v-buf
    2. Dec 27 20:24:31 myzotac vdr: video: 20:49:53.779 +32 117 0/\ms 0+0 v-buf

    und das Bild friert ein. Menü/Kanalwechsel funktioniert noch.


    softhddevice: Bildschirm läuft auf lt. xrand auf 50Hz. CPU Auslastung ist ca. 4%... Und ich habe die Pufferung/Skalierung/Deinterlace Konfig so weit es geht testweise zurückgedreht (s.u.). Die Probleme sind auf alten nvidia basierten Boards (Zotac ND22 mit ION2 oder M4N78 Pro). Kabel TV, Sat und DVB-T funktionieren dagegen problemlos mit softhddevice.


    Mir gehen langsam die Ideen aus, was ich noch ausprobieren könnte. Hat jemand eine Idee, woran es noch liegen könnte???? Es scheint etwas im Zusammenspiel IPTV+softhddevice zu sein.


    Danke


    Guter Gedanke die Module einzutragen, würde jedoch auch das Problem nicht vollständig beheben. Bis WPA2+DHCP bei WLan durch sind, dauert es des öfteren schon einige Sekunden. Mit dem Eintragen gewinnt man ein paar Sekunden, aber immer genug?


    Aber was passiert, wenn man eben WLan nutzen will und kein Kabel angeschlossen ist? Sobald eines der in /etc/network/interfaces angebenen Interfaces mit DHCP nicht beim booten schnell da ist, gibt es zumindest mit dem webconfig schnell Probleme.

    Alleine die Wartezeit zu verkürzen könnte evtl. nicht reichen. Prüfe auch, ob Du erfolgreich das Webconfig von einem anderen Rechner aus aufrufen kannst. Ich hatte hier zwei unterschiedliche Probleme:


    1. In /etc/init/tntnet.conf tritt start on static-network-up niemals ein und damit wird tntnet beim Booten nicht gestartet. Evtl. gibt es hier noch Probleme mit anderen Diensten?


    2. Selbst wenn tntnet gestartet wird, kann es gerade bei WLan dazu kommen, daß das Webconfig nicht aufrufbar ist. Der Aufbau der WLan Verbindung beim Booten dauert einfach zu lange und tntnet bindet sich dann scheinbar nicht richtig ans Interface. Hier hilft evtl. ein sleep Befehl vor dem exec Aufruf in der tntnet.conf .


    Derzeit bin ich dazu übergegangen, während des Bootens zu schauen, ob in eth0 ein Netzkabel steck. wlan0 ist nicht auf auto in /etc/network/interfaces eingestellt und wird nur bei Bedarf von folgendem Code beim Booten gestartet:


    Code
    1. # Check for eth0 ethernet cable when running on a system with RT2790 based wlan. Enable wlan if no cable link is detected
    2. if /sbin/ip link | /bin/grep -q 'eth0:.*state.*DOWN'; then
    3. if lspci | /bin/grep -q 'RT2790'; then
    4. logger -t $0 "*** eth0 cable disconnected. Starting wlan0"
    5. echo "eth0 cable disconnected. Starting wlan0"
    6. { ifup wlan0; sleep 5; dhclient wlan0; } &
    7. fi
    8. fi


    Aber noch bin ich nicht so recht zufrieden, da hier immer noch der 1. Fall auftretten kann. Ich teste noch. Es sieht wohl so aus, als ob ich in einem init Script alle Netzwerk Interfaces nach Bedarf selbst starten muss :-( Es


    PS: Bei einem pfsense 2.2.4 Wlan Router klappt DHCP nicht... und ich muss dhclient separat aufrufen. Bei einer Fritzbox klappt es mit dem DHCP. Wäre schön, wenn jemand herausfindet, wo man in Ubuntu drehen muss, damit sich 14.04 wie 12.04 verhält. Aber es gibt hier ein Setup, wo ich nicht sehe, wie man es ohne zusätzliches Script zum laufen bekommt.

    Korrekt, Du solltest erst über das VDR Tool Menü versuchen mittels pavucontrol das richtige Ausgabedevice einzustellen. Das klappt eigentlich meistens. Die Probleme sind bei mir erst bei einem Neustart aufgetaucht, da dann die pavucontrol Einstellungen aus diversen Gründen nicht erneut geladen wurden. Wie im 0.6 Announce angegeben kannst Du dann versuchen die system.pa Datei anzupassen, damit es auch bei einem Neustart klappt. Doch wie in yavdr 0.6 preseed - Probleme und Fixes beschrieben, klappt auch dies nicht unbedingt. In einem Fall hier musste ich beim Booten per Script immer einige Sekunden warten, bevor ich mittels sudo -u vdr pactl set-card-profile 0 output:hdmi-stereo auf das gewünschte Profil/Device umstellen konnte. Wenn alles scheitert, einfach per webconfig auf ALSA umschalten und rebooten.

    Dank seahawk1986 gibt es bei yaVDR 0.6 nun die Möglichkeit ein Lockfile für Lifeguard anzugeben. Damit nicht jeder hier alles Neu erfinden muß, hier mal eine Beschreibung wie und wozu ich das hier seit Jahren nutze. Vielleicht findet jemand anderes auch, daß es für seinen Fall nützlich ist.


    Das Problem ist, daß die bislang verfügbaren Möglichkeiten von Lifeguard oft nicht ausreichten, um z.B. zuverlässig das Ausschalten des VDR Rechners zu verhindern. Bei mir schaltete der yaVDR Rechner z.B. während längerer Up- und Downloads aus, weil die Internetverbindung kurz gestört war (z.B. wg. der Zwangstrennung) und die vorhandenen Möglichkeite von Lifeguard nicht ausreichten, um zuverlässig zu erkennen, wann ausgeschaltet werden darf.


    Die jetzt bei yaVDR 0.6 vorhandene Möglichkeit von Lockfiles erlaubt es, updatesicher Lifeguard um eigene durchaus komplexere Erkennungsmöglichkeiten zur erweitern. Hier nun ein Beispiel, daß leicht angepaßt werden kann. Das Beispiel soll das Ausschalten beim Zugriff auf einen auf dem System vorhandenen proFTPd Server verhindern (dient mir zum Download von TV Aufnahmen des yaVDR Rechners). Es läßt sich aber leicht anpassen, um z.B. das Ausschalten bei diversen Downloads, VPN Verbindungen usw. zu verhindern.


    Zuerst muss man updatesicher in der Lifeguard Konfigurationsdatei /etc/vdr/lifeguard.conf mittels Templates ein Lockfile angeben. Der Rechner soll nicht ausschalten, solange die angegebene Lockdatei vorhanden ist.
    Folgendes Beispeil als root User (sudo su) ausführen.


    Dazu mit folgenden Befehlen ein Verzeichnis/Datei erstellen:

    Code
    1. mkdir -p /etc/yavdr/templates_custom/etc/vdr/lifeguard.conf/
    2. nano /etc/yavdr/templates_custom/etc/vdr/lifeguard.conf/061_delayoff
    3. chown root:root /etc/yavdr/templates_custom/etc/vdr/lifeguard.conf/*
    4. chmod 644 /etc/yavdr/templates_custom/etc/vdr/lifeguard.conf/*


    mit folgendem Inhalt:

    Code
    1. <?cs if:(vdr.plugin.lifeguard.enable != "false") ?>
    2. file /tmp/.delayoff <?cs var:_("Warte\ noch\ etwas mit\ Shutdown\ wegen\ FTP\ Transfer.") ?>
    3. <?cs /if ?>


    Die Änderung der Konfiguration aktivieren:

    Code
    1. process-template /etc/vdr/lifeguard.conf


    Sobald jetzt eine Datei /tmp/.delayoff vorhanden ist, schaltet der Rechner nicht mehr aus. Nun gilt es im zweiten Schritt ein Script zu erstellen, daß die Lockdatei erstellt/löscht. Man kann ähnlich wie Lifeguard in /usr/share/vdr/shutdown-hooks/S91.lifeguard auf Traffic achten oder man nutzt die diversen Statustools der verwendeten Software (bei proftpd bietet sich ftpwho an). Wird Traffic gefunden, wird die Lockdatei erstellt und im Beispiel für 10 Minuten nicht wieder gelöscht. Ein Datentransfer kann also ca. 10 Minuten z.B. wegen einer Zwangstrennung komplett ausfallen, ohne das der yaVDR Rechner ausschaltet.


    Dazu erstelle das Script /usr/local/bin/delaycheck.sh


    Mache das Script ausführbar: chmod +x /usr/local/bin/delaycheck.sh


    Und lasse es mittels cron alle 2 Minuten starten. Dazu crontab -e aufrufen und folgende cron Datei erstellen:

    Code
    1. SHELL=/bin/sh
    2. MAILTO=""
    3. PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
    4. */2 * * * * /usr/local/bin/delaycheck.sh


    Das wars. Jetzt wird alle 2 Minuten geprüft, ob Up/Downloads auf dem proftpd Server stattfinden und falls ja wird für 10 Minuten das Ausschalten mittels Lifeguard verhindert. Kurze Störungen wegen der Zwangstrennung sind kein Problem mehr,


    Man kann das obige Script leicht erweitern/ändern. So kann man die Zeile mit ftpwho leicht anpassen um z.B. andere Up/Downloads als FTP zu erkennen. Wer z.B. bislang Lifeguard zum Erkennen von Traffic benutzt hat, sollte sich mal /usr/share/vdr/shutdown-hooks/S91.lifeguard anschauen. Das obige System erlaubt es aber, Lifeguard auch um durchaus andere Methoden zum verhindern des Ausschalten zu erweitern.


    So schaltet bei mir der Rechner bei einer vorhandenen OpenVPN Verbindung nicht aus. Dazu setzt OpenVPN im Up-Script eine fast unendlich laufende Lockdatei und im Downscript wird dann einfach folgendes gemacht:


    Code
    1. # Delay shutoff at least DELAYOFFSECS seconds after the checked communication ended
    2. DELAYOFFSECS=3000
    3. # path/name of file checked by lifeguard for delayed shutdown
    4. LIFEGUARDFILE=/tmp/.delayoff
    5. X=$(($(date +%s) + $DELAYOFFSECS))
    6. echo $X >"$LIFEGUARDFILE"

    Du hast aber einen freien LAN Port, kannst nur kein Kabel bzwl. Powerline legen/nutzen? Ich weiß, dies ist nicht unbedingt die Antwort auf Deine Frage, aber vielleicht erspart Dir das den Ärger den ich mit diversen WLan Treibern unter Linux hatte:


    Nach meiner Erfahrung ist das mit WLan und Linux so eine Sache. Zum einen sind die Treiber oft nicht wirklich zuverlässig. Es gibt nicht selten kurze Verbindungsabbrüche oder Kompatibilitätsprobleme mit bestimmten APs. Gerade wenn man stundenlang HDTV streamt sind auch kleine Störungen schnell ein echtes Ärgernis. Das andere Problem ist, daß gerade schnelle MIMO WLans von den Linux Treibern auch nicht gut unterstützt werden. Der Software Support einiger Distributionen ist auch teilweise eher schlecht. Z.B. bei yaVDR muss Software fürs WLAN inkl. GUI erst installiert werden (Tutorials dazu gibt es hier im Forum von mir.. klappt auch mit yaVDR 0.6 preseed).


    Mein Tip daher ist es, unter Linux einfach einen WLan Client mit LAN Port direkt an den LAN Port des Rechners anzuschliessen. Dann muss man auf dem Linux Rechner keine zusätzliche WLAN Software installieren und es gibt einige durchaus sehr interessante und günstige Geräte. Die C't hatte mal einige getestet und ich kann es aus eigener Erfahrung nur bestätigen, so funktionierte hier in diversen schwierigen Fällen ein AVM FRITZ!WLAN Repeater 300E schnell und wochenlang problemlos (Entertain IPTV via Fritz Box klappt auch!). Empfindlichkeit des Empfängers war hier sehr gut. Der 300E Repeater kam hier zum Einsatz, nachdem diverse andere Lösungen mangels ordentlicher Linux Treiber oder schlechtem Empfang nicht zuverlässig funktionierten. Der neuere AVM FRITZ!WLAN Repeater 450E dürfte auch interessant sein, unterstützt aber kein a-Netz. Gerade bei einigen Fritz Boxen die auf n und a gleichzeitig senden können, kann der a-Netz Support des 300E recht interessant sein. Die Konfiguration ist dank WPS ja meistens sehr einfach.

    mini73 : Sorry, aber das ein Kernelupdate unter Ubuntu mit einem Befehl gelöst ist, ist leider nur die halbe Wahrheit. Wer hat hier nicht schon im Forum die diversen Probleme gelesen, die nach einem Kernelupdate mit DVB Treibern, NVidia Treibern, LIRC usw. auftretten können? Wir wissen ja auch noch nicht, was nächstes Jahr evtl. an Treibersupport eingestellt wird. Auch habe ich in den letzten 15 Jahren mit VDR/Kodi Rechnern die Erfahrung gemacht, daß nur selten ein System wirklich zuverlässig arbeitet. Wenn ich hier ein getestetes System meinen diversen Usern gebe, vermeide ich es, einen eigentlich unnötigen Kernelwechsel durchzuführen. Der Support für den 14.04.1 Kernel ist ja sehr lang und wenn yaVDR 0.6 erst nach August 2016 fertig wird, haben wir ja wieder einen neuen LTS Kernel zur Auswahl. Aber letztlich habe ich das wohl nicht zu Entscheiden, bitte jedoch das Thema Zuverlässigkeit und einen langfristigen Support nicht aus den Augen zu verlieren. Wenn man ein paar Macken nachbessert, hatte bislang yaVDR sich hier durchaus sehr gut geschlagen und ich musste nur einmal im Jahr meine User größer Updaten, was die Arbeitszeit mit ca. 50-100 Std. in einem akzeptablen Rahmen hielt.