Beiträge von AyNoMeGusto

Zitat

Original von felge1965
...
Allerdings wollte ich meinen Servern .NET solange es geht ersparen, da das .NET-Framwork den Rechner übel zusetzt (W200-Server).

Wirklich? Wir haben 2002 nach .NET migriert und wickeln seitdem alle Projekte in NET ab (bzw. ASP.NET für Webanwendungen). Wir hatten da noch keine Probleme, auch mit relativ altertümlicher Hardware.

Zitat

Von der Reihenfolge her baue ich erst die Datenbeschaffung (epg.date-Import) , dann die Weboberfläche und dann ggf. die Schnittstellen zu SVDRP und ggf. VideoDB.

Alles klar. Ich bin erstmal damit beschäftigt meine Lib Feature-Complete zu bekommen. Zumindest einige interessante kleine Tools/Spielereien, wie eine Fernbedienung für den VDR die auf einem PocketPC läuft funktionieren aber schon.

Sven

Zitat

Original von felge1965
Da ich meinen LinVDR in einer reinen Windows-Umgebung einsetze enstand der Wunsch, die EPG-Daten unter Windows weiterzuverwenden. Das Projekt von XPIX ist eine schöne Vorlage, aber unter Windows nur schwer umzusetzen.

Mein Ziel: Die EPG-Daten der letzen 30-90 Tage und die EPG-Daten der nächsten X Tage sehr schnell durchsuchen zu können. Die Datenbank und die konvertierung der epg.data funktionieren bereits.

Gibt es hier weitere Interessenten für dieses Thema oder bin ich völlig OT?

Hi,

ich weiss nicht ob es für dich überhaupt interessant ist, aber ich arbeite an etwas ähnlichem. Und zwar bin ich gerade dabei eine Client-Library für die SVDRP-Schnittstelle als .NET class library zu implementieren.

Hierbei wird alles, inkl. EPG-Daten, Channels, Aufnahmen, Timer,... objektorientiert gekapselt sein. Endziel ist, daß die Library funktional komplett ist und sowohl auf dem .NET Framework, dem .NET Compact Framework (für WinCE) und evtl. auch auf Mono läuft.

Zur Zeit fehlt allerdings noch ein guter Teil an Funktionalität (u.a. EPG, Channels) und ich habe nicht allzu viel Zeit für private Projekte übrig. Es kann also noch ein Weilchen dauern bis das präsentabel ist.

Ist natürlich nur beschränkt relevant für dich, wenn Du ASP einsetzen willst, auch wenn man die Lib vermutlich mit einem COM Wrapper nutzen könnte.

Übrigens, wenn ich mich nicht irre habe ich hier im Forum auch mal einen Post von jemand gelesen, der sowas ähnliches angefangen hat wie du, nämlich ein Web-Interface für VDR auf Windows-Plattform, allerdings hat derjenige wiederum .NET verwendet.

Sven

Zitat

Original von kt1040
an Tobi: FORCE REBOOT war bereits drin, hat also anscheinend nicht gezogen.

Wundert mich nicht. Das Script, was Du weiter oben angehängt hast, überprüft FORCE_REBOOT garnicht. Du hast da also entweder nicht die aktuelle Version von vdr-addon-nvram-wakeup, oder Dein shutdown-hook entspricht nicht dem aktuellen Stand.

Zitat

Wäre toll, wenn trotzdem noch jemand einen Rat hätte, ganz zur Not werde ich mal versuchen in dem script (siehe oben) den Returncode vom nvram-wakeup zwangsweise auf 1 zu setzen.

Schau mal, dass du die aktuelle Version vom o.g. Paket aus Tobis Repository ziehst, dann sollte sich das Problem eigentlich von selbst erledigen.

Sven

Zitat

Original von kt1040
Hallo allerseits,

folgendes scheint passiert zu sein (Logfile siehe unten):

