Posts by olebowle

Hi, sorry für die Verzögerung. Ich war im Urlaub und konnte es nicht testen. Es klappt jetzt wieder mit der aktuellen Version. Vielen Dank! Für shady ist das folgende Kommando notwendig:

# sed -i 's|<?xml version="1.0" encoding="UTF-8"?>|<?xml version="1.0" encoding="UTF-8" standalone="no"?>|' globals.xml setup.xml xmlfiles/displayreplay.xml xmlfiles/displaymenu.xml xmlfiles/plug-setup-skinpreview.xml xmlfiles/plug-weatherforecast-weatherforecastdetailcurrent.xml xmlfiles/displayaudiotracks.xml xmlfiles/plug-plex-detail.xml xmlfiles/plug-tvguideng-root.xml xmlfiles/displaychannel.xml xmlfiles/plug-tvguideng-recmenu.xml xmlfiles/plug-tvguideng-detail.xml xmlfiles/plug-weatherforecast-weatherforecast.xml xmlfiles/plug-weatherforecast-weatherforecastdetailhourly.xml xmlfiles/displaymessage.xml xmlfiles/displayvolume.xml xmlfiles/plug-weatherforecast-weatherforecastdetaildaily.xml xmlfiles/plug-plex-root.xml themes/default/theme.xml themes/orange/theme.xml

kamel5 Du hast Recht. Mit metrixhd habe ich ähnliche (mehr) Fehlermeldungen:

Sep 25 11:14:52 htpc vdr[1401]: [1401] initializing plugin: skindesigner (1.2.25): Skin Designer
Sep 25 11:14:52 htpc vdr[1401]: [1401] starting plugin: skindesigner
Sep 25 11:14:52 htpc vdr[1401]: [1401] setting current skin to "metrixhd"
Sep 25 11:14:52 htpc vdr[1401]: [1401] loading /var/lib/vdr/themes/metrixhd-default.theme
Sep 25 11:14:53 htpc vdr[1401]: [1401] skindesigner: Error in XML: standalone: normalization of attribute text on drawtext by external subset declaration
Sep 25 11:14:53 htpc vdr[1401]: [1401] skindesigner: Error in XML: standalone: normalization of attribute text on drawtext by external subset declaration
Sep 25 11:14:53 htpc vdr[1401]: [1401] skindesigner: Error in XML: standalone: normalization of attribute text on drawtext by external subset declaration
Sep 25 11:14:53 htpc vdr[1401]: [1401] skindesigner: Error in XML: standalone: normalization of attribute text on drawtextbox by external subset declaration
Sep 25 11:14:53 htpc vdr[1401]: [1401] skindesigner: Error in XML: standalone: normalization of attribute text on drawtextbox by external subset declaration
Sep 25 11:14:53 htpc vdr[1401]: [1401] skindesigner: Failed to validate XML File
Sep 25 11:14:53 htpc vdr[1401]: [1401] skindesigner: error reading displaychannel template, aborting
Sep 25 11:14:53 htpc vdr[1401]: [1401] skindesigner: error during loading of templates - using LCARS as backup

Es ist nicht dringend. Ich update dann erstmal nicht und stehe bereit für Tests!

Unter Arch wird nun die Version 2.15.0 von libxml2 angeboten. Ich setze hier shady als Skin ein (git commit 230f25efb5969b79a6426dc2a236a89b3c899cf7, ohne Anpassungen)

Nach dem Update fällt der Skindesigner auf LCARS zurück, die Fehlermeldungen im Log lauten:

Sep 22 05:54:39 htpc vdr[1139]: [1139] loading plugin: /usr/lib/vdr/plugins/libvdr-skindesigner.so.9
Sep 22 05:54:39 htpc vdr[1139]: [1139] initializing plugin: skindesigner (1.2.25): Skin Designer
Sep 22 05:54:39 htpc vdr[1139]: [1139] starting plugin: skindesigner
Sep 22 05:54:40 htpc vdr[1139]: [1139] skindesigner: Error in XML: standalone: normalization of attribute text on drawtext by external subset declaration
Sep 22 05:54:40 htpc vdr[1139]: [1139] skindesigner: Error in XML: standalone: normalization of attribute text on drawtext by external subset declaration
Sep 22 05:54:40 htpc vdr[1139]: [1139] skindesigner: Failed to validate XML File
Sep 22 05:54:40 htpc vdr[1139]: [1139] skindesigner: error reading displaychannel template, aborting
Sep 22 05:54:40 htpc vdr[1139]: [1139] skindesigner: error during loading of templates - using LCARS as backup

Mit der Version 2.14.5 sah es noch wie folgt aus:

