Box schaltet sich ohne Timer ein

[Bernie-vs]

Hallo freunde,

meine Box schaltet sich jeden Morgen um 10:25 Uhr aus dem Deepstandby ein, ohne dass ees einen Timereintrag gibt.

ich habe das seit einigen Monaten, es war mir aber nicht so wichtig, deshalb erst jetzt.
Gibt es irgendeine Einstellung, die ich aus Versehen (Fingertrouble) aktiviert habe und die die Box auch ohne Timer-Aufnahmen einschaltet?

Merkwürdig: Ich habe das Problem nie in den ersten Tagen nach einem Update, erst nach ca 1-2 Wochen. Bei der Vorgängerversion war es immer um 10:10 Uhr, jetzt ist es wie gesagt um 10:25 Uhr.

Danke für Eure Hilfe
Gruß

[santa]

Epg refresh oder sonstige plugins installiert?
Mal ohne settingsübernahme installiert?

[Andreas41]

Das gleiche Problem habe ich hier auf meinem AV7000 auch.

[flac]

Wenn schon die Zeiten bekannt sind, dann lasst doch mal ein Log mitlaufen.
Man muss ja nicht stundenlang loggen. Es reicht das Terminal eine halbe Stunde vorher zu öffnen.

So könnte man eventuell erkennen, warum die Box geweckt wird.



Gruß

Chris

...bei einem seriellen Log sollte die Box mit dem PC etc. aber schon vorher verkabelt sein.

[Bernie-vs]

Epg refresh oder sonstige plugins installiert?
Mal ohne settingsübernahme installiert?

Plugins: Default Service Scanner, DiSeq Tester, HDMU Media Center, Open Webif, Plugload, Softwareverwaltung, Automtic Volume Adjustment, Oscam

Mal ohne Settingsübernahme probieren ist etwas schwierig zu testen, da der Fehler immer erst 1-2 Wochen nach dem HDMU Update auftritt.

Trotzdem erstmal Danke für die Tipps, ich wollte auch sicher gehen, dass es kein bekannter Fehler ist. Beim nächsten Schlechtwettereinbruch installiere ich mal die neueste HDMU und warte mal ab, ob das wieder nach einiger Zeit passiert
Gruß

[Bernie-vs]

Wenn schon die Zeiten bekannt sind, dann lasst doch mal ein Log mitlaufen.
Man muss ja nicht stundenlang loggen. Es reicht das Terminal eine halbe Stunde vorher zu öffnen.

So könnte man eventuell erkennen, warum die Box geweckt wird.



Gruß

Chris

...bei einem seriellen Log sollte die Box mit dem PC etc. aber schon vorher verkabelt sein.

Hallo Chris,

sorry für die dusselige Anfängerfrage: Wie mache ich ein Log?
Natürlich ist meine Box am netz und ich kann mich ohne Probleme über Terminal auf der Box einloggen, mir fehlt halt das Wissen, wie ich logge, wo die logfiles stehen (würde mal vermuten unter /var/log ). Dann noch das Problem: Die Box ist im DeepStandby, also über Netz nicht erreichbar. Da fällt es mir schwer, mich einzuloggen...
Da das Problem ja zeitlich eingegrenz ist, könnte ich doch einfach vor dem Ausschalten in Deepstandby das Loggen einschalten, ist doch wohl egal, wie groß der Logfile wird, oder?
Wenn dieser Logfile als Text vorliegt mit Zeitstempel, könnte man das Problem mal eingrenzen.
Bin auch froh, dass ich nicht der einzige bin, der das Problem hat - ich habe Euch Gurus schon oft genug unnötigerweise mit meinem Anfänger-Mist belästigt. Eure Geduld ist bewundernswert.

Also, gib mit kurz die Info, wie ich logge (oder eine Link), dann gehe ich das mal an.
Gruß
Bernie

Gruß
Bernhard

[flac]

Oh Oh ... ich sach nichts mehr.

Leider muss man jeden 2. darauf hinweisen, dass das alles in der FAQ beschrieben ist.
Die sollte JEDER mal gelesen haben.


... da es zu warm ist, bin ich mal nicht so.:D