1. Pakt der Wölfe wurde aufgenommen
2. Ice-Age war für nächsten Nachmittag geplant, vdr-shutdown wird gemacht
3. nvram-Wakeup macht die Änderungen
4. NOAD läuft noch, deshalb wird shutdown abgebrochen
5. 5 Minuten später, nächster Versuch
6. nvram-Wakeup, will ändern, findet aber schon die entsprechenden Werte -> kein Reboot nötig (denkste) -> kein neues Aufwachen -> alle Timer seitdem nicht aufgenommen.

Alles anzeigen

Hmm, hört sich fatal nach dem Problem an, was hier:

http://www.vdrportal.de/board/thread.php?threadid=24628&sid=&hilightuser=8289

schon mal diskutiert wurde, dort allerdings noch für ctvdr 2.x. Bei der genauen Umsetzung kann ich Dir leider nicht helfen, da ich mir mit dem Umstieg auf Version 3 noch etwas Zeit lassen werde.

Sven

Zitat

was in diesem thread beschrieben wurde ist ein Problem des Kernels, der den PC "zu gut" schlafen legt.

Der Tobias hat das ja schon prima erläutert, aber nur um das noch mal 100% klar zu stellen: Das war bei mir definitiv nicht der Fall. Das Problem hatte nichts mit der Funktionsweise des Kernels bzw. der genutzten Methode für das Poweroff zu tun, sondern nur mit der Funktionsweise des Shutdown Hook.

Alles weitere ist hier ja bereits diskutiert/gelöst worden.

Sven

Zitat

Original von s_herzog
Ach so, du willst es "unelegant" haben?

Normalerweise macht man sowas immer schön nach Lehrbuch und auch richtig und so elegant wie möglich, soll doch jeder wissen, was man kann

Hehe

Naja, elegant ist halt Geschmackssache. Ich halts da gern mit dem alten Un*x Prinzip KISS (keep it simple, stupid). Da ist es für mich halt unelegant, einer Komponente die stateless ist, einen persistenten state zu verpassen, wenn man den gleichen Effekt mit einer kleinen Modifikation woanders erreicht.

Aber ich bin da pragmatisch, wenns jemand so implementiert daß es zuverlässig funktioniert beschwer ich mich bestimmt net drüber, daß mir das stilistisch nicht passt.

Sven

Zitat

Original von s_herzog
Das hat mit der Schnittstelle nix zu tun. Du könntest noch und nöcher ReturnCodes reinbauen, aber das Gundlegende ist doch:

Wie soll denn bitte NVRAM-Wakeup beim Aufruf bemerken,

"oh, ich muss nix reinschreiben, gut, dann brauch ich nix machen" oder

"oh, ich muss nix reinschreiben, oh, aber holla, ich bin bereits vor 10 Minuten gelaufen, da hab ich einen Reboot noch nötig von"

??

Alles anzeigen

<sigh> Ich denke da reden wir etwas an einander vorbei. Schau dir meine anderen Posts nochmal an: Ich bin der Ansicht, daß es so ein kompliziertes Verhalten garnicht nötig hat. Wenn nvram-wakeup aufgerufen wird um einen Timer zu setzen, so kann es dem Tool doch erst mal gleich sein, ob die korrekte Zeit bereits im NVRAM steht oder nicht. Wenn es die Board-Konfiguration diktiert, so wird halt nach _jedem_ Run bei dem die Zeit gesetzt wird ein Reboot gefordert. Wenn dann ein anderes Shutdown Hook das unterbindet ist das doch völlig wurscht, nach 5 min kommt der nächste Versuch.

Das Einzige, was die von dir zitierte Unterscheidung bringen würde, ist in bestimmten (seltenen) Fällen unnötige Reboots zu verhindern. Und zumindest mir ist es relativ egal, ob der vdr nun beim Runterfahren kurz rebootet und ob dieser Reboot zwingend nötig war.

Zitat

Das ist doch das Problem, das kannst in NVRAM nur beheben, wenn er sich den Status "muss rebooten" für sich selbst irgendwo hinsichert und es beim Systemstart wieder zurücksetzen lässt.

Eben nicht. Den Status braucht man halt nur dann wenn man auf keinen Fall einen Reboot zu viel machen will. Wenn das für dich ein KO Kriterium ist, dann wird dir diese Geschichte nicht gefallen, klar.

