Warum startet mein duo2 neu?

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

    • Im ersten Debug-Log wird die Box um 03:53:09 gestartet.
      Um 03:53:31 fängt der SerienRecorder an zu arbeiten.
      03:53:31.011 [e2-python] [SerienRecorder] Start: 13.12.2021 - 03:53:31

      Das sieht so aus, als wäre der SerienRecorder konfiguriert, um die Box einzuschalten und seinen Suchlauf zu machen.

    • Wann war der Receiver an?

      Wenn eine Box aus dem Deep-Standby aufgeweckt wird, wird das durch vom Frontprozessor gesteuert. Dazu muss aus irgendeiner Quelle ein Aufwach-Wecker eingestellt werden. Das können verschiedene Quellen sein, wie z.B.
      • Aufnahme-Timer
      • Aufgabensteuerung
      • Plugins
        • SerienRecorder
        • EPGrefresh
        • AEL
        • ...
      Wenn die Box dann aufgeweckt wird, "weiß" sie nicht, wer den Wecker ursprünglich mal gestellt hatte. Sie startet und fängt dann mit der Arbeit an. Darum ist auch im Debug-Log nicht direkt erkennbar, wer dafür gesorgt hat, dass die Box zu diesem Zeitpunkt aufwachen soll.

      In dem ersten Debug-Log ist nur zu erkennen, dass die Box direkt nach dem Aufwachen die SerienRecorder-Aktivitäten durchführt. Darum ist es naheliegend, dass der SerienRecorder die Box geweckt hat. Es kann aber auch jemand anders den Wecker gestellt haben...

    • So gestern ist nichts passiert, heute dagegen wieder.
      crashlogs vom enigma2 gibt es keinen, aber as hier von l4l.

      ps:wie ich oben bereits schrieb, macht mein receiver keine geplante shutdowns,
      Dateien
      duo4kse,vti15,dvb-s/c

    • In dem ersten Debug-Log ist zu sehen, das EPGrefresh ausgeführt wird.
      Das ist um 08:47:31 fertig.
      Direkt danach sieht das aus wie ein ganz normaler Shutdown in den Deep-Standby.
      Ich würde mal nachsehen, was in den EPGrefresh-Einstellungen in "Nach EPG-Aktualisierung herunterfahren" konfiguriert ist

    • Dann sollte EPGrefresh unschuldig sein.
      Im Debug-Log ist in der Regel nicht direkt zu erkennen, wer genau das Runterfahren eingeleitet hat.
      Man kann nur versuchen herauszufinden, was vor dem Runterfahren zuletzt passiert ist.

      Was mir beim Durchblättern des ersten Debug-Logs aber auffällt:
      Ab 06:10:26 gibt es immer wieder Spinner. Diese sind begleitet von häufigen Fehlermeldungen der Art
      ERROR reading PES (fd=653) - Value too large for defined data type
      Ich weiß aber nicht, wo im Image diese Fehlermeldung erzeugt wird.

      Ab 06:23 werden Timeshift-Dateien gelöscht. Warst Du da aktiv an der Box und hast umgeschaltet oder Timeshift ein- und ausgeschaltet, oder läuft da eine automatische Löschung von alten Dateien?
      Direkt nach der Timeshift-Löschung kommen wieder haufenweise Fehlermeldungen ERROR reading PES.

      Um 07:04 startet wieder ein Timeshift. Hast Du da Timeshift gestartet oder umgeschaltet mit automatischem Timeshift?

      Direkt danach gibt es immer wieder Spinner, begleitet von den Fehlermeldungen,

      Um 07:11 werden wieder Timeshift-Dateien gelöscht.
      Danach wieder Spinner und Fehlermeldungen.

      Was genau dann den Shutdown startet, kann ich nicht erkennen. Es kann gut sein, dass die Meldung vom SerienRecorder auch einfach Teil des Shutdown-Prozesse ist.

      Auffällig sind auf jeden Fall die ganzen Fehlermeldungen. Wenn der File-Descriptor fd=653 sich auf die Festplatte bezieht, könnte das auch ein Zeichen für Probleme mit der Platte sein. Ich weiß aber nicht, was hinter dem File-Descriptor 653 steckt.