Beiträge von ironman

hjs

Ich weiß zwar nicht in welchem Umfeld du o.g. Anforderungen an einen Router benötigst und wie hoch das entsprechende Budget dafür ist, will aber nicht unerwähnt lassen dass Router vom Hersteller Lancom das können was du suchst, siehe LCOS (LanComOS) Referenzhandbuch:

https://www.lancom-systems.de/…#topics/sms_overview.html

bzw.

https://www.lancom-systems.de/…s/sms_urlplaceholder.html

Lancom Router sind allerdings halt sehr teuere Profigeräte - dafür aber auch garantiert Backdoor-freie "IT-Security Made in Germany". Die einzigen Lancom Modelle mit LTE und analogen Telefon-Ports sind meines Wissens nach der 1783VA-4G und dessen direktes Nachfolgemodell mit Supervectoring, der 1793VA-4G.

Zur Info:

17=Serie

8/9=Generation

3=2x IDSN+2x Analog Ports

VA=VDSL+ADSL Modem

4G=LTE Modem

Der 1783VA-4G ist zwar schon seit März 2019 End of Sale, unterstützt aber die aktuelle LCOS Version 10.40. Major-Release Firmware-Updates bekommt er noch bis März 2021, und danach bis End of Life im März 2024 immer noch Firmware-Updates der letzten unterstützen Major-Version. Bei eBay bekommt man gebrauchte Geräte - gemessen am Neupreis - zu halbwegs akzeptablen Kursen. Und da die Geräte selbst quasi unkaputtbar sind spricht da auch nichts dagegen.

Sofern bei deinem Wunsch nach "buy-mount-configure-success" nicht bereits der Preis das KO-Kriterium ist, dürfte allerdings die Konfiguration ein nicht unerhebliches Problem darstellen. Für jemanden der noch nie mit Lancom Geräten gearbeitet hat ist die Inbetriebnahme alles andere als ein Kinderspiel weil dort vieles anders ist als man es von "Home"-Routern kennt (Begrifflichkeiten, Konfiguration mittels LanConfig Software, Verhalten der Geräte selbst, usw.)

und man schlichtweg erschlagen wird von der Vielfalt an Konfigurationsmöglichkeiten. Da braucht es Zeit und Muße sich damit auseinander zu setzen. Sofern man dazu gewillt ist stehen einem jedoch ein extremst ausführliches Referenzhandbuch (s.o.), ein sehr guter Hersteller-Support sowie eine hilfreiche Community zur Verfügung.

Zitat von obelix

Mit den 2-3 Wochen war schon mal nix.

Am Ende waren es dann fast 2,5 Jahre...

Sorry dass ich diesen Thread hier ausbuddeln muss, aber mir ist letzte Woche dann mal aufgefallen dass es von Atric seit Februar die Software Version 1.5 für den IR-WakeupUSB gibt. Diese stellt wiederum nach langer langer Zeit die hier im Thread besprochene neue Firmware Version 2.1 zum Einstellen der Tasten-Wiederholung bereit (allerdings nur für die Hardware Rev. 1.2). In der Software gibt es dazu dann jetzt einen neuen Menüpunkt:

[Blockierte Grafik: https://s12.directupload.net/images/200426/7lgy8een.png]

(Der Screenshot zeigt die voreingestellten Werte)

Vielleicht hilft es ja noch dem einen oder anderen...

Für mein Problem war die neue Firmware jedenfalls keine Lösung. Ich benutze an dem Atric eine Logitech Harmony mit dem KLS VDR 1.6 Profil. Mein Problem war daher auch nicht dass die Tastenwiederholung gar nicht funktionieren würde, sondern dass sie nur recht träge reagiert wie auch hier im Thread thematisiert. Ursache hierfür ist dass im Lirc der Event Count nicht hochgezählt wird wenn man eine Taste gedrückt hält (siehe dazu auch Atric USB IR-Einschalter: vdr-2.2.0_attric_usb_fakeCount.diff ). Da brachte dann auch die neuen Firmware leider keine Abhilfe.

Kann mir vielleicht jemand sagen was überhaupt die Grundvorraussetzung dafür ist dass Lirc den Event Count hochzählt und ob das überhaupt von der Einstellung der Werte im Atric abhängt? Sprich, müssen meine Harmony und der Atric beide auf gewisse Werte eingestellt sein bzw. gewisse Werte einhalten damit Lirc die Tastenwiederholung über den Event Counter registiert?

Oder müsste der Atric Empfänger dafür noch irgendwas anders handeln was er aber nicht kann? Mit einem seriellen Atric hatte ich dieses Problem früher jedenfalls nicht.

Oder liegt das Problem vielleicht auf der Seite vom Lirc dass da noch irgendwas extra eingestellt werden muss?

Bin für jeden Hinweis dankbar!

Are we talking about the same GPU? I know there is a discete AMD Radeon HD 5350 graphics card. However, I am using a AMD Athlon 5350 Socket AM1 APU with integrated Radeon R3 HD 8400 graphics which is well capable of 1080p Full HD or 1080i + temporal-spatial output - unless there are broken Mesa drivers...

Also ich hab nach wie vor nen AMD Athlon 5350 (Kabini) mit GCN Grafik im Betrieb mit Ausgabe via SoftHDDevice und VDPAU. Und was den Betrieb von AMD Hardware auf neuerem Software-Unterbau (Ubuntu 18.04.3 + yaVDR 0.7 Pakete) betrifft kann ich AMD leider nicht empfehlen.

Unter Ubuntu 14.04 Trusty lief das mit den yaVDR 0.6 Paketen und SoftHDDevice Ausgabe noch immer ziemlich gut. Einziges Problem was ich da hatte war dass nach dem Umschalten manchmal das Bild schwarz blieb. Das scheint mir aber kein Problem der AMD Hardware zu sein. Zumal es dieses Problem aktuell ja immer noch zu geben scheint (oder wieder). Von einem funktionierenden OpenGL OSD konnte man dort allerdings leider nur träumen weil die radeon Mesa Treiber da noch nicht weit genug waren.

Aufgrund des Supportendes von Ubuntu 14.04. hatte ich dann letztes Jahr auf Ubuntu 18.04. mit yaVDR 0.7 Pakete gewechselt. Auch in der Hoffnung dass die neueren radeon/amdgpu Mesa Treiber endlich die nötigen OpenGL Funktionen für das softhddevice-openglosd bereitstellen.

-Die OpenGL OSD Version crashte nun zwar nicht mehr wie vorher sofort, zeigte aber kein OSD an.

-Die normale Version von SoftHDDevice hab ich zunächst nicht stabil zum laufen bekommen wegen Problemen mit FFmpeg.

-Besserung kam dann erst mit der alten SoftHDDevice Version aus yaVDR 0.6 als "vdr-plugin-softhddevice-ffmpeg-2.8" ins Repository.

Damit lief das im Prinzip fast so wie vorher (alles etwas hakeliger), allerdings mit einem gravierenden Unterschied. Irgendwann passiert nämlich das hier: Bild ruckelt nach unbestimmter Laufzeit . Ich hatte vorher schon alles Mögliche ausprobiert von verschiedenen Kernel-Versionen bis hin zum Wechsel vom radeon Modul zu amdgpu. Laut o.g. Thread sind die Mesa Treiber > 13.0.6 das Problem, was nunmehr seit mehr als 2 Jahren immer noch nicht behoben wurde. Daran ändert dann auch die jetzt verfügbare SoftHDDevice Version 0.7.0+git20191125-762-879d011 nichts mit der die FFmpeg Probleme der Vergangenheit angehören sollen.

Ich hatte mich insofern damit arrangiert dass ich in letzter Zeit sowieso nicht mehr so lange am Stück rein TV geschaut hab. Und wenn doch, naja halt kurz Frontend detached und wieder attached und dann war's wieder gut. Letzte Woche gab's dann nochmal ein Update der radeon Mesa Treiber. Der erhoffte Fix blieb wiedermal aus. Bzw. das Gegenteil war der Fall: Mit dem Update hat's mir nämlich dann die SD Ausgabe zerschossen. Egal mit welcher SoftHDDevice Version und egal mit welchem FFmpeg. HD sieht normal aus, aber SD wird nur noch verzerrt ausgegeben. Ich war dann so genervt dass ich wieder zurück gewechselt habe zu Ubuntu 14.04. Und es läuft dort einfach alles so viel besser: schnellere Umschaltzeiten, weniger träges OSD, kein Ruckeln nach längerer Laufzeit. Auf Dauer kann das aber auch nicht die Lösung sein. Vielleicht probier ich demnächst mal noch Focal aus.

PS: Zu anderen Ausgabeplugins oder VA-API kann ich leider nichts sagen.

Zitat von pille2011

Habe folgendes versucht

Code

frank@stube-test:/etc/lirc$ sudo stop lircd
sudo: stop: Befehl nicht gefunden
frank@stube-test:/etc/lirc$

Der Befehl zum stoppen vom Lirc muss lauten:

sudo service lircd stop

Und dementsprechend war der Lirc dann bei deinen weiteren Schritten auch nicht beendet sondern lief noch...

Zitat von localhosthack0r

Das Eurosport FTA ist hängt mit der Übertragung der Olympischen Winterspiele zusammen, hier eine Meldung über freenetTV (DVB-T2):

http://www.digitalfernsehen.de…schluesselt.161495.0.html

Ob das für HD+ (Sat) auch irgendwo ofiziell verkündet wurde weiß ich nicht,....

Ja, gilt auch für Astra und im übrigen auch für TLC HD: https://www.infosat.de/digital…l-sselt-auf-astra-192-ost

Beide Sender sind bei mir seit Gestern ohne irgendwelches Zutun meinerseits (d.h. ohne Anpassung der CAID und Einsatz von verbotenen Plugins) hell.

Eurosport 1 HD;SES ASTRA:11111:HC23M5O35P0S1:S19.2E:22000:767=27:0;771=deu@106:0:0:12502:1:1043:0
TLC HD;BetaDigital:10964:HC23M5O35P0S1:S19.2E:22000:255=27:0;259=deu@106:32:0:10100:1:1033:0

Zitat von fnu

VDPAU geht auch mit den OSS nouveau Treibern für Nvidia, aber es fehlen halt genau der "heiße Scheiß", temporal, temporal-spatial, gab's auch nie für AMD.

Temporal Deinterlacing gibt's auch für AMD schon seit ein paar Jahren, siehe Grafikkarten 2015 - Nvidia/VDPAU noch sinnvoll bei Haswell CPU/GPU ?

Temporal Spatial war auch in Arbeit, aber keine Ahnung wie weit das mittlerweile gediehen ist.

Zitat von no_expert

Ich nutze den radeon Treiber....
Ich war der Überzeugung das nur der mit dieser APU funktioniert und ich hier vdpau nutzen kann.

Edit: amdgpu funktioniert schon mal nicht.

DIe APU Athlon 5350 kann wohl nicht mehr:

Code

DISPLAY=:0 glxinfo | grep GLSL
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.10

Ich hab auch nen Athlon 5350 und auch das selbe Problem mit softhddevice-openglosd. Laut https://www.x.org/wiki/RadeonFeature/ unterstützen die Kabini APUs sowohl Hardware- als auch (Kernel-) Treiberseitig OpenGL 4.5 (und damit auch GLSL 4.50). Sofern ich das bei meinen Recherchen damals richtig verstanden habe hängt die unter Linux tatsächlich untersützte GLSL Version aber vom Mesa Treiber ab. Und die hängen da traditionell etwas hinterher. Ich nutze aktuell die yaVDR 0.6 Pakte unter Ubuntu 14.04.5 mit aktuellem Mainline Kernel und dem Xenial Hardware Enablement Stack. Sprich Mesa 11.2 und somit auch nicht das neuste. Mehr wie GLSL 1.30 ist damit leider nicht drin. Ab Mesa 12.0 wird dann immerhin mal OpenGL 4.3 untersützt. Welche Mesa Version verwendest du denn bei dir?

Zwar nicht direkt mit yaVDR 0.6, aber mit Ubuntu 14.04.5 LTS und den Paketen von yaVDR 0.6. Läuft hier seit rund einem halben Jahr bestens. Ich hatte das davor auch bereits 2 Jahre lang genau so stabil laufen mit den yaVDR 0.5 Paketen unter Ubuntu 12.04 + Trusty HWE Stack, siehe Offiziell VDPAU mit AMD Grafikkarten.

Ubuntu 14.04 bringt im Gegensatz zu 12.04 grundsätzlich bereits von Haus aus alles mit was man zwingend für VDPAU mit Kabini bzw. dem radeon Treiber allgemein benötigt:
- Kernel Version >= 3.15.3 (für das radeon Kernel Modul)
- Mesa Version >= 10.1.3 (für den radeon Mesa Treiber)
- Kabini Firmware aus dem Paket firmware-nonfree

Aktuell läuft bei mir VDR v2.2.0 und SoftHDDevice v0.6.1rc1 (aus dem yaVDR 0.6 PPA) sowie Kodi v16.1 (aus dem team-xbmc PPA) auf dem Xenial HWE Stack (Mesa v11.2.0 + Kernel 4.4). Nicht dass es unbedingt nötig wäre, aber als aktiven Kernel fahr ich allerdings den neusten Ubuntu Mainline , aktuell v4.9.x.

Zitat von te36

Am liebsten haette ich eine umschaltloesung, die von menueintraegen kommt:

A) Was wuerde man denn heute als plugin nehmen, dass man im VDR menu einen eintrag mit namen hinkriegt der irgendein programm/script aufruft. Und den menueintrag dann auch passend in der menuliste plazieren laesst ? Script um VDR zu stoppen/KODI zu starten ist dann ja kein problem.

