Beiträge von hivdr

Also ich habe jetzt mal die neue FW 0.3.3 / FPGA 1.09 eingespielt (Treiber noch kein neuer, und plugin eh nicht, bin da auf das modifizierte angewiesen).
Und es sieht wirklich so aus, als wäre bereits damit der IR-Geist gebannt. Ist zwar nach eineinhalb TV-Abenden noch nicht sicher, wenn es doch wieder auftritt lass ich von mir hören, aber sieht gut aus. Auch das Blinken der IR-LED bei FB-events ist hilfreich.

Weitere hier diskutierte Probleme kann ich bestätigen und habe auch noch ein anderes anzubieten..

Phasen, in denen er auf die FB nicht recht reagieren will, bzw. jedes zweite (ungefähr) oder noch mehr der events "verschluckt" werden. Das passiert bei mir immer erst nach relativ langer Laufzeit (zB 4h) und verschwindet nach einigen Minuten von selbst wieder. Im Log ist nichts zu sehen. Mit schlechtem Empfang hat das als solches nichts zu tun, passiert regelmässig auch bei bestem Wetter. Da nun die IR-LED blinkt: wenn sie blinkt, wird auch das event verarbeitet, oder umgekehrt gesagt: wenn ein FB-Tastendruck nicht wirkt, blinkt auch die LED nicht.

Dass bei schlechtem / keinem Empfang (bei Gewitter) der VDR praktisch unbedienbar wird (Verzögerung bei FB-events von um die 5s im Schnitt), ist nochmal ein anderes Phänomen, ja! Wäre natürlich schön, wenn sowas den VDR nicht immer so komplett "ausbremst". Schalte ich in so einer Phase auf einen DVB-T-Sender um (mit Empfang), läuft es wieder "smooth" (aber bei laufender Aufnahme auf Sender ohne Empfang schlägt dann natürlich der watchdog zu).

Schliesslich habe ich gelegentlich den Fall, dass plötzlich immer kurz nach dem Umschalten der Ton weg ist. Dauerhaft - höchstens nochmal ganz kurze Fetzen. Egal wie oft ich umschalte. Nur ein Restart hilft dann.
Im Log finde ich dann folgendes:

Aug 25 22:32:33 flmedia vdr: [1332] buffer stats: 0 (0%) used
Aug 25 22:32:38 flmedia vdr: [1785] ERROR: TS packet not accepted in Transfer Mode
Aug 25 22:32:39 flmedia vdr: [1786] buffer usage: 70% (tid=1785)
Aug 25 22:32:39 flmedia vdr: [1786] buffer usage: 80% (tid=1785)
Aug 25 22:32:39 flmedia vdr: [1785] ERROR: TS packet not accepted in Transfer Mode
Aug 25 22:32:39 flmedia vdr: [1786] buffer usage: 90% (tid=1785)
Aug 25 22:32:40 flmedia vdr: [1786] buffer usage: 100% (tid=1785)
Aug 25 22:32:40 flmedia vdr: [1785] ERROR: TS packet not accepted in Transfer Mode
Aug 25 22:32:41 flmedia vdr: [1785] ERROR: TS packet not accepted in Transfer Mode
Aug 25 22:32:41 flmedia vdr: [1786] ERROR: driver buffer overflow on device 2
Aug 25 22:32:42 flmedia vdr: [1785] ERROR: TS packet not accepted in Transfer Mode
Aug 25 22:32:43 flmedia vdr: [1785] ERROR: TS packet not accepted in Transfer Mode
Aug 25 22:32:43 flmedia vdr: [1786] ERROR: driver buffer overflow on device 2
Aug 25 22:32:44 flmedia vdr: [1785] ERROR: TS packet not accepted in Transfer Mode
Aug 25 22:32:44 flmedia vdr: [1332] switching to channel 42
Aug 25 22:32:45 flmedia vdr: [1785] ERROR: TS packet not accepted in Transfer Mode
Aug 25 22:32:45 flmedia vdr: [1786] ERROR: driver buffer overflow on device 2
Aug 25 22:32:45 flmedia vdr: [1785] ERROR: skipped 587 bytes to sync on TS packet on device 2
Aug 25 22:32:45 flmedia vdr: [1786] buffer usage: 0% (tid=1785)
Aug 25 22:32:45 flmedia vdr: [1332] buffer stats: 0 (0%) used
Aug 25 22:32:48 flmedia vdr: [1332] switching to channel 41
Aug 25 22:32:48 flmedia vdr: [1332] buffer stats: 0 (0%) used
Aug 25 22:33:46 flmedia vdr: [1332] switching to channel 42
Aug 25 22:33:46 flmedia vdr: [1332] buffer stats: 0 (0%) used

Da könnt ihr natürlich jetzt wieder sagen erst mal den Treiber updaten oder kein Support für das abgewandelte dvbhddevice. Naja, Treiber mach ich schon mal, plugin wie gesagt nicht. Dann halt Pech gehabt, passiert nur selten.

Und schliesslich (siehe auch Post von griso) kommts auch bei mir mal vor, dass ich auf einem Sender plötzlich keinen Empfang habe. Insbesondere bei den (inzwischen nur noch selten genutzten) SD-Sendern. Besonders kritisch ist zB Tele5. Umschalten des Tuner per femon hilft manchmal, manchmal nicht. Und er "fängt" sich dann auch bei sonst unkritischen Sendern oft erst nach diversen Umschaltvorgängen. Allerdings hätte ich das zuletzt nicht mehr der 6400 zugeschrieben, sondern einem nicht optimalen Empfang. Man weiss es nicht.

