Meine nagelneue DM920 war gerade ebenfalls nur mit 100 Mbit/s verbunden mit meiner FB 7590. DM920 daraufhin neu gestartet, jetzt ist sie mit 1000 Mbit/s verbunden. Bedeutet das, dass wenn ich verhindern will, dass sie auf 100 Mbit/s zurück fällt, der einzige Weg ist, die DM920 einzuschicken?

Zitat von goodspirit99

Erfolg des „Firmware-Updates"

Ist es nicht etwas früh von Erfolg zu sprechen? Besser erstmal ein paar Wochen beobachten, oder? Wie defekte Sektoren im Flash damit zusammen hängen können ist mir schleierhaft - ich dachte die werden erkannt - spätestens beim erneuten flashen dann?

Ich hab keinen Magneten im Haushalt, nicht mal am Kühlschrank Dann sollte ich das mit dem Abbeizen wohl besser lassen - hatte nur befürchtet, dass die neue Lackschicht ansonsten so dick aufgetragen wird, dass das ganze irgendwie "zugeschmiert" aussieht
Auf diesem Foto (Copyright: US-Sat Dortmund, abgebildet ist ein DM500-Gehäusedeckel) sieht man ganz gut die Lackoberfläche. Danke für den Tipp mit dem Pulverlack - ich hätte nämlich gerne nachher den gleichen "Glanzeindruck" wie bisher. Welche Stufe das nun ist... vermutlich matt oder halbmatt (es gibt: hochglänzend, glänzend, halbglänzend, halbmatt, matt)

Ah danke Verzinkt scheint man wohl rein optisch auch gar nicht erkennen zu können.

PS: Wenn ich mit dem Umlackieren fertig bin stelle ich mal ein Foto hier rein.

Hallo,

ich habe bei einem Händler ein rotes Frontcover für die 800se gekauft - sieht schick aus... der Händler hatte das Teil direkt von DMM bezogen als Restbestand. Leider gibt es keine roten Gehäusedeckel mehr... deswegen wollte ich mal einen schwarzen Deckel abbeizen und rot lackieren lassen

Bitte nicht lachen: Jetzt haben mich die Abbeizspezis gefragt ob es sich bei dem Deckel um Stahl oder Alu handelt, und ob er verzinkt ist oder nicht Da ich in Materialkunde nicht so firm bin, weiß das zufällig jemand von Euch?

Zitat von Fred Bogus Trumper

Wenn das file /tmp/@reboot.works nach dem reboot angelegt wurde, funktoniert der string, aber wird wohl vor dem Netzwerkstart ausgeführt, dann müsstest du im script ein delay einbauen oder den cron start zeitlich später beim boot ausführen lassen. Wenn die Datei nicht angelegt wird, wird der string @reboot gar nicht ausgeführt

Hab's getestet - in den DMM-Images (OE1.6, OE2.0) funktionieren Strings mit @reboot definitiv nicht. Was allerdings gut funktioniert ist die von mir oben vorgeschlagene Variante per Initscript:

# !/bin/sh
/usr/sbin/rdate -s ptbtime1.ptb.de
exit 0

