Posts by Fred Bogus Trumper

    Ja, bei diesem Unsinn gehen einem wirklich die Argumente aus - übrig bleibt nur noch fassungsloses Staunen ...


    Alternative Wahrheiten, Desinformationen, zweifelhafte Propaganda und Polemik scheinen derzeit groß in Mode zu sein und machen augenscheinlich nirgends halt.

    Trefft euch doch irgendwo im nirgendwo bei einer Sommerparty wo ihr keinen Schaden an der Allgemeinheit anrichten könnt und haut euch gegenseitig die Schädel ein, nachdem euch die Argumente und obskuren Ideen ausgegangen sind. Den Rest besorgt dann schon die Evolution ...






    /dev hat immer 1970-01-01 - auch nach stundenlangem Betrieb


    enigma2 schreibt ständig nach /proc/stb/fp - deshalb ändert sich die ctime laufend - das ist bei /dev nicht so.


    die ctime von /proc/stb/fp wird beim reboot oder stromlos machen auf 1.1.1970 zurückgesetzt weil das proc filesystem neu erstellt wird und dann beim 1. Schreibvorgang durch enigma2 ausgelöst wieder aktualisiert wird. Vermutlich wird die ctime nicht verändert, wenn die Zeit beim Schreibvorgang vor der cdtime liegt. Nachdem booten aus dem deepstandby entspricht die ctime der Zeit des letzten Schreibvorganges vor dem shutdown, ist also nicht von 1970, solange die Box vor dem shutdown sich mind 1x die aktuelle Zeit geholt hat.


    man könnte auch die ctime von /proc/net/dev verwenden, weil in die Datei ständig aktualisiert wird. Auch bei traffic über das loopback interface (lo) - also auch dann, wenn die box nicht im Netzwerk hängt

    zu welchem Zeitpunkt liest du ctime von /etc aus?

    Das kann ich leider nicht bestätigen, der Ordner /etc hat hier immer eine aktuelle Zeit, also nie das Jahr 1970 - egal ob nach reboot, aus standby oder nach stromlosen Zustand - immer über die rc.local automatisch beim boot ausgelesen, sogar mehrmals nach reboot und stromlosem Zustand


    Wie es aussieht, bleibt die letzte ctime von /etc erhalten, wird aber dann irgendwann beim bootup überschrieben


    nach /tmp/etc wurde die ctime von /etc über die rc.local geschrieben, der 2. command etwas später manuell. Beides nach stromlosen Zustand ausgeführt


    Code
    root@dm900:~# cat /tmp/etc 
    drwxr-xr-x 57 root root 4096 2022-01-22 22:49 /etc
    root@dm900:~# ls -ald --time-style=long-iso /etc
    drwxr-xr-x 57 root root 4096 2022-01-22 23:10 /etc
    root@dm900:~# 


    Aber meine Box ist sicher nicht die Referenz. Dazu habe ich schon viel zu viel im Linux Unterbau herumgeschraubt und hole mir die aktuelle Zeit sehr früh von einem Zeitserver und mein Image ist am Software stand vom 30.5.2019 ...


    das proc filesysstem wird beim booten dynamisch erzeugt und ist scheinbar nach reboot oder stromlosen Zustand weg - aber nicht, wenn die Box vom frontprozessor gestartet wird


    ich habe mir in der Zwischenzeit ein systemd service gebaut, dass beim bootup vor dem Netzwerkstart die Paketanzahl des inferface lo aus /proc/net/dev ausliest. Das hat bisher zumindest jeden boot aus dem standby erkannt. Wenn lo packages < 5 wurde sie entweder neu gestartet oder war stromlos, wenn größer kommt sie aus dem standby


    die ctime von /proc/stb/fp müsste auch reichen, wenn sie nicht zu früh nach dem start aktualisiert wird

    Ich bin vielleicht einen Schritt weiter:

    es wird ja nicht nur die ctime der Dateien im proc filesystem behalten sondern auch deren Inhalte wenn die Box aus dem deepstandby hochfährt


    z.B. /proc/net/dev

    hier werden rx, tx und pakete der Netzwerkschnittstellen geschrieben

    nach einem reboot oder stromlosen Zustand wird der Zähler auf 0 gesetzt


    über einen command in der rc.local beim bootup ausgelesen, da sieht man schön, dass eth0 0 bytes bzw. pakete empfangen oder gesendet hat

    Code
    Inter-|   Receive                                                |  Transmit
     face |bytes    packets errs drop fifo frame compressed multicast|bytes    packets errs drop fifo colls carrier compressed
        lo:     140       2    0    0    0     0          0         0      140       2    0    0    0     0       0          0
      eth0:       0       0    0    0    0     0          0         0        0       0    0    0    0     0       0          0


    die Werte gehen dann natürlich sofort hoch, wenn das Netzwerk aktiv wird



    aus dem deepstandby sieht es dann z.B. so aus


    Code
    Inter-|   Receive                                                |  Transmit
     face |bytes    packets errs drop fifo frame compressed multicast|bytes    packets errs drop fifo colls carrier compressed
        lo:    4409      53    0    0    0     0          0         0     4409      53    0    0    0     0       0          0
      eth0: 14578254   10818    0   12    0     0          0         0   196263    2446    0    0    0     0       0          0


    die rx/tx Werte eignen sich vermutlich nicht zum Rechnen, weil die Zähler irgendwann wieder bei 0 beginnen soweit ich weiß


    jetzt müsste man nur noch ein file im proc file system finden, indem etwas hochgezählt wird mit dem man Arbeiten kann und bei ein reboot auf 0 gesetzt wird und aus dem deepstandby den Inhalt behält


    dann könnte man im python die Datei auslesen und aus dem Wert ersehen ob es ein reboot oder boot aus dem deep standby war - dann kann das auslesen vor dem enigma2 Start im OS komplett wegfallen


    etwa nach dem Prinzip:

    wenn die paketanzahl der schnittstelle lo größer als 100 ist kommt die Box aus dem Deepstandby, wenn der Wert kleiner als 100 ist, war es ein Reboot wenn die Datei standby.chk nicht existiert oder die Box war stromlos wenn die Datei standby.chk existiert

    das funktioniert auch bzw. kann man mit der rc.local viel machen - ich habe da einiges eingebaut, dass im Linux Unterbau greift


    wenn die Zeit über die Transponderzeit geholt wird hast du vermutlich genügend Zeit. Wenn die Zeit über einen Zeitserver gesynct wird, kann ich nicht sagen ob sich das ausgeht


    ich hole mir die aktuelle Zeit beim bootup mit rdate über die rc.local, die ctime habe ich in der rc.local vorher ausgelesen. d.h. wenn die rc.local ausgeführt wird hat die Box vermutlich in keinem Fall die aktuelle Zeit.


    Über die Settings kannst zumindest rausfinden ob die Transponderzeit aktiviert ist oder nicht

    Code
    root@dm7080:/# grep -i TransponderTime /etc/enigma2/settings
    config.misc.useTransponderTime=false
    root@dm7080:/# 


    Bin mir aber jetzt nicht 100% sicher ob das auch im Originalimage greift, nutze ein alternatives OE2.5 Image


    alternativ könntest du ein eigenes systemd service basteln, nicht jeder hat das rc-local.service aktiviert

    IHMO ist das service by default deaktiviert und die rc.local muss auch manuell erstellt werden


    mir fällt gerade ein, die Zeit MUSS irgendwo gespeichert werden bzw. weiterlaufen. Woher weiss die Box sonst ohne Hardware Clock wann sie wg. eines Timer Events im Standby aufwachen muss?


    Das erklärt vielleicht auch, warum bei reboot die ctime nicht behalten wird: weil nicht notwendig


    Ich such mal im sys ...

    Hehe,

    jetzt ist es mir wieder eingefallen, wie man das prüfen kann


    es wird ja im Betrieb ständig in das proc file system geschrieben, d.h. auch die Dateiattribute wie ctime werden ständig aktualisiert. Vielleicht kann man das zunutze machen, dass die OE2.5 Boxen keine hardware clock haben.

    Wenn man die Box in den deepstandby schickt (auch mit shutdown -h now) bleibt die ctime im proc file system erhalten. D.h. die letzte Änderungszeit bleibt erhalten und wird erst überschrieben, wenn sich die Box die aktuelle Zeit wieder vom Zeitserver oder Transponder geholt hat und wieder ins proc file system geschrieben wurde.


    Bei einem reboot oder GUI Neustart oder stromlosen zustand wird die ctime des Odners auf Unixzeit zurückgesetzt


    Warum auch beim reboot kann ich nicht sagen.



    Ich hab mir dann den folgenden command in meine rc.local eingebaut, um die ctime von /proc/stb/fp beim bootup in ein temp file zu schreiben

    ls -ald --time-style long-iso /proc/stb/fp > /tmp/proc_stb_fp


    nach dem Aufwecken aus dem (deep)standby sieht das so aus - die letzte change time bleibt also erhalten

    nach Standby über die GUI oder das Web-IF, oder nach

    shtudown -h now

    systemctl poweroff


    Code
    root@dm900:~# cat /tmp/proc_stb_fp 
    dr-xr-xr-x 2 root root 0 2022-01-22 15:05 /proc/stb/fp
    root@dm900:~# 


    Nach einem bewussten stromlos machen oder einem Stromausfall und bei einem reboot/Neustart wird die ctime zurückgesetzt und es wird die Uhr auf die Unixzeit gesetzt: 01.01.1970 00:00 UTC


    d.h. nach dem Start aus einem stromlosen Zustand oder reboot sieht das so aus

    Code
    root@dm900:~# cat /tmp/proc_stb_fp 
    dr-xr-xr-x 2 root root 0 1970-01-01 01:00 /proc/stb/fp
    root@dm900:~# 


    d.h. das Datum 01.01.1970 ist ein Indikator für einen stromlosen Vorzustand - warum auch immer dieser eingetreten ist.

    Wenn das ctime Jahr von /proc/stb/fp 1970 ist UND das reboot.chk file vorhanden ist, war es ein geplanter Neustart

    Wenn das ctime Jahr von /proc/stb/fp 1970 ist UND das standby.chk file vorhanden ist, hatte die Box im standy einen Stromausfall

    Wenn das ctime Jahr von /proc/stb/fp nicht 1970 ist UND das standby.chk file vorhanden ist, hatte die Box im standy keinen Stromausfall
    usw.

    Ob das für das Plugin nutzbar ist kann ich nicht sagen. Hängt wohl davon ab wie schnell sich die Box über eine Zeitserver oder der Transponderzeit die aktuelle Zeit holt und die ctime des Beispielordners im proc filesystem aktualisiert wird.

    IHMO gehört der ganze Freigaben bzw. Mountmanager längst angepasst bzw. mehr als optimiert, weil da einiges nicht so gut gelöst ist und oft mehr Sorgen als Einfachheit bereitet. Ich mounte die Freigaben nur über die fstab mit systemd im DreamOS.


    Nach meiner Erfahrung sollte man die Standardaufnahmepfade anpassen, wenn man mit HDD Ersatz mountet


    /media/hdd statt /media/hdd/movie und alles ist gut - dann braucht es auch keinen movie Ordner am NAS etc.



    Sauberer ist es NICHT mit HDD Ersatz zu mounten und die Standard Aufnahmepfade auf den Einhängepunkt der Netzwerkfreigabe bzw. auf einen Ordner darin umzustellen


    Wenn man mit HDD Ersatz mountet bzw. auf eine Nezwerkfreigabe aufnimmt wäre es am Besten, die Freigabe in eine ram disk (tmpfs) zu mounten damit der Flash nicht platzt, wenn die Aufnahme warum auch immer im file system landet und nicht am share. Nach einem reboot ist dann wieder alles sauber,

    ah, das mit dem cache daemon hatten wir schon mal, da gabs mal einen memory leak ...


    Ein Neustarten des dreambox teletext cache deamons behebt das aktuelle Problem im OE2.5 aber nicht, am Puffern liegt es glaube ich also nicht


    dbttcd ist meines Wissen closed source - da kann nur DP was ändern, wenn es daran liegt

    nach Auswahl TeleText wird kein Inhalt angezeigt. Schwarzes Bild nada Inhalt.


    Du hast Recht - sorry, das war mein Fehler
    Ich hatte das auf der Box ohne Sat Anschluss getestet. Da werden alle Sender über Partnerbox Bouquet gestreamt. Da wurde mit dann der Teletext eines anderen Senders angezeigt. Wenn ich es auf der Box mit Sat Anschluss ohne Partnerbox teste, kommt beim Teletext auch das schwarze Bild.

    Text DSMCC funktoniert aber, scheint eine HBBTV Lösung zu sein

    Aber wie geschrieben: gestern hatte ich die Auswahl noch nicht - d.h. ARD schraubt hat da etwas geändert