Okay, danke.
Das war mir nicht bewusst.

GaborDenes schrieb:

Vllt versucht ja mal jemand, der das Problem regelmäßig hat, ob sich das verifizieren läßt?

Das mit dem 'regelmäßig' ist ja das Problem: ich hab' die Solo4k vor ca. einem Monat auf VTI 14.x upgedatet - seither ist mir 3x aufgefallen, dass sie nicht komplett runter gefahren ist. Meistens funzt es ja - mir ist nur noch nix aufgefallen, was Ursache sein könnte.

Eventuell, wenn von einer anderen Box noch eine Freigabe zur Solo4k aktiv ist? Ich kann's z.Z. leider nicht testen, weil auf Urlaub.

Und die Solo4k in der FeWo bleibt vorläufig auf 11.0.2, weil da alles, was ich brauch', astrein funzt. Außerdem gibt's da das Problem sie ins Netz zu hängen, weil ich über einen Anmeldebildschirm des Providers mit Passworteingabe drüber müsste ... aber das ist ein anderes Problem.

LG

Mit regelmäßig meine ich Fälle, die nicht nur sehr sporadisch auftreten wie bei mir (weniger als 1x im Monat)
Die aktive freigabe würde ich als Fehlerquelle ausschließen, denn dann müßte es ja immer passieren, oder zumindest häufiger.

Wie ich schon mehrfach schrieb, hängt es bei mir von der Aufgabe "ImageBackup" ab. Nur wenn diese aktiv ist(also ein backup ausgeführt wurde), hängt meine Solo4K dann, wenn ich sie wieder einschalten will.

Das mit der Freigabe würde ich ausschließen. Ich habe drei Freigaben auf meiner UNO 4K zur SOLO 4K eingerichtet, die (siehe Profil) bei mir als "Sklavengerät" ohne Festplatte läuft. Fahre ich die SOLO runter, passiert das auch bei laufender UNO ohne Probleme, diese friert dann halt ein.

Ich habe keine Freigabe und sonst außer fritzcall keine Plugins installiert. Bei Neuinstallationen nutze ich keine Backups. Es hängt nur eine usb 2,5 Platte dran. Somit kann man mal das ein oder andere ausschließen.

Nur zur Info wegen dem Experiment mit der uno 4K se.
Ich habe die Box seit 2 Wochen. Rund 50 Aufnahmen gemacht und die Box fährt weiterhin richtig runter. Nur fritzcall installiert wie auf der solo 4K auch und sonst exakt gleich eingestellt.

Meinem Gefühl heraus werdet ihr das Problem nicht eingrenzen oder gar selbst beheben können.

Viele werden das Problem ignorieren oder lesen hier mit und warten. Andere lassen die Box durchlaufen und sind somit nicht mit diesem Problem behaftet. Sonst könnte ich mir vorstellen dass sich noch einige andere Anwender melden würden.

Hallo zusammen,
nachdem ich wie hier von Bastelbogen beschrieben das "Autotimer aufrufen" deaktiviert hatte lief meine Box einen! Tag fehlerfrei um dann heute Morgen, zu einer sehr ungewöhnlichen Zeit, in einen sehr außergewöhnlichen Freezer zu verfallen.

Laut Log ist die Box 04:51 Uhr aufgewacht um einen Aufnahme zu tätigen, was sie auch gemacht hat wie ich an den blinkenden Uhr am Display selbst sehen konnte. Doch anstatt danach dann wieder einzuschlafen, steht sie nun mit eingefrorenem Display bei 05:34 Uhr unbedienbar über die Fernbedienung und wartet bis ich sie per 15 sec Power wieder wecken kann.

Ich weiß schon dass diese Verhalten nicht genau unser Problem darstellt (oder doch) hänge aber mal den Log an den es nun anscheinend gibt.

Grüße Guy

Ich bin beileibe kein Spezialist fürs Auswerten von Logs, aber das hier
"05:35:00.071 [e2-python] [#----] VTiCore [DataBase] connecting failed --> THREAD error! another thread is using the database"
fällt mir sofort auf
und passt auch zeitlich recht gut zu deiner Beschreibung...
Ich würde demnach in Richtung Database suchen, bzw. die DB abschalten und löschen.

Über Aufnahmen/Menü/Datenbank löschen und initialisieren?

Gesendet von meinem Pixel 2 mit Tapatalk