>>Klick<< (http://www.hdmedia-universe.com/board/showthread.php?3439-Loggen-leicht-gemacht)




Gruß

Chris


...entweder das Log File hier Anhängen oder die Ausgabe in einer Codebox posten.

[Bernie-vs]

Oh Oh ... ich sach nichts mehr.

Leider muss man jeden 2. darauf hinweisen, dass das alles in der FAQ beschrieben ist.
Die sollte JEDER mal gelesen haben.


... da es zu warm ist, bin ich mal nicht so.:D



>>Klick<< (http://www.hdmedia-universe.com/board/showthread.php?3439-Loggen-leicht-gemacht)




Gruß

Chris


...entweder das Log File hier Anhängen oder die Ausgabe in einer Codebox posten.

Danke Dir für Deine unendliche Geduld mit Laienspielern. Bin gerade dabei, mich durchzufummeln durch die diversen Threads.
Morly´s Admin Tool und Startscript habe ich ja schon mal gefunden, nur läuft das leider nicht unter Yosemite (Mac 10.10.4). Jetzt probier ich mal, mit Wine Emulation die Windoof Version zum laufen zu bringen.
Ach ja, mein letztes serielles Kabel habe ich vor ca 25 Jahre weggeschmissen - mit sowas gebe ich mich nicht mehr ab...
Gruß
Bernhard

[flac]

Bitte Probleme mit dem MAT im richtigen Bereich posten. @Morly kümmert sich dann darum.

Tja, so ein Kabel schmeißt man ja auch nicht weg.
Die Box hat nicht umsonst eine serielle Schnittstelle.

Mit MAT kann man übers Netzwerk nicht alles loggen. Dann ist die serielle zwingend nötig.



Gruß

Chris


... so ein Kabel gehört, meiner Meinung nach, zur Grundaustattung wenn man eine Box besitzt.
Es kann auch mal zum Supergau kommen und nix geht mehr. Dann biste froh, wenn du dann seriell loggen kannst.
Mein Laptop hat keine serielle Schnittstelle mehr. Funzt aber mit einem Seriell > USB Adapter top.

[DboxOldie]

Ach ja, mein letztes serielles Kabel habe ich vor ca 25 Jahre weggeschmissen - mit sowas gebe ich mich nicht mehr ab...

so so...das wäre dann so 1990 rum....
Interessante Zeit:
Es gab gerade mal den i486, der die Einführung der Home-PC´s arg beschleunigte...
Die Mainboards ( AT Formaktor ) hatten meist 2 serielle COM - Ports...
USB > nada
Internet wurde gerade freigegeben....
Die ersten 2400 Baud Modems ( Post zugelassen ) kamen auf den Markt....

Naja und ca. 8 Jahre später kam die D-Box2, wo ein flashen ohne serielles Nullmodem Kabel schlecht möglich war....

[Bernie-vs]

@ Chriss: habe das unter Morly gepostet, ich denke, ich warte die Antwort mal ab ehe ich mit der Windows-Version rumbastele.
Falls ohne serielles Kabel keine Hinweise komme, kaufe ich mir halt eins mit Adapoter über ebay, scheint kein großes finanzielles Risiko zu sein (außer dass es nicht läuft).
@DboxOldie: In der Zeit war ich schon lange auf Apple umgestiegen und hatte einen wunderbaren Macintosh II mit 68030 Motorola. Hab immer über die Kollegen gelacht, die sich nur mit Win-Problemen rumgeplagt haben statt ernsthaft mit der Kiste zu arbeiten. Das scheint heute nicht anders zu sein...
Gruß
Bernie

[flac]

Die Adapter kosten nicht die Welt. Sollten aber auf FTDI Chip Basis sein.
Damit haben die meisten Betriebssyteme keine Probleme (Treiber).

... und dann noch ein serielles Kabel dazu und gut ist. Aber bitte nicht länger als 10m.

Solche Wäscheleine nutz ich z.b.
Die Box steht und bleibt im Wohnzimmer.:D


Das alles bekommst du für unter 10 Teuros



Gruß

Chris

[Bernie-vs]

Hallo Chris,

habe jetzt Morly zum Laufen gebracht, funzt prima.
Allerdings ist das Einschalt-Problem wahrscheinlich nicht mit Loggen über Ethernet zu fassen, die Box fährt bei Eingeschaltetem Loggen nicht runter.
Nach hartem Ausschalten und Einschalten der Box (bei laufendem Morly) enthalten die Logging-daten alles bis zum Ausschalten, aber keine neuen Daten. Morly zeigt "Stop Logging". Drückt man drauf und macht start logging, wird wieder neu geloggt ab der Aktivierung.
Das ist alles sicher korrekt, aber bringt keine Hinweise auf den Fehler.
Bleibt also nur, das über die Wäscheleine zu machen - blöd, dass die Box kilometer entfernt vom Mac steht, aber 10m reichen vielleicht...

Ich melde mich wieder
Gruß
Bernie

[Bernie-vs]

Die Adapter kosten nicht die Welt. Sollten aber auf FTDI Chip Basis sein.
Damit haben die meisten Betriebssyteme keine Probleme (Treiber).

... und dann noch ein serielles Kabel dazu und gut ist. Aber bitte nicht länger als 10m.

Solche Wäscheleine nutz ich z.b.
Die Box steht und bleibt im Wohnzimmer.:D


Das alles bekommst du für unter 10 Teuros



Gruß

Chris

Hallo Chris,

kannst Du mir noch einen Tipp geben?
Was ist besser:
10m serielles Kabel plus Adapter oder
10m USB Kabel mit Repeater plus Adapter
Adapter gibts wie Sand am Meer, allerdings haben die alle Stecker (male) statt Buchse (female), da muß ich also eh noch einen Adapter oder serielles Kabel mit female-female kaufen. Lösung 1 wäre deshalb billiger, so ein 10m Kabel kostet 8€.
Die Adapter haben leider alle nur kurze Kabel

Gruß
Bernie

[flac]

Ich würde Lösung 1 vorschlagen.

Mein Adapter hat ca.30 cm USB Kabel und ist mit Stecker. Also würde direkt an die Box passen (Buchse).
Das serielle Kabel hat Buchse/Stecker.

Ob es mit dem Repeater funktioniert kann ich dir nicht schreiben. Noch nie mit gearbeitet.


Gruß

Chris


...das Zeug ist in den letzten Jahren irgendwie teurer geworden. K.A.warum.

[DboxOldie]

Mmhh...
Bei meinen Boxen (ufs910, spark7162, d-box2) ist der RS232 Anschluss als Stecker mit Stiften an der Box. ( Ausnahme : ufs913/12 > da muss man sich was mit Western Würfel zusammen basteln. )
Genauso waren ja die RS232 Anschlüsse an den "alten" PC´s, und der USB < > RS232 ist üblicherweise auch als Stecker ausgebildet.
Dazwischen kommt ein Null-Modem Kabel (Buchse / Buchse ) wo RX / TX gekreuzt sind.
Stichwort:
"Laplink" > In der "vor-Netzwerk-Zeit" Daten von einem PC zum anderen "jagen"

[Bernie-vs]

Mmhh...
Bei meinen Boxen (ufs910, spark7162, d-box2) ist der RS232 Anschluss als Stecker mit Stiften an der Box. ( Ausnahme : ufs913/12 > da muss man sich was mit Western Würfel zusammen basteln. )
Genauso waren ja die RS232 Anschlüsse an den "alten" PC´s, und der USB < > RS232 ist üblicherweise auch als Stecker ausgebildet.
Dazwischen kommt ein Null-Modem Kabel (Buchse / Buchse ) wo RX / TX gekreuzt sind.
Stichwort:
"Laplink" > In der "vor-Netzwerk-Zeit" Daten von einem PC zum anderen "jagen"

Bei meiner Octagon 1028 sind Stifte hinten, also ist das definitiv male bzw Stecker.
Die Adapter haben alle ebenso Stifte / male / Stecker, also brauch ich ein Kabel Buchse/Buchse bzw. female/female 10m.
Unklar für mich: Die bisher gefundenen Kabel sind alle 1:1. Ich interpretiere das so, das da nix gekreuzt ist.
Muß ich wohl mal im Deutschen Museum vorbeischauen...oder das Thema beerdigen
Gruß
Bernie

- - - Aktualisiert - - -

oder geht das hier?
http://www.amazon.de/Kabel-Tex-DB9-Pin-RS232-Nullmodemkabel/dp/B0038PVKOO/ref=sr_1_5/277-4604487-7848919?ie=UTF8&qid=1436388164&sr=8-5&keywords=rs232+10+m

[flac]

Ist aber bei mir so ...


Gruß

Chris


...und der Adapter für die UFS913 ist selbst gebaut und dort passt das 10m Kabel dran.



10313

[DboxOldie]

@Mpp3Chris2712:
Ich meine auf Deinem Bild sind eindeutig Stifte amRS232 zu sehen, dann hast Du möglicherweise eine USB <> RS232 NULLMODEMADAPTER
So etwas gibt es auch und ist auch zu finden, allerdings nicht billig. >> http://www.startech.com/de/Karten-Adapter/Serielle-Karten-Adapter/1-Port-USB-auf-Nullmodem-RS232-DB9-Serieller-DCE-Adapterkabel-mit-FTDI~ICUSB232FTN
Da sind natürlich die Leitungen schon gekreuzt und man kann mit einer RS232 Verlängerung (male/female) dann verbinden / verlängern.
@Bernie-vs:
Genau: das wäre ein Standard Nullmodem Kabel
Hier weitere Erklärung / Verwendung / Historie:
https://de.wikipedia.org/wiki/Nullmodem-Kabel

[Bernie-vs]

Prima, danke DboxOldie, das hätte ich Dussel natürlich auch gleich mal über Wiki klären können.
Dann wär das mal geklärt: Ich brauche also ein Nullmodem-Kabel.
Habe Kabel + Adapter gleich mal bestellt, sind halt doch 25€ incl Versand der beiden Teile. Hoffentlich funzt das auch...
Übrigens, am Bild der Box-Rückseite ist schwer erkennbar, ob male oder female. Meine serielle Schnittstelle hat definitiv Stifte!!!

[flac]

Da muss ich mich berichtigen. Duck :ba22:

Durch das ganze Nullmodem Gedöns bin ich durcheinander gekommen.

Natürlich muss es ein Nullmodemkabel sein. Ich habe damals den Adapter für die UFS913 auf Nullmodem gelötet.
So passten daran die 10m Kabel.
Als ich die Box wechselte steckte ich an die LX3 ein 1m Nullmodemkabel und daran die 10m Kabel als Verlängerung.

Das komplette Kabel hängt in einer Schlaufe hinter dem Rack.
Habe erst gestern die Box auf gehabt (Tunerplatine) aber nicht auf den seriellen Anschluss geachtet.
Beim Einbau im Rack wird immer blind verdrahtet.


...aber 25 Teuros sind schon happig. Hab ebend in der Bucht geschaut.
Ein Anbieter der meinen Adapter vertreibt, hat auch 10m Nullmodemkabel...

... für insgesamt 20 Teuros incl. Versand


Naja, die 10m Kabel und das Nullmodemkabel hab ich vor ca.15 Jahren für ein Appel und nen Ei bei Pollin bekommen.

Seitdem die E2 Boxen den Markt erobert haben, sind die Preise irgendwie nach oben gegangen.
Kann mich auch Täuschen. Wird ja nicht alltäglich gekauft.:D



Gruß

Chris





Übrigens, am Bild der Box-Rückseite ist schwer erkennbar, ob male oder female. Meine serielle Schnittstelle hat definitiv Stifte!!!


Hat meine inzwischen auch.:36_2_49:

[Bernie-vs]

Ich warte jetzt mal ab, bis die Teile da sind (2-3 Tage), dann melde ich mich.
Entweder mit nem gescheiten Logging-File oder mit weiteren dusseligen Fragen...
Gruß
Bernie

- - - Aktualisiert - - -

Ach, noch was: Der Fehler mit dem Einschalten der Box tritt jetzt doch nicht mehr so zuverlässig zur gleichen Uhrzeit auf, mal war es 07:30 uhr, mal 14:00 Uhr, mal gar nicht.
Aber egal, wenn das mit dem logging klappt, kriegen wir den Hund. Ich laß einfach das Logging laufen, wenn´s sein muß tagelang...
Gruß

[Bernie-vs]

Das gleiche Problem habe ich hier auf meinem AV7000 auch.

@Andreas41:
Ich habe den Verdacht, dass der Fehler nur dann auftritt, wenn man keinerlei Timer gesetzt hat. Ich nehme seit ein paar Tagen jeden Tag Tour de France auf - seit dem ist der Fehler nicht mehr aufgetreten. Kannst Du mal versuchen, das zu verifizieren? Oder tritt der Fehler bei Dir regelmäßiger auf ? Wann ?

Gruß
Bernie

[Andreas41]

Mit deiner Vermutung köntest du richtig liegen,weil ich auch eher selten was Aufnehme. Also bei mir schaltet der Receiver sich jeden Tag zu verschiedenen zeiten von selbst ein,aber ich glaube an den Tagen wo ich mal eine Aufnahme programiert hatte ist sie im Deep Standby geblieben.

[Bernie-vs]

Mit deiner Vermutung köntest du richtig liegen,weil ich auch eher selten was Aufnehme. Also bei mir schaltet der Receiver sich jeden Tag zu verschiedenen zeiten von selbst ein,aber ich glaube an den Tagen wo ich mal eine Aufnahme programiert hatte ist sie im Deep Standby geblieben.

Heute hatte ich mal den einzigen Timer (der für die Tour, heute ist Ruhetag) gelöscht - prompt trat der Fehler um 12:10 Uhr auf. Leider sind weder Kabel noch Adapter bisher eingetroffen, sonst hätte ich das geloggt.
Es gibt allerdings für das Problem einen einfachen Work Around: Irgendeinen Timer in ferner Zukunft setzen, der immer bleibt - so gegen End of Life der Box ;-) - also ca 2018.

Gruß
Bernie

[max]

Dann liegt der Fehler, an/in fp_control, weiß nur gerade nicht was HDMU da zur Zeit benutzt.

[samoth]

An alle: Kann nur Eure Ausführungen bestätigen. Es muss mindestens ein Eintrag in der Timerliste vorhanden sein. Ich trage dort immer etwas in der fernen Zukunft ein z.B. in drei Jahren
und dann funzt alles prima ... :)