Sep 22 05:27:54 htpc vdr[743]: [743] loading plugin: /usr/lib/vdr/plugins/libvdr-skindesigner.so.9
Sep 22 05:28:01 htpc vdr[743]: [743] initializing plugin: skindesigner (1.2.25): Skin Designer
Sep 22 05:28:01 htpc vdr[743]: [743] starting plugin: skindesigner
Sep 22 05:28:04 htpc vdr[743]: [743] skindesigner: invalid factor {transLists} in expression "{transLists}"
Sep 22 05:28:07 htpc vdr[743]: [743] skindesigner: invalid factor {timerwidth} in expression "{timerwidth}*{areawidth}*0.9/1000"
Sep 22 05:28:07 htpc vdr[743]: [743] skindesigner: invalid factor {timerwidth} in expression "{timerwidth}*{areawidth}*0.9/1000"
Sep 22 05:28:07 htpc vdr[743]: [743] skindesigner: invalid factor {timerwidth} in expression "{timerwidth}*{areawidth}*0.9/1000"

Ist der XML Parser jetzt strikter geworden? transLists ist nur in xmlfiles/displaychannel.xml zu finden. Ich habe bereits versucht transparency="{transLists}" durch transparency="0" in dieser Datei zu ersetzen, aber das hat nichts gebracht.

timerwidth findet sich nur in xmlfiles/plug-tvguideng-recmenu.xml, aber das Log von Version 2.15.0 beklagt sich ja über einen Fehler im displaychannel Template.

Wie kann ich das am besten debuggen?

Very interesting. Currently I'm running vdr-softhddevice from AUR (author ua0lnj v1.9.7). I applied the patch and it seems the segfaults are gone! I guess the GT430 can stay for now. Thanks!

Hallo liebe Gemeinde,

seit Ende letzten Jahres werden die Fermi Grafikkarten nicht mehr offiziell von Nvidia unterstützt: https://nvidia.custhelp.com/app/answers/de…cy-gpu-releases

