NHD2 - Bug - Liste

[DboxOldie]

Ja klappt bei mir mit allen 3 Modellen ( ufs910/913 und spark7162 )
Nutze auch das .reboot Token und nur den init 0/6, die entsprechenden Dateien > umountfs, sendsigs, reboot und halt werden ja vom init dann aufgerufen.

[Grabber66]

So wie es aussieht hat DBO den Fehler gefunden.
Es lag an der "halt" im git auch halt_cuberevo.

Dort muss der schluss geändert werden :
von

Code: Alles auswählen

#halt -d -f -n -i $poweroff $hddown
if [ -e /bin/cubefpctl ]; then
	/bin/cubefpctl --poweroff
else
	/bin/fp_control -e
fi
: exit 0

nach

Code: Alles auswählen

#halt -d -f -n -i $poweroff $hddown
	/bin/fp_control -l 0 0
	/bin/fp_control -dt 1
	/bin/fp_control -e
	echo "0" > /proc/progress
	sleep 5
: exit 0

[BPanther]

Wozu das sleep? Nach fp_control -e darf es eh nicht weitergehen und die Box muß ich damit abschalten. Selbst das echo "0" > /proc/progress ist da überflüssig so gesehen.

Ist ab sofort im GIT...

[santa]

bp, du hast da nen c+p Fehler drin, das /bin/cubefpctl --poweroff ist ja nicht mehr vorhanden,
das brauch man nur in stm22 Images ohne Konfetti Treiber.

[Grabber66]

Wozu das sleep? Nach fp_control -e darf es eh nicht weitergehen und die Box muß ich damit abschalten. Selbst das echo "0" > /proc/progress ist da überflüssig so gesehen.

Ist ab sofort im GIT...

Das sleep ist drin, da sich die box zwar sonst ausschaltet, aber noch die bekannte Meldung
"INIT: no more processes left in this runlevel"
erscheint. Mal komplett mal etwas abgeschnitten, bevor die Box ausgeht.
Ist aber eher kosmetischer Natur.


Nachdem nun der Deepstanby geht, hab ich damit natürlich direkt getestet.
Aufnahmen klappen wie gewohnt, aber die Box bleibt dann an.
Ich meine das war bei NMP auch mal so. Habt Ihr das da gelöst, und wenn ja wie ?

[BPanther]

@santa: Nunja, nicht wirklich vergessen, denn es hieß ja "ersetzen gegen". Aber habe das nun zusätzlich wieder mit rein davor reingesetzt.

@Grabber66: Die Meldung ansich ist nicht so tragisch als solches, hauptsache die Box schaltet sich nun ab. Das kommt sogar beim normalen Linux vor wenn man keine GUI benutzt.
Das mit dem aktiv bleiben nach der Aufnahme und nicht wieder abschalten muß anders gelöst werden, da nichts dazu eingebaut ist, Neutrino fragt das nicht selbst ab. Das wurde damals schon bei der v1 anderweitig gelöst (mit rcS etc.).

[mohousch]

Das mit dem aktiv bleiben nach der Aufnahme und nicht wieder abschalten muß anders gelöst werden, da nichts dazu eingebaut ist, Neutrino fragt das nicht selbst ab. Das wurde damals schon bei der v1 anderweitig gelöst (mit rcS etc.).

@BP:
eingentlich funktioniert das hier nicht weil neutrino (NHD2) und fp_control sich in Quere kommen, im timermanger.cpp verwaltet da neutrino die timer aus der rtc genauso wie fp_control und hier löscht einer den andern den flag (siehe timermanager.cpp)
das ging mit den alten Treiber vom tideglo und die cubefpcontrol die mischt sich nicht in Timer Events ein wie fp_control

hab mich mit fp_control nicht so viel beschäftigt, ist es möglich dass die fp_control die timer nicht managet?

[BPanther]

fp_control liest die timerd.conf aus und setzt zumindest die Zeit zum aufwecken der Box. Aber mehr macht es nicht soweit ich weiß.

[DboxOldie]

Ne, läuft ja auch nicht ständig mit als daemon.
Ich benutze den auch um bei der spark7162 die Uhrzeit ins Display zu schreiben nach Start aus stromlos.
Dann stimmt die integrierte Uhr wenigstens.
Gibt ja auch den Parameter : fp_control -w ( wakeup reason ) nur hab ich den noch nie ausgewertet, was der sagt wenn die box per Timer aufwacht.

[Grabber66]

Hier mal die Funktionen von fp_control:

Code: Alles auswählen

cuberevo:~# fp_control -h
fp_control: SW Version 1.04
Model: cuberevo
vBoxType: 12
Selected Model: CUBEREVO frontpanel control utility
init
checkConfig
configs: DISPLAY = 1, DISPLAYCUSTOM = 1, CUSTOM =     %H:%M:%S
, WAKEUPDECREMENT  300
usage:

fp_control argument [optarg1] [optarg2]
-e   --setTimer          Args: No arguments or [time date] Format: HH:MM:SS dd-mm-YYYY
        Set the most recent timer from e2 or neutrino to the frontcontroller and standby
        Set the current frontcontroller wake-up time