VG, Samoth

[santa]

Fo_control sollte die von @audioniek drin sein, vielleicht hat er ja ne idee

[Audioniek]

Werde mal nachschauen ob im fp_control etwas nicht richtig ist. Habe auch ein Box zum Testen.

Gruesse,

Audioniek.

[Bernie-vs]

Werde mal nachschauen ob im fp_control etwas nicht richtig ist. Habe auch ein Box zum Testen.

Gruesse,

Audioniek.

Kann auch sein, dass eine zusätzliche Bedingung erfüllt sein muss:
bei mir trat der Fehelr immer erst ca 1-2 Wochen nach dem Flashen einer neuen Version auf, wobei vorher sehr viele Aufnahmen und Timeshifts waren.

Würde es helfen, ein serielles Log zu schicken?
Gruß
Bernie

[Audioniek]

Ich habe endlich mal Zeit gehabt im fp_control herum zu schauen. Das Programm macht nichts in eine andere Weise als die andere Fortis Modelle. Wenn fp_control die Ursache sein sollte, sollten mehrere Fortis Modelle dieses Problem haben muessen, Bis jetzt hat nur ein anders Mitglied das Problem bestaetigt auf ein HDBOX (FS9000).

Die Situation im zweiten teil das beteiligt ist in diesen Context is der nuvoton Treiber. Die enthaelt zwar Code die specifisch ist fur die Atevio7500 aber die Code ist schon sehr lange unveraendert.

Ich schliesse darum vorlauefig auf ein Hardwareproblem.

Ein serielles log vom Phaenomen koennte hilfreich sein. Wenn die Moeglichkeit besteht Telnet zu machen, wuerde ich mich sehr Interessieren was das Befehl fp_control -w ausspuckt. Die soll, wenn unterstuetzt von den verwendeten nuvoton Treiber die Wakeup reason geben (power on, from standby oder timer).

Gruesse,

Audioniek.

[Bernie-vs]

Ein serielles log vom Phaenomen koennte hilfreich sein. Wenn die Moeglichkeit besteht Telnet zu machen, wuerde ich mich sehr Interessieren was das Befehl fp_control -w ausspuckt. Die soll, wenn unterstuetzt von den verwendeten nuvoton Treiber die Wakeup reason geben (power on, from standby oder timer).

Gruesse,
Audioniek.

Hallo Audioniek,

leider bringt fp_control -w immer nur den gleichen Output, ob Boot über FB, Boot über Einschaltknopf am Panel oder eben diese fehlersituation:

MAT:~# fp_control -w
Error reading wakeup mode from frontprocessor
Wakeup reason = 0 (Unknown)
MAT:~#

Ich werde Dir nächste Woche ein serielles Log liefern. Morly macht noch einen Fehler in der Mac version von MAT raus, dann kann ich loslegen.
Gruß
Bernie

[Octa10_28]

Der Thread ist zwar schon älter, aber da das Problem wohl immer noch aktuell ist klink ich mich mal hier ein:

Da die Octagon Firmware seit längerer Zeit nur noch sehr selten aktualisiert wurde, habe ich nach einer Alternative gesucht und bin hier im Board fündig geworden. Da meine Dream auch mit Enigma läuft, fand ich euer HDMU Image für die Octagons sehr gelungen und hab mich dann dran gesetzt um meine Receiver umzurüsten. Ich besitze neben einer Dream 7020HD noch 3 Octagon SF918G SE+ und eine SF1028P. Zu allererst: euer Image ist genau das, was ich immer gesucht habe. Durch den Einsatz der möglichen Skins, kann ich die Menüoberflache zwischen der Dream und den Octagons ziemlich gleich halten. Auch die Settings kann ich 1:1 kopieren. Das hilft immens bei der Pflege der Settings. Dennoch habe ich bei den Octagons das gleiche Problem, das hier in diesem Thread geschildert wird.

1. Die Boxen schalten sich zu unterschiedlichen Zeiten von alleine an. Leider gibt es zwischen den Receivern keine Gemeinsamkeiten wann dies der Fall ist. Ich habe die hier im Board geposteten Tipps fast alle durch. Die Software habe ich mehrmals aufgespielt, mal habe ich alle Plugins weggelassen, die Settings habe ich nur auf die benötigten Files getauscht, mal habe ich keine Änderungen an den Parametern durchgeführt, die Timerfunktion überprüft. Alles ohne Erfolg. Die Boxen schalten sich täglich mindestens einmal von alleine ein.

2. Bei dem SF918G SE+ wird im Display nicht die korrekte Uhrzeit angezeigt. Das passiert immer folgendermaßen: Nach dem Image Update stimmt die Uhrzeit noch. Wird der Receiver einmal stromlos gemacht, steht in der Anzeige nur noch die Zeit, die er betriebsbereit war. Also z.B. 00:25. Wenn ich dann mit der original Octagon Software die Box starte, stimmt die Uhrzeit wieder. Boote ich anschließend mit dem HDMU Image bleibt die Uhrzeit korrekt, bis der Receiver stromlos gemacht wird. Dann hat er wieder die falsche Uhrzeit. Ich hab auch schon mal die fp_control getauscht, aber ohne Erfolg. Ich wollte dann mal das Display komplett ausschalten, weil besser DUNKEL als FALSCH, aber der Display Parameter funktioniert nicht.

Für jede Hilfe oder Tipps bin ich dankbar.

Gruß
Ralph

[Bernie-vs]

Hallo Audioniek,
anbei ein serielles Log von dem Phänomen.
Sorry, hat etwas länger gedauert, da ich erst noch auf einen Update von Morly für Mac gewartet habe.
Box hat sich aus dem Deepstandby eingeschaltet, ohne dass es einen Timereintrag gibt.
Ich hoffe, das hilft.
Gruss
Bernie

[Bernie-vs]

Hi Ralph,

ich kann Dich nur beglückwünschen zu der Entscheidung für HDMU, das ist wirklich eine Super SW und die SW-Leute kümmern sich ernsthaft drum, gemeldete und reproduzierbare Fehler auszubüchsen. Dein Problem mit der Uhrzeit habe ich nicht. Aber zu dem Einschaltproblem habe ich jetzt mal ein serielles Log geliefert, vielleicht kann Guru Audioniek damit was anfangen.
Den Workaround zu dem Problem kennst Du sicher: Einfach irgendeinen Dummy-Timer Eintrag fern in der Zukunft machen, dann bleibt die Box ruhig. Mit so einem einfachen Workaround könnte ich sogar verstehen, wenn das Problem von den Gurus nicht mit höchster Priorität behandelt wird.
Warten wir mal ab.

Gruss
Bernie

[flac]

Warum immer Fullquotes (Vollzitate) gepostet werden, kann ich nicht verstehen.
Worum es geht steht alles auf einer Seite.

...lies dir das mal auf einem Tablet und noch viel schlimmer auf einem Handy durch, dann weisst du was ich meine.