Hoffe das klärt meinen Ansatz etwas auf

Sven

Zitat

Original von Tobi
AyNoMeGusto:

Wenn die korrekte Zeit schon im NVRAM steht, die Kiste auch neu gebootet wurde und nvram-wakeup dann die selbe Zeit nochmal schreiben soll, woher soll es dann wissen, ob "Kein Reboot nötig" oder "Es wurde nichts geändert" zurüpckgegeben werden soll? In diesem Fall trifft ja beides zu.

Tobias

Hi Tobi,

das ist ja genau meine Rede. Die Schnittstelle ist nicht in der Lage alle möglichen Endzustände zu transportieren. Wenn man das beheben will, bohrt man entweder die Schnittstelle auf, oder macht die Verarbeitung simpler.

Bei letzterem, würde z.b. in deinem Beispiel trotz allem "Reboot nötig" signalisiert. Dann rebootet der Rechner zwar, obwohl es nicht zwingend nötig wäre, aber das tut uns ja nicht weh. Hierzu müßte man schlicht die if-Abfrage ab Zeile 831 in nvram-wakeup.c anpassen.

Da brauchen wir aber eh keine große Diskussion draus zu machen, da eine Modifikation des Scripts ja genauso funktioniert. Mir persönlich würde es halt besser gefallen den nvram-wakeup zu fixen, aber das ist halt Geschmackssache.

Sven

Zitat

Original von s_herzog
Nee, also NVRAM kann nix dazu, woher soll es beim zweiten Aufruf, wo es NIX ins NVRAM schreiben muss wissen, dass es schonmal vorher mit einem Reboot-Request geendet hatte? Dann müsste ja NVRAM den Status "need reboot" irgendwie persistent abspeichern und beim Reboot vom System löschen lassen....

Nene der braucht keinen Status, im Prinzip reicht es doch aus, wenn nvram-wakeup in seinem Verhalten konsequent wird:

Sprich, wenn die korrekte Zeit bereits im NVRAM steht, die Konfiguration aber besagt, daß das Board einen Reboot benötigt, dann darf halt nicht einfach ein exit(0) gemacht werden. Das läuft ja daraus hinauf, daß der Status 0 zwei Bedeutungen hat, die nicht voneinander zu unterscheiden sind, nämlich zum einen "Kein Reboot nötig" und zum anderen "Es wurde nichts geändert".

Da sollte man halt ansetzen und für eine Korrekte Semantik sorgen. Entweder definiert man einen zusätzlichen Zustand, oder man sorgt dafür daß nvram-wakeup nicht einfach 0 zurückgibt, wenn die Zeit bereits stimmt. Die entsprechende Änderung in nvram-wakeup würde sogar nur knapp 5 Zeilen umfassen.

Und schon braucht sich der Hook keinen Zustand mehr merken, weil der nvram selbst darauf kommt ob ein Reboot nötig ist oder nicht.

Sven

Zitat

Original von s_herzog
c) und a) verstehe ich nicht, das Problem ist ja, dass ein Reboot durchgeführt werden MUSS, was bringts, wenn NVRAM dann nur einmal läuft [beim wiederholten shutdown-Versuch muss das Skript ja rebooten, woher soll es das wissen, wenn der Hook von NVRAM nicht läuft?],

Naja, der Punkt ist doch dass nvram nur exakt einmal laufen darf, und das muss zu einem Zeitpunkt sein, wo ein Shutdown erlaubt ist und von keinem anderen Hook verhindert wird. Von daher funktionieren alle Lösungen, von a-d.

Andererseits wird die ganze Geschichte ja davon ausgelöst, daß die Semantik von nvram-wakeup broken ist, zwei unterschiedliche Endzustände werden über den gleichen Status signalisiert. Von daher wäre es IMHO sauberer da anzusetzen. (Ich sehe allerdings ein, daß es deutlich einfacher ist das Shellscript anzupassen als den nvram-wakeup).

Sven

