Beiträge von ecki

Hi,

das syslog sieht eigentlich in Ordnung aus, das einzige, was vielleicht stört ist:
Dec 1 14:10:11 vdr vdr: [2366] ERROR (svdrp.c,407): Broken pipe
Diese Meldung scheint in Zusammenhang mit ttxtsubs zu stehen. Ob das für das nicht-ausschalten verantwortlich ist kann ich nicht sagen.
Du benutzt ne Menge Plugins mit denen ich keine Erfahrung habe, probiere mal diese zu deaktivieren: in die /etc/vdr/plugins/order.conf '-Pluginname' eintragen. Deaktiviere einfach mal alle und schaue ob es funktioniert. Wenn das nicht hilft, benenne zusätzlich noch die setup.conf um, damit du es mal mit den Standardeinstellungen probieren kannst.
Viel Glück,
Sebastian

Am noad-shutdown hook dürfte es nicht liegen, wenn noad noch läuft, versucht der vdr es alle 5 minuten nochmal bis noad halt fertig ist. Ich lasse noad auch auf nem 300er P2 laufen. Funktioniert wunderbar inkl. shutdown, dauert halt ne weile.

Stimmt vielleicht was mit der Uhr des Boards nicht oder geht der Rechner mit zu viel Vorlaufzeit an? Wenn ich mich recht erinnere prüft der vdr beim start ob er in einem bestimmten Zeitfenster vor (oder während) der Aufnahme gestartet wurde. In dem Fall geht er von nem Timer-gesteuerten Start aus und fährt herunter wenn die Aufnahme beendet ist. Dies wird unterbrochen, wenn man eine Taste drückt.
Ich sehe jetzt zwei mögliche Probleme. 1) Der Aufwachzeitpunkt ist zu zeitig und damit ausserhalb des Bereiches um den Timer. 2) aus irgendeinem Grund geht deine Boarduhr falsch. Dann ist er natürlich beim Start auch ausserhalb des Bereiches, setzt aber die Uhrzeit kurz nach dem Start wegen des Abgleiches mit dem Transponder auf die richtige Uhrzeit und nimmt alles korrekt auf. Schau dir mal das Log rund um den VDR-Start an. Falls dies so ist, sollte da irgendwo ein Zeitsprung bei den Einträgen sein.

Als Workaround sollte folgendes funktionieren. Trage

/usr/lib/vdr/svdrpsend.pl HITK Power

in die /etc/vdr/recording-hooks/R90.custom bei before ein.
Damit wird die Powertaste beim Start einer Aufnahme gedrückt. Da gerade eine Aufnahme läuft, wird der vdr nicht sofort heruntergefahren, sondern erst wenn die Aufnahme beendet und noad fertig ist. Solltest du zu dem Zeitpunkt gerade fernsehen, wird durch eine beliebige Taste während der Aufnahme dieser Zyklus unterbrochen und er fährt nicht herunter. Einziger Nachteil: du hast bei jedem Timer eine Einblendung, dass er nach der Aufnahme runterfahren wird.

Hallo GBruno,

das passiert, wenn das Board nicht dafür geeignet ist. Je nach ACPI-Implemation im Bios kann das Board meist mindestens zu einer bestimmten Uhrzeit wecken, dann wird auch nur die Uhrzeit abgespeichert. Die Besseren können es auch zu einem bestimmten Tag innerhalb des nächsten Monats oder auch zu einem bestimmten Datum abspeichern.
Für dein Problem gibt es diese Optionen mit den regular_days in der Konfiguration. Das kannst du z.B. auf täglich 5:00 stellen und einen cron-job anlegen, der z.B. Wartungssachen o.ä. (tvmovie-update...) um diese Zeit macht und den Rechner wieder abschaltet. Wenn man das nicht macht, hat man das Problem, falls ein timer für übermorgen anliegt, er morgen angeht und erst nach Stunden wieder automatisch ausgeht.

Alternativ könntest du auch mal einen neueren Kernel probieren (s.o.). Bei mir kann ich seit dem Kernel 2.6.23 über die rtc-Methode bis zu einem Jahr in die Zukunft programmieren.

Also ich backe mir meine Kernel selbst. Da der 2.6.22 bei mir nicht funktionierte hatte ich es beim 2.6.23 das erste mal probiert. Kann sein, dass in der 2.6.22 noch etwas anders war. Bei mir bleibt die Datei auch ohne Fehlermeldung leer wenn ich eine ungültige Zeit eingebe. Also vielleicht hilft dir ein frischer Kernel 2.6.23, ist wirklich nicht schwer.