Es gibt User die Tapatalk nutzen und dann wird es unübersichtlich.

Das ist ein Hinweis und keine Kritik. Also nicht falsch verstehen.





Gruß

Chris


....es reicht einen Post mit der Angabe der Postnr. zu zitieren.

[Octa10_28]

Danke Bernie, das werde ich mal sofort probieren. Wir werden schon wahnsinnig wenn sich vier Receiver zu den unterschiedlichsten Zeiten (natürlich auch nachts) einschalten.

Mit der Uhrzeit ist ja auch nicht so schlimm, wenn du nicht gerade nach dem Schlafen auf die Uhr schaust und du denkst du kommst zu spät zur Arbeit :-))). Gut wäre natürlich, wenn der Parameter zum kompletten Abschalten des Displays funktionieren würde. Na ja, ich probiere erstmal den Timereintrag.

Gruß
Ralph

[Bernie-vs]

Das mit dem Abschalten des Displays funktioniert bei mir auch, das zeigt dann nur noch einen kleinen Punkt im Hotstandby. Allerdings finde ich gerade nicht mehr, über welches Menü ich das gemacht hatte, ist schon paar Monate her. Ich spiele bei den Updates immer die gespeicherten Einstellungen wieder ein, da ich damit noch nie Probleme hatte.

Gruss
Bernie

[santa]

@Bernie-vs: #36 gelesen und verstanden?

[Bernie-vs]

Klar, da habt ihr ja Recht...(bin halt ein fauler Hund)

[santa]

?????????

Fühle mich gerade etwas verarscht.

Es geht darum keine unnötigen vollzitate zu nutzen.

Was bringt es für einen Vorteil wenn in deinem Post meiner nochmal wiederholt drin steht???
Der steht da drüber auch und kann von jedem nachvollzogen werden.



Edit: Im nachhinein alle Zitate zu entfernen lässt meinen Post keinen Sinn mehr zu erkennen.
Aber egal, Danke für das Entfernen

[Octa10_28]

Beim SF1028P wird doch im DeepStandby gar keine Uhrzeit angezeigt :confused:

[Octa10_28]

