Beiträge von VdrMize

Hallo zusammen,

nachdem mein Intel-NUC (auf Basis Debian Stretch) mit va-api 1.6.1 und VLC auch aufgenommenes HD Material
ohne Probleme wiedergeben kann, gehe ich davon aus daß va-api auch auf Broadwell brauchbar läuft.

Nun wird es Zeit das vdr-sxfe vom Rechner runterzuschmeißen (da bei HD-Sendern im Sekundenrhytmus das Bild
ausfällt, und sich erst klötzchenweise wieder aufbaut). Das Verhalten krieg ich nicht weg ...

Jetzt habe ich eine Frage wie ich Softhddevice in den automatischen Start meines Rechners einbinde ...

• Wenn ich unter Root den VDR manuell starte (vdr -P"softhddevice -v va-api -a hw:1,0 -f" -v /video/vdr)
  hab ich Bild und Ton. Soweit prima
• Dann fehlen mir aber all die anderen VDR Parameter, die ich bisher über die /etc/vdr/conf.d/00-vdr.conf
  angegeben habe ...
• Wenn ich die Softhddevice Parameter in die /etc/vdr/conf.avail/softhddevice.conf schreibe, wirken
  sie aber nicht ...

Frage 1: Müßte Softhddevice die Parameter aus der /etc/vdr/conf.avail/softhddevice.conf mitbekommen?
Es scheint, daß es (ob VDR oder das Plugin) das nicht erkennt, und das Plugin nicht startet ...

Frage 2: Wenn ich mit "ps -ef" den VDR Prozess ansehe, sehe ich ja nicht die wirklich aufgerufene Kommandozeile.
Wie sehe ich was dem VDR beim Start wirklich mitgegeben wurde?

Frage 3: Liegt es an der Syntax die ich in softhddevice.conf verwende?

Für einen Tip wäre ich dankbar ...

m.f.G.
Michael

Hallo cinfo,

das mit dem "bei Sendern in Standardauflösung mit vaapi (ARD, ZDF, ...) ist Bild und Ton o.k." nehm ich zurück.
Nach 3-5 min ist auch dort der Ton weg - also insgesamt läuft das mit untengenannten Versionen nicht stabil ...

Ich muß mal schauen, wie ich das vaapi konfigurieren kann. Vielleicht kann ich Filter etc. erst mal wegblenden.

m.f.G.
Michael

Hallo cinfo,

vielleicht noch eine Frage:

Ist Euch etwas bekannt, daß vaapi auf Broadwell seit einiger Zeit nicht mehr laufen soll (vielleicht auch nur bei gewissen Auflösungen)?

Ich such nämlich gerade einen Fehler, daß ich Sender in Standardauflösung mit vaapi anschauen kann (ARD, ZDF, ...), Bild und Ton ist o.k.
Wenn ich diese Kanäle aber in HD anwähle, bricht das Bild alle 1-2 Sekunden zusammen (kurzzeitig ist der Bildschirm komplett schwarz),
und wird dann in Klötzchen-Gruppen wieder aufgebaut, bis wieder alles da ist. Wenn nach 1 Sekunde wieder alles komplett da ist, fängt
das Spiel gleich wieder von vorne an ...

Ich verbinde mich mit vdr-sfxe mit dem VDR, und die eigentliche Bild- und Tonausgabe erfolgt über vdr-sfxe. Das System sieht wie folgt aus:

• Debian Sid mit Kernel 4.2 ( 4.2.0-1-amd64 #1 SMP Debian 4.2.3-2), i965-driver und libva
  alles auf Version 1.6.1-1, xserver-xorg-viedo-intel auf 2.99.917-2, VDR 2.2.0-4, xinelibout-
  put-sxfe 1.1.0+cvs20150907-3 (ist ja eigentlich alles soweit ganz aktuell ...)
  

  
  

• Wenn ich mit VDR das Programm 1-2 Minuten aufnehme, und die Aufnahme dann mit VDR
  wieder abspiele, gleiches Verhalten ...
  

  
  

• Wenn ich VLC zum Abspielen nutze (auch dort ist vaapi eingestellt), ruckelt nichts. Das
  Bild kommt ganz sauber und flüssig rüber (auch mit Ton). VLC nutzt ja aber nur die HW-
  Beschleunigung von va-api, nicht aber die Filter etc.

Nicht daß da noch Fehler in va-api bekannt sind (auf Broadwell), und ich such mir hier den Wolf ...

m.f.G.
Michael

Hallo cinfo,

danke für Deinen Hinweis. Obwohl ich´s nicht glauben konnte, hab ich mittlerweile (aus Verzweiflung) mit RTC auf UTC experimentiert, und schon geht es ...

• Die Uhrzeit muß _zwingend_ auf UTC stehen, ich seh´s ja ein.
• RTC wakeup from S5 muß aus sein.
• Man darf die ACPI-Wakeupzeit nur einmal nach /sys/class/rtc/rtc0/wakealarm schreiben (macht man das zwei mal, meckert er jetzt: Device wird schon genutzt) => der Fehler kam bei local time nicht, d.h. jetzt schreibt er die Zeit auch wirklich.
• Stellt man die Uhr mit dem Script zwei Minutein in die Zukunft, zeigt es vor dem Ausschalten die Wakeupzeit korrekt an (bei local time waren es 5 min in die Zukunft, die cat /proc/driver/rtc als Wakeupzeit anzeigte)
• Und das schönste - er geht nach zwei Minuten wieder an !!!

Da ist im Linux noch an verschiedenen Stellen in Scripten still und heimlich von UTC ausgegangen (eine Stelle hatte ich gesehen), mit local hätte man zulange experimentieren müssen um all diese zu finden (vielleicht hätte ich auch mal 62 min in die Zukunft stellen müssen, daß 2 min rauskommen ...)

Das läuft jetzt. Laß ich so. Vielen Dank.

m.f.G.
Michael

Sundtek liefert ja auch ein sundtek.service File für systemd bei - das habe ich leider nicht zum Laufen gebracht.

Aber ich habe ein Skript geschrieben, das wartet bis das DVB Device erkannt wird, und das unter ExecStartPre im vdr.service File angegeben.
Es dauert jetzt in etwa 11 sec. bis die DVB Treiber gefunden werden. Dann läuft der VDR Start weiter, und findet sofort das DVB Device.

Das Thema ist für mich damit erst mal erledigt ...

m.f.G.
Michael

Hallo Lars,

Danke für den Tip (mich hat gewundert, daß er mit ps -ef zwar keine Parameter anzeigt, aber einige Plugins doch angegeben haben mußte, sonst käme ich ja mit vdr-sxfe nicht ran ...).

Drei Fragen:

• heißt das, "/etc/default/vdr" ist in Zukunft wirkungslos? (zumindest die Options die ich dort angebe verpuffen; das ENABLED und das ENABLE_SHUTDOWN auch?)
• Kommt das durch den Start mit systemd (und vdr.service), daß dadurch "/etc/default/vdr" obsolete wird?
• Muß ich an dem systemd Init-Script feilen (/etc/systemd/System/multi-user.target.wants/vdr.service), was Debian standardmäßig mitbringt, oder geht das alles über /etc/vdr/conf.d/00-vdr.conf?

Hier das vdr.service File das Debian aktuell installiert (user /home/vdr Verzeichnis gibt´s keines, falls man das bräuchte (hab ich im Forum gefunden); hab ich jetzt manuell angelegt)

m.f.G.
Michael

Hallo zusammen,

ich hab mir die letzten Tage einen VDR auf Basis Debian Stretch (sid) frisch installiert, nach der Anleitung von //wiki.debian.org/VDR.
Das lief auch ziemlich gut, weil da alle aktuellen Pakete aus einem Stand drin sind.

Meine zwei Probleme:

• SID wartet im Hochlauf nicht auf meinen Sundtek USB DVB-C Stick. Wenn der VDR automatisch gestartet wird (durch die SSD ist dies bereits 2-3 Sekunden nach dem Boot-Beginn, meldet er "kein DVB Device gefunden". Wenn ich nun vdr-sxfe starte, kommt: "Kanal nicht verfügbar". Wenn ich später den VDR mit "invoke-rc.d vdr stop" / "invoke-rc.d vdr start" neu starte, wird das DVB-Device gefunden, vdr-sxfe zeigt dann auch ein Bild.
  

  
  

• Zudem scheint es, daß das "/etc/default/vdr" Config-File nicht korrekt ausgewertet wird, denn wenn ich mit "ps -ef | grep VDR" nach VDR Prozessen suche, wird mir ein "usr/bin/VDR" ohne Parameter angezeigt. Da hat er aus dem Config File nichts übernommen (z.B. das dort eingestellte Video-Verzeichnis, oder den lirc). Wer weiß wo ich den Start des VDR finde, und warum er das File nicht nehmen könnte

m.f.G.
Michael

p.s. Mein Problem ist wahrscheinlich, daß mir das systemd (und die Hintergründe nicht bekannt sind). Rufe ich "/etc/init.d/vdr start" auf, kommt "Starting vdr (via systemctl): vdr.service". Ach ja. Und was heißt das? Und warum ignoriert er die Parameter aus der "/etc/default/vdr" ???

Hallo Albert,

muß mich bei Dir entschuldigen - stimmt wirklich: es läuft nur mit UTC (hätt ich nicht geglaubt, weil ich meinte ihn früher mit locale hinbekommen zu haben. Da mag ich mich aber täuschen).

Hab gestern nochmal die ganzen Einstellungen überprüft - in manchen Linux Scripten wird einfach von UTC ausgegangen (eine Stelle hab ich gefunden, es gibt aber scheinbar mehrere)

• WakeUpOnRtc im BIOS ausschalten
• hwclock --systohc --UTC => damit merkt sich (wahrscheinlich vor allem) Linux: RTC ist im UTC Mode
• dann mein script starten (was 2x die Wakeupzeit nach /sys/class/rtc/rtc0/wakealarm schreibt
• dann Fehlermeldung beim 2. Schreiben nach /sys/class/rtc/rtc0/wakealarm (device ist schon belegt; bei dem NUC Mainboard reicht also nur 1x schreiben) => hatte ich vorher noch nie gesehen!!! also macht er jetzt sogar etwas.
• mit cat /proc/driver/rtc die Uhrzeit kontrollieren (sie ist jetzt wirklich nur 2 min in die Zukunft wie im Script eingestellt - und nicht wie bei locale 5 min in die Zukunft (da war ein weiterer Effekt am Werkeln))
• poweroff eingeben - und nach 2 min schaltet die Kiste wirklich wieder ein. Spitze!!!

Hab im Forum einen Beitrag gefunden, wie man Windows 7 auch beibringt, mit RTC und UTC klarzukommen (nicht ganz: Win-7 stellt dann die RTC nichtum, wenn die Zeit nicht paßt) aber mein Rechner läuft die meiste Zeit mit Linux als VDR

Vielen Dank für die Tip´s ...

m.f.G.
Michael

Hallo zusammen,

hab das jetzt mit einem Linux 4.2 (Debian Testing) probiert, die Uhr steht auf UTC - hilft alles nichts ...

Hat keiner einen Tip???

M.f.G.
Michael

Hallo Albert,

Wenn es auf der Intel Seite heißt:

Zitat

Enabling ErP ... disables all of the following wake events:

•In the S4 sleep state (hibernate)
•In the S5 sleep state except for the power button

The system only wakes from the S4 sleep state, or the S5 sleep state, with the power button.
Disabling ErP allows the system to wake on events other than only the power button (wake-on-LAN, wake-on-PS2).

... und mein Rechner automatisch (per RTC) aus dem Tiefschlaf erwacht (und nicht nur per Power-On Button), dann ist doch der ErP Mode bei mir schon abgeschaltet. Oder?

Ich vermute, der ErP Mode wird mittlerweile mit dem BIOS "Wakeup from S5" oder "Wake on LAN from S4/S5" automatisch disabled (und Wake on LAN war bei mir immer eingeschaltet) Da spuckt doch bei mir noch etwas ganz anderes hinein ...

Das ist aber ein guter Tip mit dem ErP - ich meß heute Abend mal die Stromaufnahme ...

Frage zum Thema Linux und UTC (ja, das ist normalerweise die bevorzugte Einstellung. Ich habe aber ein DualBoot System mit Windows, und auf meinen anderen Rechnern hab ich das auch ohne UTC zum Laufen bekommen): Das Booten wird ja von Linux nicht disabled, wenn nicht UTC gewählt ist. Oder? Und ob UTC aktiv ist oder nicht weiß das BIOS gar nicht, und die Weckzeit ist ja nicht um 1 Stunde verkehrt, sondern um 1 Tag +/- etwas. Seltsam.

m.f.G.
Michael

Hallo ATD,

ErP find ich im BIOS nicht. Wie könnte das noch heißen??? (und liegt das echt am Power Mode, denn von RTC bootet er ja)

Meinst Du mit NIC den NetzwerkInterfaceController im Chipsatz, und damit Wake on LAN muß enabled sein?

m.f.G.
Michael

p.s. interessant ist, die veränderte Wakeupzeit nach dem Booten (aus 21:34:49 wird 21:24:52 des nächsten Tages !!! )

Hallo zusammen,

ich bekomme auf meinem Intel NUC das ACPI-Wakeup nicht zum Laufen. Kann mir jemand einen Tip geben,
wie ich das hinbekomme (oder die BIOS-Einstellungen, mit dem er seinen NUC5i3RYH betreibt?

Wenn ich den NUC über BIOS starten lasse (d.h. die Aufwachzeit im BIOS eintrage und Wakeup from S5 wähle),
startet der Rechner wie gewünscht.

Wenn ich die Aufwachzeit über ein ACPI Test-Script eintrage, wacht er nicht auf.
Stattdessen ist - nach manuellem Boot - die Wakeupzeit die er via cat /proc/driver/rtc anzeigt verstellt ...

Das Verhalten ändert sich auch nicht, wenn ich im BIOS Wakeup from S5 aktiviere oder deaktiviere

Einige Details zu meinem System:

• BIOS RYBDWi35.86A.0350 von 12.08.2015
• Debian Jessie mit Kernel 3.16 (auch mit Kernel 3.19 probiert, Verhalten identisch)
• HPET im BIOS disabled, und als Startoption "hpet=disable" des Kernel angegeben
• In /etc/init.d/hwclock.sh "Saving the system clock" abgestellt

Langsam gehen mir die Ideen aus ...

m.f.G.
Michael

Hallo zusammen,

darf ich Euch noch eine Frage stellen, wie Ihr das BIOS einstellt um den Rechner zu automatischem ACPI-Wakeup zu bewegen?

Ich hab einen Intel NUC i3 (Broadwell NUC5i3RYH) mit aktuellem BIOS. Im BIOS läßt sich folgendes einstellen:

• Wakeup von S5 (ist angeklickt)
• Die Uhrzeit (Stunde/Minute/Sekunde)
• Die Auswahl täglich/monatlich/... (steht auf täglich)

Mein Verständnis: Wakeup von S5 muß angeklickt sein, sonst wird der RTC-Alarm nicht wirksam.

Aber: Ein Einstellen einer Weckzeit mit dem ACPI-Testprogram (stellt die Weckzeit auf 2 Minuten nach der aktuellen Zeit, es schreibt die Zeit sogar zwei mal nach /sys/class/rtc/rtc0/wakealarm) bringt nicht das gewünschte Resultat. Die Uhrzeit die aus /proc/driver/rtc ausgelesen werden kann zeigt unabhängig von den 2 min auf 5 min in die Zukunft, und der Rechner schaltet nicht ein ...

An den nötigen Patches hab ich hoffentlich nichts vergessen: Debian Jessie Linux; BIOS-Zeit auf local time; im BIOS ist HPET disabled; Start des Linux mit Parameter "hpet=disable"; in /etc/init.d/hwclock steht HWCLOCKACCESS=readonly; das Sichern der Uhrzeit beim Runterfahren ist disabled; ob mit oder ohne HWCLOCKPARS="--directisa" hat auch nix gebracht ...)

Letzte Idee: Kann die RTC nur aus S4 aufwecken? (kann ja nicht sein ...) aber im Syslog steht:

Für einen Tip wäre ich dankbar ...

m.f.G.
Michael

Hallo seahawk,

stimmt, die Tastendrücke bei abgeschaltetem inputlirc kamen von XKeySyms Definitionen in der remote.conf. Als ich dort die Tasten mit KEY_XYZ bezeichnet hatte, lief die FB auch unter inputlirc.

Jetzt muß ich nur noch die Frequenz etwas heraufsetzen, in der die Tastendrücke gemeldet werden (das Scrollen in einer Liste geht noch ziemlich langsam), dann ist das erledigt.

Vielen Dank für die Hilfe.

M.f.G.
Michael

Hallo seahawk,

Danke für Deine Tips. In der /etc/rc_maps.cfg war die lokale Keytable nicht korrekt eingetragen, und in der /etc/vdr/remote.conf waren die Key´s noch mit den alten namen eingtragen (1 statt KEY_1, ...).

Jetzt klappt die Konvertierung der Scancodes in Keycodes (mit ir-keytable -t werden jetzt key-down und key-up Meldungen mit den Key-Codes angezeigt ...)

Jetzt hab ich ein komisches Verhalten:

• Wenn ich inputlirc stoppe !!! (nach: service inputlirc stop), dann sehe ich Reaktion auf die Tastendrücke (zumindest bei den Ziffern 1-9 kann ich damit den Kanal umschalten; die Farb-Tasten, laut/leise, Channel Up/Down hingegen geht nicht)
  

  
  

• Wenn ich inputlirc laufen habe (nach: service inputlirc start), dann funktionieren auch die Zifferntasten 0-9 nicht (dann geht die Fernbedienung gar nicht ...)

Ich brauche doch inputlirc, der die Tasten von /dev/input/event4 verarbeitet und an /var/run/lirc/lircd weiterleitet (/usr/sbin/inputlircd -g -m 0 -d /var/run/lirc/lircd /dev/input/event4) Oder nicht???

m.f.G.
Michael

Hallo zusammen,

ich möchte an meinem Broadwell Intel-NUC und derem internen Nuvoton CIR (Consumer Infrared Receiver) meine bisherige RC5 Fernbedienung zum laufen bekommen, um damit den VDR zu bedienen.

• HW-Konfiguration: Nach anfänglichem Zweifel ob der CIR überhaupt RC5 Format unterstützt (weil im BIOS meines Broadwell NUC5i3RYH für den CIR die drei Varianten: Generic Remote Controller, RC6 Remote Controller und XBOX Remote Controller) eingestellt werden kann; RC5 wird nicht expilziert aufgeführt, und auch in der Doku ist RC5 in keinem Wort erwähnt), bin ich jetzt ein Stück weiter. Ja ich kann RC5 Kommandos empfangen. Ich habe im BIOS die Einstellung "Generic Remote Controller" gewählt.
  

  
  

• SW-Installation: lirc ist ja mittlerweile durch inputlirc oder eventlirc ersetzt. Ich habe bei mir inputlirc installiert. Ich empfange auch schon Codes von meiner Hauppuage Fernbedienung, nur ist scheinbar meine remote.conf noch nicht richtig eingestellt, daß der VDR die Zeichen auch korrekt empfängt.

Wenn ich inputlirc starte, sehe ich, daß inputlirc Events von meiner FB (über /dev/input/event4) auswertet und an /var/run/lirc/lircd ausgibt.

Mit IR-Keytable kann ich auch Zeichen von der Fernbedienung empfangen

Was scheinbar noch fehlt, ist die richtige Zuordnung der Scancodes in der remote.conf (da hab ich noch die remote conf, die früher mit LIRC zusammengearbeitet hat, und ich finde auch nichts darüber, wie ich die Scancodes, oder Kombination aus Scancodes und Events dort korrekt eintrage ...)

In einem Beitrag hab ich was gefunden von KEY_NUMERIC_1, ... (und ich hab das im LIRC Teil der remote.conf in den Zeilen 2-6 mal abgeändert, aber das hat auch nicht geklappt), so daß ich hoffe - mir kann da jemand weiterhelfen ...

m.f.G.
Michael

Hallo zusammen,

ich habe meinen VDR auf Basis von Jessie und e-tobi´s Repositories zu VDR 2.2 frisch installiert, und gerade zum ersten mal mit VA-API Bild und Ton bekommen ... (war ein langer Weg) ...

Jetzt hab ich ein paar Plugin´s installiert und wollte diese - wie auf meinem Vorgängersystem - mit menuorg otrganisieren. Das gibt es ja nicht unter Jessie (sondern nur unter Wheezy).

1. Frage: Kann man das menuorg von Wheezy auf einem Jessie System zum Laufen bringen (und ist das auch so gedacht), oder müssen wir e-tobi bitten, daß er das für Wheezy entsprechend baut? (hab nämlich versucht das menuorg.deb von Wheezy auf meinen Rechner zu kopieren und zu installieren - er bringt dauernd neue fehlende Abhängigkeiten (im Moment gerade den vdr-abi-2.0.0 Multipatch ...) Nicht daß das gar nicht gehen kann, und ich mir mein System wieder zerschieße ...

2. Frage: Das Repo von Wheezy wie untenstehend mit einzubinden ist immer noch zu empfehlen? (nimmt er die Jessie Pakete auch wirklich zuerst, oder wird dazu ein apt-pinning angeraten, das dann wie aussehen sollte)

# e-tobi.net VDR-Repository
deb     http://e-tobi.net/vdr-experimental wheezy base addons
deb-src http://e-tobi.net/vdr-experimental wheezy base addons


deb     http://e-tobi.net/vdr-experimental jessie backports vdr-multipatch base
deb-src http://e-tobi.net/vdr-experimental jessie backports vdr-multipatch base

m.f.G.
Michael

Hallo cinfo,

hab mir noch mal das bm2lts System frisch installiert, und mache gerade ein dist-upgrade um es auf aktuelle Version zu bringen.
Da mein Debian System partout nicht laufen will, und es scheinbar mit den X11 Einstellungen zusammenhängt, möchte ich meine
X11 Einstellungen (und die Versionen der Intel Treiber) mit denen aus Eurer bm2lts vergleichen

Meine Vermutung: Ich habe zwei oder drei Probleme die zusammenspielen:

• Mein LCD Monitor (mit dem ich das momentan teste) ist über einen DVI Adapter an den MiniDisplayPort angeschlossen.
  Dadurch werden die Settings für den HDMI Ausgang (den Standard-Monitor) in der xorg.conf ignoriert. Ich muß die pas-
  senden Settings für den Display Port finden ... (wie gebe ich die für den DP ein?)
  

  
  

• Mein LCD Monitor wird dann nach den Bildwiederholfrequenzen befragt (die er unterstützt), dabei sind natürlich nur 60Hz
  Frequenzen dabei (ich weiß nicht, ob das bei Debian Ärger macht). Es sieht aber danach aus, daß er bei bm2lts gut mit den
  50Hz Einstellungen in der xorg.conf klar kommt. Wenn man die Abfrage unterdrückt, scheint das zu laufen.
  

  
  

• Der Intel Treiber auf meinem Debian System (/usr/lib/xorg/modules/drivers/intel_drv.so) meldet in der Xorg.0.log, daß er
  den Chipsatz (Broadwell) nicht kennt (Zeile 86), und schaltet deshalb die Hardwarebeschleunigung ab (Zeile 189). VaInfo zeigt
  wahrscheinlich deshalb keine VaApi Funktionen an, bei Nutzung von Vaapi durch die Applikationen stürzt die Kiste ab ...

Da aber bm2lts auf meinem Rechner auf dem Monitor Videos darstellen kann, schließe ich einmal Hardwareprobleme aus.

Meine Fragen:

• Im /etc/X11 Verzeichnis sind verschiedene xorg.conf zu finden. Welche werden bei einem Broadwell-NUC System genutzt?
  

  
  

• Unter /var/log/ findet sich normalerweise eine detaillierte Xorg.0.log (die ich mit meiner vergleichen wollte). Leider ist dort
  nichts zu finden. Kann man diese Log-Datei irgendwie aktivieren? (sollte ähnliche Daten beinhalten wie die untere Log-Datei)

m.f.G.
Michael

Hallo cinfo,

ja, das ist ein 64-Bit System. Der Befehl uname -a gibt folgendes aus: "Linux Intel-NUC 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt11-1+deb8u2 (2015-07-17) x86_64 GNU/Linux".

Siehst Du da etwas, was nicht zusammenpaßt?

m.f.G.
Michael

Hallo SOliver,

Danke für die bereitgestellten Pakete - damit war das Upgrade schnell durchgeführt, und ich sehe jetzt überall die Version 1.6.0. Prima.
Die X-Server Abstürze sind bei mir allerdings immer noch da. Sind mit dem von Dir generierten Intel-Treiber Probleme bekannt?

Siehe Intel NUC-Umbau (Beitrag 206)

m.f.G.
Michael