Posts by Reichi

    And how did you bring it to that state?

    There's two possibilities I see at this point:


    1. It's actually is some kind of hardware issue (I kinda doubt that, tbh)

    2. You or some software you used (prominently any kind of partitioning tool) messed around with the initial sectors of the emmc (where uboot resides) and therefore ruined the "second stage" bootloader.


    If you see yourself in position 2. please contact our support for instruction on how to get your box fixed.

    We don't pass that software around for a reason! (flashing the bootloader just for fun is a horrible idea!)

    What you're saying is ALL wrong.


    There has been no dreambox requiring or even working with DreamUp in almost a full decade!!


    There is a integrated recovery system that is being loaded when holding down the power button on boot.

    From there a new image can be flashed using a standard webbrowser.


    Ruining the bootloader won't happen on original images.
    At least we currently know of 0 cases where that happend.


    We did have some cases where 3rd party images managed to ruin the boot process by partitioning the mmc blockdevice (which is NOT supported currently).

    You can't blame us for that.


    Still, we do have a solution to recover even from a broken u-boot (you do have to contact our support for that).

    From a pure software side, it is almost "impossible" (yeah, there's always some way) you'll get a dreambox one/two/seven in a state where it can't be recovered as it can load the bootloader from an SD-Card even if the emmc is completely empty.

    Ist das auch aus objektiver Sicht die geeignete Stelle?

    Fast ;).

    ich würden den "onHide" callback nutzen (vom Screens.Screen.Screen geerbt).

    also sowas wie InfoBar.instance.onHide.append(self._showHbbTVMethod)


    um auf ein einblenden der InfoBar zu reagieren kann man parallell dazu auch noch sowas machen InfoBar.instance.onShow.append(self._hideHbbTV)


    Beim deaktivieren des Plugins zur Laufzeit halt nicht vergessen die callbacks wieder aus den listen zu entfernen.

    Auf diesem Weg musst du nämlich überhaupt nix an der InfoBar manipulieren und kannst als reines Plugin agieren :)


    Es gibt kein Stop oder close def in der HbbTV Klasse. Muss ich wirklich den Exit Knopfdruck simulieren im Code oder gibt es einen besseren Weg. Ich vermute, dass __onClose(self) genutzt werden müsste. aber eErhlich gesagt bin ich durch die def noch nicht ganz durchgestiegen. Das mit der app verstehe ich schon, aber ich kriege es nicht aufgerufen -> GS. Keine Ahnung was ich da falsch mache.


    Jeder Screen hat u.A. eine close() Methode und noch ganz viele Callbacks etc.

    Da der HbbTV Browser ein Screen ist, hat auch dieser dieser sie :).

    Siehe dazu /usr/lib/enigma2/python/Screens/Screen.py


    Mit 5-7 Sekunden Anzeigezeit werden wir nicht auskommen, ich denke die Einbeldung muss eher 20-30 Sekunden werden.

    Das denke ich auch. Das könntest du aber sehr leicht Konfigurierbar machen, so dass jeder es so einstellen kann wie es ihm Beliebt.

    Ich denke Ausblendezeiten im Bereich von 10 - 40 Sekunden in 10-Sekunden Schritten sollten aber völlig ausreichen. Zuviele Optionen machen die Konfiguration für die meisten User sehr schnell unverständlich/zu aufwändig.


    Man müsste mal sehen ob die HbbTV Imlementierungen nicht sogar selbst den "hide" callback rufen. Ich hab das grad nicht mehr im Kopf. Wenn ja, so könnte man eventuell auf den "offiziellen Timeout" reagieren.

    Wenn ich die 20-30 Sekunden mit einem eTimer realisiere, kann ich den einfach mit dem Druck auf eine HbbTV Taste (Farbtasten) unterbrechen? In dem Fall soll ja das zeitgesteuere Close nicht ausgeführt werden.

    Ja, eTimer hat eine "stop()" Methode welche jeden laufenden Timer unterbricht.

    Wie sieht's eigentlich mittlerweile aus? Wann kommt den nun endlich die Funktion?


    6 Monate sind schon wieder rum.


    Totgeschwiegenes Thema?


    Ganz und gar nicht! Im nächsten Update wird die Funktionalität enthalten sein.

    Sie wird aber zu Beginn noch manuelle schritte erfordern um überhaupt nutzbar zu sein (der Bootloader muss aktualisiert werden).

    im MediaPlayer den Wert überschreibe - sind davon auch andere Programme betroffen?

    Ich weiß nicht, ob diese konkrete Size sonst jemand nutzt.

    Wenn ja, dann wirkt sich das natürlich auch an anderen Stellen aus.


    Der Aufruf würde übrigens crashen wenn es MediaplayerPlaylist nicht explizit im skin gibt, das sollte man vorab prüfen.


    Generell rate ich aber dringend davon ab programmatisch ComponentSizes zu verbiegen.

    Sie wurden geschaffen damit man es im Skin anpassen kann.

    In dem Fall wäre da eventuell eine skin_user.xml in /etc/enigma interessant

    Unser Ziel ist die Datenbank zu fixen nicht sie einfach global zu deaktivieren und nie zu nutzen.

    Das mag stellenweise etwas steinig sein, aber offenbar ging beim Rewrite doch mehr schief als ursprünglich angenommen.


    Aber ich bin da dran. Fix kommt!

    Die aktuelle Boxengeneration ist schon das, was damals unter dem Namen "Goliath" angekündigt wurde.


    Nur gab's da ein paar mehr gewollte, aber auch völlig ungewollte Hardwareiterationen.


    Der Hersteller des ursprünglich geplanten SoCs hat damals, quasi über Nacht, seine "Smartphone SoC" Sparte eingestampft.

    Wir waren dadurch über Nacht wieder mehr oder weniger auf 0.


    Genau deshalb gab es dann doch nochmal einige Boxen mit Broadcom SoC wie z.B. die DM9x0 (und die restlichen im neueren Design).


    Bei der one haben wir uns, obwohl schon quasi produktionsreif, recht kurzfrisitig entschieden direkt auf den jetzt verbauten AmLogic S922 statt des ursprünglichen S905 zu setzen.

    Bei der two kam Corona und jeder Zeitplan war völlig ad absurdum geführt.


    Wir können, wollen und werden aber während der Entwicklungsphasen nicht erklären was passiert und/oder warum.

    Wer beruflich mit Hardwareentwicklung zu tun hat wird solche Probleme aber kennen.

    Wer schon in Crowdfunding von Hardware involviert war ist vermutlich ebenfalls hinreichend leidgeplagt von Verzögerungen aufgrund "noch einer neuen Hardwarerevision".


    Natürlich "war das alles doof" und wir hätten uns das irgendwie auch anders vorgestellt.

    Aber es kam halt so.

    Wir selbst sind mittlerweile sehr erprobt mit solchen Dingen umzugehen.


    Der Vorteil an der Platform one/two/seven ist, dass wir nun auch mal den SoC wechseln könnten ohne dass "alles" neu gemacht werden muss.



    HINWEIS: Bitte nehmt dieses Posting nicht zum Anlass irgendwelche Ansprüche abzuleiten über was wir Zukünftig in Informieren werden oder nicht.

    Ich dachte nur, der Eine oder Andere könnte es ganz Interessant finden was da hinter den Kulissen grob los war.

    Es ist alles längst geschehen und deshalb auch kein großes Geheimnis mehr.