(alles hier beschriebene bezieht sich auf VDR0 laut Sig)

Zitat von TheChief

Sofern LIRC läuft, kannst Du den VDR mit der Option:

--lirc[=PATH] use a LIRC remote control device, attached to PATH
(default: /dev/lircd)

starten. Vorher kannst Du ja mal die remote.conf leeren, dann sollten die Dialoge zum anlernen
erscheinen.

Mit anderen Worten: die Datei remote.conf wird nicht nur vom remote-Plugin verwendet (wie das ja doch sehr naheliegend wäre), sondern ggf. auch vom VDR direkt ohne Plugin. Gut zu wissen. Aber das remote-Plugin stört auch nicht.

Zitat von TheChief

XBMC und Lirc kannst Du dann mittels der Lircmap.xml verheiraten, musst aber beim Start von XBMC ein svdrpsend REMO Off an den
VDR senden, damit die Fernbediung nur auf XBMC reagiert.

Siehe auch allererster Post, trotzdem Danke!

Zitat von clausmuus

sag mal, wozu brauchst Du denn noch das remote Plugin, wenn Du /dev/lircd als Eingang benutzt. Dann könnte das lirc device doch direkt dem VDR mitgegeben werden. Wo liegt da der Unterschied/Vorteil?

Ganz einfach: ich wüsste nicht wie. Das kann auch sehr gut sein, dass ich es einfach nicht weiss, aber auch im LIRC-Artikel im VDR-Wiki finde ich beim Überfliegen keine explizite Anweisung, wie der VDR zu konfigurieren ist, aber dafür kommt die remote.conf vor.
Also, wer weiss ob und wie der VDR auch ohne remote-Plugin mit LIRC zu steuern ist, kann es ja mal kurz erläutern.

Aber was mich angeht, ist das so mit remote-Plugin eine sehr gut funktionierende Lösung.

Zum IR-Geist (ich war einst der erste, der das im grossen 6400-Thread gemeldet hatte, damals haben es noch (nur) zwei andere bestätigt):

Bei mir wird da nichts "verschluckt"! Die FB funktioniert ganz normal. Der letzte Tastendruck aber wird dann gerne mal ganz unmotiviert wiederholt, und das kann relativ bald sein, oder auch erst (sehr) viele Minuten später. Oder auch mehrfach!
Man sollte sich also angewöhnen, zB nach einem Mute immer nochmal per OK die Statusanzeige aufzurufen - schlimmstenfalls passiert das dann später noch ein paarmal, aber es wird nicht un-ge-muted (es lebe Denglish..)

Das ganze scheint ja aber nicht bei jedermann zu passieren.
Ich selbst habe inzwischen einen zweiten 6400-VDR in Betrieb, wenn auch seltener, und bei dem ist es mir noch nie aufgefallen.

Fragt sich also, womit es zusammenhängt: Basis-HW, FB, SW etc?

Bei mir gibt es folgende Unterschiede:

VDR1_mit_ dem Geistereffekt:
Sandy-Bridge (Core i3-2105, Chipsatz H67), FB eine uralte Philips auf RC5, Kubuntu 11.04 64bit mit VDR 1.7.18

VDR2 _ohne_ den Geist:
Zotac IONITX (also Atom und ION, siehe auch Sig), FB eine Logitech Harmony auf VDR1.6-Einstellung, SW-Installation praktisch identisch (cloned)

Vielleicht können ja alle _mit_ dem Effekt mal ihre Eckpunkte hinterlassen, und der ein oder andere der den Effekt nicht hat ebenso.
So dass sich evtl. Gemeinsamkeiten herauskristallisieren.

Zitat von googles

Natürlch funktioniert das mit lircd und 2 Abnehmern. Habe ich auch seit erscheinen der 6400 im Einsatz.

OK, stimmt!
Habe jetzt auch umgestellt: das remote plugin ist ja trotzdem im Spiel, man übergibt nur nicht das device per "-i /dev/input/ir" sondern per "-l /dev/lircd" und muss neu anlernen.
Nun kann ich parallel zum VDR irw laufen lassen - oder in Zukunft dann eben XBMC (und währendessen per SVDRP die FB im VDR deaktivieren, wie ich es ja auch schon im ersten Post beschrieben habe). irexec werde ich wohl nicht verwenden, sondern einen Eintrag in commands, denn eine eigene Taste dafür kann ich nicht "abstellen", so viele hat meine FB jetzt nicht.

Wunderbar, die dev-input-Duplizierung ist also wirklich überflüssig. (Aber hätte auch funktioniert )
Anders als die /dev/input/eventX ist das /dev/lircd kein character device, sondern ein Socket. Darin liegt wohl begründet, dass mehrere Consumer gleichzeitig versorgt werden können.

Damit dürfte die optimale Lösung für den Task laut Thread-Titel gefunden sein (mit nur dem eingebauten IR-Receiver).

Zitat von TheEnvoy

Das ist doch mal ein interessanter Thread...

Freut mich, wenn es der ein oder andere interessant findet, und nicht nur der andere oder eine am Sinn zweifelt

Diskutiert worüber ihr wollt, solange es grob dazupasst.

Mir selbst geht es aber eben darum, mit nur dem IR-Receiver der 6400 auszukommen. Und daher muss man dessen events ggf. vervielfachen, wenn es keinen anderen Weg gibt mit zwei "Verbrauchern" gleichzeitig daran zu horchen.