Wo genau hast du denn deinen Kernel her, dann würde ich den auch mal testen?

Funktioniert denn ein direktes echo $((`date +%s` + 650)) >/sys/class/rtc/rtc0/wakealarm mit anschliessendem cat?

Im Paket dvb-utils ist eine Kommandozeilenversion von femon enthalten, damit kannst du dir die Stärke ansehen. Siehe: http://www.vdr-wiki.de/wiki/index.php/Dvb-apps_femon
Ich bin mir grad nicht sicher, ob der vdr dabei laufen darf.

Ok, zum einen hatte ich dir das falsche geschrieben. Ich ging davon aus, dass die Kommandozeilenparameter bei 0 anfangen zu zählen. Daher dachte ich den ersten Parameter auf irgendetwas setzen zu müssen. Das Kommando zum Testen sollte jetzt jedenfalls heissen /usr/share/vdr/shutdown-hooks/S90.acpiwakeup $((`date +%s` + 400)), dies setzt eine Aufwachzeit in 400Sek.

Ich habe aber trotzdem den Fehler im Skript gefunden: In Zeile der Zeile "TIME_TO_SET=$TIMER else" muss das else in einer neuen Zeile beginnen, dann klappt es auch.

Die 1.4.7 benutze ich auch.
Dass im Log gar nichts ankommt ist komisch. Ich habe in deinem Skript ertmal keinen Fehler gefunden. Es scheint, als ob deine time_to_set Variable leer ist. Denn zumindest "Setting ACPI alarm time to:" ist unabhängig von der neuen wakeup-Position.
Probiere doch mal in dem Skript an verschiedene Stellen ein echo $TIMER bzw. $TIME_TO_SET einzufügen und das Skript von hand per /usr/share/vdr/shutdown-hooks/s90.acpi-wakeup.sh 111 `date +%s` zu starten. Irgendwo scheint die Variable gelöscht zu werden.
Wenn ich zu hause bin kann ich ja mal mein skript posten, auch wenn ich auf den ersten Blick keinen Unterschied sehe.

Ich benutze Kernel 2.6.23.8

Es gibt mittlerweile eine alternative Möglichkeit die rtc des Computers anzusteuern. Bei mir heisst das neue Modul rtc_cmos. Da das alte Modul ein laden des neuen verhindert kann man es entweder nicht mit in den Kernel kompilieren oder man muss es blacklisten, dazu einen Eintrag 'blacklist rtc' in die /etc/modprobe.d/blacklist eintragen.

Wenn das neue Modul erfolgreich geladen wurde steht in etwa so etwas in in der dmesg:

dmesg |grep rtc
rtc_cmos 00:05: rtc core: registered rtc_cmos as rtc0  
rtc0: alarms up to one year, y3k

Man hat damit auch eine neue Verzeichnisstruktur unter /sys/class/rtc/.
Nun muss man dem ACPI_Wakeup Skript noch mitteilen, wo der neue Wecker ist. In /etc/vdr/vdr-addon-acpiwakeup.conf folgendes ändern:
ACPI_ALARM=/sys/class/rtc/rtc0/wakealarm

In /usr/share/vdr/shutdown-hooks muss auch noch einiges verändert werden.
Zum Einen wird die Zeit bei der neuen Methode in Sekunden erwartet. Da dies das gleiche Format ist, wie der VDR es ausgibt, ist eine Konversion per TimeToString nicht mehr nötig. Also die Stellen mit TIME_TO_SET=`TimeToString $TIMER` durch TIME_TO_SET=$TIMER ersetzen. Das neue System erlaubt kein Setzen der Zeit wenn schon ein Timer existiert, deshalb muss dieser vorher gelöscht werden.
Dazu vor der Zeile "echo TIME_TO_SET >$ACPI_ALARM" ein "echo 0 >$ACPI_ALARM" einfügen. Da mit der neuen Methode ein zweimaliges Setzen eh nicht möglich ist, habe ich die zweite echo-Zeile noch auskommentiert.

