Instabilität vor und nach Aufnahmen bei 1.1

    Seit nach der Umstellung auf Gen2VDR 1.1 das Kabelfernsehen hier wieder in Betrieb ging, beobachte ich häufige Restarts von VDR zu Beginn und nach dem Ende von Aufnahmen - ein Log sagt mehr als tausend Worte: :rolleyes:


    http://phpfi.com/139328


    Die Verweise von [sSMTP] auf ein fehlendes mail finden sich seit Jahren in von verschiedenen Usern geposteten Logs; sie dürften aber wohl nur darauf hindeuten, daß hier offenbar (warum & wovon genau ist nicht bekannt) versucht wird, Benachrichtigungen auf diesem Wege zu versenden.
    emerge procmail; emerge nail wurden durchgeführt, offenbar wird aber ein laufender Mailer-Daemon auf Port 25 erwartet (wie, wenn überhaupt, sollte man diesen auf einem VDR-System aktivieren?). Ein telnet zu dessen Überprüfung (sonst netcat) liefert übrigens erst emerge netkit-telnetd.


    Hier ein weiteres Log der nächsten Testaufnahme:


    http://phpfi.com/139341


    "Verdächtig" sind hier natürlich zunächst einmal Plugin-Konflikte sowie noad.
    Als Verursacher besonderer Systemlast auf der Activy 300 ist alcd bekannt (das unter 1.1 übrigens selbst stabil zu laufen schien!), nach dessen Deaktivierung zeigt sich, daß sein gleichzeitiger Betrieb wohl die VDR-Restarts statt ausführlicherer Fehlermeldungen im Log auslöste. Letztere sind aber schwer verständlich:


    http://phpfi.com/140082


    Kann sich jemand einen Reim darauf machen, woran sich noad, das in Gen2VDR 1.0rc4 problemlos funktionierte, hier offenbar verschluckt (und wie man dieses ggf. vorübergehend abschaltet oder auf manuelle Aufrufe beschränkt) - bzw. wo sonst der Fehler liegen könnte?

    ... ich würde auch wieder die kleinen Problem'chen mit vdr-1.4.x + Bigpatch in die Runde werfen.


    <Umbenannt in> DVB-C Bug mit Bigpatch???


    Wenn du es mal ausprobieren willst vdr-1.4.x + liemikuutio-patch + wareagleicons-patch.

    TEST FOXCONN 560A "Cool`n`Quiet"
    Software: Gen2VDR V2 + vdr-1.6-ext59 + Nvram-Wakeup + KDE
    Hardware: AMD Athlon 64 X2 Dual Core 4800+, 4GB DDR2RAM, SAMSUNG SATA HD501LJ 500 GB, SAMSUNG SP2514N 250 GB, HD SV1604N 160GB, HL-DT-STDVD-RAM GSA-H58N, Cablestar2, TTDVB-C + Scart-out + ASUS-SPDIF


    Activy 300
    Software: Gen2VDR V2 + vdr-1.4.7-ext40 + STR + FreeVo (Browser, Games, ... )
    Hardware: 256MB SDRAM, HD SV1604N 160GB, DVD SD-M1612, FSDVB-C + Scart-out, Technisat Cablestar2, leise

    Danke für die Hinweise - es ist hier nur eine einzige Fujitsu-Siemens DVB-C FF, und daß der Bigpatch evtl. nur bei DVB-C auftretende Probleme verursachen kann, daran hätte ich bestimmt nicht gedacht.


    Könnte sein, daß hier mehrere Dinge zusammenkommen:


    Die Restarts von VDR beim Aufruf von noad lassen sich verhindern, indem man Plugins, insbesondere alcd bzw. graphlcd und das (auf der Activy 300 momentan ohnehin noch nicht funktionierende) graphtft deaktiviert.
    Dann kann noad vor wie auch nach der Aufnahme seine Arbeit aufnehmen, ohne daß VDR dabei abstürzt.


    Der berüchtigte OOM-Killer hat sich zwar nicht bemerkbar gemacht, aber Fehlermeldungen der Dolby- und Audio-Repacker während der Aufnahme, und während noad läuft, ist per top zu beobachten, wie ein Prozess namens hald-addon-stor offenbar Schwerstarbeit verrichten muß (wobei der Swapspace allerdings nur bis etwa 190 MB in Anspruch genommen wird) - möglicherweise stösst das System mit nur 128 MB einfach an seine Speicherplatzgrenzen (oder die Performance reicht nicht beim Swappen in den 256 MB virtuellem Speicher).


    Die Mails sind lediglich Statusmeldungen von noad ("logger: "), wahrscheinlich weil in /etc/metalog/metalog.conf "Mail :" konfiguriert ist - sSMTP fängt sie als "Sparversion von sendmail" ab und schreibt sie in die /root/dead.letter - wo sie außer bei noad-after ohnehin nur eine Leerzeile enthalten. Abschalten sollte man sie trotzdem, denn von diesem auf einem VDR überraschenden Weg der Protokollierung weiß wohl fast niemand.

    Bzgl. der noad-dumps selbst wusste im Chat nun woppr, der vom selben Netzbetreiber KabelBW versorgt wird, interessanterweise zu berichten, daß auch auf seinem deutlich besser ausgestatteten System solche Fehler offenbar seit einer netzbetreiberseitigen Umstellung der DVB-C-Belegung häufiger vorkommen - möglicherweise spielen hier auch Fehler im Stream mit, da er vielleicht schon beim Multiplexing nicht korrekt zusammengebaut wird, oder weil die Frequenztabelle (PDF S. 11 aus den Spezifikationen) hier mit sehr kritischen Nachbarkanälen gespickt ist.

    Für noad 0.6.0 hat woppr bereits einen Bugfix ausgetüftelt: :]

    Diff
    --- /usr/local/src/noad-0.6.0/vdr_cl.h     2006-08-13 18:10:19.000000000 +0200