Eine Harmony zum automatischen Eingangs-Wechsel ist natürlich nett und entkräftet auch noch dieses Argument - wenn man bereit ist eine zu kaufen und sich mit der "Programmierung" auseinanderzusetzen.

Zitat von MarMic

nun habe ich hier so gelesen und überlegt ob man das nicht inputlirc machen lassen kann. das verwaltet doch exentx's und gibt sie als /dev/lircd frei -> somit sollte der vdr und xbmc darüber bedient werden können.

Also ich weiss jetzt nicht was das spezielle an inputlirc ist (es gibt auch noch ein eventlirc), aber man kann ja nun (wie oben beschrieben) auch mit dem normalen lirc als "Receiver" ein /dev/input/eventX definieren. Der Punkt ist, ob man auf das entsprechende lircd device dann mehr als einen consumer gleichzeitig setzen kann, die beide alle events erhalten. Daran bestehen ja deutliche Zweifel, und daher bräuchte man die im Eingangs-Post vorgeschlagene Duplizierungs-Lösung (oder eine ähnliche / bessere).

Die andere "Spur", der ich noch nicht weiter nachgegangen bin, wäre wohl eben das "externalplayer" Plugin.

Zitat von Keine_Ahnung

Die FB ist ja kein Problem, da gibts soviele Möglichkeiten das zu handhaben.

Wie gesagt, da hatte ich explizit andere Aussagen gelesen. Die mögen ja falsch gewesen sein.

Zitat

Das Problem ist das VDR und XBMC ihr Video über verschiedene HDMI Ausgänge ausgeben.

Das ist sicherlich ein Schönheitsfehler, aber eben wirklich kein KO-Kriterium, warum man sagen könnte, die 6400 eigne sich grundsätzlich nicht für einen HTPC.

Zitat

PS: Leider nutzen xbmc und vdr einen ziemlich seltsamen Weg um mit lirc zu komunizieren (fragen das lirc Device direkt ab). Das erschwert es etwas. Aber lösen kann man es.

Na dann wäre hier die richtige Stelle, eine exemplarische, konkrete, definitiv funktionierende (getestete) Lösung mal aufzuzeigen. Oder mehrere, nicht alles passt für jeden.
Bin gespannt.

Aber bis auf weiteres plane ich eben auch meine "Verbiegungen" noch etwas weiterzuverfolgen. Muss ja keiner tun, der glaubt es anders besser hinzubekommen (oder der sich gar nicht für XBMC interessiert).

DocViper

Auch interessant, was man doch alles hinbasteln kann. Aber ich dachte jetzt schon eher an eine Lösung mit den vorhandenen Mitteln: eine 6400 mit dem eingebauten IR-Receiver, eine dazu passende FB und sonst nix was die HW betrifft. Das soll jetzt schon ein 6400-Thread sein, kein vdpau-Thread
(Ja, auch ich habe davon zwei Jahre lang profitiert, keine Frage, war dankbar dass es das gibt, besser als nichts. Nur mit der 6400 hat es sich für mich erledigt. Meine persönliche Ansicht. Wobei, wenn es dann mal wirklich ans Installieren von XBMC geht, kann man es vermutlich auch wieder gut brauchen, wenn der auch HD-Videos zeigen können soll. Also bei nvidia-HW. Bei dem SandyBridge-Rechner wäre es dann wohl dieses vaapi.)

Zitat

Ansonsten muss man eben sicherstellen, dass das Lircdevice entweder an den VDR oder an XBMC "verknüpft" ist. Da man das Lircdevice beim starten des VDRs festlegt wüsste ich jetzt leider keine Möglichkeit es ihm einfach zu entziehen.

Genau das hatte ich befürchtet. Demnach bräuchte man eben auch dann, wenn man auch beim VDR mit LIRC arbeitet, immer noch eine "Verteilerlösung" wie oben skizziert, wenn man den VDR weiterlaufen lassen will.

Aber genug der Theoretisiererei, vielleicht komme ich heute Abend nochmal zu ein paar konkreten Tests.

Zitat von Atechsystem

ist dafür nicht das external player plugin gedacht? Soweit ich weiss kann man auch die FB weiterleiten.

Kannte ich nicht. Auf den ersten Blick sagt mir die WIKI page dazu jetzt aber auch nicht viel.. aber ist immer schön, von potentiellen Alternativen zu hören.
Generell hatte ich jetzt nicht vor, den XBMC als VDR-Frontend zu nutzen (davon versteht ich gar nichts), ich wollte ihn erst mal einfach nur parallel an den Start bringen, einfach für das übliche: Videos, Fotos, Musik..

Zitat von TheChief

Irgendwie versteht ich den Thread nicht so ganz. Bei mir laufen VDR und XBMC mit Lirc auch ohne das ganze
Gedöhns (bis auf REMO on/off). Ich verwende allerdings einen iMon Empfänger. Was genau ist jetzt der Zweck
dieser Verbiegungen?

Naja, stimmt schon: vermutlich könnte man auch gleich nur LIRC auf das /dev/input/ir der 6400 setzen, und beim VDR auch LIRC nutzen. Allerdings finde ich grundsätzlich das remote-plugin viel schöner/einfacher und wollte erst mal so wenig wie möglich an der gut laufenden VDR-Installation drehen.

Und wie ist das bei LIRC, wenn man zwei Anwendungen gleichzeitig laufen lässt: bekommen die beide die events (ist ja erst mal auch nur ein normales device file, sollte also kein Unterschied zum /dev/input/eventX sein), oder nimmt wirklich VDR nach REMO off die events nicht mehr an, so dass sie dann (und nur dann) beim "Zweitverwerter" landen?