Das Externalplayer Plugin bietet diese Funktionalität. Gibt hier im Forum auch einige Beiträge dazu mit den entsprechenden Configs für das Plugin und Startscripten für Kodi.

Zitat von te36

B) Kriegt man dasselbe im KODI hin ? Also evtl. im KODI garnicht "Live TV" konfigurieren, sondern ebenso im Hauptmenu einen Eintragen, eg> "VDR" haben...

Idealerweise sollte man ja KODI/VDR nicht killen muessen beim umschalten, sondern irgendwie bloss suspenden, damit das umschalten besser flutscht, aber ich befuerchte mal, dass das nicht geht

Um via Externplayer Plugin automatisch zum VDR zurückzukehren muss man Kodi lediglich beenden. Das entspricht dann zwar nicht exakt dem was du willst, aber es funktioniert. Also zumindest im Zusammenspiel mit SoftHDDevice. Inwiefern sich das beim RPIHDDevice genau so verhält kann ich dir nicht sagen.

War ein Problem vom Sender. Ich hatte die Partie in SD verfolgt und es wurde während der Ausstrahlung vom Kommentator darauf hingewiesen dass man auf Eurosport HD Tonprobleme hat. Und man sollte dann ggf. für den Moment auf die SD Version umschalten wo die Probleme nicht vorhanden waren.