Bisher verrichtete bei mir zuverlässig eine GT430 ihre Dienste. Seit dem Update von glibc 2.36 auf 2.37 startete allerdings zunächst der X-Server nicht mehr. Mit einem Trick im Archlinux Forum (https://bbs.archlinux.org/viewtopic.php?id=283327) konnte ich diesen wieder zum Laufen bringen. Allerdings stürzte dann aller 2-3 Minuten der vdr mit einem Segfault ab. Ich habe nun zunächst wieder auf glibc 2.36 downgegraded. Allerdings ist das gerade bei einer Rolling Release Distribution keine dauerhafte Lösung.

Der Post soll zunächst als Warnung für Nutzer von Fermi Grafikkarten dienen und zweitens würde ich gern in Erfahrung bringen, welche Nvidia Grafikkarten aktuell empfohlen werden. Die GT1030 habe ich des Öfteren gelesen. Eine MSI GT 1030 2GH LP OC sagt mir z.B. zu.

Ist diese Grafikkartenempfehlung noch aktuell (es soll nur Full-HD Inhalte abgespielt werden)?

Der komplette Stack cxxtools, tntnet und vdr-live muss in dieser Reihenfolge neu gebaut werden, weil diese Pakete noch gegen libnsl.so.2 linken. cxxtools-3.0-1 baut nicht, deshalb habe ich cxxtools-git aus dem AUR genommen.

Naja Zeile 16 und 17 aus Post 36 sagen doch aber, dass inputlircd noch auf /dev/input/event9 zugreift?

Ok, du hast inputlircd zwar gekillt, dann aber den Rechner neu gestartet. Kann es sein, dass das inputlircd bei dir beim booten automatisch mit gestartet wird und sich dann die events wieder krallt?

Dein Problem ist nicht der xserver, sondern inputlircd. Wenn du mit ir-keytable oder evtest spielen willst, musst du vorher inputlircd beenden.

Deine modprobe Konfiguration sollte ja folgendermaßen aussehen:

cat /etc/modprobe.d/cx23885.conf
options cx23885 card=49

Folglich sollte im Log dann:

CORE cx23885[0]: subsystem: 14f1:8512, board: DVBSky S950 [card=49,insmod option]

anstelle von stehen:

CORE cx23885[0]: subsystem: 14f1:8512, board: UNKNOWN/GENERIC [card=0,autodetected]

Kannst du das mal durch hinzufügen/löschen der Datei und reboot verifizieren?

Welche Kernel Version hast du denn jetzt? Und was genau funktioniert beim Bauen des Treibers nicht?

Achso, die Datei ist einfach nicht mehr verlinkt auf deren Seite. Wenn man den Link kennt, kann man die Datei aber noch herunterladen. Kann natürlich sein, dass die irgendwann gelöscht wird.

Die option mit card=49 hat für dich jetzt den Charme, dass du das Treiberpaket nicht mehr bauen musst, selbst wenn ein neuer Kernel benutzt wird.

Stimmt mit der insmod option ist es noch einfacher. Allerdings kann sich die card Nummer geändert haben. Einfach mal in der Ausgabe von 'dmesg | card=' nach der S950 suchen und die entsprechende Nummer verwenden.

Probier mal folgendes:

wget http://www.dvbsky.net/download/linux/media_build-bst-151028.tar.gz
tar xvf media_build-bst-151028.tar.gz
cd media_build-bst
ln -srf v4l/sit2_op.o.x$(uname -m | grep -o "[0-9]\{2\}$") v4l/sit2_op.o
wget -qO- "https://aur.archlinux.org/cgit/aur.git/plain/4.3-compat.patch?h=media-build-dvbsky&id=90ec58e04b03e7b280a9d5baf977d65bb14cf2cd" | patch -p1 -i-
wget -qO- "https://aur.archlinux.org/cgit/aur.git/plain/4.4-compat.patch?h=media-build-dvbsky&id=90ec58e04b03e7b280a9d5baf977d65bb14cf2cd" | patch -p1 -i-
wget -qO- "https://aur.archlinux.org/cgit/aur.git/plain/add_s850.patch?h=media-build-dvbsky" | patch -p1 -i-
make
sudo make KDIR26="/lib/modules/$(uname -r)/updates/kernel/drivers/media" media-install

Welchen Kernel setzt du momentan ein (uname -a)? Dann kann man sagen, welchen compat Patches du brauchst.

Die ids identifizieren die einzelnen Commits (siehe https://aur.archlinux.org/cgit/aur.git/l…ia-build-dvbsky).

Interessant, darf man fragen, wo der Patch liegt? Ich habe auf Anhieb keinen Patch in eurem git gefunden.

Es kommt sowohl als auf die Version der Karte (V2 vs. V3), als auch auf das Alter der Karte drauf an. Bei einigen läuft es mit den mitgelieferten Modulen ootb, nachdem man die Firmware Dateien abgelegt hat.
Die alten V2 Karten haben den älteren Tuner m88ts2020 anstatt m88ts2022, der neueren V2 Karten. Meine alte V2 läuft auch nur mit dem Treiberpaket. Mit den Modulen eines aktuellen Kernels (ohne Treiberpaket) wird die Karte zwar erkannt und entsprechende Knoten in /dev/dvb/ angelegt, allerdings läuft das Tuning dann immer in ein Timeout. Ich hatte das vor einiger Zeit bereits auf der ML angesprochen, so richtig viel hat sich aber nicht getan: https://www.spinics.net/lists/linux-media/msg87673.html.
Es wäre schön, wenn sich alle betroffenen Benutzer mal auf der Mailingliste "beschweren" könnten. Ich glaube es fehlt nicht mehr viel, sodass auch die älteren Karten unterstützt werden. Das Anpassen des media-build trees an neue Kernel wird auch immer aufwendiger. Für den 4.6er Kernel wird es wieder ein größerer Patch werden.
Und ja die Fernbedienung läuft bei mir auch nicht mehr. Das ging aber definitiv mit einem früheren Kernel und dem Treiberpaket mal. Wie gesagt, die richtige Lösung wäre, dass wir uns mal an die Mailingliste wenden, wie ich es bereits vor einem Jahr versucht hatte.

Testweise kannst du auch mal das Treiberpaket von dvbsky.net anstelle der mitgelieferten Kernelmodule testen. Bei meiner S952V2 funktioniert es nur mit Ersterem.

$ wget http://dvbsky.net/download/linux/media_build-bst-160430.tar.gz
$ tar xvf media_build-bst-160430.tar.gz
$ cd media_build-bst-160430
$ ln -sr v4l/sit2_op.o.x$(uname -m | grep -o "[0-9]\{2\}$") v4l/sit2_op.o
$ wget -qO- "https://aur.archlinux.org/cgit/aur.git/plain/4.5-compat.patch?h=media-build-dvbsky" | patch -p1 -i-
$ make
# make KDIR26="/lib/modules/$(uname -r)/updates/kernel/drivers/media" media-install

Das installiert die neuen Module auch gleich in den updates Ordner, sodass die bestehenden Module nicht überschrieben werden. Die linux-headers und perl-proc-processtable müssen installiert sein, sonst läuft das ganze nicht sauber durch.

Hab gerade mal bei meiner S952 geschaut. Auch da wird der IR-Empfänger mit dem gepatchten media_build-bst-151028 nicht mehr erkannt. Mir ist das bist jetzt noch nicht aufgefallen, da ich den Empfänger auf dem Mainboard nutze. Das hat aber definitiv schon einmal funktioniert. Schön ist was anderes.

Das Treiberpaket sollte mal wieder auf einen aktuellen Kernel ordentlich rebased werden. Viel Hoffnung habe ich allerdings nicht, da ein Großteil der DVBSky Karten von aktuellen Kerneln mehr oder weniger unterstützt werden.

Was sagt denn ir-keytable bzw. ir-keytable -r?

Ja genau, die Autodetection wird durch den von dir verlinkten Patch (#1) erreicht.

Wird die Karte jetzt auch ohne die option automatisch erkannt?

Und ja, du musst das Paket bei jedem Kernelupdate neu bauen. Für das 4.5er Release wird übrigens auch ein kleiner Patch gebraucht, den ich dann noch einchecken werde.