@Bernie: Das mit dem Timereintrag hat übrigens nicht funktioniert. Der Receiver war heute Mittag wieder an :(

[Bernie-vs]

@ santa: dito. Fühle mich auch verarscht. Jetzt habe ich schon alle Vollzitate rausgeschmissen - und das reicht doch noch nicht?

Ich schätze Eure gute Arbeit, es ist sicher auch euer gutes Recht, Nutzer, die daneben liegen, zu erziehen. Musst Dich aber nicht verarscht fühlen, war keine Absicht
Gruss und nix für Ungut
Bernie

- - - Aktualisiert - - -


Beim SF1028P wird doch im DeepStandby gar keine Uhrzeit angezeigt :confused:

Korrekt. Im Deep Standby wird bei mir gar nichts ins Display geschaufelt. Da ist die Kiste relativ tot, auch kein Netzt etc. Was noch läuft, wissen die Gurus.
Ich meinte auch den Hot-Standby. Den kann man so einstellen, dass er im Standby entweder Uhrzeit oder nichts (nur einen Punkt) zeigt und im eingeschaltenen Zustand den Kanal.
Und das alles auf meiner Octagon, eine andere Kiste verhält sich ggf anders.
Gruss
Bernie

[santa]

Deswegen ja mein edit, als ich das geschrieben hatte, hattest du mein Post davor zitiert, das fand ich komisch.
Anschließend hast du alle Zitate entfernt und somit sieht mein Post unglücklich aus, aber löschen wollte ich es dann auch nicht mehr.
Es geht dabei nicht darum euch User zu ärgern, sondern einfach nur um das lesen angenehmer zu machen und nicht alles doppelt zu lesen.
Unten auf antworten klicken reicht doch, dann hat man kein Zitat drin.

Egal jetzt, prost

[Audioniek]

Ich habe den log mal nachgeschaut und nichts besonderes aufgemerkt.

Vielleicht ist dies die Ursache: der HS8200 ist HDMI CEC faehig. Vieleicht gibt in den Setup ein Komponent die den Receiver spontan einschaltet; ich habe so etwas gehabt mit ein billig-Mediaplayer der mein TV spontan einschaltete. Ich wuerde das versuchen zu ueberpruefen durch das
benutzen der Component-ausgang anstelle HDMI (nur als Test, max. Resolution ist dann 1080i). Wenn das spontan Einschalten dann ausbleibt, ist auf jeden Fall die Ursache gefunden.

Gruesse,

Audioniek.

[Octa10_28]

Hmmm, kann ich mal testen ist aber für mich schwer vorstellbar. Der Octagon ist mit HDMI Kabel an einen LG Plasma angeschlossen. Der Fernseher ist aber aus (kein standby) und trotzdem schaltet sich der Receiver zu den unterschiedlichsten Zeiten ein. Ich ziehe das HDMI Kabel mal ab und teste dann.

Hab auch schon gedacht, dass er sich über WOL einschaltet. Aber auch ohne LAN Kabel, geht er an. Bei der Original Octagon Firmware, funktioniert alles wie es soll.

[Bernie-vs]

Ist ja laut Gurus ein seltener Fehler, ich hoffe, dass die sich trotzdem drum kümmern und anhand meines Logs was finden. Wobei das bei mir (und wohl auch anderen) mit dem Workaround klappt. Nur um Missverständnisse auszuschliessen: Mit Dummy Timer-Eintrag meinte ich schon einen richtigen Timer-Eintrag, also eine programmierte Aufnahme irgendwann in der Zukunft von irgendeinem Kanal.
Gruss
Bernie

[DboxOldie]

Ich hab mir mal das Log angeschaut.....
Wieso eigentlich so viel Zeilenumbrüche und diese vielen "1" en ???

Ist ja im Prinzip nur der etwas uninteressante Start ab init.....
Viel wichtiger wäre meiner Ansicht nach ein Shutdown Log ( aber echt seriell ) ohne gesetzten Timer.
Da ja fp_control üblicherweise was in das Log schreibt wenn es den WakeUp Timer in das Front Panel schreibt.

[Octa10_28]

ok, das kann ich machen. Dann brauche ich aber ein bisschen Hilfe. Was muss ich dafür tun? Serielle Kabel und Schnittstellen am PC sind vorhanden. Ist noch ein altes Überbleibsel von der dBox Zeit :o.

[Bernie-vs]

Hier das serielle shutdown log ohne Timer.12930
Keine Ahnung, wo die 1en und Umbrüche herkommen.
Ich mache halt das serielle Log völlig ohne Einstellungen mit Morlys Admin Tool
Soll ich beim nächsten Mal was einstellen? Wo? Bei Morly oder in der Box?
Gruss
Bernie

[Octa10_28]

so, hab mich jetzt schon mal ein wenig durch das Bord gekämpft und das MAT v2.4.3.1 geladen. Leider bekomme ich nach dem Starten immer die Fehlermeldung das in diversen dll's der Prozedureinspiegspunkt nicht gefunden wurde :confused:. Und nu?

[flac]

Das passende .dll Pack herunterladen und ins MAT Verzeichnis entpacken.

Befindet sich da wo auch MAT zu downloaden ist.





Gruß

Chris

[Octa10_28]

Danke Chris, aber das habe ich natürlich vorher schon gemacht, sonst würde er ja nicht sagen 'Einstiegspunkt in dll nicht gefunden'.

[DboxOldie]

Die Boxen liefern das eigentlich richtig, da braucht man nichts einstellen.
Im MAT : keine Ahnung, ich nutze immer Putty für so etwas.

Wie es aussieht ein anderer fp_control......

Hier mal am Beispiel der UFS913 ohne Timer:

/bin/fp_control: SW Version 1.04
Model: ufs913
vBoxType: 10
Selected Model: Kathrein UFS912 frontpanel control utility
init
configs: DISPLAY = 1, DISPLAYCUSTOM = 1, CUSTOM = %H:%M:%S
, WAKEUPDECREMENT 300
setTimer ->
success reading time from fp
Current Fp Time: 00:12:49 29-02-2016 (UTC)
Current Linux Time: 00:12:43 29-02-2016 (UTC)
Setting Current Fp Time to = FFFFFFE067 0 12 43 (mtime)
Getting Enigma2 wakeup time - Done
Getting neutrino wakeup timeOpening /var/tuxbox/config/timerd.conf
- Done
Entering DeepStandby. ... good bye ...
INIT: no more processes left in this runlevel


Und die Box bleibt auch aus....

Hier mit gesetzten Timer:



/bin/fp_control: SW Version 1.04
Model: ufs913
vBoxType: 10
Selected Model: Kathrein UFS912 frontpanel control utility
init
configs: DISPLAY = 1, DISPLAYCUSTOM = 1, CUSTOM = %H:%M:%S
, WAKEUPDECREMENT 300
setTimer ->
success reading time from fp
Current Fp Time: 10:24:34 29-02-2016 (UTC)
Current Linux Time: 10:24:34 29-02-2016 (UTC)
Setting Current Fp Time to = FFFFFFE067 10 24 34 (mtime)
Getting Enigma2 wakeup time - Done
Getting neutrino wakeup timeOpening /var/tuxbox/config/timerd.conf
- Done
configs: DISPLAY = 4313224, DISPLAYCUSTOM = 4313224, CUSTOM = %H:%M:%S
, WAKEUPDECREMENT 300
Planned Wakeup Time: 10:50:00 29-02-2016 (UTC)
Setting Planned Fp Wakeup Time to = FFFFFFE067 10 50 0 (mtime)
Entering DeepStandby. ... good bye ...
INIT: no more processes left in this runlevel



Und die Box startet rechtzeitig.


Vielleicht mal den unveränderten fp_control 1.04 probieren ?

[flac]

....ähm, und wenn keine .dll vorhanden ist?


Die Meldung kommt von MAT und aus keiner .dll.






Gruß

Chris

[Octa10_28]

wenn keine dll vorhanden ist, kommt die Meldung 'das Programm kann nicht gestartet werden, da xxxxx.dll auf dem Computer fehlt'.

- - - Aktualisiert - - -

es wird die qtdeclarative4.dll, qtwebkit4.dll, qtscript4.dll, qtsql4.dll und qtxmlpatterns4.dll angemeckert.

[flac]

ja, und auch das richtige Pack heruntergeladen und ins MAT Stammverzeichnis entpackt?


...genau deine Meldung entspricht, das er sie nicht gefunden hat.





Gruß

Chris

[Octa10_28]

hoffe doch, aus dem Upload Center hier.

[flac]

Da ich dein BS nicht kenne....musst du schon selber gucken.

...es gibt eins für Windoofs und eins für Linux.





Gruß

Chris

[Octa10_28]

Das sind die Fehlermeldungen. Natürlich habe ich die Windows Version genommen. Hab allerdings Windows 10 / 32 bit

[flac]

Dann muss es sich halt @morly ansehen...ich bin da raus.

Log halt mit Putty oder Telnet....





Gruß

Chris

[Octa10_28]

wie sind denn für PUTTY die Parameter?

[flac]

Bitte schau in die FAQ "Technisches rund ums Image". Da steht alles über das Loggen drin.




Gruß

Chris

[DboxOldie]

Putty seriell..
Richtigen COM Port wählen, dann so:

[Octa10_28]

vielen Dank, das hilft weiter. Hier das log meiner Box ohne Timereintrag....

12936


warum macht die Box das?

< 7001.946162>
< 7001.972017> set wakeup time to 2016/02/29 16:36
< 7002.028118> [EPGRefresh] Stopping Timer
< 7002.049194> [eDVBDB] ---- saving lame channel db

[DboxOldie]

Das kann ich auch nicht sagen, irgendein EPG refresh Gedöns ??
Da müsste mal ein HDMU Source Kundiger schauen....

Wenn unten die Ausgaben vom fp_control richtig sind:


Current system time: 13:26:01 29-02-2016 (local)
Getting 1st Enigma2 timer (none set) - Done


macht der ja nichts....

[flac]

vielen Dank, das hilft weiter.


...mein Post hätte auch weiter geholfen.
Ein bisschen Eigeninitiative ist wohl nicht zu viel verlangt.




Gruß

Chris

[Octa10_28]

neee, ich meine den Eintrag darüber....

< 7001.972017> set wakeup time to 2016/02/29 16:36

sieht für mich so aus als setzt die Box beim Runterfahren ein WAKEUP für 16:36Uhr

Ich bin mal gespannt, ob der Receiver um genau die Uhrzeit einschaltet.

[DboxOldie]

Ja schon richtig, hab ich auch gesehen.
Nur passiert das schon während E2 noch runter fährt....
Da ist noch nicht die rcS erreicht welche das halt script aufruft, und da an letzter Stelle den 'fp_control -e' der eben die 1.st Timer ausliest, setzt und danach das Board abschaltet.

[Octa10_28]

so, er hat sich nicht um 16:36 eingeschaltet.

[santa]

Evtl andere Zeitzonenzeit, evtl geht die Box eine oder zwei Stunden später an

[Octa10_28]

Ja, das hab ich auch erst gedacht und auch auf die falsche Uhrzeit im VFD Display geachtet. Aber die Zeitzone stimmt und auch nach Erreichen der 16:36Uhr im VFD Display, ging die Box nicht automatisch an. Ich weis einfach nicht woran sie festmacht, sich einzuschalten. Heute morgen hat sich z.B. der Eintrag im Log auf...

< 7001.946162>
< 7001.972017> set wakeup time to 2016/03/01 16:36
< 7002.028118> [EPGRefresh] Stopping Timer
< 7002.049194> [eDVBDB] ---- saving lame channel db

...geändert. Natürlich wird auch geloggt, dass kein Timer aktiv ist.

Current system time: 08:05:12 01-03-2016 (local)
Getting 1st Enigma2 timer (none set) - Done
There are no timers set

[zeini]

Das ist auch auf meiner Spark Triplex, dass Anfangs die Uhrzeit nicht stimmt. Egal welches Image. Aber die Box einfach mal in Standby versetzen und dann wieder starten, behebt das Problem.

[Audioniek]

Im log ist da ein kleines Stueckchen wegggefallen, da die vollstaendige Text "There are no Timers set or wakeup time in the past" lautet. Moeglicher weise gibt es da ein Problem, da in meine Erinnerung die HS8200 front panel nicht mit absolute wakeup Zeit rechnet, sondern mit relativ-Zeit in die Zukunft. Muss ich mal nachschauen.

Gruesse,

Audioniek.

[DboxOldie]

Das ist auch auf meiner Spark Triplex, dass Anfangs die Uhrzeit nicht stimmt. Egal welches Image.

Was Enigma2 betrifft: das mag sein.

Neutrino setzt die Uhrzeit im Display sofort, sobald es die gültige Zeit vom Sat hat.
Und dieser Vorgang wird peiodisch wiederholt, das ist schon immer so.

In E2 fehlt einfach diese Funktion....

[santa]

@octa10_28:
Ich les da was von Epg refresh.
Kannst du bitte mal ein neues Image flashen, nur erstassi einstellen, mehr nicht, dann herunterfahren und stehen lassen.
Hoffe du kannst so lange auf die Box verzichten bis sie angeht.

[Octa10_28]

Mach ich ! Hab so viele Boxen hier, da kann ich (die Kinder) mal auf eine verzichten :D

@audioniek: sag mir Bescheid, wenn ich irgendwie helfen kann.

[Octa10_28]

so, die Neuinstallation ist durch. Hier mal ein aktuelles Log beim Ausschalten des Receivers....

12937

...wie man sieht, wird hier die WAKE UP TIME nicht gesetzt. Bin mal gespannt ob er sich wieder einschaltet.

[Octa10_28]

Tja, das war es nicht. Der Receiver hat sich heute um 10:46 Uhr wieder eingeschaltet :( Und die Uhrzeit am VFD startet wieder bei 0:00 Uhr.

[santa]

@Audioniek: kannst du bitte mal ein fp_control binary von dir anhängen, Vielleicht hat unsere Version einen Fehler drin.

[Audioniek]

Und die Uhrzeit am VFD startet wieder bei 0:00 Uhr.

Dann ist es fuer mich Klipp und Klar: Hardwareproblem. Entweder die Frontprocessor verliert kurzfristig power under macht ein Reset (Uher geht auf 00:00) oder Die Processor selber ist nicht in Ordnung. Im ersten Fall verdenke ich dass Standby teil vom Powersupply. Wenn der Box schon etwas alter ist und intensiv benutzt worden ist, mal im Powersupply nach Elco's mit gewoelbter oberseite suchen.

Gruesse,

Audioniek.

[Octa10_28]

Das kann nicht sein audioniek. Ich hab 3 Octagon SF918G SE+ und eine Octagon SF1028P. Alle schalten sich unkontrolliert ein. Und alle laufen mit der Originalfirmware von Octagon einwandfrei.

[Octa10_28]

Hab gestern mal eine andere Box getestet und nach SANTAS Vorgaben installiert. Gleiches Fehlerbild auch bei dieser Box nur mit anderer Uhrzeit. Die Box hat sich um 10:45 Uhr automatisch eingeschaltet.

[Audioniek]

@Audioniek: kannst du bitte mal ein fp_control binary von dir anhängen, Vielleicht hat unsere Version einen Fehler drin.

Hier ist sie.

Gruesse,

Audioniek.

Anhang: 12942

[Octa10_28]

ok, dann probiere ich diese mal.

[Octa10_28]

am fp_control hat es nicht gelegen. Der Receiver war heute morgen wieder an :(

[santa]

Komisch, langsam gehen die Ideen aus

[Octa10_28]

Tja, wenn euch schon die Ideen ausgehen, was soll ich da erst sagen :rolleyes::rolleyes:. Ich würde euch ja auch mal einen Receiver zusenden, damit ihr seht, dass ich nicht einen an der Klatsche habe.

[DboxOldie]

Schon mal den alten fp_control (1.04) probiert ?
Es müssten ja auch andere dieses Problem haben, falls es daran liegt.

[Octa10_28]

Hab schon mal einen anderen probiert. Hab aber nur die Version 1.02 gefunden. Damit geht's auch nicht.

[Bernie-vs]

Thema Workaround:
Wenn der Dummy-Timereintrag zu weit in der Zukunft liegt, tritt der Fehler trotzdem auf Ich hatte jetzt einen Timereintrag für 20.12.16 gemacht und die Box schaltete sich abends von selbst an, nachdem sie schon mal morgens an war.
Bei Timer-Einträgen so ca 4 Wochen in der Zukunft funktioniert der Workaround zumindest bei meiner Box und die bleibt aus.
Weiss nicht, ob das alles irgendwie Zufall ist...
Gruss
Bernie

[Octa10_28]

probiere ich mal!

so, hab mal einen Timer auf den 15.04.2016 gesetzt. Steht auch im Log.

12945

[DboxOldie]

Naja 1.02 muss ja steinalt sein, aber wenn es damit auch nicht geht.....da gab es glaub ich die av7500 schon.
Das finde ich seltsam:


Wakeup Time: 14:55:00 15-04-2016 (local)
Time difference between fp and system: 3641 seconds
Calculated wakeup Timeú

Das log bricht so plötzlich ab.

Und das:


e2 ended <- RTV: 1
1
SHUTDOWN
starting e2->
INIT: Switching to run
INIT: Sending processes the TERM Signal

E2 beendet sich > in rcS wird init 0 aufgerufen > die Schleife läuft aber weiter, und nach der Ausgabe von "starting e2->" kommt ja das Kommndo E2 zu starten.
Keine Ahnung ob E2 da "angestartet" wird.

[Bernie-vs]

Das sieht bei mir irgendwie noch kurioser aus, wie ein Überlauf. Wakeup Time im Jahr 2001 - Klasse.
Ich glaube, wir kommen dem Hund auf die Spur: (Auszug aus dem Ende des seriellen Logs mit Timer auf 30.4.16 3:00 Uhr (mit 5min Vorlaufzeit):

Current system time: 14:37:46 05-03-2016 (local)
Getting 1st Enigma2 timer - Done
Wakeup Time: 02:55:00 30-04-2016 (local) Time difference between fp and system: -477424017 seconds Calculated wakeup Time: 08:08:03 14-03-2001 (local)

INIT: no more processes left in this runlevel

Gruss
Bernie

- - - Aktualisiert - - -

stört Euch nicht an dem blöden Emoticon, ist nicht von mir da reingemacht.
Wakeup time ist:
8 Uhr 8min 3 sec am 14.3.2001

[flac]

Wenn man sowas in einer Codebox postet, entstehen auch keine Smileys.




Gruß

flac

[Bernie-vs]

Und so sieht das aus bei Timer auf 30.12.2016 04:00 Uhr


Current system time: 14:59:18 05-03-2016 (local)


Getting 1st Enigma2 timer - Done


Wakeup Time: 02:55:00 30-12-2016 (local)


Time difference between fp and system: -477424016 seconds


Calculated wakeup Time: 09:08:04 13-11-2001 (local)




INIT: no more processes left in this runlevel




Diesmal mit Codebox, um Euch glücklich zu machen (was es nicht alles in diesem Forum gibt...)
Gruss
Bernie

P.S. Es sind schon Generationen von Programmierern an Datum/Uhrzeit gescheitert...

[flac]

Hat mit glücklich sein nichts zu tun...

Dafür gibts in der allgemeinen FAQ extra einen Abschnitt "Bewegen im Forum".

Die FAQ hast du doch gelesen, oder? Schon allein wegen den Boardregeln.





Gruß

flac

[Bernie-vs]

und jetzt zurück zum Thema...

[ReWard]

Leider kommst Du hier immer vom Thema ab, und das stört im Thema.

Und es geht hier nicht ums glücklich machen, es geht darum, das man das auch vernünftig lesen kann, auch auf dem Handy, das hatte santa Dir auch schon gesagt.

Und das gibt es nicht nur hier im Forum, das ist überall Standard, vielleicht ist das in anderen Foren egal, wir möchten das eben so.

[DboxOldie]

Schon seltsam alles....


Code aus ndv fp_control:
printf("Time difference between fp and system: %d seconds\n", (int)(curTimeFP - curTime));
Ergebnis:
Time difference between fp and system: -477424016 seconds

In Linux Konsole:
date -d '2018-03-05 14:59:18' +%s
ergibt:
1520258358
Rückrechnung:
1520258358 - 477424016 = 1042834342
In Linux Konsole:
date -d @1042834342
ergibt:
Fri Jan 17 21:12:22 CET 2003


Demnach müsste ja curTimeFP der 17.1.2003 ...usw. gewesen sein.

(Kopfkratz....)

[ReWard]

Ich mal als Laie.

Kann da ntp helfen?

[DboxOldie]

Denke nicht....
Setzt ja auch nur eine aktuelle Systemzeit wie von SAT, und Systemzeit ist ja die Referenz.
Das könnte höchstens helfen falls über Hotbird da was aus einer anderen Zeitzone gesetzt wird....aber das sind Stunden keine Jahre.

[DboxOldie]

Ui...Schreibfehler von mir: wir haben ja erst 2016 :)


date -d '2016-03-05 14:59:18' +%s
1457186358
1457186358 -477424016 = 979762342
date -d @979762342
Wed Jan 17 21:12:22 CET 2001


Also curTimeFP der 17.01.2001 ..... gewesen.

[Octa10_28]

...und was heißt das jetzt für uns? Muss sich bestimmt ein Entwickler anschauen, oder können wir noch was tun?

[ReWard]

Das ist auch einer, der Dir das schreibt. :)

[DboxOldie]

Ich würde zuerst das "Wiederstarten" verhindern wenn ein Shutdown ausgelöst wurde:


until false
do
echo "starting e2->"
/usr/local/bin/enigma2
rtv=$?
echo "e2 ended <- RTV: " $rtv
case "$rtv" in
1) echo "1"
echo "SHUTDOWN"
case $model in topf)
echo "STB" > /dev/fpsmall
echo "SHUTDOWN" > /dev/fplarge;;
*) echo "SHUTDOWN" > /dev/vfd;;esac
if [ -e /etc/.cecstandbyon ]; then
echo "0" > /proc/stb/cec/systemstandby
fi
init 0
sleep 6;;
2) echo "2"