Script unter /etc/init.d speichern (Dateiname z.B. rdate.sh) bzw. dorthin kopieren, Rechte 755, dann noch einschalten mit folgendem Befehl (wird an Position 20 in die Runlevel 2,3,4 und 5 eingefügt (aufgrund alphabetischer Sortierung direkt hinter S20inetd, nämlich als S20rdate.sh). In die Runlevel 0,1,6 wird nichts eingefügt (also nichts zum Killen - ist ja nicht notwendig):

update-rc.d rdate.sh start 20 2 3 4 5 .

Löschen/Austragen kann man es hiermit:

update-rc.d -f rdate.sh remove

Ich habe testweise mal das Netzwerkkabel rausgezogen und die Box rebootet: Der Bootvorgang dauert nicht länger (hängt also nicht) und die Zeit stellt sich entsprechend halt auch nicht.

Zitat von gutemine

Wozu ich das alles damals wohl ins DVBTime Plugin eingebaut hatte ...

Kommt mit dem Plugin eigentlich (huckepack) ein ntpdate binary, das unter OE1.6/2.0 lauffähig ist? Leider ist die Plugin-Beschreibung nicht so detailliert (oder ich hab es nicht gefunden). Ich würde gerne das Network Time Protocol probieren Oder kennt jemand eine Downloadquelle für das Binary?

Es macht einfach mehr Spaß wenn man die Zusammenhänge versteht und es selbst zusammenbauen kann Das ist es sicher auch was Dich antreibt beim Software schreiben und Du hast ja schon eine Menge nützlicher Plugins etc. auf die Leute losgelassen

Ich hoffe ich kann mein "@reboot-Problem" unter OE1.6/2.0 noch lösen, dann bin ich glücklich.

ls -al /etc/rc?.d/*cron*

root@dm800se:~# ls -al /etc/rc?.d/*cron*
lrwxrwxrwx    1 root     root           22 Jan  1  2000 /etc/rc0.d/K20busybox-cron -> ../init.d/busybox-cron
lrwxrwxrwx    1 root     root           22 Jan  1  2000 /etc/rc1.d/K20busybox-cron -> ../init.d/busybox-cron
lrwxrwxrwx    1 root     root           22 Jan  1  2000 /etc/rc2.d/S20busybox-cron -> ../init.d/busybox-cron
lrwxrwxrwx    1 root     root           22 Jan  1  2000 /etc/rc3.d/S20busybox-cron -> ../init.d/busybox-cron
lrwxrwxrwx    1 root     root           22 Jan  1  2000 /etc/rc4.d/S20busybox-cron -> ../init.d/busybox-cron
lrwxrwxrwx    1 root     root           22 Jan  1  2000 /etc/rc5.d/S20busybox-cron -> ../init.d/busybox-cron
lrwxrwxrwx    1 root     root           22 Jan  1  2000 /etc/rc6.d/K20busybox-cron -> ../init.d/busybox-cron
root@dm800se:~#

Es interessiert ja erstmal nur der Runlevel 3 (Default-Runlevel der Dreambox, siehe Datei /etc/initab) und demzufolge der Inhalt vom Verzeichnis /etc/rc3.d:

root@dm800se:~# ls -al /etc/rc3.d
drwxr-xr-x    2 root     root            0 Jan  1  2000 .
drwxr-xr-x   33 root     root            0 Jan  1 01:00 ..
lrwxrwxrwx    1 root     root           16 Jan  1 01:00 S02dbus-1 -> ../init.d/dbus-1
lrwxrwxrwx    1 root     root           18 Jan  1  1970 S10dropbear -> ../init.d/dropbear
lrwxrwxrwx    1 root     root           22 Jan  1  2000 S20busybox-cron -> ../init.d/busybox-cron
lrwxrwxrwx    1 root     root           15 Jan  1  1970 S20inetd -> ../init.d/inetd
lrwxrwxrwx    1 root     root           16 Jan  1  1970 S20syslog -> ../init.d/syslog
lrwxrwxrwx    1 root     root           16 Jan  1 01:00 S20vsftpd -> ../init.d/vsftpd
lrwxrwxrwx    1 root     root           16 Jan  1  1970 S21autofs -> ../init.d/autofs
lrwxrwxrwx    1 root     root           22 Jan  1 01:00 S21avahi-daemon -> ../init.d/avahi-daemon
lrwxrwxrwx    1 root     root           19 Jan  1  1970 S99rmnologin -> ../init.d/rmnologin
root@dm800se:~#

Ich vermute mal, dass inetd der Daemon ist, der für die Netzwerkverbindung notwendig ist und dass dieser erst nach busybox-cron gestartet wird, weil die Liste bei gleicher Startnummer sequentiell alphabetisch abgearbeitet wird. Soll ich inetd ja durch einen Eintrag in dessen Startscript z.B. auf S10 vorziehen (vor dropbear) und busybox-cron auf S21 (hinter avahi-daemon)?

Andererseits habe ich mal

@reboot sleep 60 && /usr/sbin/rdate -s ptbtime1.ptb.de

getestet, sowohl unter OE1.6 also auch OE2.0, beides ohne Erfolg. Auch mit 120 Sekunden geht es nicht. Gegenprobe: Am Sleep-Kommando selbst liegt es nicht, denn

5 * * * * sleep 60 && /usr/sbin/rdate -s ptbtime1.ptb.de

funktioniert: Die Uhr startet nach dem Booten ja bei 01:00 Uhr und das Update findet dann um 01:06 (01:05 Uhr plus 60 Sekunden) statt. Auch

@reboot sleep 120 && /usr/sbin/rdate -s ptbtime1.ptb.de

geht nicht. Bei Dir funktioniert @reboot aber, hm

Zitat von Fred Bogus Trumper

das busybox-cron ist im OE1.6 installiert, aber buggy

entweder manuell fixen -> busybox-cron bug

Danke für den wertvollen Hinweis Brauchte etwas Zeit, um crontab, Cron-Daemon und die Befehle zu verstehen, aber es läuft jetzt soweit - nach Anlegen der beiden Verzeichnisse und des Symlinks (damit der crontab-Befehl funktioniert) auch unter OE1.6.
Eigentlich bräuchte ich bloß folgende zwei Cronjobs, aber busybox-cron unterstützt offenbar keine "@"-Expressions - und das auch nicht unter OE2.0:

@reboot /usr/sbin/rdate -s ptbtime1.ptb.de
55 * * * * /usr/sbin/rdate -s ptbtime1.ptb.de

Also erstellt man für ein rdate im Bootprozess stattdessen ein Script, richtig? Funktionieren Scripte nach folgendem Muster eigentlich nur für "Daemons" oder auch mit einfachen Befehlen wie rdate? Würde folgendes winziges Script funktionieren, wenn man es nach /usr/script kopiert (mit Rechten 755 und mittels Symlink als Initscript verlinkt)? Also wird das bei jedem Bootvorgang dann immer einmalig so ausgeführt und automatisch beendet, ganz ohne irgendwelche ifs und cases?

#!/bin/sh
/usr/sbin/rdate -s ptbtime1.ptb.de
exit 0

Dein rdate-Binary läuft hier unter OE1.6 auch super

root@dm800se:~# tar vxzf /tmp/rdate_mipsel.tar.gz -C /
usr/
usr/sbin/
usr/sbin/rdate
root@dm800se:~# ls -al /usr/sbin/rdate
-rwxr-xr-x    1 root     root        15996 Apr 19  2017 /usr/sbin/rdate
root@dm800se:~# rdate -s ptbtime1.ptb.de
root@dm800se:~# date
Thu Apr 20 12:57:46 CEST 2017
root@dm800se:~#

Ich werde jetzt noch die Transponderzeit ausknipsen:

• Enigma2 stoppen mit "init 4"
• /etc/enigma2/settings editieren, Zeile einfügen: config.misc.useTransponderTime=false
• Enigma2 wieder starten mit "init 3"

Oh, ich merke gerade ich hab' auch kein cron, um beim Booten und in Intervallen den Zeitserver abzufragen. Fehlt das auch in meiner busybox (also doch austauschen?) oder muss ich es separat installieren (enigma2-plugin-extensions-cronmanager, auf dem Feed ist es allerdings nicht)?

Oh super, danke - werde ich gleich morgen Vormittag testen (einfach komplett entpacken und nach /usr/sbin kopieren, Rechte 755).

Was muss ich denn beachten, wenn ich die ganze busybox (unter /bin/busybox) tauschen will - einfach im laufenden Betrieb überschreiben?

opendreambox 1.6:

dm800se login: root
root@dm800se:~# busybox rdate
rdate: applet not found
root@dm800se:~#

opendreambox 2.0:

dm800se login: root
root@dm800se:~# busybox rdate
BusyBox v1.19.4 (2013-04-23 14:57:27 UTC) multi-call binary.


Usage: rdate [-sp] HOST


Get and possibly set the system date and time from a remote HOST


        -s      Set the system date and time (default)
        -p      Print the date and time


root@dm800se:~#

Muss ich das busybox-Binary austauschen? Aber wie, und welches nehmen? Kann ich einfach das Binary aus OE2.0 drüberkopieren, oder wurde das anders kompiliert - ansonsten hätte ich noch das busybox-Binary aus einem auf OE1.6 basierenden "Doppel-N"-Image, das wohl anders gebaut wurde (inkl. rdate).

Hallo in die Runde,

ich habe noch zwei DM800se, die ich gerne auf OE1.6 lassen würde. Ich vermisse aber das "rdate", welches bei OE2.0 drin ist (siehe unten, ich habe testweise mal das opendreambox 2.0 experimental installiert):

root@dm800se:~# date
Thu Jan  1 01:08:19 CET 1970
root@dm800se:~# rdate -s ptbtime1.ptb.de
root@dm800se:~# date
Wed Apr 19 12:35:49 CEST 2017
root@dm800se:~# which rdate
/usr/sbin/rdate
root@dm800se:~#

Kann ich rdate vom OE2.0 Image (/usr/sbin) nehmen und unter OE1.6 ebenso nach /usr/sbin kopieren? In Filezilla wird mir rdate als Verzeichnisverknüpfung angezeigt, aber wenn man es auf den PC kopiert hat man eine 662.868 Byte große Datei... Ich dachte auch rdate wäre kleiner.