Jedenfalls wurde in anderen Threads explizit die FB-Problematik als Hindernis genannt, warum mit einer 6400 kein HTPC mit XBMC neben dem VDR praktikabel sei (ich glaube von jemandem aus dem yavdr Team). Mein Ansatz lässt vermuten, dass das schon machbar ist. Wenn es eigentlich noch viel einfacher geht, umso besser (der Thread-Titel ist ja entsprechend allgemein formuliert). Allerdings bitte dann auch erst mal selbst austesten, ob es wirklich klappt. Ich werde meine Idee jedenfalls sicher noch ein bisschen weiterverfolgen, interessiert mich auf jeden Fall ob es letztendlich funktioniert. Kann nur noch ein bisschen dauern (zu wenig Zeit).

Vorausgeschickt (siehe auch Thread "FF oder VDPAU"): für mich gilt in erster Linie mal: ein VDR ist ein VDR ist ein VDR. Das hier ist ein VDR-Forum, man sollte meinen das sieht hier die Mehrheit so. Jedenfalls bin ich mit meinen mittlerweile zwei 6400-basierten FF recht glücklich, was man von den zwei Jahren mit HD-VDRs auf vdpau Basis (einer selbstgebastelt, einer mit yavdr) bei mir nicht behaupten konnte. Jedenfalls was problemlosen stabilen Betrieb betrifft. Wer dauernd basteln _will_ (der Weg ist das Ziel) mag das anders sehen.

Aber nichtsdestotrotz würde auch ich gerne wieder XBMC dazu installieren. Das passt nicht zum FF-basierten VDR? Naja. Man muss den Eingang umschalten. Ich bin ja ein Verfechter der "jede kleine Hürde ist zu viel"-Theorie, weil der Mensch von Natur aus faul ist, und deshalb Kleinigkeiten beim Komfort letztlich den Unterschied ausmachen können, wie (und ob) man etwas nutzt oder nicht. Aber den HDMI am TV umschalten - das ist wirklich machbar.

Bleibt das Problem mit der Fernbedienung. Ich habe jetzt noch gar keinen XBMC installiert (keine Zeit), aber mal ein bisschen was "probiert".
Ziel ist, dass man beides, also VDR und XMBC, mit der gleichen FB bedienen kann.

Ein cat /dev/input/ir (per udev Link auf das richtige eventX) bei laufendem VDR zeigt: der VDR fängt offenbar alle events weg.

Also folgendes Experiment:

mkfifo /tmp/ir
mkfifo /tmp/ir2
cat /dev/input/ir | tee /tmp/ir /tmp/ir2 >/dev/null &

Damit wird der ir input auf zwei "named pipes" in /tmp, ir und ir2, dupliziert.

Den VDR (remote plugin) konfiguriert man nun auf /tmp/ir statt /dev/input/ir und startet ihn neu.

Man installiert LIRC, konfiguriert es auf "Linux input event layer" (oder so ähnlich) und in hardware.conf als device wiederum statt /dev/input/ir nun /tmp/ir2.
Und man startet irw.

Ergebnis: der VDR lässt sich einwandfrei bedienen, gleichzeitig landet jeder FB-Tastendruck in der irw-Ausgabe.

Statt irw sollte man eigentlich ohne Probleme auch den XBMC auf das lirc device setzen können.

Natürlich muss man nun noch beim VDR, wenn man über die commands XBMC startet, die Reaktion auf FB events abschalten (und nach dem Beenden des XBMC wieder anschalten) - also im Startskript vor und nach dem XBMC-Aufruf. Dafür gibt es SVDRP Kommandos (REMO off/on, svdrpsend.pl). So hatte ich das auch schon bei meinem vdpau-VDR gemacht, hat einwandfrei funktioniert: der VDR läuft parallel weiter, aber reagiert einfach nicht auf die FB, solange XBMC läuft.

Potentielle Probleme: die named pipes (ich kenne mich nicht wirklich gut damit aus) sind eine recht spezielle Sache: sobald nicht von beiden pipes die events auch abgenommen werden, bricht der Verteiler-Befehl (s. oben cat | tee..) ab. Man muss also, solange XBMC _nicht_ läuft, etwa per "cat ... > /dev/null" die events vom lirc-device abnehmen (habs probiert: das statt irw, und die FB im VDR tut auch). Ausserdem wäre es natürlich umgekehrt ein Problem, wenn VDR im Modus REMO off die events nicht von /tmp/ir abnimmt (hab ich nicht getestet, hoffe er ignoriert sie einfach nur, sonst müsste man wiederum einen cat>null beim XBMC-Start machen).

Der Beweis muss also erst noch erbracht werden, dass das tatsächlich stabil so funktioniert. Aber vielleicht mag schon mal jemand mitdenken oder hat sogar vor mir Zeit, das in der Praxis real auszuprobieren. Viel Erfolg!

Und vielleicht gibt es ja auch noch einen viel einfacheren, eleganteren oder problemloseren Weg (keine Abnahmepflicht?) als mit den named pipes, die events zu duplizieren. Unix-Kenner vor!

Zitat von Freddy

danke fürs ausprobieren, hivdr! Steht bei dir im syslog auch folgendes

Code

sti7109_raw_data (0): timed out waiting for data ready
sti7109_raw_osd_cmd (0): timed out waiting for osd command ready

