Posts by wfaust

    kodi-start.conf soll Kodi automatisch nach dem Booten/Resume starten. Frontend und Kodi sollen nicht gleichzeitig laufen. Vielmehr soll darauf gewartet werden, daß das VDR+Frontend gestartet ist und erst anschliessend wird dann auf Kodi umgeschaltet (was das Frontend wieder beendet). Siehe auch hier . Es hat sich hier bei Tests gezeigt, daß es besser ist auf vdr und frontend zu warten. Kodi-start.conf läuft jetzt seit einiger Zeit auf mehreren yaVDR Clients hier ohne Probleme.


    Was das Beenden angeht, so habe ich ehrlich gesagt an der Baustelle noch nie gearbeitet. VDR und Kodi werden ja schon normal vorm Suspend beendet. Ich muß also wohl zuerst Openbox und Alsa/Pulseaudio beenden. Dann wird es für mich schon schwieriger: plymouth? Und womit beende ich X? xorg-launcher?


    nvidia-persistenced? Ich kann hier keinen Prozess mit persistenced oder persist finden. Auch kein Module und auch kein passende Datei in /usr/bin. Habe den 340 Treiber.

    Load_Cycle_Count hat ja nichts mit dem hier diskutierten Spindown zu tun (ausser daß der Spindown meistens auch den Load_Cycle_Count erhöht).


    Das Load_Cycle_Count Problem der Greens und älteren Reds ist ja bekannt und kann z.B. wie von Dir beschrieben meistens abgestellt werden. Ob die hohen Load_Cycle_Count Werte wirklich zu signifikant höheren Ausfallraten führt, ist nach meiner Kenntnis nicht ansatzweise bewiesen. Jedoch gut dabei schlafen tut halt keiner. Das ist beim Spindown/up ähnlich. Hier will keiner hohe Smart-Werte sehen und früher sind Festplatten wirklich oft daran futsch gegangen. Ich verwende hier seit vielen Jahren Spindown (mit 1 Stunde nicht zu aggressiv eingestellt... ca. 4-5 Starts pro Tag) und sehe keine größeren Ausfallraten im Vergleich zu den Festplatten mit wenig Starts. Ich weiß, nicht re­prä­sen­ta­tiv, dennoch nicht nur ein paar Laufwerke. Externe Gehäuse in denen Festplatten im Sommer beim längeren Schreiben schnell >50C werden scheinen die Ausfallrate massiv zu steigern.


    Ich selbst hatte auch einige dutzend 1,2 und 3TB Greens. Davon lebten nach 3 Jahren nur noch wenige. Bei den Seagate und Samsung Festplatten sah es oft noch schlechter aus. Meine Ausfallraten waren oft ähnlich zu den oft zitierten Backblaze Ausfallstatisken. Habe dann etwas nachgeforscht und bin auf Hitachi bzw. später auf WD Reds (>3TB!) umgestiegen. Seit 4 Jahren mit dutzenden Festplatten in diversen Servers/Backup Systemen hatte ich bislang keinen einzigen Ausfall mehr. Ähnlich wie bei Backblaze scheinen die neuen >3TB Festplatten bislang wirklich besser zu sein.


    Noch eine Warnung zum Thema Spindown und Linux: Gerade wenn mehrere Festplatten gleichzeitig aufgeweckt werden sollen, kann es schnell Zuverlässigkeitsprobleme geben. Scheinbar dauert es dann manchmal einfach zu lange und es kommt vor, daß eine Festplatte aus dem System verschwindet oder read-only wird. Also checkt Eure Logs auf Fehler! Bei mir war die Lösung letztlich einen Controller zu nehmen, der das mit dem Aufwecken zuverlässig hinbekommt. Aber das ist dann die teure Lösung :-(

    Das vdr auf stop steht ist korrekt. Der Rechner wurde per regular Timer um 2:55 gestartet und nach 30 Minuten hat sich dann vdr korrekt beendet (das System aber wegen des oben beschriebenen Problem nicht ausgeschaltet). Vielleicht sollte ich es irgendwie hinbekommen, den Aufruf direkt nach dem Einschalten zu machen. Das wird um 2:55 schwer. Der Rechner ist remote. Vielleicht in ein paar Tagen.


    Aber mir ist aufgefallen, daß das hier von mir schon gepostete Upstart Script zum automatischen Start von Kodi nicht gestartet wird. Das kodi-start.conf Script wird normal gestartet durch:


    Code
    1. start on (startup and
    2. (started vdr
    3. and started vdr-frontend)
    4. or (resume
    5. and
    6. (started vdr
    7. and started vdr-frontend)))


    Insofern würde ich doch einmal darauf tippen, daß vdr oder vdr-frontend für upstart entgegen den Logs nicht gestart wurde. Da der exec-Befehl in vdr.conf keinen Fehler meldet (habe hier logger Befehle hinzugefügt), würde ich jetzt doch einmal auf das Frontend tippen. Allerdings wurde das frontend lt. initctl gestartet.


    Daher noch einmal meine Frage: Wie bekomme ich beim Aufwachen den nvidia-Treiber neu geladen? Welche daemon/module müssen da alle beendet/entladen werden? Ich denke, ich werde dann einfach mal ausprobieren, diverse Daemon/module beim Einschalten neu zu laden und dann schauen, ob das Problem weg ist. Falls das hilft, kann man den Verursacher durch try&error finden.

    Heute tratt der Fehler wieder auf und ich habe mal initctl list aufgerufen:



    Vdr hatte sich in der Zwischenzeit wegen Inaktivität beendet. Auch sonst sehe ich in den Logs trotz reichlich hinzugefügter Befehle nur, daß VDR und Frontend erfolgreich gestartet wird. Warum dann aber das aufrufende initctl nicht weiter macht und hängt, bleibt weiter ein Rätsel.


    Ich würde jetzt als nächstes mal versuchen, den NVidia-Treiber und diverses andere mehr beim Aufwecken neu zu laden. Nennen wir es einfach mal ein ungutes Gefühl das ich habe, das mich dazu treibt. Frage: Was muss ich tun, um den Nvidia Treiber neu zu laden? Openbox, xorg-launcher, alsa beenden? Und dann das nvidia Module neu laden?

    hd-idle hatte bei mir in der Vergangenheit in einigen Fällen Probleme, die Festplatte zu befriedigen. Die von hd-idle verwendete Vorgehensweise wird nicht von jeder Festplatte bzw. SATA/USB/FireWire-Adapter unterstützt. Aber meistens ist es wohl am einfachsten es erst einmal mit hd-idle zu versuchen. Kompatibler mit diversen Festplattengehäusen usw. ist das von Druidenschlumpf am 29./30. Mai gepostete Script hier

    Ich habe mit service status diverse mögliche Upstart Dienste geprüft - und wie beschrieben die Upstart Logfiles. Aber wenn das nächste Mal das Problem wieder auftritt, schaue ich mit initctl nach. Ich habe auch noch ein paar Log-Befehle in diverse Upstart Scripte eingefügt. Jetzt heißt es auf den Fehler warten :-(

    Ich habe ein weiteres Problem bei meinen yaVDR 0.6.1 (stable) Usern gefunden und ich hoffe, jemand hier kennt eine Ursache/Fix:


    Der Rechner läßt sich per FB nicht ausschalten. VDR wird zwar beendet, dann aber fährt das System nicht weiter runter. Soweit ich feststellen konnte, liegt die Ursache schon beim Aufwachen aus S3 daran, daß manchmal das /etc/pm/sleep.d/20vdr_sleep Script nicht beendet wird. Soweit ich es verstanden habe, wird in den Script mittels "initctl emit resume" im wesentlichen die dvb-Treiber (gibt es hier nicht) und VDR gestartet und das klappt scheinbar auch. Zumindest sehe ich im log "vdr.conf: vdr is ready" und auch sonst gibt es scheinbar keine Probleme bei der Nutzung (Bild, Ton, usw. ist ok). Doch nach dem Start von VDR geht es scheinbar nicht weiter bei initctl und 20vdr_sleep wird nie beendet, woraufhin dann später das Ausschalten des Systems mittels der pm-utils auch nicht klappt. Ich wüßte jetzt nicht, wo ich noch Log-Befehle einfügen könnte um die Ursache für den Hänger weiter einzugreisen. In den Upstart-Logdateien habe ich auch nichts gefunden.


    Darum die Frage(n):


    Hat hier jemand einen Tipp, was ich machen könnte, um die Ursache bei initctl weiter einzugreisen bzw. hat jemand schon einen Fix für das Problem?


    Derzeit helfe ich mir mit folgender /etc/init/wait-for-vdr.conf Datei, die nach 25 Sekunden nach dem Einschalten schaut, ob das 20vdr_sleep Script noch läuft und dann rebootet:


    Das System zu Rebooten ist naklar böse. Ich frage mich daher, ob es einen besseren Weg gibt das hängende 20vdr_sleep Script beim Start zu beenden. Kann ich nicht einfach ein & hinter "initctl emit resume" in 20vdr_sleep hinzufügen?

    Ich habe bei mehreren yaVDR 0.61 stable Users hier immer wieder das gleiche Problem: Inbesondere wenn Kodi >60 Minuten lief und dann wegen Inaktivität ausschaltet, hängt Kodi beim beenden. Manchmal sieht man dann nur noch einen schwarzen Bildschirm. Manchmal ist aber noch der Kodi Bildschirm sichtbar, doch die Software reagiert nicht auf die FB. Das Log von Kodi gibt nicht wirklich viel her:



    Interessant ist, daß ein hängendes Kodi durchaus noch von einem "stop kodi" Befehl beendet wird. Auch das VNSI Addon produziert noch Log-Einträge (s.o.). Kodi ist also noch nicht so weit beendet, daß garnichts mehr läuft. Ist das VNSI Addon aktiviert, läuft ein CPU Kern auf 100%. Ohne VNSI Addon wird fast keine CPU Last angezeigt.


    Das Problem taucht nicht immer auf, aber insbesondere wenn das System aus S3 aufgeweckt wurde und das VNSI Addon eingeschaltet ist, hängt Kodi gerne beim Ausschalten nach 65 Min Inaktivität. Das Problem taucht aber auch gelentlich nach einem Kaltstart und ohne VNSI Addon auf. Nach z.B. 10 Minuten Inaktivität klappt das Ausschalten praktisch immer. Man muß also doch etwas warten. Auch tritt das Problem auf, wenn man per Power-Taste auf der FB Kodi beenden will.


    Irgendeine Idee, woran es liegen könnte? Oder wie ich evtl. weiter vorgehen sollte, um die Ursache zu finden?


    Derzeit helfe ich mir mit folgendem Script, daß einfach darauf achtet, ob Kodi beenden will und dann notfalls nach 12 Sekunden einen Stop-Befehl absetzt:



    Wobei ich das Script mittels /etc/init/kodi-stop.conf Upstart-Datei starte:

    Code
    1. description "ensures kodi does not hang on exit"
    2. start on started kodi
    3. stop on stopped kodi
    4. script
    5. exec /usr/local/bin/mykodi.sh
    6. end script

    Inzwischen habe ich yaVDR auf einigen Rechnern mit Nvidia Chipsatz installiert. Nachdem wie hier beschrieben die Probleme mit Abstürzen und Hängern des forcedeth Netzwerk-Treibers beseitigt wurden, bleibt jedoch weiterhin ein Zuverlässigkeitsproblem bei Übertragungen. Die von vier System gesammelten Daten zeigen, daß manchmal beim Aufwecken/Starten der Netzwerktreiber innerhalb der ersten 10 Minuten anfängt mit Empfangsfehlern zu kämpfen, die nach einiger Zeit zu erheblichen Problemen bei der Verbindung sorgen.


    Derzeit versuche ich das Problem zu erkennen und im Fall von Übertragungsfehlern in den ersten 2000 Sekunden den Rechner entweder gleich noch einmal neu zu booten bzw. den forcedeth Treiber neu zu laden. Das klappt, stört aber evtl. schon gestartete Übertragungen. Folgendes Script wird bei mir bei jedem Start/Aufwecken gestartet:



    Jetzt frage ich mich, hat hier jemand Erfahrung gesammelt, wie man das Empfangsproblem mit forcedeth besser vermeidet?

    Noch ein Nachtrag: Ich habe eben auch auf meinem älteren Asus M4N78Pro Motherboard einmal die pci=nomsi Option aus Grub rausgenommen. Die Ursache des Problems ist wohl ein Resourcenkonflikt inbesondere mit dem forcedeth Netzwerk Treiber, der auf vielen NVidia Chipsatz Boards zum Einsatz kommt. Der forcedeth Treiber scheint oft zu Problemen mit Hängern bei Netzwerk, Bildschirm usw. zu führen. Um das Problem dauerhaft bei mir auszuschalten reichen folgende Befehle als root auszuführen:


    Code
    1. echo options forcedeth msi=0 msix=0 >> /etc/modprobe.d/options
    2. update-initramfs -u
    3. reboot


    Für weitere Info siehe hier und hier

    Die Probleme beim Aus- oder Einschalten von yaVDR 0.61 werden scheinbar durch den forcedeth Netzwerktreiber der NVidia Chipsätze verursacht. Die Lösung fand ich hier . Insofern empfehlen sich wohl folgende Befehle als root auf Nvidia basierten Boards mit forcedeth Netzwerktreiber:


    Code
    1. echo options forcedeth msi=0 msix=0 >> /etc/modprobe.d/options
    2. update-initramfs -u
    3. reboot

    Inzwischen ist das Problem mehrmals wieder aufgetretten und langsam Kreise ich ein, was hier passiert. Das Problem wird nicht durch den VDR segfault verursacht. Es ist auch kein Problem beim Ausschalten, sondern vielmehr geht schon etwas beim Aufwachen aus S3 per acpiwakeup von yaVDR hier schief. Das pm/sleep.d/20vdr_sleep resume suspend Script wird beim Aufwachen nie beendet, weshalb später beim Ausschalten der /sbin/initctl --quiet emit --no-wait init-s3 Aufruf im VDR Shutdown Hook das System nicht wieder in S3 versetzt. Ich denke, daß Problem bekomme ich jetzt durch einen entsprechende Abfrage mit evtl. Reboot gelöst...

    Das Problem sehe ich darin, daß er per Software nur erkennen kann, ob der TV beim Booten des Rechners an war. Er muß aber letztlich erkennen, ob der TV nach dem Booten eingeschaltet wurde. Da aber vermutlich das HDMI Handshake zwischen TV und Receiver nicht funktioniert (der Verstärker liefert ja einen Ton. was auf eine funktionierende VDR->Receiver Verbindung schließen läßt), hat der VDR Rechner oder Receiver das Einschalten nicht mitbekommen. Es besteht also keine Verbindung, die man per Software abfragen könnte. Wie gesagt, mein Tipp wäre, mal einen aktiven HDMI Repeater zu versuchen. Ansonsten sehe ich schwarz, denn in einer Schleife dauernd den X-Server neu zu starten um zu sehen, ob nach dem dann erfolgreichen Handshake der TV an ist (müsste man evtl. in den Logs sehen... oder einfach schauen ob Du per get-edid die Edid Daten lesen kannst), hört sich für mich nach keiner wirklichen Lösung an.

    Auch ich vermute, daß Problem liegt beim HDMI Handshake vermutlich zwischen TV und Receiver. Das kommt leider wohl öfters vor als man denkt. Auch zwischen meinem Onkyo Receiver und Samsung TV gibt es schnell richtig Ärger. Mein Tipp: Kauf einfach einen billigen (ca. 25 EUR) aber aktiven(!) HDMI Repeater. Hat nicht nur bei mir damals das Problem gelöst. Nachteil: Ein weiteres Gerät mit einem Steckernetzteil und ein Wechsel des Bildschirmmodus dauert jetzt wegen des doppelten HDMI Handshakes ca. 2 Sekunden länger.

    Mein User hat noch keinen TV Tuner, aber hoffentlich bald.


    Das Installieren einer debug Version bei einem 400km entfernten remote Client scheint mir noch nicht nötig. Meine neuste Erkenntnis: Das Gerät scheint durchaus trotz segfault ausschalten zu können. Das Problem könnte also durchaus garnicht mit dem segfault zusammenhängen.... ich suche weiter... derzeit vermute ich, daß das Problem entweder nur auftaucht, wenn der Rechner per acpiwakeup Timer Nachts gestartet wird oder wenn der Rechner wegen Inaktivtät ausschaltet - letzteres scheint aber irgendetwas zu hinterlassen, daß dafür sorgt, daß ich VDR nicht einfach neu Starten kann und dann per Powertaste ausschalten kann. Ich muß erst den Rechner neu booten um dann den Rechner remote ausschalten zu lassen.


    Ich kreise weiter...

    Ich habe wegen baulicher Gründe keinen guten Sat-Empfang und habe in den letzten Jahren auf der Suche nach 1-2% mehr Signalqualität viel ausprobiert (diverse Sat-Schüsseln, LNBs, Switches, Receiver, Sat Karten). Ich bin immer auf der Suche nach etwas besserem das mir doch noch den störungsfreien Empfang eines Transponders erlaubt. Insofern war die Werbung eines empfindlichen Eingangs wie bei der 952 für mich Grund genug, diese unter yaVDR 0.5 auszuprobieren. In Kombination mit einem guten Inverto Black Ultra LNB erreiche ich hier damit die besten Ergebnisse, auch wenn es für für ein paar Transponder immer noch nicht so ganz reicht. Ja, viele Sat-Karten hier waren wirlich deutlich schlechter als die meisten guten Receiver... die 952 aber nicht. Auch der LNB ist nach meiner Erfahrung eine sehr günstige Möglichkeit viel an Qualität zu gewinnen. Bei vielen LNBs wird bei mir im Low-Band alles dunkel.


    Irgendeinen Tip, was noch besser ist? Wenn es mich nicht in den Ruin treibt, probiere ich es gerne aus. Immer noch besser als auf Kabel mit Abzockgebühr zu wechseln. Wirklich halbwegs brauchbare Vergleichsdaten findet man ja leider nur selten.

    Ich habe hier einen remote yaVDR client mit aktuellem stable Update der Nachts um 02:55 per acpiwakeup startet und dann nach einigen Minuten der Inaktität wieder ausschalten soll. Dies funktioniert nicht, da scheinbar beim Ausschalten VDR einen segfault erzeugt. Ich finde dann am nächsten Tag die Maschine eingeschaltet und ohne laufenden VDR. Ich kann VDR dann auch starten, doch beim Ausschalten gibt es weiter einen segfault. Erst nach einem reboot klappt das Ausschalten dann wieder. Hier das Log mit segfault:



    Ich hatte schon versucht, möglichst viele VDR plugins auszuschalten, doch der segfault bleibt, auch wenn nur noch folgende plugins aktiv sind:


    Code
    1. ls /etc/vdr/conf.d
    2. 00-vdr2.conf 02-vdr-charset.conf 40-osdteletext.conf 50-control.conf 50-menuorg.conf 50-restfulapi.conf 50-svdrpservice.conf
    3. 00-vdr.conf 03-vdr-lirc.conf 50-channellists.conf 50-dbus2vdr.conf 50-osdserver.conf 50-softhddevice.conf 50-text2skin.conf


    Irgendeine Idee, wo ich suchen sollte?


    Ich vergaß: Der Rechner hat noch keinerlei TV Karte und damit auch keinen Sender in der channels Datei. Der User benutzt eigentlich nur Kodi. Hat VDR damit Probleme? Was sollte man sonst als "leeren" Kanal einstellen?

    seahawk1986 :


    Das Problem mit Kodi hängt nicht mit Lifeguard zusammen. Es geht einfach nur darum, daß Kodi bei Inaktivität beendet werden muß. Kodi soll sich bei mir nach 1h50m beenden wobei in VDR 1h55m eingestellt ist, so daß nur wenige Minuten nach Kodi dann das System von VDR runtergefahren wird. Das Problem ist halt, daß Kodi oft nicht beendet wird (aber scheinbar noch normal läuft und auch manuell beendet werden kann). Ich frage mich, ob dies evtl. irgendwelche Addon Update- bzw. VNSI-Meldungen sind. Ich habe auch nur UT 2-3 Scraper Addons zusätzlich installiert. Die sollten das Problem nicht verursachen.


    VDR schaltet bei mir meistens bei Inaktivität sauber ab. Nur manchmal klappt es einfach nicht und VDR versucht es nicht einmal (also kein Lifeguard Problem). Noch ist unklar, woran es liegen könnte, daher meine Frage bzgl. des OSD um die mögliche Ursache besser einzugreisen und zu lösen.

    seahawk1986 :


    Ah... und ich mich erst vor einer Stunde hier gewundert, warum mein Testsystem seit Stunden ohne Aktivität nicht runtergefahren ist. Das das System bei Inaktivität nicht zuverlässig runterfährt war hier die letzten Testwochen ein häufiger auftrettendes Problem, dessen ich mich eigentlich jetzt über Ostern widmen wollte (hoffentlich das letzte Problem, bevor meine User das yaVDR 0.61 System ausgeliefert bekommen ;-). An Lifeguard liegt es nicht, da ich sehr wohl per FB runterfahren kann.


    Frage: Wie erkennst Du, daß das OSD an User-Aktivitäten denkt? Ich würde gerne die Ursache hier weiter einkreisen, warum manchmal VDR nicht mal versucht auszuschalten. Bei Kodi ist es scheinbar noch schlimmer und der Rechner läuft oft den ganzen Tag, wenn ich nicht die FB zum ausschalten benutze. Ich hatte die Vermutung, daß hier irgendwelche Meldungen (VNSI, Addon Updates) als Aktivität zählen?