und ich benutze keine NAS.

soweit ich verstehe geht es nicht um NAS oder nicht, sondern um mounts zu/von anderen Geräte
das wäre natürlich ein Punkt, welcher seit Anfang der ganzen Thematik mWn nicht beleuchtet wurde: der Zugriff eines anderen Gerätes auif die betroffene Box

... Deshalb habe ich ja extra geschrieben, dass ich von den freezes seit VTI 13.x betroffen bin obwohl ich meine beiden Boxen standalone nutze.
Insofern haben wir hier vollkommen unterschiedliche configs.

Verstanden habe ich bisher, daß Enigma2 sauber beendet wird (daher kein crashlog) und dann erst die Box einfriert. Da meine Box standalone ist (eine Box WLAN, eine LAN) und nur interne Festplatte, kein CI slot belegt grenzt das doch schon ein wenig den Fehlerkreis ein...



Gesendet von meinem SM-G965F mit Tapatalk

also hast du keinerlei mounts auf den Boxen eingerichtet, keine Netzwerkgeräte?

...absolut korrekt, keine Netzwerkgeräte.

Eingerichtet ist eine feste IP Adresse (also KEIN DHCP).

hajeku123 schrieb:

Poste bitte noch den dazugehörigen Shutdown Log
Danke.

das wurde mal wieder überschrieben oder ist das richtig

Bei deiner shutdownlog Datei fehlt der Timestamp im Datei Namen und der Inhalt

Das sollte so ausschauen.

Unbenannt.JPG

Immer wenn ich ein Update einspiele, wie heute zum Beispiel, dann starte ich die Box ja neu.

Es kommt Reboot, please wait und dann Update please wait. Meist bleibt die Box bei Update please wait hängen.

System ist frisch aufgesetzt. Ich hänge mal die Dateien an.

Komischerweise ist es nur bei der Solo 4k so. Die Ultimo 4k und die Uno 4K Se haben das nicht.

Vielen Dank für eure Hilfe

hajeku123 schrieb:

Was mir auffällt sind folgende Zeilen, welches es bei mir nicht gibt, obwohl ich auch ein NAS habe.



Jan 21 20:50:50 vusolo4k user.warn kernel: [17618.998536] [AUD]: AUDIO_CONTINUE 1869117952 1 aph=0xcc0c6c80
Jan 21 20:50:50 vusolo4k user.warn kernel: [17618.998541] [AUD]: Mute : 0
Jan 21 21:22:48 vusolo4k daemon.notice rpc.mountd[1095]: authenticated mount request from 192.168.2.6:669 for /media/hdd/movie (/media/hdd)
Jan 21 22:09:35 vusolo4k daemon.notice rpc.mountd[1095]: authenticated mount request from 192.168.2.6:994 for /media/hdd/movie (/media/hdd)
Jan 21 22:15:03 vusolo4k daemon.notice rpc.mountd[1095]: authenticated mount request from 192.168.2.6:906 for /media/hdd/movie (/media/hdd)
Jan 21 22:16:05 vusolo4k daemon.notice rpc.mountd[1095]: authenticated mount request from 192.168.2.6:973 for /media/hdd/movie (/media/hdd)
Jan 21 22:49:19 vusolo4k user.warn kernel: [24728.264657] [VID]: VIDEO_STOP 1 1
Jan 21 22:49:19 vusolo4k user.warn kernel: [24728.264727] [AUD]: AUDIO_STOP 1869117952

• Gibt es diese Zeilen auch im Log, wenn die solo4k korrekt ausschaltet?
  
• Im Plugin shutdownlog "Ausschalten erzwingen" Ja oder Nein eingestellt?
  
• Du hast ein NAS nach /media/hdd gemountet?
  
• Als HDD Ersatz in den Freigabeoptionen ?
  
• CIFS oder NFS ?
  
• AutoFS oder Klassisch?
  

ich habe eine Zero4K die auf die HDD zugreifen darf

Es ist die IP von der Zero4K

Gesendet von meinem SM-G930F mit Tapatalk

Bei mir gibt es kein Shutdownlog, trotz zweier Freezer... (auch kein Crashlog)

mydebian schrieb:

Es ist die IP von der Zero4K

wie ist die Freigabe auf der Zero4K eingestellt: klassisch oder autofs?

@Tekram3456
ja, merkwürdig. Da kennt Python das Objekt nicht mehr beim Herunterfahren und crasht dann.
Warum das nur bei der bei der Solo 4k passiert - keine Ahnung.
Konnte ich mit meiner duo 4k bislang auch nicht reproduzieren.
Ich fange den Fehler mal ab.


@mydebian
Bei dir gibt es scheinbar unter /shutdownlog nur die messages_xxx und keine shutdownlog_xxx.
Auch komisch. Kommt Update, vielleicht sehen wir dann etwas mehr.
Der shutdownlog, welchen du gepostest hast, stammt aus /var/log und wird aktuell beim Hochfahren des Systems erstellt und später vervollständigt. Diese Datei ist für uns nicht relevant. Wir brauchen die Dateien aus Verzeichnis /shutdownlog
Ich würde vermuten, dass die Kiste beim Runter fahren einen Netzwerkzugriff hat und deshalb einfriert. Wie gesagt nur eine Vermutung und werden wir mit der nächsten Version etwas näher beleuchten.
Gibt es die Zeilen authenticated mount request from 192.168.2.6:906 for /media/hdd/movie (/media/hdd) in den anderen messages-Logs auch, wo die Kiste normal runter fährt?
"Ausschalten erzwingen" hast du deaktiviert?


@dummy1001
so ganz standalone sind deine Geräte ja nicht. Zumindest haben beide eine Netzwerkverbindung.
Mit aktivierter Option "Ausschalten erzwingen" hattest du bislang keine freezer mehr?

EDIT
@GaborDenes
Option "Ausschalten erzwingen" ist an oder aus?

Gute Frage, hab gerade gesehen, das das Plugin nicht mehr installiert war, keine Ahnung, wie das passieren konnte.
Hab gerade die 02 installiert und teste weiter.

Nachtrag:
Ich habe jetzt 02 installietr und wie folgt eingestellt:


Da morgen ein Imagebackup per Aufgabe läuft, müßte es wieder zu einem Freeze kommen, werde ich dann erst Donnerstag posten können.

@hajeku123

Ja, korrekt. Mit der Option ausschalten erzwingen hatte ich keine freezes mehr.
Sollte es Sinn machen, dass ich das ich die Funktion deaktiviere um logs zu erzeugen dann mache ich es.


Gesendet von meinem SHT-W09 mit Tapatalk

@hajeku123

möchte dir mal ein Lob und Danke ausprechen, wie du dich hier mal wieder reinhängst. Und das ohne selbst betroffen zu sein.

GaborDenes schrieb:

Bei mir gibt es kein Shutdownlog, trotz zweier Freezer... (auch kein Crashlog)

mydebian schrieb:

Es ist die IP von der Zero4K

wie ist die Freigabe auf der Zero4K eingestellt: klassisch oder autofs?

autofs

Gesendet von meinem SM-G930F mit Tapatalk

Dann wäre meine Theorie (das die Zero die Verbindung offen hält) schon wieder raus.
Ich habe auch Zugriff von meiner Ultimo4K auf die Solo4K,ebenfalls per autofs und ich hab diese Meldung nicht im Log...

Vllt ist es trotzdem den Versuch wert, die Freigabe auf der Zero mal zu deaktivieren.

Ich kann das ausschließen.
Hatte erst die Solo4k und da hatte ich schon das Problem.

Gesendet von meinem SM-G930F mit Tapatalk

Wie dummy hier schon schrieb, hat er keine(!) Netzwerkfreigaben - und trotzdem den Hänger vorm Abdrehen. Wenn's angeblich nicht im VTI sein kann und auch nicht an Netzfreigaben hängt - was bleibt dann noch über? Wobei ich das Problem mit VTI 11 nicht hatte...

Wenn's angeblich nicht im VTI sein kann

geh weg Troll und poste deine aus den tasten gesogenen Behauptungen woanders

Wenn auf Deep Standby verzichtet wird, kann sich die Box nicht beim Runterfahren aufhängen, weil sie nicht runterfährt. Das schützt zwar nicht prinzipiell, aber im Einzelfall kann es ne Lösung sein. Hauptsächlich schuld sind alle Arten von Netzwerkaktivität und Laufwerke mit eigener Energieverwaltung, die erst mehr oder weniger Zeit zum Aufwachen brauchen. So stabil wie mein alter TechniSat, an dem nur ne SD-Karte zum Aufnehmen hing, könnte die Box auch werden, wenn man sie nutzt wie nen Receiver von gestern, ganz ohne Netzwerk und besser auch HD.
Alle ein bis zwei Wochen 10s Reset oder Strom aus, damit das Ding startet, wie es bei mir zZ ist, finde ich tragbar und besser wird es wohl nie, bei den Meisten.