+++ /usr/local/src/noad-0.6.0/vdr_cl.h  2006-08-13 18:11:02.000000000 +0200
@@ -52,7 +52,7 @@
#define KILOBYTE(n) ((n) * 1024)
// The maximum size of a single frame:
-#define MAXFRAMESIZE  KILOBYTE(192)
+#define MAXFRAMESIZE  KILOBYTE(256)
#define FRAMESPERSEC 25
#define FRAMESPERMIN (FRAMESPERSEC*60)

    Bei Gen2VDR 1.1 also im Verzeichnis /usr/local/src/_div/noad-0.6.0 z.B. per nano -w vdr_cl.h in Zeile 55 die Zahl 192 durch 256 ersetzen, dann make;make install und noad sollte wieder ohne Dumps oder Abstürze laufen. :)


    DISCLAIMER: Niemand übernimmt Verantwortung für irgendwas. :whatever

    Es ist offenbar auch ein Lastproblem beteiligt, vermutlich wenn bei knappem RAM ein großer Teil des "Hauptspeichers" tatsächlich nur aus der Swap-Partition besteht:


    Nach Installation einer zusätzlichen Budget-Karte (Terratec Cinergy 1200 DVB-C, a.k.a. KNC1) treten die Symptome auch mit korrigiertem noad wieder auf - solange die Plugins alcd oder GraphTFT aktiv sind (die sich dann nur noch über die PLUGINS-Zeile in /etc/conf.d/vdr entfernen lassen, um VDR wieder benutzbar zu machen).


    Mit der zweiten Karte ist nun ein Auftreten dieser Fehler bei einer Testaufnahme im Zusammenhang aus /var/log/messages ersichtlich:

    Also ein (reines) Ressoucenproblem ist es jedenfalls nicht:
    Bin endlich auf Speicher gestoßen - mit 256 MB RAM rührt das VDR-System den Swapspace kaum an (selbst wenn http://ten.htpc-forum.de/burn-0.0.10d.tar.gz mit ProjectX 0.90.4 DVDs erstellt, werden nun gerade einmal noch 300kB davon in Beschlag genommen) - aber dennoch kommt es zum (leider kommentarlosen) VDR-Neustart an gleicher Stelle, wenn alcd und/oder graphtft laufen.


    Auch die VDR-Restarts bei "Gelöschte Aufnahmen entfernen" sind immer wieder zu beobachten.

    ... VDR ohne Patches hast du schon probiert und die selben Probleme?

    TEST FOXCONN 560A "Cool`n`Quiet"
    Software: Gen2VDR V2 + vdr-1.6-ext59 + Nvram-Wakeup + KDE
    Hardware: AMD Athlon 64 X2 Dual Core 4800+, 4GB DDR2RAM, SAMSUNG SATA HD501LJ 500 GB, SAMSUNG SP2514N 250 GB, HD SV1604N 160GB, HL-DT-STDVD-RAM GSA-H58N, Cablestar2, TTDVB-C + Scart-out + ASUS-SPDIF


    Activy 300
    Software: Gen2VDR V2 + vdr-1.4.7-ext40 + STR + FreeVo (Browser, Games, ... )
    Hardware: 256MB SDRAM, HD SV1604N 160GB, DVD SD-M1612, FSDVB-C + Scart-out, Technisat Cablestar2, leise

    Zitat

    Originally posted by netz
    ... VDR ohne Patches hast du schon probiert und die selben Probleme?

    Erst einmal die Speicheraufrüstung versucht - den Absturz mit GraphTFT allein kann ich mit verdoppeltem RAM nicht mehr reproduzieren. :]
    Allerdings ruft GraphTFT immer noch einige i18n-Fehler hervor, die eigentlich harmlos sein sollten, aber erfahrungsgemäß den VDR auch destabilisieren können (aus unbekannten Gründen):

    Code
    Aug 30 09:19:08 [vdr] [22232] graphtft: no translation found for 'DVD' in language 1 (Deutsch)