Zitat

Original von ULF
@sven
Hubs klingt spannend kannsz du ein bischen erläutern was du gemacht hast könnte mir hier helfen:
http://www.vdrportal.de/board/thread.php?threadid=22245&sid=

Danke Ulf

Das ist im Prinzip relativ einfach. Das Script /usr/share/vdr/shutdown-hooks/S90.nvram-wakeup entscheidet anhand des returncodes von nvram-wakeup, ob ein Neustart nötig ist oder nicht. Gibt nvram-wakeup den Wert 0 zurück, so wird nicht neu gestartet. Gibt nvram-wakeup dagegen 1 zurück, so wird neu gestartet.

Ich habe dieses Script so verändert, daß in beiden Fällen (0 und 1) neu gestartet wird. Hierzu habe ich die Fallunterscheidung in Zeile 48 geändert. Der Codeblock aus meinem Posting ist ein diff dieser Änderung. Die mit "-" markierten Zeilen fallen weg, und die mit "+" markierte Zeile kommt hinzu.

Ich glaube aber nicht, daß dir das hilft, du scheinst ja bis zum reboot zu kommen. Bei mir hat sich der vdr direkt beendet, ohne überhaupt den reboot zu beginnen. Bei Dir kommt er ja zumindest bis zum reboot, wenn ich das richtig sehe?

Sven

Zitat

*HUST-HUST* kein Kommentar nötig

Zitat

Wenn NVRAM nicht bemerkt, dass es einen Reboot zwischen dem letzten Schreiben ausgelassen hat, dann sollten die drumrumgefrickelten Skripte das schon können...oder ich patche selber das Skript um, dass es IMMER rebootet...

So hab ich das vorläufig gemacht, bis klar ist wo das eigentliche Problem liegt. Kuriert zwar nur das Symptom.... aber immerhin:

--- S90.nvram-wakeup.20041105   Thu Nov  4 12:14:33 2004
+++ /usr/share/vdr/shutdown-hooks/S90.nvram-wakeup      Thu Nov  4 12:15:19 2004
@@ -46,11 +46,7 @@
 $NVRAMCMD -ls $TIMER $COMMANDLINE


 case $PIPESTATUS in
-    0) # all went ok - new date and time set
-       $LOG "nvram-wakeup: everything ok"
-       exit 0
-       ;;
-    1)         # all went ok - new date and time set.
+    0 | 1)     # all went ok - new date and time set.
        #
        # *** but we need to reboot. ***
        #

Sven

Zitat

Original von s_herzog
Servus zusammen, ich hab ein recht "stranges" Problem:

<snip>

Gibt es in "ctvdr3-Pre" (nenne ich mal so) einen Unterschid in der Behandlugdes Shutdowns, ob der VDR von selbst ausgeht, oder ob ich es manuell per Fernbedienung anstoße?

Das wäre nämlich meine einzige Erklärung für das Phänomen: Abends gucke ich fern, mach von Hand aus, die Timer werden gesetzt (braucht reboot, reboot tut), mittags bin ich net daheim und er geht von allein aus....kann man da was im syslog sehen, ob da ein reboot gemacht wurde, oder nicht?

HILFEE!!

Alles anzeigen

Ahoi,

liefer bitte mal Auszüge aus deiner /var/log/messages ab dem Zeitpunkt wenn Du:

-- manuell ausschaltest und wenn
-- der vdr automatisch runterfährt

dürfte in der Logdatei relativ einfach zu finden sein, einfach mal nach shutdown suchen.

Ich hatte ein ähnliches Problem mit nvram-wakeup nach dem Herbstupdate. Bei mir reagierte nvram-wakeup nicht korrekt, wenn der vdr nach einer Aufnahme automatisch runterfuhr.

Mein EPIA braucht einen Reboot, um die Timer im NVRAM zu aktivieren, und nach einer Aufnahme erfolgte dieser Reboot nicht, sondern der Rechner hat sich einfach ausgeschaltet.

Da half nur ein Patch des Shutdown-Hooks von nvram-wakeup.

Sven