19 replies to this topic

[Pedro_Newbie]

Ik heb gemerkt dat sinds een dag of wat de Solo2 na een online update herstart, zoals bedoelt, maar daarna meteen in de standby modus gaat.

De eerste keer dacht ik dat ik per ongeluk op standby had gedrukt maar net is het voor de 3e maal voor gekomen na de online update

 

Dus Update -> herstart -> Openpli4 logo -> raders -> standby

 

 

Is dit een algemeen, dus bij anderen ook voorkomend, probleem of moet ik het lokaal zoeken?

[dirocca]

Ik heb gemerkt dat sinds een dag of wat de Solo2 na een online update herstart, zoals bedoelt, maar daarna meteen in de standby modus gaat.

De eerste keer dacht ik dat ik per ongeluk op standby had gedrukt maar net is het voor de 3e maal voor gekomen na de online update

 

Dus Update -> herstart -> Openpli4 logo -> raders -> standby

 

 

Is dit een algemeen, dus bij anderen ook voorkomend, probleem of moet ik het lokaal zoeken?

idem bij de duo2

 

grtz Philip

[littlesat]

Dan ben ik bang dat de VU zegt tegen enigma2 dat een normale bootup een wasTimerbootup was... want dan gaat de box met de laatste aanpassingen inderdaad in standby... Sjips.

Edited by littlesat, 7 September 2013 - 17:43.

[littlesat]

Als het goed is heb ik net een fix gecommit hiervoor.... het heeft wel een nadeel want de box kan nog steeds in standby gaan als spoedig een recording start.

Misschien dat iemand aan VU kan melden dat de FPWasTimerWakeup niet perfect is bij de VU....

[Pedro_Newbie]

ZIt dit in de drivers of is dit iets in Openpli of...

[Pedro_Newbie]

Gelijktijdig gepost zie ik. Kan je aangeven wat er precies gemeld moet worden want de melding: "FPWasTimerWakeup is not perfect" komt niet aan ben ik bang (als er überhaupt al wat aankomt daar, een antwoord komt er niet in ieder geval)

[littlesat]

Ik heb het moeten reverten omdat op dat moment de tijd nog niet bekend is...

 

Inderdaad is er iets in de drivers was dat niet goed doet...

[littlesat]

Staat er op de vu een file /proc/stb/fp/was_timer_wakeup

wat zie je als je daar een cat op doet?

Als die na een boot altijd 1 is dan wordt het lastig....

 

Die hoort 1 te zijn als de box "wakker" wordt door de timer van de front processor...

Door enigma2 wordt hij direct altijd 0 gemaakt na het uitlezen omdat dit een eenmalige check is.... Dus het is lastig de status te onderzoeken. Daarvoor zal je ff moeten regelen dat in  Tools.StbHardware in regel  65 een hekje komt zodat deze waarde ff niet wordt overschreven.

 

Ik krijg het vermoeden dat dit ding bij de VU altijd op 1 staat of zo iets.

 

in ieder geval bij de call in Navigation.py moet daar True uitkomen... anders wordt de box ook niet in standby gezet....

 

Bij de ET9K gaat dit prima....

Edited by littlesat, 7 September 2013 - 19:48.

[Pedro_Newbie]

Daar staat 0 in

[Pedro_Newbie]

Heb je iets aan de message log van direct na de update?

 

Ik sluit hem bij, wat er betrekking op zou kunnen hebben voor zover ik kan gokken is misschien (regels 286-287):

Sep  7 17:04:09 vusolo2 user.warn kernel: system_time_set wakeup mode get

Sep  7 17:04:09 vusolo2 user.warn kernel: system_time_set wakeup mode get 0xc3

 

Attached Files

•  messages.txt   31.92KB   2 downloads

[pieterg]

Daar staat 0 in

moet je wel opstarten met runlevel 4 als default runlevel (bijvoorbeeld).
Want zodra e2 start, zet hij de waarde op nul.

[Pedro_Newbie]

Ik ben je al kwijt

 

Ik zal morgen eens een oude image terug zetten en de oude drivers op hold zetten en dan eens updaten, kijken of het euvel zich dan ook voordoet. En daarna hetzelfde maar dan met de nieuwe drivers er in.

Ik kom er morgen nog op terug.

[littlesat]

Als hij 1 is maakt enigma2 hem meteen 0 voor de volgende keer als enigma2 op een of andere manier herstart moet worden..

je kunt ook ff een hekje in regel 65 van Tools.StbHardware.py zetten, dan wordt hij niet meer 0 gemaakt door enigma 2...(bekijk de code maar daar, daar moet je wel uitkomen)... en dan opnieuw controleren. Dan wordt hij niet meer door enigma2 op 0 gezet...

Edited by littlesat, 7 September 2013 - 20:29.

[Pedro_Newbie]

Ik ga het morgen even proberen, thanks

[littlesat]

Ik laat het nu voorlopig ff met rust... want als deze het verkeerde aangeeft... dan is het simpelweg niet te fixen

