Box hängt mit "VU+ SOLO2" im Display

Ja, in 10 Minuten habe ich das auch noch nie geschafft. Und wenn man wirklich ein paar Plugins nutzt und keine Sicherungen widerherstellt, dann dauert das bestimmt 2 Stunden.

Vielleicht ticken die Uhren in Ungarn a bissal anders ?

Ich muss eingestehen, dass ich seit der Umstellung von EPG-Refresh in den Modus "Standby" in Kombination mit dem Serienrecorder zwar keine Abstürze mehr mit dem Hinweis "VU+ Solo² " im Display habe.

ABER jetzt schafft es der Serienrecorder auch nicht mehr nach seinem Suchlauf die Box in den Deepstandby zu fahren.

Es geht nur noch in den Standby. ;cursing:

Keine Ahnung, was hier die Ursache sein kann, zumal die Einstellungen zutreffend gesetzt sind.

Bleibt auch mit Update vom 18.6 noch hängen beim Hochfahren aus Deep Standy

bei mir auch grad wieder beim hochfahren hängengeblieben.
schade das es niemand fixt:(
mit vti 8.0.0 hatte ich nie solche Probleme.

Hi,

leider muss ich mich hier auch dazu gesellen. Habe immer wieder sporadisch das Problem, dass die Box mit Solo2 im Display nicht hochfährt, sondern hängen bleibt. Ich kann keine Regelmäßigkeit erkennen, aber es passiert zu oft um darüber hinwegzusehen, v.a. weil mir dadurch massig Aufnahmen verloren gehen (der Receiver startet für Aufnahmen aus dem Deep Stand-By und bleibt bei dem Boot dann ab und zu hängen)

Um EPG-Refresh auszuschließen habe ich es erst so konfiguriert, wie hier einige vorgeschlagen haben ==> keine Verbesserung. Danach habe ich es deaktiviert ==> keine Verbesserung. Zuletzt komplett deinstalliert ==> Keine Verbesserung.

Weiß man schon, wie es zu den sporadischen Hängern kommt? Treiber? Kernel?

EDIT: Image ist aktuell 8.2.2 mit allen Updates. Mit 8.0 war das Problem noch nicht.

EDIT2: Rückkehr zu 8.0 ist keine Option, da für VMC wohl 8.2.x Voraussetzung sein wird. Ich hoffe also auf einen Fix, oder zumindest darauf, dass jemand herausfindet, wie das Problem zustande kommt.

Hallo zusammen,

bei mir tritt das Problem auch sporadisch auf. Ich habe beim EPG-Refresh den Deep-Stand-By auch deaktiviert und schalte den Receiver nur noch in den normalen Standby.
Heute kam ein neues Phänomen dazu, von dem ich aber nicht weiß, ob es einen Zusammenhang mit den Hängern gibt:
Beim Einschalten der Box (aus dem normalen Standby) um 8:00 Uhr hat er mir angezeigt, dass eine Aufnahme gestartet und das CAM-Modul initialisert wurde (SCAM). Die Aufnahme startete aber schon um 2:00 Uhr und hätte eigentlich um 3:00 Uhr beendet sein sollen. Die Aufnahme endete aber erst als ich den Receiver gestartet habe und das CAM-Modul initialisiert wurde. Die Aufnahme war dadurch leider unbrauchbar (weil schwarzes Bild) und über 500 Minuten lang. Zudem war ein Neustart des CAM-Moduls erforderlich damit die Sky Sender wieder entschlüsselt wurden.

Dieses Problem hatte ich bis dahin noch überhaupt nicht; auch SCAM funktioniert eigentlich völlig problemlos.

Positiv möchte ich bei der neuen Version die deutlich Netzwerkgeschindigkeit loben! Aufnahmen werden jetzt mindestens doppelt so schnell per LAN von der Platte kopiert.

Viele Grüße
Bender275

ich will mal versuchen, etwas zu diesem Thema beizutragen, da ich aus eigener Erfahrung weiß, wie nervig das Problem ist.
Vor ca 14 Tagen hatte ich auf die aktuelle Oscam Version gewechselt und den Ausschalt-Timer auf 1 Minute gestellt.
Seitdem konnte ich das Problem leider (oder auch zum Glück) nicht mehr nachvollziehen.
Wenn man sich die Log-Files aus den Beiträgen ansieht, ist immer ein Bezug zu Enigma2 zu finden.
Da der Fehler nur sporadisch und dann oft auch noch beim Bootvorgang auftritt, ist eine Fehleranalyse sicherlich sehr schwierig.
Ich könnte mir vorstellen, dass ein Logfile von Enigma2 hier hilfreich sein kann, welches es im normalen Betrieb leider nicht gibt.

Wenn die Boxen hängen bleiben, sollte der Netzwerkzugriff noch funktionieren.
Hat das mal jemand in diesem Zustand probiert?

Wer möchte, kann das Log von Enigma2 aktivieren und nachsehen, an welcher Stelle der Bootvotgang im Fehlerfall abbricht.
(Benutzung natürlich auf eigene Gefahr)
Ich könnte mir vorstellen, dass über diesen Weg zumindest die Fehlerquelle eingegrenzt werden kann.

Wie ist eure Meinung?
Ich schau mal in Richtung Admins - Macht das überhaupt Sinn?

Wer sich mit dem Terminalbefehlen und einem Editor der Box auskennt, kann über folgende Änderung der Datei /usr/bin/enigma2.sh ein Logfile aktivieren.


Wer sich nicht so gut auskennt oder sich nicht an die Terminalbefehle herantraut, kann die Datei auch per Netzwerkzugriff ersetzen.


Das Logfile ist dann unter /var/log/enigma2.log zu finden.

Ach ja - erstellt Euch vorher eine Sicherheitskopie der Original Datei !!!
Am besten auch noch eine aktuelle Image Sicherung der Box.
Das kann im Fehlerfall hilfreich sein.

EDIT:
Die aktivierte Log-Datei protokolliert im Hintergrund auch nach den Bootvorgang fleißig weiter.
Die Box sollte somit regelmäßig in DS heruntergefahren werden. Damit wird die Datei auch nicht zu groß
Ebenfalls sollte das Log nach Fehleranalyse wieder deaktiviert werden.
@PAZ85 - vielen Dank für den Hinweis.

Ich würde aber empfehlen die log Datei auf den usb Stick zu lenken.

warum?
Wenn die Box mit Anzeige "Vu+ Solo2" hängen bleibt und Du in diesem Zustand gleich nach der Log-Datei schaust, ist eine Historie nicht mehr interessant.

oder sehe ich das falsch?

Warum? Ganz einfach das der interne Speicher nicht zugemüllt wird. Sonst wegen nichts.
Ich weis ja nicht wieviel Daten die vu erzeugt, aber wenn das mal ne Woche oder zwei die Daten sammelt kommt bestimmt was zusammen. Und dann tauchen hier die Threads auf: "Solo 2 kein Speicher mehr".

es kommt darauf an. wie lange die Solo durchläuft.
Mit jedem Boot (Einschalten aus DS) wird das Verzeichnis /var/log und die aktuelle Log-Datei automatisch gelöscht und neu angelegt.

EDIT:
Hinweis unter #88 eingefügt
@PAZ85 vielen Dank.

Hatte heute morgen auch wieder das leidige Problem. ;cursing: ;cursing: ;cursing: ;cursing:

EPG-Refresh hat die Box nicht aus dem Deepstandby zum Laufen gebracht.

Ist denn nun das VTI 8.2.2 Schuld oder EPG-Refresh einfach nur veraltet in seiner Version 1.1.xx??

Hallo,

war auch bei mir heute morgen das erste Mal, dass die Box mit Loading... + Bootlogo hängengeblieben ist. Es stand eine Timeraufnahme die Nacht an, die natürlich NICHT angefertigt wurde. (Frau wird stinkig sein)
Ist mir die ganzen 14 Monate mit dem 6.0.5 nicht ein einzigen Mal passiert.
Das ist sehr schade, da ich wegen des Transponderproblems bei Aufnahmen und oscam endlich mal was neues nehmen wollte, aber das kann ich dann wieder vergessen.
Werde wieder zurückrudern. Möchte nicht noch mehr Aufnahmen verlieren.
Außer autoremover, der aber 19:00 Uhr läuft, habe ich keine zusätzlichen Plugins geladen.

@maarmu
war das Log von Enigma2 beim Bootvorgang aktiv und kannst Du das mal posten?

Ich hatte das "Problem" auch. War egal, ob ich 6.0 oder 8.0 oder 8.2.2 drauf hatte. Immer aufgehangen. Habe die Box zur Reparatur gebracht. Es wurde das Mainboard getauscht. Seitdem kein einziger Hänger mehr.

Das Problem mit dem Hänger wegen Mainboard ist aber ein anderes als das hier thematisierte...

Ohne PluginMover hab ich seit dem 16.6 keinen einzigen Hänger mehr gehabt.

Mir fällt nur auf das ab und an im Mediaportal der Ton der Box weg geht und weg bleibt bis zum Neustart und die Box dann auch komische Macken nach dem Neustart hat wie z.b. keine EPG Daten.

Habe das gleiche Problem.Aber bei mir wurde Aufgenommen.Ich musste komplett ausschalten.

Ich hab das ganze mal für mich etwas angepasst, da ich morgens weder Zeit noch Lust habe mich
vor der Arbeit mit der Box zu beschäftigen.

Somit wird jeden Tag ein neues Log angelegt und das alte bleibt erhalten, außerdem wird
bei einem Restart das aktuelle auch nicht gelöscht sondern weitergeführt.

Das ganze ist aber nur mit einem Log auf dem USB-Stick zu empfehlen da doch einiges an Daten zusammen kommt.
Nach dem Startvorgang hat die Datei auch gleich mal 2 MB, und das ist je nach Flash Auslastung schon zu viel für einige hier.


Der Ordner /log muss auf dem USB Stick vorhanden sein, und ihr solltet beim Anlegen auf Groß und Kleinschreibung achten.