Diese Einträge finde ich in den Logs nirgendwo, weder in der fraglichen Zeit noch seither. Könnte allerdings, wie hier mittlerweile angesprochen wurde, daran liegen, dass ich keine verbose-option gesetzt habe.
Gestern hatte ich dann tatsächlich auch nochmal einen Total-Hänger, der nur durch Restart zu beheben war, und der auch nach OSD roch: mitten beim Blättern / Herumschalten im EPG war Schluss, die obere Hälfte des OSD zeigte den beabsichtigten neuen Inhalt, dann brach es ab und zeigte unten den Inhalt der vorigen Ansicht. Gewissermassen eine "Abrisskante" mitten in einer Zeile.

Kann also auch bestätigen, dass mit dem OSD offenbar doch nicht alles so 100% OK ist, auch wenn bei normaler Nutzung nur selten sowas passiert. Hoffe die Ursache kann noch identifiziert werden.

Zitat von Keine_Ahnung

Du sollst ja auch nicht das ganze Kabel tauschen sondern nur die 20 cm Fensterdurchführung gegen 20 cm normales Antennenkabel tauschen. Also 20 cm Kabel, 2 F-Stecker und 2 F-Verbinder.

Für einen Test ist das viel aufwendiger als zwei lange Kabel zu legen (so weit weg ist die Schüssel nicht), und als Dauereinrichtung kommt es nicht in Frage, Sorry. Sommer? Da regnet es auch, und stürmt, und ist laut draussen.

Zitat von lola

Dann wirst Du mit der Ungewissheit weiter leben müssen und eine Lösung ist so auch nicht in Sicht. Das Problem scheint dann nicht so wichtig zu sein.

So siehts aus. Ich hoffe ja für den Moment es durch Umstecken gelöst zu haben.

Zitat

Es gibt Fensterdurchführungen mit und ohne Schirmung, welche hast Du?

Das ist wirklich ein richtig flaches Flachbandkabel, die (zB) kupferfarbenen recht breiten, also vermutlich ohne "Schirm".
Mir ist schon klar, dass so kein optimaler Signalweg aussieht, aber das ist nun mal was bei mir die Gegebenheiten vorgeben. Es sind auch keine "Sender" in der Nähe des Fensters, und die Durchleitung ist nur kurz.
Da es jahrelang funktioniert hat (mit anderen Tunern) würde ich erwarten, dass es auch mit der 6400 klappt. Irgendwo hat mal jemand geschrieben die 6400 hätte die besten / empfindlichsten Tuner die er je gesehen hat. Naja..

Aber wie gesagt, im Moment habe ich Hoffnung. Wenn es doch wieder Probleme gibt, werde ich den Kabeltest machen - und wieder hier aufschlagen..

Zitat von lola

Fenster-Durchführungskabel sind eigentlich nur ein Notbehelf, da sie die Homogenität des Kabel stören und rel. viel Dämpfung, Fehlanpassung und Reflektionen hervorrufen. Auch ändern sich mit jedem Öfnen des Fensters und anschließendem Quetschen des Kabels diese Parameter.
Jetzt im Sommer könntest Du doch mal testweise einen Bypass durchs geöffnete Fenster legen ( mit ordentlichen Kabel )

Also immerhin laufen sie ja seit Jahren ansonsten fehlerfrei. Auch gequetscht wird da nicht, dieses Fenster ist immer zu! (habe noch andere zum Lüften..)
Also klar wäre ein Test mit normalen Kabeln interessant, werde den Aufwand in nächster Zeit aber eher nicht treiben..

Zitat von Freddy

hast du den bewegten text aktiviert (verzögerung 10 ms, pause 1000 ms, alle texte aktiviert, true color osd im dvbhddevice aktiv)? Und gibt es auch was zu bewegen z.B. im Hauptmenü (z.B. Timer)? Damit kann ich die Hänger sofort reproduzieren (abwarten, bis die Texte mindestens paar mal nach links und rechts gescrollt wurden). Werden die Texte bei dir auch nur mit deaktiviertem high level osd gescrollt? Schmiert bei dir vdr beim anzeigen des teletextes mit high level osd ab (segfault in syslog)? Was bedeutet eigentlich high level osd?

Ich hatte TrueColor aktiv, aber nicht die "animated texts" aus den Plugin-Einstellungen des Skin. Stelle ich dann auch noch auf 10ms Verzögerung (also schnelles Scrollen), so konnte ich Dein Problem tatsächlich reproduzieren - Ruckler beim Text-Scrollen, und schliesslich auch ein crash / Restart des VDR. Mit 30ms allerdings keinerlei Probleme, notfalls kann man auf die Scrollerei auch ganz gut verzichten (bei der Default Textgrösse sieht man doch ziemlich viel, ausser bei den Timern im Hauptmenu rechts).
High Level ist aus weil sonst osdteletext einfach gar nichts anzeigt (aber kein crash).
Was es bedeutet wurde hier schon mal erklärt, ich glaube es war in etwa so: ohne High Level wird das Menu als Bitmap fertig gerendert vom VDR an die Karte übergeben, mit High Level OSD kann VDR eben "höhere" Zeichenbefehle der Karte direkt nutzen, was ggf. schneller wäre.