Voorheen had je er dan geen last van... omdat de box niet in standby opstarte als je de box wakker werd voor een timer... de shutdown after procedure werdt voorheen na 30 seconde gestart als er een timer zou starten binnen 6 minuten (of al gestart was). Dus boeide het eigenlijk niet zoveel wat deze flag was.

 

Ik vermoed (pure speculatie) dat deze flag 1 is als de box wakker is en er nog een timer op de fontprocessor draait... terwijl hij eigenlijk alleen 1 hoort te zijn als hij daadwerkelijk door zo'n ding wakker gemaakt is.

 

Het enige wat ik er aan kan doen is een work-a-round maken door de box pas in standby te zetten als de tijd bekend is... dan kan ik daar die binnen 6 minuten een recording test weer invoeren...

 

Maar liever uiteraard dat VU dat vlaggetje goed zet zoals het bedoeld is... dat houd het ook lekker zuiver in de code. Want een work-a-round moet eigenlijk niet nodig zijn.

Edited by littlesat, 7 September 2013 - 20:55.

[Pedro_Newbie]

Het wordt er niet duidelijker op:
Ook een normale herstart leverde een herstart naar standby op.
Back-ups terug gezet laatste goede was van 5/9 (Enigma2 1/9 - last update 3/9)
De back-up van 6/9 (enigma2 van 4/9 last update 5/9) bevat de fout, ook een simpele herstart van de ontvanger resulteerde in een herstart naar standby.
Dus de laatst goede back-up van 5/9 weer terug gezet en toen geprobeerd te updaten naar de stand van vandaag. Dit resulteerde in een green screen loop.
Toen de back-up van vanmorgen vroeg weer terug gezet en zie daar, de restore procedure start de Solo2 opnieuw op maar ging niet in standby. Toen de image weer geupdate en ook deze ging weer normaal herstarten.
Ook de normale herstart verloopt weer goed.
 
Er zal wel een vuiltje ergens zijn ingeslopen maar het vreemde is dat in de back-up van vanmorgen deze fout ook zou moeten zitten maar deze doet zich niet meer voor.
rara hoe kan dit?

Voorlopig maar even aankijken maar het lijkt erop dat het probleem zich nu niet meer voordoet.
 
Logje greenscreen

Activating language Nederlands
cannot open /proc/stb/avs/0/input_choices
--> setting scaler_sharpness to: 00000000
couldn't open /proc/stb/misc/12V_output
[ePopen] command: ip -o addr show dev eth0
setLCDBrightness 0
setLCDBrightness 255
FIXME: request for unknown slot
FIXME: request for unknown slot
FIXME: request for unknown slot
Plugin  Extensions/WebInterface failed to load: No module named plugin
Plugin probably removed, but not cleanly in /usr/lib/enigma2/python/Plugins/Extensions/WebInterface
[Ipkg] Added to OPKG destinations: /media/hdd
[NetworkBrowser] fallback to default translation for Mount again
[NetworkBrowser] fallback to default translation for Attempt to mount shares again
getModeList for port DVI-PC
remove DVI-PC because of not existing modes
getModeList for port YPbPr
getModeList for port Scart
getModeList for port DVI
hotplug on dvi
-> setting aspect, policy, policy2, wss 16:9 panscan letterbox auto
-> setting aspect, policy, policy2, wss 16:9 panscan letterbox auto
-> setting aspect, policy, policy2, wss 16:9 panscan letterbox auto
-> setting aspect, policy, policy2, wss 16:9 panscan letterbox auto
setMode - port: DVI mode: 1080p rate: multi
-> setting aspect, policy, policy2, wss 16:9 panscan letterbox auto
starting hotplug handler
EXCEPTION IN PYTHON STARTUP CODE:
------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/enigma2/python/mytest.py", line 594, in <module>
    runScreenTest()
  File "/usr/lib/enigma2/python/mytest.py", line 441, in runScreenTest
    nav = Navigation(config.misc.isNextRecordTimerAfterEventActionAuto.value)
TypeError: __init__() takes exactly 1 argument (2 given)
------------------------------------------------------------
(exit code 5)
]]>
        </enigma2crashlog>
    </crashlogs>
</openpli>

Edited by Pedro_Newbie, 8 September 2013 - 08:28.

[Pedro_Newbie]

Helaas ook vandaag, zowel voor de update als na de update, levert een herstart een herstart naar stand-by op. Het verschil is alleen dat het geen "echte" stand-by stand is. Het display wordt niet gedimd zoals dat bij een echte stand-by wel het geval is.

[littlesat]

Vanaf vandaag hoort hij niet meer in standby te komen. Maar blijkbaar is het image niet gebouwd.

Edited by littlesat, 9 September 2013 - 07:00.

[Pedro_Newbie]

Net weer geupdate/grade en nu herstart ie weer in normale modus, thanks!

[littlesat]

Blijft natuurlijk wel zo dat er een ongemakje in de drivers zit....