Zitat von johns

Zu AMD kann ich nicht viel sagen, da ich es nicht richtig verfolgt habe,
Mein letzter Stand ist, daß es immer noch keine gute Deinterlacer gibt.
Aber BOB war ausreichend gut.

Es gibt seit geraumer Zeit auch nen Temporal Deinterlacer für AMD [1] [2], der sich hinter dem Temporal Deinterlacer von Nvidia imho nicht zu verstecken braucht.

Und wenn ich mir die folgende Unterhaltung im Radeon Channel anschaue, bin ich mir nicht sicher ob es sich dabei nicht sogar schon um Temporal Spatial Deinterlacing handelt, mit dem hier das VDPAU "Temporal" Profil impelentiert:

Zitat

03:39 #radeon: < zgreg> I haven't fully implemented the spatial filter yet, but without that it should be plenty fast
03:42 #radeon: < fritsch> iirc correctly without the spatial filter the deinterlacing actually does not reall do much?
03:42 #radeon: < fritsch> when you implemented the algorithm you showed me last time?
03:51 #radeon: < zgreg> fritsch: that's not correct, it's much better than bob
03:51 #radeon: < zgreg> the spatial filter improves areas with movement considerably though
03:56 #radeon: < fritsch> zgreg: in that case, you could tell the one "temporal"
03:56 #radeon: < fritsch> zgreg: and the other temporal / spatial
03:56 #radeon: < zgreg> yes, that's the plan

Alles anzeigen

http://people.freedesktop.org/~cbrill/dri-log/?channel=radeon&date=2013-09-18

Die Unterhaltung war ca. 3 Monate bevor die entsprechenden Patches hochgeladen wurden. Und wenn nicht sollte Temporal Spatial ja auf jeden Fall auch noch in Arbeit sein. Müsste man ggf. mal genau nachfragen.