Was meine Artefakt-Probleme angeht. Auch wenn es seltsamerweise nicht von Anfang an so war, war es in letzter Zeit absolut reproduzierbar: nach Start oder auch Restart erst mal Artefakte. Nur einige male Umschalten und Abwarten half. Oder etwas direkter: das Umschalten des Tuner.
Eine meiner Leitungen ist etwas "schwächer" als die andere, und diese hängt am ersten Tuner, mit dem VDR wohl grundsätzlich startet.
Ich habe nun die Kabel getauscht, und das Problem scheint erledigt (noch unter Vorbehalt).
D.h. wenn man mit der "guten Leitung" startet, ist danach auch die andere ohne Einschränkungen in Ordnung: man kann sofort den Tuner wechseln und alles ist OK. Man darf nur nicht mit dieser Leitung "starten".
Was es alles gibt. Beide meine Leitungen haben Fenster-Durchführung (Flachband), vielleicht bekommt der LNB über das eine Kabel zu wenig Saft?
Seltsam nur, dass es eben nie solche Probleme mit dem Vorgänger-VDR gab (TBS und TT 3600 USB, Sig. VDR1).

Zitat von Mr_T

kann ich ebenfalls bestätigen

Lustig. Also kann man lustig finden, und ist im Vergleich zu zB Artefakt-Problemen fast vernachlässigbar, aber letztlich kann es schon auch sehr nerven. Wenn man mutet und den Raum verlässt, und die Kiste plötzlich wieder losplärrt (zB Werbung extra-laut oder was sonst peinliches plötzlich auf dem Sender läuft). Man kann sich sicher auch Szenarien ausdenken, wo einem dadurch eine Aufnahme abhanden kommt, wenns auch unwahrscheinlich ist.

Während ich mit dem Haupt-VDR im Moment wieder etwas unglücklich bin (s. oben, nicht zuverlässig immer artefaktfrei, Katastrophe eigentlich), hatte ich dennoch (war schon bestellt) zwischenzeitlich einen weiteren VDR umgerüstet (VDR3 aus Sig). Der ist nun grade mal ein paar Stunden gelaufen, also weit weg von Langzeittest, und früher oder später werden auch da die kleinen Probleme und Ungereimtheiten auftauchen (was sich hinziehen wird, da erst wieder in zwei Wochen vor Ort).

Trotzdem diesbezüglich mal wieder eine positive Nachricht. Ich habe in dem Zotac-Atom-Board einfach die Karte eingesteckt, und meine komplette Installation von VDR0 geklont.
Sicher, ein bisschen Arbeit macht das auch: man muss das neue System zum Booten bringen (grub), einiges an der Systemkonfiguration anpassen (Partitionen / fstab, Netzwerk usw) und auch ein paar Details an der VDR-Konfiguration der neuen Umgebung anpassen.

Aber im grossen und ganzen lief das wirklich gut, und die Installation (von einem H67-Board) lief ohne weiteres mit allen Treibern unverändert auf dem Atom (Vorsicht, nur die Desktop-Atoms beherrschen 64bit!). Der VDR mit allen Plugins ist da und funktioniert - bisher sauber.
Für die Fernbedienung nur die Zeilen für "ir" aus remote.conf entfernt und neu angelernt, und schon ein voll bedienbares System.

Allein für den integrierten IR-Receiver finde ich rentiert sich die 6400 ja fast schon (was ich mich rumgeärgert habe mit dem Atric, der bei mir einfach nicht laufen wollte, und letztlich war ich jeweils beim blau-transparenten TT USB-IR-Dongle gelandet, das zwar ganz gut funktioniert, aber natürlich mit LIRC viel mehr Aufwand bei der Einrichtung braucht - und genau die richtige config damit es gut funktioniert. Eine Logitech hatte damit öfter doppelte events, am Empfänger der 6400 ganz solide).

Wenns jetzt eben nur bei der Kern-Disziplin, dem stabilen zuverlässigen 100% sauberen Empfang, nicht noch diese Unsicherheiten gäbe..

Mit dem OSD hatte ich übrigens auch bisher keinerlei Probleme. High Level musste ich nur abschalten für osdteletext plugin, ist aber immer noch flott genug (skinenigmang).

Auch von mir mal ein kleiner Bericht zu meinem neuen TT-6400-basierten VDR. Eingebaut in einem Shuttle SH67 (siehe Sig "VDR0").

Nach den vernichtenden ersten Tests in einem MSI-H67-Board im April lief es nun eigentlich recht gut (aktuelle Treiber/FW), so dass ich nach zwei Wochen beschlossen habe produktiv umzusteigen. Erst sah alles wirklich sehr gut aus (absolut stabil, und nat. ist die Wiedergabe mit der 6400 im Vergleich zu vdpau ein Traum), und ich plante schon weitere VDR mit einer 6400 auszustatten.

Allerdings - war klar - je länger man im Alltag damit lebt, desto mehr Probleme fallen auf, von Kleinigkeiten bis zu Besorgnis Erregendem.

Zuerst gab es schon einen Schock beim Umbau an den angestammten VDR-Platz: plötzlich (nachdem es nie auch nur ein Klötzchen gab) war alles voller Artefakte. Liess sich allerdings auf ein (sehr kurzes, aber defektes?) USB-Kabel zurückführen, an dem der DVB-T-Stick hing (zuvor direkt angesteckt, USB 3.0). Mit einem längeren Kabel (und vorsichtshalber an einem anderen Port, USB 2.0) verschwand der Spuk wieder. Ausserdem hing der Rechner zT sogar beim Booten im BIOS, also war da wohl wirklich was nicht ganz in Ordnung mit dem Kabel (oder - hoffentlich nicht - USB-Port).
Das ganze zeigt aber, wie fragil das Glück sein kann - offenbar kann alles mögliche zu Artefakten führen, nicht nur Treiber/FW, sondern schon das falsche Kabel am falschen Ort. Fragt sich, ob es der 6400 anzulasten ist, dass sie so sensibel ist - mangelnde EM-Störfestigkeit oder sowas?

