Ich hab' s heute geschafft den Fehler auch auf Image 3.1 zu kriegen.
Ich hab's nicht lassen können 4 updates GP3/ DMM hdr skin( inaktiv) advanced movie selection und auf libpython2.6-1.0 upgedated.
Danach ging wieder kein deep stand by mehr.
Meine Vermutung es liegt an libpython.
Vielleich hilfte es euch Spezialisten das Thema einzugrenzen.
Ein zurückflashen dank Gutemines d-flash brachte wieder Abhilfe
DM 8000 Rel 3.1
ja stimmt - die libpython wurde bei der letzten Softwareaktualisierung auf meiner box auch geändert.
Das sieht irgendwie so aus, wie wenn man was mitgeloggt hat(altes Image...) - also Enigma2 in der Konsole(telnet) gestartet hat - und dann unsinnigerweise die Box über die Gui neu starten will - was dann letztendlich nur das Enigma2 in der Konsole stoppt - aber das Linux der Box nicht die Bohne interessiert.
(Ja, ich weis, daß das ein dummer Bedienerfehler ist - aber vlt hilft es was???)
Hi,
gibts denn jemanden hier, der das ganze mit einem standard image .. ohne GP3 reproduzieren kann?
Also irgendwie will es mir nach wie vor nicht in den Kopf, wieso meine Wohnzimmer 8k als auch meine anderen Boxen das Problem nicht haben.
Ich versteh das nicht.. das muss irgendeine mir bisher unbekannte Kombination von Dingen verursachen.
Oder hmm andere Idee.. kann irgendjemand mal so ein Backup irgendwo hinladen, mit dem man das nachvollziehen kann? Egal für welche Box.
Danke!
Meine 8k hat das Problem ja auch nicht 
Nur die wo ich es selbst gesehen habe hat sicher kein GP3 drauf - das war ein nacktes OoZooN 3.2.1 image wo noch PTS dazu installiert war, wobei das Timeshift mit dem enigma2 ja stopped. Und mit dem vorherigen Experimtental OoZoN hatten wir das Problem mit den selben Plugins NICHT bis das auch auf den 3.2* Stand aktualisiert wurde.
Insofern weis ich nicht ob das Image backup was bringen sollte, weil es auch an HD/CF/USB/DVD Config liegen kann - aber gut das es solche Tools gibt mit denen man ganze Images sichern kann
LG
gutemine
Ich hatte das Problem an meiner 8000er auch, beim Online-Update von 3.2.0 auf 3.2.1. DM experimental Image, Plugins ein paar aus dem Erweiterungsmenü heruntergeladen (merlin EPG, Schnitteditor etc.) und PTS händisch installiert war drauf. Beim Neustart stehen geblieben, OLED aus, Festplatte lief noch. Müsste ich glatt mal probieren ob sie das immer noch macht...hab sie seit dem Update nicht mehr heruntergefahren.
Na ja eine box wo man das Problem 'besichtigen' kann wäre sicher hlfreich.
LG
gutemine
ich bin schon dran 
Das Problem nach/mit den Update ist bei mir auch auf ein mal da, der box bleibt beim reboot stehen!
Keine "extra" dazu gekommen, benutze eine freundliche Nemesis
--vor der Umstieg auf Enigma 3.xx noch nie das kleinste Problem gehabt!
Patchen hin, Patchen er, workaround, wäre dann genau so wenig "innovativ";
denken Sie an unserem CrossEPG, Gutemine!
dm800se
Hdd Seagate -pendrive - ( ist nicht zu viel ):-)
gekauft im November 2010
LG
blu8
Falls Ihr nicht schneller seit, werde ich am Wochenend auch mal mir nur original DMM 3.2.1 ohne GP3 das Thema versuchen nachzustellen und an Ghost zu senden.
Ich darf leider nicht früher. Meine Frau will unter der Woche keine Zahnräder mehr sehen. 
Gruß
Newdreamie
Hi,
also hmm ich war gerade bei jemandem remote auf der Box.
Und hmm da hatte ich auch komische Phänomene... und ich hab es zurückverfolgt.
Die Ursache dort ist, dass irgendjemand in der enigma2.sh an einer total ungünstigen stelle ein script aufruft.. nämlich sowas:
if [ -x /usr/script/myscripts/swap_script.sh ]; then /usr/script/myscripts/swap_script.sh start 512 /media/cf; fi
Und dieser Aufruf an dieser Stelle macht da die enigma2 return codes kaputt, die weiter unten geprüft werden sollen.
Das ist halt total falsch so...
#!/bin/sh
prefix=/usr
exec_prefix=/usr
datarootdir=${prefix}/share
if [ -x /usr/bin/showiframe -a -f /usr/share/backdrop.mvi ]; then
/usr/bin/showiframe /usr/share/backdrop.mvi
fi
# hook to execute scripts always before enigma2 start
if [ -x /usr/bin/enigma2_pre_start.sh ]; then
/usr/bin/enigma2_pre_start.sh
fi
if [ -d /home/root ]; then
cd /home/root
fi
LIBS="$LIBS /usr/lib/libopen.so.0.0.0"
#check for dreambox specific passthrough helper lib
if [ -e /usr/lib/libpassthrough.so ]; then
LIBS="$LIBS /usr/lib/libpassthrough.so"
fi
# HIER KÖNNTE MAN SCRIPTE AUSFÜHREN
PAGECACHE_FLUSH_INTERVAL=$((512*1024)) LD_PRELOAD=$LIBS /usr/bin/enigma2
# ABER NICHT HIER.... DAS IST TOTAL FALSCH UND ZERSTÖRT GGF. DEN ENIGMA2 RETURN CODE DER WEITER UNTEN GEPRÜFT WIRD!!!!!!
# enable swap
if [ -x /usr/script/myscripts/swap_script.sh ]; then /usr/script/myscripts/swap_script.sh start 512 /media/cf; fi
# enigma2 exit codes:
#
# 0 - restart enigma
# 1 - halt
# 2 - reboot
#
# >128 signal
ret=$?
# HIER WÄRE ZUR NOT AUCH NOCH OKAY... WEIL DER RETURN CODE SCHON IN DER VARIABLE ret GESPEICHERT WURDE
case $ret in
1)
/sbin/halt
;;
2)
/sbin/reboot
;;
4)
/sbin/rmmod lcd
/usr/sbin/fpupgrade --upgrade 2>&1 | tee /home/root/fpupgrade.log
sleep 1;
/sbin/rmmod fp
/sbin/modprobe fp
/sbin/reboot
;;
*)
;;
esac
# ODER ABER HIER ...Das zeigt mal wieder wunderbar wie einfach man alles kaputt machen kann
Nunja.. hat mich dann doch einiges an Zeit gekostet.
Sollte jemand anders hier mit einer unveränderten enigma2.sh trotzdem Probleme haben. Dann bitte melden und mir remote Zugang zur Box verschaffen.
Dann schau ich mir das gerne an.
cya
Woran kann man erkennen ob die Datei verändert wurde? Dann sehe ich mal nach...
Woran kann man erkennen ob die Datei verändert wurde? Dann sehe ich mal nach...
Wenn Du eine jungfräuliche Installation hast, kannst Du von dort die Datei /usr/bin/enigma2.sh auf die Box kopieren, auf der Du die Datei vergleichen willst (z.B. nach /tmp). Dann kannst Du mit diff -q /usr/bin/enigma2.sh /tmp/enigma2.sh prüfen ob es Unterschiede gibt.
Danke Ghost, in meinem Fall ist das Problem leider noch nicht behoben.
Das Problem kommt mit einer Softwareaktualisierung auf die Kiste. Es scheint dass nach dem update "Neustart" und "Deepstandby" nicht mehr funktionieren. Die /usr/bin/enigma2.sh blieb beim Update unverändert.
Hi,
tomde: also wenn Du irgendwie einen remote zugang einrichten kannst..also auf die box.. per telnet oder ssh. Dann schau ich mir das gerne trotzdem mal an. Mich interessiert das ja auch.
Am besten halt im freenode net im enigma2 vorbeischauen.
Dann können wir das mal durchgehen.
Also Systematisch findet man die Probleme eigentlich relativ schnell..
cu
danke für das Angebot: versuche PN an Dich... ("Sie haben keine Verbindung zu diesem Benutzer.")
Grrr - jetzt habe ich mich so unbeliebt gemacht das ich immer geschimpft habe man soll in die enigma2.sh keine scripte reinpatchen und dann machen sie es schon wieder - aber auf mich hört ja keiner.
Allerdings hat die box wo ich das problem gesehen habe KEINE gepatchte enigma2.sh und kein GP3 drauf - das hätte ich beim -n -f Workaround reineditieren gemerkt, die war noch das originale enigma2.sh von OoZooN drinnen - und der hört auf mich was das angeht und lässt die Finger davon
Es kann also durchaus sein das wir hier nicht ein Problem sondern mehrere haben - was das Leben dann noch komplizierter macht :-/
LG
gutemine
Nur zur info: ich hab das Problem auch schon mehrfach gehabt, ich hab eine DM8000 (glaube 1. version mit dem USB nach SATA adapter fürs dvd laufwerk).
In meiner eingma2.sh siehts gut aus soweit ich das erkennen kann...
Ach ja und kein gp3:-)
#!/bin/sh
prefix=/usr
exec_prefix=/usr
datarootdir=${prefix}/share
if [ -x /usr/bin/showiframe -a -f /usr/share/backdrop.mvi ]; then
/usr/bin/showiframe /usr/share/backdrop.mvi
fi
# hook to execute scripts always before enigma2 start
if [ -x /usr/bin/enigma2_pre_start.sh ]; then
/usr/bin/enigma2_pre_start.sh
fi
if [ -d /home/root ]; then
cd /home/root
fi
LIBS="$LIBS /usr/lib/libopen.so.0.0.0"
#check for dreambox specific passthrough helper lib
if [ -e /usr/lib/libpassthrough.so ]; then
LIBS="$LIBS /usr/lib/libpassthrough.so"
fi
PAGECACHE_FLUSH_INTERVAL=$((512*1024)) LD_PRELOAD=$LIBS /usr/bin/enigma2
# enigma2 exit codes:
#
# 0 - restart enigma
# 1 - halt
# 2 - reboot
#
# >128 signal
ret=$?
case $ret in
1)
/sbin/halt
;;
2)
/sbin/reboot
;;
4)
/sbin/rmmod lcd
/usr/sbin/fpupgrade --upgrade 2>&1 | tee /home/root/fpupgrade.log
sleep 1;
/sbin/rmmod fp
/sbin/modprobe fp
/sbin/reboot
;;
*)
;;
esacHabe heute Abend nachgesehen, meine Box fährt wieder sauber herunter. Es kam also nur einmal zwischen 3.2.0 und 3.2.1 vor...
Vlt sollte mal jemand mit diesem Problem vom Start der Box bis zum Ende mitloggen (seriell - so wie bei einem bootlog meine ich) - alles andere ist anscheinend doch nur rätselraten...
Wenn ich mal jemanden grob zitieren darf...
Das Nullmodemkabel sei mit euch