Also ein "sleep 6" an der Stelle in die rcS einfügen. (Auf die Semikolon achten !!)
Dadurch pausiert die rcS für 6 Sekunden, während parallel der Init arbeitet und alle Prozesse killt.
Und klar > Unix fähiger Editor.

So sollte das Shudown Log schon anders aussehen.

[Audioniek]

Falls es noch versucht werden soll, hier ist ein fp_control version 1.04 binary, Quallcode vom ddt-git entnommen.

Gruesse,

Audioniek.

Anhang: 12947

[Octa10_28]

Ich glaub, da bin ich hier raus :confused:. Das sagt mir alles nix. Oder Du musst mich ein bisschen anschubsen 'DboxOldie'. Welche Datei ist denn das und wo finde ich sie?

Das andere fp_control teste ich gleich.

[santa]

Die rcS ist die Datei in der steht was alles gestartet und gestoppt wird.
Findest du unter /etc/init.d

[Octa10_28]

ok, dann werde ich das auch mal probieren. Momentan läuft aber noch der Test mit 'bernies' Dummy Timer Eintrag. Bis jetzt (schon 18 Std. her) hat sich die Box noch nicht eingeschaltet.

[Audioniek]

Ich bin da mal in Detail auf der Suche gegangen, und habe Folgendes heraus gefunden (Ich mache weiter in English da ich mich dann besser ausdruecken kann, bitte um Verstaendnis):