Ich hab ja seit längerem einen Kabini (Athlon 5350) auf dem MSI AM1I Board im Betrieb, siehe Radeon/VDPAU Thread (dort gibt's auch Messwerte vom qvdpautest). Ich fahre mittlerweile Kernel 3.18 und hab keine Probleme mehr. Vorher lief das soweit zwar auch schon alles schon ganz gut, allerdings gab's ab und an mal noch ne Kernel Panic wegen dem radeon Modul. Stromverbrauch mit SoftHDDevice - heute neu gemessen - liegt bei 20,5W bei 576i (DMAX), 21,6W bei 720p (ARD) und 22,4W bei 1080i (ServusTV). Zum Vergleich: auf dem Desktop im Idle bei gestopptem VDR sind's 13,6W. Unter Last war der Verbrauch bei allen Formaten bei früheren Messungen auch schon mal ca. 1-1,5W besser. Allerdings gab es seitdem Änderungen an den Powerstates mit Kernel 3.17 und ich habe einen Atric IRWakeupUSB eingebaut sowie den RAM gewechselt von DDR3-1066@1.5V zu DDR3-1600@1,35V. Keine Ahnung was da jetzt genau welchen Einfluss hatte. Mit Powertop konnte ich damals bei den Tests mit allen aktivierten Optionen im Idle auch noch 2-3W mehr rausholen. Allerdings hat dann meine Logitech K400 Tastatur extrem träge reagiert und danach habe ich mich nicht mehr näher damit beschäftigt welche der einzelnen Optionen sinnvoll wären weil ich auch ohne Powertop schon zufrieden war. Es gäbe da also auch noch durchaus Potential für weitere Optimierungen.

Ich habe zwar keinen direkten Vergleich, aber ich bilde mir ein dass das Temporal Spatial Deinterlacing auf der GT220 von meiner vorherigen Nvidia Kiste schon noch nen Tick besser ausgesehen hat. Aber was das Deinterlacing angeht ist das wohl jammern auf hohem Niveau. Da vermisse ich eher das HQ Upscaling. Mir war aber in erster Linie wichtig dass sich das ganze deutlich unter 25W bewegt und in ein ITX Gehäuse passt (ich hab dieses: Silverstone Milo ML05). Nvidia + DD Cine geht im ITX Format ja quasi nicht. Man braucht dann immer noch 2 PCIe Steckplätze und ITX Mainboads mit FullSize Mini PCIe Slot für die Octopus Bridge sind äußerst rar gesät...

Zitat von mike777

fstab:

Code

/dev/sr0            	/cd 	auto	user,noauto         	0   	0

Kannst du mal die DVD von Hand nach /media/... mounten, z.B. nach /media/dvd und schauen ob das XBMC sie dann vielleicht erkennt? Ich vermute mal dass das XBMC die dort erwartet. Wie in dem anderen Thread geschrieben funktioniert das bei mir ja mittlerweile mit der Erkennung. Und bei mir wird eine DVD nach dem Einlegen von Ubuntu ohne weiteres Zutun dynamisch nach /media/<VOLUME> gemountet.

Das Problem hatte ich auch mal. Eigentlich sollte es beim Confluence Skin ja so sein: Man legt eine DVD ein, und es erscheint im Hauptmenü ein Eintrag "Disc Abspielen" mit Untermenü "Öffnen/Schließen". Und zwar zwischen "Programme" und "System", und nicht etwa als Untermenü von "Video". Das funktionierte bei mir allerdings nur dann, wenn der eingelegte Datenträger vom Betriebssystem (bei mir Ubuntu 12.04) nach dem Schließen des Trays auch direkt automatisch eingebunden wurde. Dazu musste ich unter "Einstellungen" -> "Wechseldatenträger- und Medieneinstellungen" -> "Datenträger" die Option "Wechselmedien beim Einlegen einhängen" aktivieren. Aber keine Ahnung wie man das unter yaVDR macht.

Eine Skin-Einstellung um das "Disc Abspielen" immer anzeigen zu lassen gibt es für das Confluence Skin nicht. Man kann allerdings auch in der Datei "/usr/share/xbmc/addons/skin.confluence/Home.xml" rumpfuschen. Wenn man dort nach dem DVD Code sucht und dort das <visible>System.HasMediaDVD</visible> entfernt, wird der Hauptmenü-Eintrag immer angezeigt unabhängig davon ob eine Disc eingelegt ist bzw. korrekt erkannt wurde oder nicht.

Ah ok. Super, danke für die Aufklärung! Dann nutzt Boss666 ja doch auch libav, sorry für die Konfusion. Damit scheidet ffmpeg als Ursache aus und die Suche geht wieder von neuem los...

Hmm, komisch... Ich nutze ja libav weil Ubuntu 12.04 standardmäßig damit daher kommt. Allerdings ohne dass ich das SoftHDDevice extra dafür selbst gebaut hätte bzw. hätte müssen. Ich hab das ganz normale yaVDR Paket aus dem Testing PPA drauf. Wenn yaVDR 0.5 aber doch ffmpeg nutzt (oder etwa nicht?!?), müsste doch das SoftHDDevice demnach auch für ffmpeg gebaut sein. Aber wieso funktioniert bei mir libav dann trotzdem

Ich war sowieso gerade letztens erst hier im Forum auf das Thema libav/ffmpeg bei SoftHDDevice gestoßen und frage mich die ganze Zeit schon was denn für SoftHDDevice die bessere Lösung ist und warum? Soweit ich das jetzt sehe braucht's für ffmpeg unter Precise sowieso schon mal eine externe Paketquelle. Und für ffmpeg >= 2.2 brauchst's dann auch noch ein neueres SoftHDDevice als das aus yaVDR Stable bzw. Testing mit entsprechendem Fix. Lohnt sich der Aufwand überhaupt?

Ich würd auch auf ffmpeg tippen. Denn was mir aufgefallen ist: Boss666 nutzt mit yaVDR 0.5 ffmpeg. Ich nutze unter meinem Ubuntu + yaVDR PPA hingegen libav. Und bei mir läuft SD Material aber ja ohne Probleme, obwohl wir ansonsten seit der Aktualisierung des yaVDR Stable Repos ja quasi auf die gleiche Art unterwegs sind...

Brauchst du jetzt (oder auch in absehbarer Zeit) eine Low Profile Karte? Dann würd ich nämlich eher die Zotac empfehlen. Die ist zwar ein paar Euro teuerer, hat aber im Gegensatz zu Palit und Gainward auch ein LP Slotblech mit dabei. Das müsstest du sonst teuer nachkaufen. Wie das bei den Karten von ASUS und PNY aussieht weiß ich nicht.

Zitat von n1k0

1 gb = 65 W
2 gb = 75 W

Das sind Modelle mit dem alten Nvidia GF108 Chip. Wie von fnu bereits erwähnt solltest du nach einem Modell mit GK208 Chip Ausschau halten:
http://geizhals.at/de/?cat=gra16_512&xf=1439_GT+730+%28GK208%29~1439_GT+630+%28GK208%29#xf_top
Die haben ne TDP von nur 23-25W. Ob nun GT 630 oder GT 730 ist wie ebenfalls oben bereits erwähnt egal.

Zitat von Boss666

Mit dem Konglomerat kam kein Bild. Da ich auch per ssh nicht mehr auf den VDR drauf komme, wird es wohl Probleme mit der Hardware (Ethernet-Onboard) im Zusammenhang mit dem Kernel geben. Ich werde mal schauen, dass ich auch testweise mal den 3.15.3er Mainline-Kernel installiert bekomme.

'Kein Bild' heißt kein TV-Bild vom VDR? Oder lief der xserver auch schon nicht?

Zu dem Netzwerkproblem: Abgesehen davon, dass bei dem LTS Trusty Stack Firmware-Dateien für das r8169 Modul fehlen (diese hatte ich mir aus dem Debian Wheezy Paket firmware-realtek geholt), scheint da ab Kernel 3.13 irgendwas mit dem r8169 Modul für die Realtek NICs nicht mehr zu passen. Ich hatte nach dem Upgrade auf den Trusty Stack auf 2 verschiedenen Systemen ebenfalls Probleme damit. Bei der Realtek RTL8111DL auf dem MSI 785GM-E65 von meinem Produktiv-VDR half es das r8169 Paket zu Blacklisten und stattdessen das r8168-dkms Paket zu nutzen. Da dies aber momentan gegen Kernel 3.15 nicht mehr baut, war das für die Realtek RTL8111G auf dem MSI AM1I von meinem Kabini System aber keine Lösung. Nachdem ich bei dem System im syslog Fehler vom dnsmasq entdeckt hatte, konnte ich die Probleme dort vorerst damit gelösen dass ich dnsmasq im NetworkManager einfach deaktiviert hab. Nachträglich hab ich dann gesehen dass das hier z.B. auch geholfen hatte.

Zitat von Boss666

Ist halt noch der wackelige Punkt mit SoftHDDevice aus dem yaVDR Stable- oder doch besser Testing-Repo.

Daran sollte es dann jetzt auch nicht mehr scheitern
Updates für yaVDR 0.5 stable: VDR 2.0.6, XBMC Gotham, Lirc usw.