TTD Forum

Hi!

Wie sich bei Tests vom SmartSkipper gezeigt hat, gibt der Topfield in einigen Situationen (Endschnitt einer Wiedergabe aus einem Unterordner) zurück, dass er sich im Playmode befindet (im speziellen Fall im Playmode Timeshift) und dass bei einer zurückgemeldeten Gesamtblockgrösse von 0. Dadurch kommt es natürlich in vielen TAPs schnell dazu, dass eine Division durch "0" erfolgt, wodurch der Topfield abstürzt.

Nun gibt es viele Wege, diesen Zustand abzufangen um den Absturz zu vermeiden.
Da dieser Zustand wohl nur während eines Endschnitts auftritt und dort auch weniger als eine Sekunde dauert, habe ich mich in ImproBox dazu entschlossen, einfach "nichts" zu machen, wenn dieser Zustand eintritt.

Die Lösung (wohl die einfachste, wenn man sein TAP in dieser Situation ruhig mal 1 Sekunde pausieren lassen kann) müsste folgende Codezeile am Anfang (vor allen dort stehenden Anweisungen) von TAP_EventHandler( word event, dword param1, dword param2 ) sein:
Sollte jetzt der Fall auftreten, dass ein Playmode mit 0 Blöcken gemeldet wird, so macht das TAP gar nichts.
Wie gesagt, es gibt zig andere Lösungen...das hier ist halt meine...

Gruß,
Gerti

Hat TAP_GetPlayInfo eigentlich nur auf dem 5800 eine Macke?

http://www.toppy.org.uk/forum/viewtopic ... 5844#45844

You've found the 2 most common API bugs in one fell swoop:
1. a buffer overrun in TAP_Get_PlayInfo (also occurs in TAP_Get_RecInfo) that's overwriting your stack
2. the 512 file length bug

Use libutils (source at tap.berlios.de) and include tapapifix.h in all your files. This will put safe wrappers around all your calls to offending functions.

It's worth looking at the Topfield Developers Wiki, we're trying to document the APIand it's quirks. If you find any more please document them!

http://toppy.xwiki.com/

Hier der Workarround: http://svn.berlios.de/wsvn/tap/trunk/li ... rev=0&sc=0

Harvey hat geschrieben:Hat TAP_GetPlayInfo eigentlich nur auf dem 5800 eine Macke?

Nein, alle Modelle/FW-Versionen sind davon betroffen. Es passiert nur eben nicht bei jedem Sender bzw. jeder Sendung. Ich habe den Eindruck, daß es etwas mit Sendungen zu tun hat, bei denen die Info-Strings die zulässige Länge in der API-Struktur überschreiten. Da die FW mit strcopy() und nicht mit strncopy() die Strings aus einem internen Puffer in die API-Struktur kopiert, kann es bei Stringlängen > 128 zu unerwünschten Nebeneffekten kommen. Warum das Problem auch bei TAP_GetRecInfo() beobachtet werden kann, ist mir unklar (selber habe ich es noch nie erlebt).

Hehe - das könnte man mit nem Firmwarepätsch selbst bereinigen, falls an geeigneter Stelle ein nop für a2=Länge übrig ist (nein, ich suche jetzt nicht).

Aber jetzt wo Du es schreibst fällt mir ein: Das war nicht das erste mal, oder? Sorry.