fp_control / time management analysis

Two clocks
There are two clocks in the system: the Linux system time and a separate clock maintained by the front panel processor. It is important to realise that the Linux kernel is not aware of the front panel clock, and therefore never interferes or interacts with it. This in turn means that it is the responsibility of the user software (in this case the HDMU image) to properly maintain the front panel clock.

Sequence of events in the HDMU image, power on from deep standby
As observed above, the earliest point in the startup where the system time and the front panel time are (supposed to be) dealt with is the rcS-routine. Regarding timehandling, it does the following:


The first thing that happens is the start of the nuvoton front panel driver. This driver is the speaking channel to the front panel clock and also controls the power state this way. The driver cannot synchronise the front panel clock, because at this point there is no network connection, and no satellite channel tuned in, so all possible sources of a correct and reliable time and date are absent
Just before Enigma2 is started the program /sbin/set_was_timer_wakeup is called. What that does exactly I cannot tell, as it a binary in the image.
Enigma2 is started.


Observation 1: Unless these tasks are done by the mysterious /sbin/set_was_timer_wakeup, either the system time, nor the front panel clock have been touched at this point. This in practice could mean that the system time is set to midnight January 1st 1970 (or 2000). This also means that the front panel clock is uninitialised when the receiver was off the mains before.
Observation 2: In usr/sbin there is a script time.sh that used to be called by the rcS, but is no longer. The script deleays itself for 52 seconds and then again for 30 seconds and executes a fp_contol -dt. The rationale behind this is that is very likely that by this time a satellite channel has been tuned in, and enigma2 has synchronised the system time with the transponder time. I have not been able to find any calling of this routine however.
fp_control -dt version 1.04 does absolutely nothing on a HS8200
fp_control -dt version 1.06 also does absolutely nothing on a HS8200

Net result seems to be that Enigma2 sets the system time, and the front panel clock is untouched at this point.

Sequence of events in the HDMU image, power down to deep standby
Enigma2 stops and returns to the rcS with a return value of 1. The rcS displays the message SHUTDOWN on the front panel display, sets the HDMI CEC and executes an init 0 (=system halt). At the end of this process /etc/init.d/halt is called. The very last ting is script does is an fp_control -e (without a further argument).

fp_control 1.06 now does the following. First it gets the current system time for the local timezone (the front processor works in local time, not UTC). Then it reads the earliest timer entry from enigma (in /etc/enigma2/timers.xml). It evaluates four cases:
A. No timer set at all;
B. Timer time is negative;
C. Timer time is valid, but in the past;
D. Timer time is valid and more than 300 days in the future.
In all four cases the lines: "There are no timers set or\nwake up time in the past;\nshutting down now." are written in the log and the receiver is powered down through nuvoton. Note that the front panel clock is still untouched and may still be uninitialsed!

If none of the above four cases are true, then there is a valid timer entry. fp_control now calculates the wakeup time in local time and writes this in the log.

Both versions now calculate the time difference between the system time and the timer time, and proceed to read the front panel clock time. Then the front panel time is compared to the system time.

fp_control 1.04 and 1.06 handle things differently from this point on.

Version 1.04 accepts a time difference between the two clocks of up to 12 hours either way, with version 1.06 this is 1 hour either way.

If there is a difference of more than 12 hours fp_control 1.04 sets the front panel clock equal to the system time, and then reports the front panel time in the log. It sets a wake up time of the front panel clock plus the calculated difference as wakeup time. If reading the front panel time fails, it does the same, but uses the system time plus the difference as the wake up time.

If there is a difference of more than 1 hour, fp_control 1.06 reports this in the log, but does NOT correct the front panel clock.
It then adds the calculated difference to the front panel time read previously and sets this as wakeup time.
If reading the front panel time fails, it sets the difference (plus zero) as the wake up time (this needs improvement as this will probably result in a failed timer. However if one cannot read the front panel time, is is very unlikely that one can set the wakeup time correctly).

The net result of both approaches should be the same, provided no overflows in the calcuations with a potentially uninitialised front panel clock occur. The approach in version 1.04 is the better of the two, and I have updated the git accordingly.

Both versions more or less assume Enigma2 sets the front panel clock, wheras it does not. The only point in time the front panel clock is corrected at the moment of writing, is when a power down to deep standby is done with fp_control version 1.04 and a valid timer set. Version 1.06 wrongly assumes the front panel clock would be set each time the system time is set, but is assumption is clearly wrong. The version currently in the git should correct this; the fp_control version number has been set to 1.07. I just pushed it.

Please not that this behaviour has been verified by users of Spark7162 with VFD display: they all conmplain about the front panel clock being incorrect until after the first deep standby and subsequent power on has occured. The real improvement would be that the rcS would set the front panel clock correctly before Enigma2 starts in about the the time.sh would do. fp_control 1.05 and higher have an option for this: option -sst copies the system time which must have be set correctly beforehand to the front panel clock. Neutrino handles all this correctly and initialises the front panel clock as part of its startup procedures.

Regards,

Audioniek.

[santa]

Zu 1. Set_was_timer_wakeup wartet auf die Zeit vom Satellit und schaut anschließend ob die jetzige Zeit innerhalb von 6 Minuten vor dem nächsten Timer ist, wenn das so ist, Wird ein proc gesetzt, Welches nach der Aufnahme die Box wieder in den Deep versetzt.
Zu 2. Hab jetzt nicht in das git geschaut, aber mir war so als wenn die time.sh ein Relikt Alter Zeiten war, als einige boxen die Zeit im vfd falsch angezeigt hatten, kann sein das wir das mal rausnehmen müssten.

[DboxOldie]

Zu time.sh kann ich was sagen:
Die wurde bei Spark7162 benutzt, damit im VFD nach Start die Zeit gesetzt wurde.
Kam die DVB Zeit zu spät > war das Script beendet und die Zeit passte nicht.

Als Ersatz hab ich mal den aotomtd gebastelt, der auch benutzt wird:


spark|spark7162)
/usr/bin/lircd
(sleep 75;aotomtd 60) &
/bin/evremote2 useLircdName 100 50 35 &;;


Nach Parameter ( hier alle 60 Sek. ) wird die VFD Zeit aktualisiert mit dem IOCTL:


#define VFDSETTIME2 0xc0425afd // seife, set 'complete' time...


Das hat seife mal vor ewigen Zeiten in die aotom Source eingebaut, und setzt die komplette Zeit inklusive Datum.

Das Daemon Tool (aotomtd) macht im Grunde das, was Neutrino im Falle Spark periodisch macht.

[Octa10_28]

@dBoxOldie

Jetzt habe ich mal den SLEEP eingebaut, aber nun fährt der Receiver nicht mehr hoch. Er bleibt auf LOADING stehen :confused:
vorher....


until false
do
echo "starting e2->"
/usr/local/bin/enigma2
rtv=$?
echo "e2 ended <- RTV: " $rtv
case "$rtv" in
1) echo "1"
echo "SHUTDOWN"
case $model in topf)
echo "STB" > /dev/fpsmall
echo "SHUTDOWN" > /dev/fplarge;;
*) echo "SHUTDOWN" > /dev/vfd;;esac
if [ -e /etc/.cecstandbyon ]; then
echo "0" > /proc/stb/cec/systemstandby
fi
init 0;;
2) echo "2"

nachher...


until false
do
echo "starting e2->"
/usr/local/bin/enigma2
rtv=$?
echo "e2 ended <- RTV: " $rtv
case "$rtv" in
1) echo "1"
echo "SHUTDOWN"
case $model in topf)
echo "STB" > /dev/fpsmall
echo "SHUTDOWN" > /dev/fplarge;;
*) echo "SHUTDOWN" > /dev/vfd;;esac
if [ -e /etc/.cecstandbyon ]; then
echo "0" > /proc/stb/cec/systemstandby
fi
init 0
sleep 6;;
2) echo "2"

war doch richtig so, oder?

[santa]

Notepad++ oder einen anderen Linuxkonformen Editor benutzt?

[flac]

...die Semikolons sind wohl falsch. Sie müssen hinter dem init bleiben. Darunter der Sleep,



Gruß

flac