Leider habe ich seither nun schon mehrfach doch wieder Artefakte "gesehen". Einmal nur in Eins Festival (Demoschleife), nach Umschalten war es wieder weg.
Dann nach dem Booten: Startprogramm war ServusTV-HD, Bild schwarz, Ton nur in Fetzen. Wieder nach Umschalten alles OK.
Zuletzt wieder nach dem Booten in der Aufnahme und live: Artefakte! Streckenweise massiv, streckenweise weniger, aber dauerhaft. Umschalten half nichts. Restart des VDR (via OSD-Setup) half auch erst nichts, aber nach einiger Zeit war wieder alles OK. Einfach so. Wetter die ganze Zeit bestens.
Im Log absolut nichts verdächtiges.
Das ist natürlich die grösste Sorge - wenn die erste wichtige Aufnahme verpixelt ist, ist der Ärger gross. Stabilität und Zuverlässigkeit ist das absolut wichtigste, und nachdem es erst so gut aussah, steht nun alles wieder in Frage.
Leider kann ich nichts dazu beitragen, dem Fehler auf die Spur zu kommen - wie gesagt keinerlei Fehler im Log.
Aber perfekt ist das noch lange nicht.

Dann gibt es noch so gewisse Seltsamkeiten.

So 1-x mal am Tag/Abend wird das letzte FB-event nach einigen Minuten wiederholt, einfach so. Also ich habe zB gemutet, plötzlich ist der Sound wieder da. Oder ich habe zuletzt umgeschaltet "nach unten", plötzlich schaltet er von selbst nochmal eins zurück. Das heisst der IR-Receiver doppelt sporadisch das letzte event und schickt es mit grosser Verzögerung nochmal. An der FB kann es kaum liegen, die verwende ich seit 8 Jahren mit allen Vorgänger-VDR problemlos.

Manchmal (bisher sehr selten) ist der Ton einfach weg. Nach Umschalten ist er nur kurz da, dann wieder dauerhaft weg - auf allen Sendern. Nur ein VDR-Restart hilft.

Einzelne ganz wenige Sender (Sport1 SD) sind nur auf einem der Tuner zu empfangen - beim anderen schwarzer Schirm. Nach dem Umschalten dort hin dann plötzlich auch Probleme mit anderen Sendern, die zT gar nicht mehr kommen wollen. Erst Restart hilft. Die Details habe ich allerdings schon wieder verdrängt.

Also - Licht und Schatten. So ganz uneingeschränkt kann ich die 6400 noch nicht empfehlen.. auch wenns mich bei Threads wie "mein täglicher HD-Wahnsinn" schon jucken würde das zu tun - Wiedergabe-seitig ist es natürlich wunderbar, eben "wie früher" mit der FF.. Sprünge gehen fix, und man kann tatsächlich wieder _spulen_ - Wahnsinn!

Also, das funktioniert ganz gut mit dem wakeup über Server und WOL.. falls es mal wer brauchen kann, hier das Skript auf dem VDR:

$ cat /usr/local/bin/set_server_wol_alarm


zone=$(date -R | awk '{print $6}')
if [ $zone == '+0200' ]
then
 addtime=7200
else
 addtime=3600
fi


# not utc on server / at
SECS=`expr $1 + $addtime`


# time formatted for at
ATTIME=`date -ud "1970-01-01 + $SECS seconds" '+%H:%M %d.%m.%y'`


logger scheduling wakeup on server for: $ATTIME
ssh user@server "echo '/path/to/wakeup-script' | at $ATTIME" >/tmp/wakeup_last 2>&1

Dieses Skript aus dem vdrpoweroff.sh aufrufen, und ihm als Parameter ($1 oben) die Aufwachzeit (ebenfalls $1 im vdrpoweroff, minus Vorlaufzeit) übergeben.
Da der VDR UTC liefert, at auf dem Server aber lokale Zeit erwartet, 1h oder 2h dazuzählen (je nach Sommer/Winterzeit, SECS oben).
Damit der ssh-Aufruf ohne PW-Abfrage klappt, muss man im .ssh/authorized_keys von user auf dem Server den Schlüssel des vdr-user vom VDR hinterlegen (ssh-keygen, .ssh/id_rsa.pub).
/path/to/wakeup-script als user auf dem Server aufgerufen muss den WOL-call auslösen.

Verbesserungspotential: alle bisherigen Timer auf dem Server löschen vor Setzen (atq, atrm), sonst bleibt ein wakeup-Termin für einen zukünftigen aber wieder gelöschten Timer erhalten.

Zitat von Frodo

Das sollte doch kein Problem mehr sein. Für WakeOnLan musst du die Netzwerkschnittstelle mit ethtool für WakeOnLan aktivieren und verhindern das das rückgängig gemacht wird.
Und für ACPI sind eventuell zusätzliche Kernel Parameter wie "hpet" nötig.

Das ganze ist aber im Wiki sehr gut erklärt und mit weiterführenden Links bekommt man auch Problemfälle in den Griff.

Ich kann Dir versichern, dass ich das alles schon recht ausführlich durchgetestet habe (siehe auch meine Posts weiter oben)! Er wacht einfach nicht per ACPI wakeup auf. Aber ich lasse mich gerne von jemand anderem, der das Shuttle kauft, eines besseren belehren.

Bei WOL war es das gleiche: ich habe alles notwendige getan, aber es hat nicht funktioniert. Kein Wunder, der Link am Switch nach dem poweroff war tot. Das hat sich nun mit BIOS 1.07 geändert, und es funktioniert, ohne dass ich SW-seitig nochmal irgendwas geändert hätte!