Aug 30 09:19:08 [vdr] [22232] graphtft: no translation found for 'MP3' in language 1 (Deutsch)
Aug 30 09:19:08 [vdr] [22232] graphtft: no translation found for 'MPlayer' in language 1 (Deutsch)

    Leider sind diese Strings offenbar nicht in GraphTFT enthalten, und ich kenne den Quellcode nicht gut genug, um ihre Herkunft zu ermitteln und zur Vermeidung dieser Fehler umzubauen. Möglicherweise liegt das Problem schon in einem vorgelagerten Aufruf von tr('unübersetzbarer Menüpunkt') ...


    Nachdem Coredumps aktiviert wurden (vdr und "verdächtige" Plugins rekompiliert) und einige Backtraces (bt in gdb) auf Fehler in einer Stringformatierung in alcd hinwiesen, hat mir HelAu freundlicherweise eine ganz neue vdr-alcd-1.1.0.tgz zur Verfügung gestellt, mit der sich in diesem Plugin ebenfalls bislang keine Abstürze mehr provozieren ließen. :]
    helau: Mit DEFINES += -DDEBUG im Makefile wird alcd-1.1.0 allerdings so gesprächig, daß für nichts anderes mehr Platz in /var/log/messages ist. Das Abschalten von Samba und XXV funktioniert nur über rc-update del dienst und manuelles Editieren von /etc/conf.d/vdr; beim Versuch über admin passiert nur folgendes: http://phpfi.com/147225


    Den noad-Fehler (ursprünglich zu knapper Puffer) hat inzwischen ja woppr bereits behoben. :]


    Es spielten also mehrere Probleme zusammen, die sich jedemfalls bei knappem Speicher und dadurch ohnehin schon hoher Last nicht auseinanderhalten ließen.


    Die folgenden Fehlermeldungen treten auch dann noch auf, wenn "Mail : " in /etc/metalog/metalog.conf auskommentiert ist:

    Code
    Aug 30 21:47:05 [sSMTP] Unable to locate mail
Aug 30 21:47:05 [sSMTP] Cannot open mail:25

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden