API-Calls nur im Idle ausführen

[Gerti]

Hi!

Ich möchte an dieser Stelle einen wichtigen Hinweis an alle TAP-Entwickler loswerden. Die Firmware der der Masterpiece-Geräte (sowie der englischen Topfields) sind extrem empfindlich, wenn API-Calls direkt durch Keyevents ausgelöst werden. Hierbei kommt es bei besagten Geräten idR. zu einem ungewollten Reboot der Geräte.

Um dieses zu verhindern, sollte dafür Sorge getragen werden, dass API-Calls nur im Idle-Event ausgeführt werden und nicht schon direkt bei der Auswertung des Key-Events.

Gruß,
Gerti

[Erdnussnase]

[eber]

Vielleicht hilft folgender Code das Problem relativ einfach zu umgehen:

static word GlobalLastEvent=0;
static word GlobalLastParam1=0;
static word GlobalLastParam2=0;
static bool GlobalLastProcess=FALSE;

extern dword TAP_EventHandler( word event, dword param1, dword param2 ){

if (event!= EVT_IDLE ){
//Notiere das Nicht-Idle-Event
GlobalLastEvent=event;
GlobalLastParam1=param1;
GlobalLastParam2=param2;
GlobalLastProcess=TRUE;
return param1;
}
//Hier muß es ein EVT_IDLE sein
if (GlobalLastProcess){
//es ist noch ein altes Event da, das statt dem Idle-Event verarbeitet werden muß
event=GlobalLastEvent;
param1=GlobalLastParam1;
param2=GlobalLastParam2;
GlobalLastProcess=FALSE;
}

//ab hier der "alte" Code
}

Spinnen die bei Topfield z.Zt. mal wieder - was soll den das?

[The Specialist]

Das obige Code-Snippet kann aber dazu führen, das Events verloren gehen, oder? Korrekterweise müsste man die Nicht-Idle-Events wohl in eine Queue packen, die dann im Idle-Fall abgearbeitet wird...

[eber]

Das obige Code-Snippet kann aber dazu führen, das Events verloren gehen, oder? Korrekterweise müsste man die Nicht-Idle-Events wohl in eine Queue packen, die dann im Idle-Fall abgearbeitet wird...

Korrekt - wobei man es normalerweise nicht schafft, zwei Key-Events schnell genug hintereinander auszulösen, ohne das ein Idle-Event dazwischen rutscht. Besser wäre allerdings ein kleiner Event-Puffer.
Außerdem hat die Lösung den Nachteil, das man bei Key-Events keine abweichende Taste (oder überhaupt einen Wert) an das nachfolgende Tap weiterreichen kann.
Oops - da muß ich gleich noch eine kleiner Änderung einbauen sonst frißt der obige Code alle KeyEvents und reicht diese nie weiter.
Das wird vermutlich doch etwas verzwickter da man manchmal die Taste ja auch nicht weiterreichen möchte (wenn sie vom Tap selbst verarbeitet wurde) - oh je oh je

Grüße

Eber

[bubendorf]

Das obige Code-Snippet kann aber dazu führen, das Events verloren gehen, oder? Korrekterweise müsste man die Nicht-Idle-Events wohl in eine Queue packen, die dann im Idle-Fall abgearbeitet wird...

Das mit der Queue wäre wohl die sauberste Lösung. Zur Not kann man auch das erste if (...) durch
if (event!= EVT_IDLE && GlobalLastProcess==FALSE)
ersetzen. Dann wird wenigstens das erste Event ausgeführt und nicht das letzte.

Gruss
Bubendorf

[jk]

na da freu ich mich doch schon auf die nächte version für die 5er serie, da wird dann das große codeändern in den taps beginnen

[eber]

Meiner Meinung nach muß Topfield da etwas unternehmen den sie verstossen eindeutig gegen ihre eigene Tap-Spezifikation und irgendwie kann es nicht sein das nun jeder Tap-Programmierer mühsam einen Workaround basteln muß. Vor lauter Workarounds blickt man bald nicht mehr durch
Vor allem stellt sich die Frage wie man als Entwickler der normalerweise nur einen Topf zum Entwickeln hat die Lauffähigkeit auf anderen Modellen überhaupt noch testen soll.
Bereits der Masterpiece hatte ja schon einige gravierende Abweichungen im API
Schließlich verkauft Topfield durch die Taps mit Sicherheit mehr und nicht weniger Geräte - die Topfield-eigenen Neuerungen sind dagegen recht überschaubar.

Grüße

Eber

[thensch]

Schließlich verkauft Topfield durch die Taps mit Sicherheit mehr und nicht weniger Geräte - die Topfield-eigenen Neuerungen sind dagegen recht überschaubar.

Ich frage mich nur immer wieder, ob denen das eigentlich klar ist.

[eber]

Bestimmt nicht, denn dann wäre der Support für Tap-Entwickler vielleicht etwas besser. Ich will mich ja auch nicht beklagen, denn gelegentlich gab es ja Fortschritte was den Umfang des APIs anbelangt. Und eigentlich fehlen auch nur noch ganz wenige Funktionen (File-Move, Abfrage des gerade aktiven Tuners, Zugriff auf die Videotext-Daten und evt. noch auf die Schnittfunktionen) zum vollständige Glück.
Aber das man jetzt nur noch in Idle-Phasen auf API-Funktionen zugreifen darf ist irgendwo Willkür und wäre sicherlich für Topfield leicht behebbar.

Es macht einfach keinen Spaß, wenn man von außen versuchen muß, die Fehler im API zu umgehen. Wenn das so weiter geht muss man zukünftig als TAP-Entwickler verschiedenste Firmware-Varianten berücksichtigen und das kann man als Privatperson irgendwann nicht mehr leisten und vor allem nicht mehr testen.
Wie bereits schon mal geschrieben bin ich der Meinung, das ein Topfield-Entwickler hier (in einem speziellen und natürlich englischem) Thread mitlesen sollte. Ich denke das man dann vieles wesentlich einfacher und vor allem schneller lösen könnte. Viele Fehler im API verursachen u.U. ja auch Fehler in der normalen Firmware und somit wäre es auch für Topfield sinnvoll, hier mitzulesen.
Aber es scheint irgendwie aussichtslos....

Grüße

Eber

[Gerti]

Hi!

Wie gesagt, handelt es sich hierbei um eine Beobachtung von mir und nicht um eine Aussage von Topfield. Nur um das klarzustellen...

Gruß,
Gerti

[mastercb]

Ich finde das --sorry-- echt eine Sauerei, wie Topfield mit Euch TAP-Programmierern umgeht.

Ihr schreibt die TAP's, die sicher für viele Leute ein Argument sind, sich überhaupt einen Topf zu kaufen und dann machen Die Euch noch soviel unnütze Arbeit

Vieleicht wäre es eine gute Strategie, einfach die "neueren" Topf Modelle (welche Euch immer wieder Schwierigkeiten machen) in den TAP's BEWUßT nicht zu unterstützen. Vielleicht merkt dann endlich Topfield, was sie von Euch haben und ob es vielleicht gut für Geschäft wäre, endlich die Hauseigenen API-Specs einzuhalten.

Letztes Beispiel für die Ignoranz von Topfield ist ja die FW Sept05.

[eber]

Schon klar - aber es reicht ja eigentlich schon aus wenn Taps die sich an alle Vorgaben halten unter bestimmten (neueren) Firmware-Varianten plötzlich nicht mehr lauffähig sind. Und das ist ja hier ziemlich sicher der Fall. Das Topfield die Ursachen nicht dokumentiert macht die Sache eher noch schlimmer....
Eigentlich erwarte ich schon, das jedes neue API abwärtskompatibel ist.

Es wird uns aber erfahrungsgemäß trotzdem nichts anderes übrig bleiben, als selbst um diese Besonderheit herumzuprogrammieren. Nur Spaß macht das nicht

Grüße

Eber

[buko]

Bereits der Masterpiece hatte ja schon einige gravierende Abweichungen im API
Schließlich verkauft Topfield durch die Taps mit Sicherheit mehr und nicht weniger Geräte - die Topfield-eigenen Neuerungen sind dagegen recht überschaubar.

Grüße

Eber

...wie wahr..!!.

gruss buko

[Happy]

Hi,
das ist ja echt ne Frechheit
Hauptsache die TAP-Programmierer sind beschäftigt.

Gibts denn spezielle Sachen, die gerne schief gehen? Hat evtl jemand Links zu Threads in andere Boards, wo das besprochen wird ? Damit ich weiss wo ich aktiv werden muss. Automove betreffend habe ich aus UK noch nichts diesbezüglich gehört :

Gruß,
Happy

[Gerti]

Hi!

Das lässt sich nicht an besonderen Dingen festmachen...
Ich hatte das Problem mehrfach mit ImproBox (auf unseren Toppis keine Probleme, auf den UK-Toppis kam es zu reboots).
Nachdem ich die API-Calls dann aus dem Key-Event entfernt (dort habe ich dann z.B. nur Jump=1 gesetzt) entfernt und in den IDLE-Bereich verschoben hatte, waren den Fehler in UK beseitigt.
Da ich z.Zt. ja einen 6000 zum testen habe, habe ich natürlich auch einige TAPs getestet und ImproBox läuft absolut stabil (weil es im Prinzip schon fast alle API-Calls so behandelt), SmartEPG hingegen bringt den Topfield alle paar "Aktionen" zu einem reboot. Daher vermute ich halt, dass es an den API-Calls ausserhalb der Idle-Events liegt (weil ich damit die selben Probleme mit ImproBox beheben konnte). Eine 100% Garantie kann ich natürlich nicht geben...Schaden kann es aber auf keinen Fall...
Falls Eber SmartEPG in Kürze so umgestellt haben sollte, kann ich genaueres dazu sagen...

Solche Dinge wie die Abfrage vom Aufnahme/Wiedergabestatus, etc. mache ich auch ausserhalb der Idle-Events. Sprünge, etc. mache ich aber nur mehr in den Idle-Events.

Gruß,
Gerti

[Acade]

Das wäre jetzt nach http://board.topfield.de/viewtopic.php?p=185397 schon wieder so ein Hammer! Wozu eigentlich überhaupt noch neue FW unterstützen, wenn man sich auf das API nicht mehr verlassen kann? Dann gibt's halt für neue Geräte keine TAPs mehr (wenn sie nicht auch mit einer alten FW laufen). Es artet immer mehr in eine riesige Zeitverschwendung aus ...

Sauer,
Acade

[Happy]

@Gerti,
danke für die Ausführungen. Wie sieht es denn mit der Navigation in einem Menü aus. Das wäre bei meinen TAPs etwas typisches, wo eine Taste direkt das Neuzeichnen des OSD verursacht. Muss man das auch umschreiben?

Gruß,
Happy

[Gerti]

Hi!

Da Dein TAP ja nur auf dem 5500 läuft und dort keine Probleme dieser Art auftreten, brauchst Du Dir da wohl keine Gedanken machen...

Wie gesagt, wäre wohl abzuwarten, ob SmartEPG durch besagte Änderungen stabil auf dem 6000 laufen würde.

Gruß,
Gerti

[eber]

Mein Problem bei der Anpassung ist folgendes:
Die eigentliche Verarbeitung eines Key-Events in das nächste Idle-Event zu verlagern ist recht einfach machbar. Die Änderungen beschränken sich auf TAP_EventHandler und damit könnte ich leben.

ABER:

Wenn ein Key-Event ankommt muß ich bereits entscheiden, ob ich die Taste weiterreiche (an das nächste Tap) oder nicht. Für diese Entscheidung darf ich aber auf dem TF6000 keine API-Funktionen benutzen (es läuft ja noch ein Key-Event) und auf später verschieben geht auch nicht.

Dieses Problem läßt sich nicht nach Schema F lösen und erfordert (zumindest bei Smartepg) größere Eingriffe an verschiedensten Stellen im Code.
Ohne entsprechendes Testequiment ist mir das momentan zu zeitraubend

Auch tut sich Topfield meiner Meinung nach selbst keinen Gefallen (von Taps mal ganz abgesehen) wenn die einzelnen Firmware-Versionen immer weiter auseinander driften. Schließlich wirken sich solche Effekte ziemlich sicher nicht nur im API sondern auch in den firmware-eigenen Routinen aus.
Und es macht auch wenig Sinn wenn man statt Ursachen die Symptome beseitigt.
Eigentlich müßte Topfield selbst das größte Interesse an einem einheitlichen API für alle Modelle haben.
Daher bin ich weiter der Meinung das wir wieder an einer besseren Connection zu den Entwicklern in Korea arbeiten sollten.

Grüße

Eber