IG88

Interessant. Offenbar scheint es eben schon einen Markt für sowas zu geben, was wiederum darauf schliessen lässt, dass es nach wie vor Boards gibt, wo der Wakeup anders einfach nicht klappen will.

Ich hatte selbst schon die Idee, jetzt da WOL wenigstens funktioniert, das zum Timer-wakeup einzusetzen. Denn ich habe einen durchlaufenden Server, und könnte ja einfach beim vdrpoweroff statt die ACPI-Uhr zu setzen die Zeit an den Server übermitteln, und dort etwa per at-daemon das wakeup-Skript (WOL) aufrufen.
Trotzdem: so etwas bleibt ein unschöner workaround, bringt zusätzliche Abhängigkeiten, ein sauberer ACPI wakeup wäre für aktuelle HW wirklich angebracht, bin da sehr enttäuscht von Shuttle (auch wenn ich nat. nie zu 100% ausschliessen kann, dass ich selbst noch irgendwo einen "Fehler" mache oder die korrekte Kombination von Einstellungen noch nicht gefunden habe).

Zitat von Mr_T

echo "blacklist saa716x_ff" > /etc/modprobe.d/blacklist-saa716x_ff.conf
echo "blacklist ?dvbtstick?" > /etc/modprobe.d/blacklist-?dvbtstick?.conf

OK, Danke, darauf hätte ich auch selbst kommen können.. ich blackliste jetzt nur das USB-device (dvb_usb_dib0700) und lade es in der runvdr, die sowieso erst mit 5s Verzögerung startet. Insgesamt nun Boot-Zeit bis Bild 45s (davon 20s BIOS), und tatsächlich tritt das Problem "not all devices ready after 30s" nun nicht mehr auf. Das DVB-T-Device ist erst der dritte Adapter in /dev/dvb und auch das dritte device im VDR. Scheint zu helfen, und auch beide 6400-Tuner scheinen wieder im Transfermodus zu laufen. Offenbar erwartet das dvbhddevice bzw. dessen Modifikation kein weiteres device, jedenfalls keines "vor" der 6400, vielleicht wird die Umschaltung über die Indices 0 und 1 vorgenommen, was nun wieder "stimmt".

Danke für die Hinweise.

Zitat von spitzb

Wenn VDR beim Kaltstart im Transfermodus startet gibt es einen Versatz zwischen Bild und Ton von 1..2 Sekunden! Der Transfermodus kommt dann vor, wenn meine zusätzlich vorhandene Tevii S470 als Tuner 0 erkannt wird.

Einmaliges Umschalten behebt das Problem zuverlässig.

Ich habe ein ähnliches Problem. Sobald ich einen DVB-T-Stick zur 6400 dazustecke, wird für diesen der Treiber als erster geladen (/dev/dvb/adapter0) und VDR erkennt ihn wohl daher zwangsläufig als erstes device. Beim Booten hängt der VDR knapp 30s, dann Fehlermeldung "not all devices ready after 30 seconds", danach scheint i.w. alles OK, bis auf zwei Dinge.
Erstens gibt es den beschriebenen Ton-Versatz (und ja, durch Umschalten erledigt).
Zweitens kann er nur mit einem der 6400-devices entschlüsseln - und das obwohl ich das modifizierte dvbhddevice verwende, was ohne den Stick auch einwandfrei funktioniert. So aber erkennt er zB einen Timer-Konflikt.

Ich dachte Transfermodus ist genau das, wohin man mit der Modifikation beide devices zwingen will (oder ist es umgekehrt?). Insofern ist es bei mir umgekehrt: mit DVB-T-Stick klappt der Transfermodus bei einem device gerade nicht, und dazu habe ich am Anfang den Ton-Versatz.

Was könnte man tun?
Könnte man es schaffen, dass der Treiber für die 6400 als erster geladen wird? Oder dass VDR die 6400-devices in jedem Fall als die ersten nimmt (falls das helfen würde)? Warum behauptet er es wären nicht alle devices ready? Alle Treiber sind fertig initialisiert, der Fehler (not all devices ready) kommt auch beim VDR-Restart (ohne Modul-reload).

Auch nicht ganz optimal-intelligent vom VDR: er erkennt zwar (Timer-Konflikt), dass er mit dem zweiten device eine geplante Aufnahme nicht durchführen kann, weil das dazu fähige device zu dem Zeitpunkt bereits mit einer anderen Aufnahme belegt ist (ebenfalls noch nicht aktiv) - obwohl es diese Fähigkeit für diese erste Aufnahme nicht braucht - aber er kommt nicht auf die Idee, es mal umgekehrt mit den devices zu versuchen / zu planen.

Aber das ist ja ein altbekannter VDR-Makel: man hat zu wenig Kontrolle über die devices, kann sie zB nicht bei den Timern selbst auswählen.
Genauso wie beim Streaming: er soll bevorzugt ein lokales device nehmen, sowohl für live wie auch für Aufnahmen (dann erst live eben über Streaming) - so ein Verhalten scheint nicht hinzubekommen zu sein.

Mit dem neuen BIOS 1.07 für das Shuttle SH67 funktioniert nun Wake-On-LAN.
Der ACPI Wakeup aber nach wie vor nicht, ob wake-on-rtc an oder aus ist. Eine BIOS-Einstellung bzgl. HPET gibt es nicht mehr, Kernel-Option noch nicht getestet (wenig Hoffnung). Seufz.