-d   --shutdown          Args: [time date] Format: HH:MM:SS dd-mm-YYYY
        Mimics shutdown command. Shutdown receiver via fc at given time.
-g   --getTime           Args: No arguments
        Return current set frontcontroller time
-gs   --getTimeAndSet           Args: No arguments
        Set system time to current frontcontroller time
-gw   --getWakeupTime           Args: No arguments
        Return current wakeup time
-s   --setTime           Args: time date Format: HH:MM:SS dd-mm-YYYY
        Set the current frontcontroller time
-gt   --getTimer          Args: No arguments
        Get the current frontcontroller wake-up time
-r   --reboot            Args: time date Format: HH:MM:SS dd-mm-YYYY
        Reboot receiver via fc at given time.
-p   --sleep             Args: time date Format: HH:MM:SS dd-mm-YYYY
        Reboot receiver via fc at given time.
-t   --settext           Args: text
        Set text to frontpanel.
-l   --setLed            Args: led on
        Set a led on or off
-i   --setIcon           Args: icon on
        Set an icon on or off
-b   --setBrightness     Args: brightness
        Set display brightness
-P   --setPwrLed     Args: 0..15
        Set PowerLed brightness
-w   --getWakeupReason   Args: No arguments
        Get the wake-up reason
-L   --setLight   Args: 0/1

[BPanther]

Die Hilfeseite ist relativ, auch wenn was gelistet wird muß es nicht unbedingt funktionieren - schon öfter gehabt das Problem.

[mohousch]

fp_control liest die timerd.conf aus und setzt zumindest die Zeit zum aufwecken der Box. Aber mehr macht es nicht soweit ich weiß.

das ist aber zum groessen teil das Problem:
wenn die RTC die Box aufweckt (vorher beim timer setzen hat neutrino und danch fp_control ein 1 hier gestzt /proc/stb/fp/was_timer_wakeup) und wo die Box wacht vermutlich schreibt fp_control ein 0 hier was zu spät für neutrino ist, er überprüft diesen Proc Eintrag ist ein 1 aha die Box ist vom schlaf gewacht nach der Aufnahme ich schicke sie wieder im Schlaf aber wenn fp_control ihm den Flag weg nimmt denn ist für neutrino die Box gar nicht vom standby gekommen.

[Matze2002]

Videotext : Box ging schlafen.... 910er, rev 1393

Code: Alles auswählen

Tuxtxt: ended
CNeutrinoApp::AudioMute: current_muted 1 new 1 isEvent: 1
[audio_cs.cpp]:SetMute (1)
StartSubtitles: Show
[dvb-sub] start, stopped 1 pid 0
TuxTxt subtitle unpause, running 0 pid 0 xage 0
[neutrino] StopSubtitles
TuxTxt stopping subtitle thread ...
TuxTxt 1.95 for 32bpp framebuffer
CRCInput::loadKeymap:
[tuxtxt] using PID 0x25
font /usr/share/fonts/tuxtxt.ttf
Tuxtxt: national_subset 5 (cfg 0)
tuxtxt_start_thread: starting... tid 973
TuxTxt: source demux 0
TuxTxt service started 25
tuxtxt_CacheThread: starting... tid 5608
TuxTxt running thread...(025)
screenmode 0
[TuxTxt] Full txt Screen (2).
TuxTxt: init ok
Segmentation fault
SHUTDOWN
level: 0
INIT: Sending processes the TESending all processes the TERM signal...done.

[Grabber66]

Wollte gerade mal gestet was denn die -w option ausgibt. Dabei ist mir aufgefallen, das die systemzeit und die fp-time 2h auseinander liegen.
Und die Box zwar aus dem Deep startet (das hatte ich ha heute nacht getestet) aber zur falschen Zeit.
Danach habe ich versucht die fp_time zu ändern.

Code: Alles auswählen

cuberevo-mini2:~# fp_control -s 20:14:20 17-05-2013
fp_control: SW Version 1.04
Model: cuberevo-mini2
vBoxType: 12
Selected Model: CUBEREVO frontpanel control utility
init
checkConfig
configs: DISPLAY = 1, DISPLAYCUSTOM = 1, CUSTOM =     %H:%M:%S
, WAKEUPDECREMENT  300
getTimeFromArg
getTimeFromArg <
setTime ->
Setting current Fp Time to: 130517201420@ (mtime)
setTime <- 0
cuberevo-mini2:~# fp_control -g
fp_control: SW Version 1.04
Model: cuberevo-mini2
vBoxType: 12
Selected Model: CUBEREVO frontpanel control utility
init
checkConfig
configs: DISPLAY = 1, DISPLAYCUSTOM = 1, CUSTOM =     %H:%M:%S
, WAKEUPDECREMENT  300
getTime ->
Getting current Fp Time...
Got current Fp Time 0  (mtime)
getTime <- 0
Current Time: 18:14:30 17-05-2013
cuberevo-mini2:~# 

Aber auch danach ging es nicht anders.

[DboxOldie]

Das ist richtig mit den 2 stunden, aber die box startet trotzdem passend...