Ich hoffe, du kommst damit ans Ziel.
Was mir bei meinen Tests noch aufgefallen ist: Wenn man in die /sys/class/rtc/rtc0/wakealarm einen Wert einträgt, wird er vom Modul irgendwie umgerechnet. Also ein 'cat' liefert einen anderen Wert als man per 'echo' reingeschrieben hat. Aber es funktioniert!
Wenn das bei dir funktioniert, können wir vielleicht Tobi bitten, eine kleine Änderung am offiziellen addon vorzunehmen um dies für alle zur Verfügung zu stellen.

/proc/acpi/alarm ist deprecated und wird in neueren Kerneln nicht mehr unterstützt. Dies läuft jetzt über das rtc-device und ist an einer anderen Stelle. Ich bin letztens auch von nvram wieder auf diese Schiene umgestiegen. Das ACPI-shutdown Skript habe ich entsprechend angepasst, in den letzten 2 Wochen hat es auch zuverlässig funktioniert. Die gute Sache ist, seit der Umstellung funktioniert mein board bis zu ein Jahr in die Zukunft (vorher max 24h). Ich bin grad noch unterwegs, poste aber sobald ich zu hause bin mal die Änderungen.

Bei fehlendem Ausgabegerät kannst du dir mit vdr-plugin-control das Menü auch per Telnet oder auf der Textkonsole anschauen. Bei der Gelegenheit solltest du dir auch mal mit dem femon-Plugin die Stärke des Sat-Signals ansehen.

Hallo,

benutze auch diesen Pundit und habe keine Probleme mit dem X-Server.
Die von die angegebene Fehlermeldung ist laut google nicht kritisch. Da muss vorher schon was schief gelaufen sein. In /var/log sollte das Log vom Start des X-Servers sein. Schau da mal rein was schief gelaufen ist oder hänge es mal hier an.
Ich benutze die Closed-Source Treiber von Nvidia, funktionierte bei mir problemlos und auf Anhieb. Ich hatte allerdings nen selbstkompilierten Kernel benutzt, kann sein, dass du vorher noch die Kernel-Header installieren musst.

Ich habe grad kein Linux zum testen zur Hand, aber die acpi-wakeup.conf müsste als script ausgeführt und ausgewertet werden. Du kannst darin also auch je nach Wochentag unterschiedliche einschaltzeiten mittels einer case-Struktur festlegen. Ein `date "+%w"`gibt dir den aktuellen Wochentag zurück, den du auswerten kannst. Wenn du dann noch berücksichtigst ob es schon nach Mitternacht ist, sollte deine Lösung mit täglich wechselnden Aufwachzeiten fertig sein.

Ich glaube, was dir hilft ist die Option 'ACPI_REGULAR_TIME' bzw. DAYS in der /etc/vdr/vdr-addon-acpiwakeup.conf. Da er dann auch nicht wegen eines Timers aufwacht, geht er auch nicht wieder sofort aus. Unterschiedliche Aufwachzeiten Wochentags und am Wochenende klappen so aber nicht.

Alternativ könntest du dir einen cron-job anlegen, der Wochentags um 16:00 und am Wochenende um 9:00 per svdrpsend eine Taste an den vdr schickt. So wird Aktivität registriert und er fährt nicht gleich nach dem Timer herunter.

Tobi
Könntest du diesen Patch zum speichern der Setupwerte des remoteosd Plugins mit aufnehmen?
Link

Ok, danke. Ich hab's mal in den richtigen Thread gestellt.

Ich habe mal die neue Option zum Ersetzen des Timers und Schedules Menüeintrags durch das remoteosd Plugin ausprobiert. Diese Option funktioniert ganz wunderbar, ich kann so automatisch Timer auf dem headless Server programmieren.
Allerdings überlebt diese Funktion einen Neustart des VDR's nicht. Im Log steht dann auch 'unknown config parameter: remoteosd.ReplaceSchedule = 1', dasselbe mit Timers. Ich denke mal, die Option müsste mit kleinem 'r' in der setup.conf gespeichert werden.

Ich habe mal die neue Option zum Ersetzen des Timers und Schedules Menüeintrags durch das remoteosd Plugin ausprobiert. Diese Option funktioniert ganz wunderbar, ich kann so automatisch Timer auf dem headless Server programmieren.
Allerdings überlebt diese Funktion einen Neustart des VDR's nicht. Im Log steht dann auch 'unknown config parameter: remoteosd.ReplaceSchedule = 1', dasselbe mit Timers. Ich denke mal, die Option müsste mit kleinem 'r' in der setup.conf gespeichert werden.

Ich schick dir mal meine weiteren (Post-)Daten per PN.