Hallo zuammen,
das Löschen der DB hat funktioniert, danke dafür, und die Box ist heute Morgen nicht an dem selben Fehler wie gestern eingefroren.
Stattdessen wieder in den selben leidigen Zustand wie "immer". Das deaktivieren des Autotimer aufrufen hat dann anscheinend nicht gebracht. Anbei der Log.
Als nächstes versuche ich das Autotimer Autopol auszuschalten... Wir werden sehen...

Bei dir ist es echt krass
Da hätte ich auch kein Bock mehr

Gesendet von meinem SM-G930F mit Tapatalk

Ach ja, man gewöhnt sich an vieles...

Gesendet von meinem Pixel 2 mit Tapatalk

Ich habe das Problem auch regelmäßig und außer dem Serienrecorder und Oscam keine weiteren Plugins installiert.

Interne HDD, keine Freigaben oder sonstige Geräte über USB.

keine weiteren Plugins installiert

bitte teile mit, wie du den Serienrecorder ohne EPG-Aktualisierung betreibst - ist evtl eine Alternative für andere user

@Guy Incognito
Mich würde interessieren, ob der Prozess von Enigma2 beim Herunterfahren offen bleibt oder geschlossen wird.
Installiere mal beiliegendes Plugin. Fährt die Box runter und schaltet nicht aus, sollte nach einem Timeout von 2 Minuten das Systemlog, die Prozessliste und der Mount Status unter /shutdownlog (Verzeichnis wird im Flash automatisch erstellt) protokolliert werden. Vielleicht kann man im System Log etwas sehen.

Beim nächsten Hängenbleiben bitte VTI Debug Log und Shutdown Log posten.






Nebeneffekt von dem Plugin:

Die Box sollte trotz Fehler korrekt ausgeschaltet werden.

Ach ja...
Wer testen möchte, ob das Plugin seine Arbeit im Hintergrund verrichtet, meldet sich mit Telnet oder Putty an.
Dann eingeben: init 4 und Box in diesem Zustand stehen lassen.

Nach default 2 Minuten wird eine Log Datei erstellt und die Box schaltet sich selbst aus.

hajeku123: Hervorragend,das ist doch mal ein Ansatz. Vielen Dank dafür! Das wird gleich mit meinen Default Settings heute Nacht getestet, perfekt!

Die Installation und der Test haben schon mal funktioniert das heißt es sollte Morgen auch was zum auswerten geben.

ich werde es auch testen

Ich häng mich mal mit dran...

Hallo zusammen,
die Box istz heute Morgen nach manuellem ausschalten , übers Ausschaltmenü, nicht sauber runtergefahren.
Log anbei.

@hajeku123: Leier hat dein Plugin nicht funktioniert wie gedacht. Es existiert trotz Fehler kein Log im entsprechenden Ordner. Habe ich etwas falsch gemacht?

Und gerade als ich den oberen Post geschrieben habe und die Box manuell weider ausschalten wollte, das exakt selbe fehlerbehaftete Verhalten.

Heute Nacht hat sich die Box nach einem DateBase Fehler aufgehangen, vergleichbar wie vergangenen Freitag hier. Um das zukünftig zu vermeiden habe ich die vtidb.db heute Morgen auf /hdd1, also die externe SSD, gelegt.
Hat dieser Schritt das Problem verschärft? Ist das vielleicht auch ein Hinweis auf das ursprüngliche Problem denn die epg.db liegt da ja auch...

Testhalber werde ich das jetzt mal ändern und alles in den Flasch nach/etc/enigma2 packen. Wir werden sehen...

Guy

... Bei mir ändert sich auch nichts, regelmäßig friert die Box ein beim runter fahren in Deep Standby.

Ich benutze EPG Share in Verbindung mit FluidNext seit VTI 12.x Installation. Bei mir werden immer alle Updates durchgeführt (VTI, EPG Share, FluidNext, SerienRecorder und EMC installiert).

EPG Share schaltet immer wieder die SQL Datenbank ein (welche als möglicher Verursacher des Problems in Verdacht steht) . Per Einstellungen deaktiviere ich also SQL Datenbank und mache dann einen Neustart. Bei dem Neustart wird dann die SQL Datenbank wieder aktiv (bei meiner Kombination).

Meine Frage:
Haben diejenigen, die hier von dem Problem mit dem einfrieren betroffen sind, eine ähnliche Kombination (also EPG share und FluidNext) in Einsatz?


Gesendet von meinem SHT-W09 mit Tapatalk