[Octa10_28]

@santa

Hab mit WINSCP gearbeitet. Der ist linuxkonform.

[Bernie-vs]

#112 erklärt auch das unterschiedliche Verhalten bei mir, je nach dem, ob der Timer >300 Tage in der Zukunft liegt oder nicht.

[santa]

@flac, das mit den Semikolons ist schon richtig, da sonst das sleep nach dem init nicht aufgerufen wird und sonst im Nichts steht.



Häng mal die geänderte rcS hier an

Edit: Alternativ mal rcS und e2 killen und dann erst kopieren.

Also im telnet:

killall rcS
killall enigma2

Datei tauschen

init 6

[Octa10_28]

@santa
das geht leider nicht mehr. Musste den Receiver neu aufbereiten, da ich nicht mehr übers Netzwerk auf die Box kam :-(

- - - Aktualisiert - - -

@bernie

mit dem 'Dummy-Timer' schaltete sich die Box seit über 36 Stunden nicht mehr automatisch ein.

[DboxOldie]

Geändert war es ja richtig....( mit den Semikolon)
Wenn die Box nicht mehr startet:
Entweder das Unix Format zerdeppert, oder die Rechte nicht mehr auf 755.

[santa]

schon klar, wenn die rcS kaputt ist, dann geht eben nix mehr, also nochmal aufs neue.
Schöner wäre es ja den fehler ohne dummy hinzubekommen

[Octa10_28]

..das stimmt. Teste gerade nochmal den fp_control 1.04 von 'audioniek'.

[DboxOldie]

Max hat ja eine av7500: er braucht kein Dummy, und die Box startet auch nicht von alleine.
Audioniek hat ja was geändert an seinem fp_...

[Audioniek]

Audioniek hat ja was geändert an seinem fp_...

Die die gepostete 1.04 Version stammt von den Max-git und ist unveraendert compiliert worden. Die Aenderung in meinem fp_control ist wieder herausgenommen in der Version 1.07 (jetzt in meinem git verfuegbar).

Gruesse,

Audioniek.

[Octa10_28]

kannst Du mir mal die neue Version compiliert zur Verfügung stellen. In deinem git sind ja glaube ich nur die Quellen, oder?

Dann nimm ich mal den Pseudo-Timer von 'bernie' wieder raus und teste mit der neuen Version.

[DboxOldie]

Die Aenderung in meinem fp_control ist wieder herausgenommen in der Version 1.07 (jetzt in meinem git verfuegbar)

Ja das meinte ich: deine letzte aktuelle Änderung. :)

[DboxOldie]

Den Unterschied sehe ich hier:

Audioniek Git:


//check --> wakeupTime is set and larger than curTime and no larger than a year in the future (gost)
//check --> there is no timer set
if ((wakeupTime <= 0) || ((wakeupTime == LONG_MAX)) || (curTime > wakeupTime) || (curTime < (wakeupTime - 25920000)))
{
/* shut down immedately */
fprintf(stderr, "There are no timers set or\nwake up time in the past;\nshutting down now.\n");
vData.u.standby.time[0] = '\0';
if (ioctl(context->fd, VFDSTANDBY, &vData) < 0)
{
perror("Standby");
return -1;
}
}
else //wake up time valid and in the future


Max DDT Git:

//check --> WakupTime is set and larger curTime and no larger than a year in the future (gost)
if ((wakeupTime <= 0) || (curTime > wakeupTime) || (curTime < (wakeupTime - 25920000)))
//if ((wakeupTime <= 0) || (wakeupTime == LONG_MAX))
{
/* nothing to do for e2 */
// fprintf(stderr, "no e2 timer found clearing fp wakeup time ... good bye ...\n");
// vData.u.standby.time[0] = '\0';
fprintf(stderr, "no timer found ... good bye ...\n");
setNuvotonTime(wakeupTime, vData.u.standby.time);

if (ioctl(context->fd, VFDSTANDBY, &vData) < 0)
{
perror("Standby");
return -1;
}
}
else


Wenn kein Timer gefunden: wird LONG_MAX (2147483647) als wakeupTime zurückgegeben.
Irgendwo in 2038:


date -d @2147483647
Tue Jan 19 04:14:07 CET 2038


Im Max Git wird diese Zeit in Nuvoton Zeit umgerechnet und in den FP geschrieben.

Im Audioniek Git wird vData.u.standby.time[0] nur mit '\0' gefüllt und in den FP geschrieben.

[Audioniek]

@DboxOldie: Ich habe mich die Code noch mal angeschaut und nochmals nachgebessert. Die code im DDT schreibt wenn kein Timer gefunden wuerde wie gesagt LONGMAX (convertiert nach nuvoton format MJD H M S). Aber in den anderen Fallen wird die vorhandene wake up Zeit geschreiben, auch wenn sie unsinnig ist oder mehr als 300 Tagen in der Zukunft liegt, womit die ganze test auf gueltige Timer zwecklos ist.

Mein heutige version 1.07 schreibt bei fehlende gueltige Timer in allen Fallen LONGMAX (convertiert nach nuvoton format MJD H M S) als wake up Zeit, d.h. entweder es ist ein gueltige Timer gesetzt oder ein convertierter LONGMAX.

Im Anhang die fp_control 1.07 binary (heutige version) zum ausprobieren.

Gruesse,

Audioniek.

Anhang: 12953

[Bernie-vs]

Hab es gerade auf meiner Octi 1028 installiert und den Workaround Dummy-Timer vorher gelöscht.
Das sieht jetzt beim Shutdown recht gut aus:


Current system time: 17:04:09 07-03-2016 (local)


Getting 1st Enigma2 timer (none set) - Done
No timers set, wake up time in the past, or more than 300 days ahead.
Setting wake up Time: 04:14:07 19-01-2038 (local)




INIT: no more processes left in this runlevel


Danke für die schnelle Reaktion von allen Beteiligten.
Gruss
Bernie

[Bernie-vs]

Keine weiteren Auffälligkeiten:
- Timer Aufnahme aus deep stdby ok
- Box schlaltet sich auch nach 13 h nicht von selbst ein
Sobald das mal in einer der nächsten offiziellen HDMU Build Versionen ist, teste ich weiter "by using".
Gruß
Bernie

[Octa10_28]

Bei mir das gleiche. Dummy-Timer Eintrag entfernt und den neuen fp_control eingesetzt. Auch nach mehreren Stunden schalten sich die Octagon SF918G SE+ und die SF1028P nicht mehr automatisch ein. Ich mache aber noch einen Langzeittest über mehrere Tage.

Hut ab an alle :sm49:

[Bernie-vs]

Ist dieser fp_control fix eigentlich in einem der neueren Builds (HDMU_15083_E2_at7500_217_git_4129_nodebug_mix_Fla sh vom 22.5.16) enthalten? Aus dem changelog kann ich nichts entdecken.
Falls nicht: Kann ich die neue fp_control Version einfach manuell nachinstallieren oder gibt es da Kompatibilitätsprobleme.
Es regenet, es ist mal wieder Zeit für nen Update...
Gruss
Bernie

[santa]

Schau ich heute Abend mal nach und ersetze gegen eine aktuellere Version

[Bernie-vs]

@bonkel, santa und die andren Gurus:
Das neue fp_control 1,07 scheint noch nicht im neuesten Build zu sein (HDMU 1571).
Versehen?
Absicht?
Gruß
Bernhard

[santa]

Sollte drin sein, Image selber scheint aber selber kaputt zu sein

[Bernie-vs]

Santa, bitte tu mir einen Gefallen: Prüfe mal nach, ob die aktuelle fp_control 1.07 wirklich in den aktuellen Builds ist.
Meine Box hat sich nämlich jetzt wieder von selbst eingeschaltet.

Ich war von Donnerstag, dem 25.7. bis gestern 1.8. weg, Box war aus (deep stby, nicht Stdy), 1 Aufnahme war programmiert (Sonntag, F1). Als ich heute ankam, lief die Box. Die Aufnahme war da, was ja ok ist. Sie hätte aber nach der Aufnahme wieder in Deep Stdy gehen müssen, was sie wahrscheinlich auch machte. Evtl hat sie sich danach wieder eingeschaltet wegen des obigen fp_control Problems. Ich hoffe nicht, dass es ein neues Problem ist.
Leider habe ich vor Wut die Box hart ausgeschaltet, sorry, sonst hätte ich ein Log liefern können.

Also, meine Bitte: Verifizierung, ob correkte fp_control in aktuellen Builds ist.Danke im voraus
Gruß
Bernie