RecordTimer.py

1. offizieller Beitrag

    Ein Hallo in die Runde,


    nachdem ich jetzt erfolgreich einige Änderungen an einigen Python Skripten vorgenommen habe, wollte ich das RecordTimer.py Skript modifizieren.


    Nachdem ich die geänderte Datei per FTP hochgeladen hatte, wollte die Box nicht mehr starten (nach 3/4 des Bootvorgangs) blieb sie einfach stehen.


    Auch als ich meine Änderungen wieder rückgängig gemacht hatte, konnte ich die Box nicht zum Starten überreden. Erst die Neuinstallation des Images schaffte Abhilfe.


    Jetzt interessiert mich natürlich wieso die Box nicht mehr starten konnte - wie kann ich das am besten Debuggen. Gibt es am RecordTimer Skript etwas besonderes zu beachten?


    Was hat es mit den .pyc Dateien auf sich - muss ich immer beide Dateien modifizieren?



    Vielen Dank für eure Antworten



    MacDisein

    wenn du dateien vom enigma selbst modifizierst solltest du sie immer vorher nach fehlern testen - dafür enigma stoppen und im telnet von hand staten, dann siehst do ob es fehler hat (die dann das booten verhindenr können)


    init 4
    killall -9 enigma2
    enigma2


    Weil plugins wenn sie fehler haben werden einfach igoriert und nicht zu .pyc compiliert und geladen, aber beim enigma selbst greift dieser schutz natürlich nicht.


    Und im python muss man halt genau aufpassen das man die einrückungen syntac,... etc richtig macht. Da ist es extrem streg, dafür verzeiht es wieder eine menge andere sachen, bzw sind die viel einfacher zu machen wie mit anderne Programmiersprachen :smiling_face:


    Anbei eine kleine Modifikation der RecordTimer.py um wenn man eine Aufnahme mit DeepStandby programmiert hat und noch schaut das am bildschirm vor dem schutdown noch gefragt wird ob man nicht doch weiterschauen will.


    Probier mal zur Übung das was zwischen # gutemine steht ins DMM oder ein CVS Image seiner recordTimer.py einbauen und wie oben beschrieben testen.


    PS: Und die 3 Zeilen code könnte DMM ruhig auch ins CVS aufnehmen :smiling_face:


    EDIT - die Shutdown Abfragen sind jetzt auch im CVS verfübar mit den Try* routinen, ich hab den Anhang daher hier rausgenommen, würde nur Ärger machen - danke DMM fürs einbauen !


    LG
    gutemine

    3 Mal editiert, zuletzt von Lost in Translation ()

    Hmmm, ich glaube ich sollte mich wohl doch mal ein wenig mit Python beschäftigen - wenn da auch die Einrückungen wichtig sind, dann weiß ich wahrscheinlich schon wo mein Fehler lag, ich hatte mich auch schon gewundert, dass Bedingungen keine geschweiften Klammern oder so etwas haben - aber dann läuft das in Python offenbar über das Einrücken.


    Um die Skripte zu testen muss ich also erstmal Enigma stoppen (init4 und killall) und dann kann ich die Skripte testen - wahrscheinlich mit python scriptname oder so ähnlich und wenn alles läuft dann mit enigma2 die/das/der Enigma wieder starten.


    Dann werden also bei jedem Start alle Skripte neu kompiliert, egal ob etwas geändert wurde oder nicht?



    Ich sehe auch gerade, dass es hier im Forum ja einen eigenen Developer Bereich gibt - dann ist dieses Posting hier wahrscheinlich falsch.


    Danke gutemine für deine Infos, dann probier ich noch mal ein wenig rum - mich hat nur gewundert, dass die Box selbst mit dem alten Skript nicht wieder gestartet ist.



    MacDisein

    • Offizieller Beitrag

    Also zum testen von python Skripten direkt auf der Box habe ich persönlich immer 2 Stufen.


    Stufe 1: python scriptname.py


    Damit findest du schonmal syntax-fehler.


    Wenn die erste Stufe dann darin endet, dass sich python über nen fehlenden Import beschwert weißt du schonmal, dass deine syntax i.O. ist.


    Stufe 2: E2 starten und guggen obs läuft :winking_face:


    Du bekommst ohnehin den Python-Traceback und die Ausgaben von e2 angezeigt wenn du es direkt über Konsole startest und kannst damit dann auch relativ gut debuggen.


    Ansonsten ist es für größere Dinge dann schon sehr angenehm ein funktionierendes netzwerk-root-fs zu haben auf dem man rumeditieren kann (beschleunigt den Entwicklungsvorgang doch ganz erheblich).

    Zitat

    Original von Reichi
    Ansonsten ist es für größere Dinge dann schon sehr angenehm ein funktionierendes netzwerk-root-fs zu haben auf dem man rumeditieren kann (beschleunigt den Entwicklungsvorgang doch ganz erheblich).


    Ähm, kannste davon bitte mal mehr erzählen? Da werde ich richtig hellhörig und hab von sowas noch nie gehört! Meinst aber kein OE oder?

    • Offizieller Beitrag

    Prinzipiell schon.
    Du nimmst ein OE, ziehst dir das rootfs nach erfolgreichem build raus und gibst das dem kernel in der command-line als rootfs mit. Nicht mehr, nicht weniger.
    Alles was man benötigt ist ein funktionierendes OE und eine einzige NFS-Freigabe (vorausgesetzt der Kernel im Image ist kompatibel zu den Treibern im rootfs auf dem NFS-Share).

    Ok, das kommt 'meiner' Methode schon recht nahe. Ich habe mir / als Sambashare in Windows gemountet und das als Projekt in Eclipse eingebaut. Somit hab ich auch auf alle Dateien Zugriff vom PC aus. Nur das ich halt immer neu Flashen muss, um Änderungen aus dem CVS zu bekommen.

    na ja so kompliziert arbeite ich nicht, schon weil mein PC nur in Notfällen unter Linux bootet.


    Ich hab einfach mit Ultraedit über FTP das File vom PC offen und noch eine telnet session für den enigma output.


    Und wenn ich gut drauf bin progge ich es gleich in telnet mit vi editor


    Nur ist mein Enigma auf einer 500MB CF Partition mit allen nötigen dev libs dazuinstalliert - dauert zwar 30min bis die in einem aktuellen CVS Image zusätzlich drinneb sind, aber dann ist die Dreambox fast wie ein Linux PC


    :wq


    gutemine

    2 Mal editiert, zuletzt von Lost in Translation ()

    Nachdem die Abfrage ob man wirklich rutnerfahren will wenn Aufnahme läuft jetzt im CVS drinnen ist hab ich die gepatchte RecordTimer.py rausgenommen um Ärger zu verhinden, und brauchen tut man sie auch nicht mehr.


    Nochmals Danke
    gutemine

    Wobei mir an der jetzigen Lösung (Bestätigung beim Beenden) etwas aufgefallen ist - vielleicht liegt auch ein Benutzerfehler vor, ich denke aber nicht.


    Folgende Situation:


    Gestern habe ich 24 auf RTL2 gesehen, um 23:00 Uhr wollte ich dann ins Bett (die Folge lief noch bis 23:55 Uhr) - ich habe also eine Sofortaufnahme gestartet und dann im Timer für diese Aufnahme eingestellt, dass die Box nach der Aufnahme runtergefahren werden soll. Dann habe ich die Box in den Standby geschickt.


    Als ich dann heute morgen aufgewacht bin, war die Box noch immer im Standby. Ich habe dann die Box wieder eingeschaltet und dann tauchte der Meldung auf, dass die Box heruntergefahren werden soll, obwohl noch eine Aufnahme laufen würde.


    Für mich sieht es so aus, als ob die Box jetzt nach einer Timeraufnahme nicht mehr abschalten kann. Außerdem sollte sie sich natürlich immer. ohne Meldung aus dem Standby abschalten, wenn der Timer das verlangt.


    Ich werde nachher aber noch ein paar Tests machen.



    edit: Ich habe es jetzt nochmal probiert - wenn die Box normal läuft während der Aufnahme und im Timer ist eingestellt, dass die Box heruntergefahren werden soll, dann kommt die Meldung, dass ein Timer die Box runterfahren möchte und nach 20 Sekunden wird die Box dann heruntergefahren, wenn ich den Dialog nicht mit Nein bestätige.


    Ist die Box aber während der Aufnahme im Standby, dann kommt dieser (oben genannte) Dialog erst wenn ich die Box wieder "aufwecke". Das sollte möglichst geändert werden.


    MacDisein

    Einmal editiert, zuletzt von MacDisein ()