API-Unterschiede TF5k - TMS

[Erdnussnase]

Der Aufruf von TAP_Osd_Sync() sollte nur erfolgen wenn wirklich etwas neu gemalt wurde. Die Funktion neigt bei unnötig häufigem Aufruf dazu den Topf in einen ca. 10 Sekunden dauernden Tiefschlaf zu versetzen.

[xyzzyx]

Ich habe etwas ähnliches. Die Verwendung des Namens
Keyboard_Init(...)
für eine Routine wird vom Compiler/Linker nicht angemeckert. Bei der Ausführung wird jedoch nicht die eigene Keyboard_Init angesprungen, sondern man landet in den Tiefen des TMS aus denen man (meist) dummerweise wieder herauskommt als sei nichts gewesen.

Ich habe mir daher eine blacklist.h gebaut die derzeit folgendermaßen aussieht.

Code: Alles auswählen

#ifndef _BLACKLIST_H_
#define _BLACKLIST_H_

#define wait                    <Do not use this name>
#define Keyboard_Init           <Do not use this name>

#endif

Habe mit John De Angelis rausgefunden, dass auf dem 2400er Modell auch die Funktion Initialize schon intern genutzt wird und man diesen Namen nicht verwenden darf.

Somit siehts jetzt so aus:

Code: Alles auswählen

#ifndef _BLACKLIST_H_
#define _BLACKLIST_H_

#define wait                    <Do not use this name>
#define Keyboard_Init           <Do not use this name>
#define Initialize              <Do not use this name>

#endif

[Indy]

[quote="Erdnussnase"]Der Aufruf von TAP_Osd_Sync() sollte nur erfolgen wenn wirklich etwas neu gemalt wurde. Die Funktion neigt bei unnötig häufigem Aufruf dazu den Topf in einen ca. 10 Sekunden dauernden Tiefschlaf zu versetzen.[/quote]

TAP_Osd_Sync() hatte ich in meine exit/clean-up Routine. Das TAP beendete sich ohne Probleme, wenn es manuell gestoppt wurde, aber der TMS stürzte ab sobald die Gelbe Taste oder Wiedergabe vor-/rückwärts gedrückt wurde. Das gleiche passiert mit TAP_EnterNormal(). Die beide Methode habe ich aus mein exit Routine entfernt und jetzt habe ich das reboot Problem nicht mehr.

[flechumer]

Hier ein Unterschied zum TF5/6k, der auf die unterschiedliche Prozessorarchitektur zurückgeht. Der folgende Code-Schnipsel

Code: Alles auswählen

{
	dword d = 0x12345678;

	TAP_SPrint( text, " Test %08x -> %02x %02x %02x %02x  %04x %04x", d,
		((byte*)&d)[0], ((byte*)&d)[1], ((byte*)&d)[2], ((byte*)&d)[3],
		((word*)&d)[0], ((word*)&d)[1] );
	TAP_Osd_PutString( 0, 80, 120, 639, text, COLOR_Gray, COLOR_Black, 0, FNT_Size_1926, 0);
	TAP_Osd_Sync();
}

liefert folgende Ausgabe:

Code: Alles auswählen

 Test 12345678 -> 78 56 34 12  5678 1234

Mit anderen Worten: Zahlen werden in absteigender Adressrichtung gespeichert. Das hat natürlich weitreichende Konsequenzen - man denke nur an die Darstellung von Datum und Uhrzeit in einem dword.

Erstaunlich, daß das hier noch nicht thematisiert wurde.

Nochwas ist mir aufgefallen: Bei der Abspeicherung von Textdateien, die auf CR, LF enden, wird ein VT angehängt und hinter dem Text mit Blanks aufgefüllt. Das VT fand ich einigermaßen hinterlistig , das Auffüllen aber komfortabel :.

[flechumer]

Nochwas ist mir aufgefallen: Bei der Abspeicherung von Textdateien, die auf CR, LF enden, wird ein VT angehängt und hinter dem Text mit Blanks aufgefüllt. Das VT fand ich einigermaßen hinterlistig , das Auffüllen aber komfortabel :.

Das hat sich jetzt als trickreicher Folgefehler herausgestellt. Das eigentliche Problem war die Benutzung einer Text-Variablen mit Namen "error" (nomen est omen). Vor diesem Namen sei gewarnt. Ihm werden - von wem auch immer - Werte zugewiesen.

[flechumer]

Ein weiteres Problem: Bei Timeshift-Recording wird der CurrentEvent des Wiedergabe- nicht des Aufnahmezeitpunkts erfaßt. Vielleicht soll das ja so sein.

[flechumer]

Jetzt wieder ein Unterschied:

Wollte man früher wissen, ob Timeshift gerade aktiv ist, mußte man die beiden Slots 0 und 1 abfragen und auf recType == RECTYPE_Timeshift testen. Beim TMS ist der Slot 2 für TS vorgesehen.

If one needs to know if time shift is active on a TF5k, it was necessary to check slots 0 and 1 and test for recType == RECTYPE_Timeshift. On the TMS, slot 2 is reserved for the TS details.

Code: Alles auswählen

TYPE_RecInfo          RecInfo;

TAP_Hdd_GetRecInfo(2, &RecInfo);
if(RecInfo.recType == RECTYPE_Timeshift)
{
  ?
}

Die Abfrage genügt leider nicht. Startet man zuerst eine Aufnahme und geht dann in den Timeshift, wird RECTYPE_None für Slot 2 angezeigt. Im zur Aufnahme gehörenden Slot 0 wird dagegen RECTYPE_Normal angezeigt. Nur der Playmode wird korrekt mit PLAYMODE_RecPlaying angezeigt.

[flechumer]

Nachtrag: Wird aus dem Timeshift eine Aufnahme gestartet, wird im zugehörigen Slot 0 RECTYPE_Copy angezeigt.

[FireBird]

Nachdem ich immer wieder gefragt werde, was sich in der .inf versteckt, habe ich begonnen, die Struktur zusammenzufassen.

Code: Alles auswählen

 typedef struct
{
  tRecInfHeader         RecInfHeader;       //Offset = 0x0000
  tRecInfServiceInfo    RecInfServiceInfo;  //         0x001c
  tRecInfEventInfo      RecInfEventInfo;    //         0x0044
  tRecInfExtEventInfo   RecInfExtEventInfo; //         0x0168
  tRecInfTPInfo         RecInfTPInfo;       //         0x0574
  tRecInfBookmarks      RecInfBookmarks;    //         0x0584
  byte                  filler[8192];       //         0x0850: reserved space
  tPreviewImages        PreviewImages;      //         0x2850: Preview images
} tRecInf;

typedef struct
{
  char                  Magic[4];           //"TFrc"
  word                  Version;            //0x8000
  byte                  Unknown1[2];        //possibly an unused filler
  dword                 StartTime;          //start of the recording
  word                  DurationMin;
  word                  DurationSec;
  byte                  CryptFlag;          //0=FTA, 1=scrambled, 2=descrambled, 3=partly scrambled

  byte                  FlagUnused:5;
  byte                  FlagUnknown:1;
  byte                  FlagTimeShift:1;    //This is a TimeShift file
  byte                  FlagCopy:1;         //This is a copy (C icon)

  byte                  Unknown2[10];       //Reserved for future use?
} tRecInfHeader;  //28 bytes

typedef struct
{
  byte                  SatIndex;
  byte                  ServiceType;

  word                  TPIndex:10;
  word                  FlagTuner:2;
  word                  FlagSkip:1;
  word                  FlagLock:1;
  word                  FlagCAS:1;
  word                  FlagDel:1;

  word                  ServiceID;
  word                  PMTPID;
  word                  PCRPID;
  word                  VideoPID;
  word                  AudioPID;
  char                  ServiceName[24];
  byte                  VideoStreamType;    //see tap.h for possible video and audio stream types
  byte                  AudioStreamType;
} tRecInfServiceInfo; //40 bytes

typedef struct
{
  byte                  Unknown1[2];
  byte                  DurationMin;        //Duration of the event
  byte                  DurationHour;
  dword                 EventID;
  dword                 StartTime;          //Event times
  dword                 EndTime;
  byte                  RunningStatus;
  byte                  EventNameLength;
  byte                  ParentalRate;
  char                  EventNameAndDescription[273];
} tRecInfEventInfo; //292 bytes

typedef struct
{
  word                  ServiceID;
  word                  TextLength;
  dword                 EventID;
  char                  Text[1024];
  byte                  NrItemizedPairs;
  byte                  unknown[3];
} tRecInfExtEventInfo; //1036 bytes

typedef struct
{
  dword                 SatIndex:8;
  dword                 Polarization:1;     //0=vert, 1=hor
  dword                 Mode:3;
  dword                 ModSystem:1;        //see tap.h
  dword                 ModType:2;          //see tap.h
  dword                 FEC:4;              //see tap.h
  dword                 Pilot:1;
  dword                 UnusedFlags1:4;
  dword                 Unknown2:8;

  dword                 Frequency;
  word                  SymbolRate;
  word                  TSID;

  word                  ClockSync:1;
  word                  UnusedFlags2:15;

  word                  OriginalNetworkID;
} tRecInfTPInfo; //16 bytes

typedef struct
{
  dword                 NrBookmarks;
  dword                 BookmarkPosition[177];
  dword                 Resume;      //in blocks (1 block = 9024 bytes = LeastCommonMultiple(188, 192))
} tRecInfBookmarks; //716 bytes 

typedef struct
{
  word                  NrOfImages;         //Check if the inf file size is at least 10322 bytes to
                                            //  make sure that NrOfImages is valid
  word                  unknown1;             
  dword                 unknown2;
  dword                 unknown3;
  dword                 PixelData1[196*156];  //ARGB
  dword                 unknown4;
  dword                 unknown5;
  dword                 PixelData2[196*156];  //ARGB
  dword                 unknown6;
  dword                 unknown7;
  dword                 PixelData3[196*156];  //ARGB
  dword                 unknown8;
  dword                 unknown9;
  dword                 PixelData4[196*156];  //ARGB
} tPreviewImages;

Manche TAPs fügen Information zur .inf hinzu. Folgende sind derzeit bekannt:

RecInfHeader.Unknown1[0] (Byte-Offset 7):

Bit 0: RebuildNAV: Datei wurde gescannt
Bit 1: RebuildNAV: Datei muss nicht gescannt werden (gesetzt durch IQTuner im QuickMode)
Bit 2: RecStripper: rec wurde gestrippt
Bit 3: RecStripper: rec zum Strippen vorgesehen
Bit 4: RecStripper: Strippen wegen verschlüsselter Pakete abgebrochen

SmartFiler hängt bei Bedarf einen 2kB großen Datenblock am Ende der .inf an.

Code: Alles auswählen

typedef struct
{
  char  Magic[4];           //0 = "SFIB"
  byte  Version;            //4 = 1
  byte  Filler1;            //5
  word  Duration;           //6
  dword LastBlock;          //8
  bool  Seen;               //12
  dword RecycleDate;        //16
  char  RecoverPath[512];   //20
  byte  Filler2[1516];      //532
                            //2048
}tinfBlock;

----------------------------------------------------------------------------------------
chris86:

- MovieCutter tobt sich im Bookmarks-Bereich aus
- INFplus hängt ebenfalls einen Datenblock ans Ende der inf an
----------------------------------------------------------------------------------------
DeltaMikeCharlie:

Under normal conditions, INFplus does not add any data to the INF file, but it does create a hard link to the INF file.

The user can manually prepare a recording for archive to another medium or configure INFplus to do this automatically when the recording ends, but this is disabled by default.

If a recording is prepared for archive, INFplus will add the entire INF+ file contents to the INF file using the FireBirdLib function infData_Set() with "INF+ARCHIVE" as the NameTag value.

[flechumer]

Wenn ich das richtig sehe, gibt es wohl keinen Fehlermeldungsthread im SRP-Bereich. Deshalb bringe ich das mal hier unter, wobei ich mir nicht ganz sicher bin ob es nicht schon mal irgendwo gemeldet wurde:

Im Timeshift oder Playback liefert weder TAP_GetCurrentEvent noch TAP_GetEvent mit runningStatus == 4 korrekte Ergebnisse. Das gilt für die aktuelle FW ebenso wie für die letzte Beta-FW.

[FireBird]

Nachdem ich gerade danach gesucht habe: manche Geräte unterstützen bis zu vier gleichzeitige Aufnahmen. Das bedeutet, dass der SlotIndex von TAP_Hdd_GetRecInfo() von 0 bis 3 läuft und 4 für Timeshift reserviert ist.

Aktuell sind die folgenden Geräte bekannt (inkl AUS):

SRP-2401CI+ (22120)
SRP-2410 (22121)
SRP-2410M (22122)
TF-7100HDPlus (32030)
TRF-7160 (33021)
TRF-2400 Masterpiece HD (32020)
TRF-2460 Masterpiece HD Plus (32026)

[FireBird]

Beim 5k konnte man im TAP_EventHandler durch die Rückgabe von 0 die Weitergabe von Events blocken. Bei einem Wert ungleich 0 wurde der Event an das nächste TAP oder die Firmware weitergereicht. Es war jedoch nicht möglich, z.B. den Tastenwert (param1) zu verändern.

Beim TMS ist es jedoch so, dass der Rückgabewert des TAP_EventHandler bei Key-Events zum param1 für das nächste TAP wird. Also Vorsicht, da ein TAP sonst gleich den halben Topf lahmlegen kann.

[xyzzyx]

Code: Alles auswählen

#ifndef _BLACKLIST_H_
#define _BLACKLIST_H_

#define wait                    <Do not use this name>
#define Keyboard_Init           <Do not use this name>
#define Initialize              <Do not use this name>
#define idcnt                   <Do not use this name>

#endif

Der Variablenname idcnt verursacht bei mir das Phänomen, dass er (als byte definiert) irgendwie sehr eigenartig dazu beitrug, dass drei andere Byte-Variablen auf 0 gesetzt wurden, wenn sein Wert geändert wurde. D.h. er ist evtl. anderswo schon als dword definiert.
Kaum geändert, nur dass ich statt idcnt dann idscnt verwendete, wurden die anderen drei byte-Variablen nicht mehr gelöscht.

[xyzzyx]

Wieder eine interessante Fehlerquelle entdeckt:
Wenn man char-Arrays zu klein definiert und ein größerer String als die mögliche Länge reingeschrieben wird, so werden knallhart die benachbart definierten anderen Variablen überschrieben.

Des Weiteren:
- bei strcpy wird das \0 Stringbegrenzungszeichen mit in den neuen String übernommen
- bei strncpy wird es beim kopieren eines kürzeren Strings als die bisherige Länge nicht automatisch angefügt, d.h. man muss es selbst anhängen

[Gerti]

Hi!

Um den Dateinamen einer laufenden Aufnahme zu ermitteln, die zeitversetzt geschaut wird, ist playinfo.file->name nicht geeignet.

Der Dateiname einer laufenden Aufnahme kann sich während der Aufnahme ändern. Das passiert z.B. dann, wenn eine Sofortaufnahme gestartet wird und sich im Laufe der Aufnahme die Sendung ändert. Nach einer gewissen Zeit erhält die laufende Aufnahme dann den Namen der aktuellen Sendung.
In playinfo.file->name ist dann jedoch nach wie vor den ursprüngliche Name der Aufnahme zu finden.

Fragt man hingegen recinfo.fileName ab, so beinhaltet dieses immer den korrekten Namen der Aufnahme.

Gruß,
Gerti

[flechumer]

Fragt man hingegen myrecinfo.fileName ab, so beinhaltet dieses immer den korrekten Namen der Aufnahme.

Was bitte ist "myrecinfo"? Die Suche ergibt keine Treffer.

[Gerti]

Hi!

Du kannst es auch recinfo nennen...
Bei mir in den TAPs heissen die immer myplayinfo und myrecinfo...
Es geht halt nur darum, die Info aus den RecInfos und nicht den PlayInfos auszulesen.

Gruß,
Gerti

[xyzzyx]

Ein API-Bug:

void* TAP_Osd_DecompressJpeg(const char* fileName, dword w, dword h, dword option);
#define JPEG_OPTION_KEEP_RATIO 0x20

Unter bestimmten Bedingungen (abhängig von JPG-Datei, deren Auflösung und dem eigenen Code) führt TAP_Osd_DecompressJpeg scheinbar intern zu einer Endlosschleife (oder manchmal dann bei TAP_Osd_Sync), obwohl w und h genau der Auflösung des JPEGs entsprachen.
Da half es bei mir, dass ich den Parameter option von JPEG_OPTION_KEEP_RATIO auf 0 geändert habe.
Dann gab es keine Endlos-Schleife mehr.
Und das war für mich reproduzierbar. Nur als einziges die option geändert und schon gab es bei diesem jpg dann eine Endlos-Schleife oder eben keine.

Vielleicht möchte ja jemand die Firmware entschlüsseln und nachschauen warum.
Oder die Koreaner könnten eine Korrektur nachschieben.
Aber das einfachste ist wohl, dass man 0 statt JPEG_OPTION_KEEP_RATIO verwendet.

[xyzzyx]

Noch ein API-Definitions-Fehler:

In der key.h steht:

Code: Alles auswählen

#define KEY_Flag_Click    0x40000000
#define KEY_Flag_Push     0x20000000

Aber es müsste lauten:

Code: Alles auswählen

#define Keyflag_Click	  0x02000000 //wrong definition in key.h
#define Keyflag_Push	  0x01000000 //wrong definition in key.h

[FireBird]

Ich versuche hier ein paar Regeln mit dem Umgang mit einer UTF8-Firmware zusammenzufassen. Auch wenn es auf den ersten Blick einfach aussieht, steckt der Teufel im Detail und man endet in einer zeitaufwendigen Trial-and-Error-Bastelei. So mir weitere Punkt auffallen, erweitere ich die Liste. Bitte auch um das Feedback anderer TAP-Programmierer.


ANSI vs. UTF

Eine UTF8-Firmware unterstützt beide Varianten, setzt jedoch voraus, dass ein ANSI-Text mit Umlauten mit einem Codepage-Zeichen (in unserem Fall das 0x05) beginnt, da sie sonst versucht, den Text als UTF8-Text zu interpretieren. Da diese Codepage-Zeichen aber Probleme beim Übertragen von Aufnahmen macht, werden sie schon seit Ewigkeiten von div. TAPs entfernt. Da diese Vorgehensweise auch weiterhin sinnvoll ist, bleibt nichts anderes übrig, als neue Timer-Namen, Dateinamen usw. im UTF8-Format anzulegen.


UTF8 und die TAP-API

Namen werden nicht konvertiert, sondern 1:1 durchgereicht. Durch den Mischbetrieb von ANSI- und UTF-Texten ist somit nicht vorhersagbar, in welcher Form ein String geliefert. Solange man sich innerhalb des TAP-APIs aufhält, ist die Information auch nicht wichtig, da auch die TAP_Osd-Funktionen mit beiden Formaten umgehen können.


UTF8 und die FBLib

Die FireBirdLib liefert einerseits einige Funktionen, die das Arbeiten mit UTF-Texten vereinfacht, die OSD-Ausgaben der TMS OSD Menu-Funktionen können weiterhin nur mit ANSI-Texten umgehen. Daher muss vor den Ausgaben zwingend in ANSI umgewandelt werden. Gleiches gilt auch für Log- oder Telnet-Ausgaben.

Folgende Funktionen stehen zur Verfügung:

* bool isUTFToppy(void);

Prüft, ob das TAP auf einem Topf mit UTF-Firmware läuft.


* void GetStringEncoding(char *Text, bool *hasAnsiChars, bool *hasUTFChars);

Liefert die Information, ob ein String ANSI- oder UTF-Zeichen enthält. Sind beide Rückgabewerte TRUE, ist der Text unter Umständen schon beschädigt und sollte nicht weiter bearbeitet werden.


* void StrToUTF8(byte *SourceString, byte *DestString);

Konvertiert einen ANSI-String in einen UTF8-String. Eine Prüfung mittels GetStringEncoding() wird von dieser Funktion durchgeführt, eine Konvertierung erfolgt nur bei reinen ANSI-Texten. Wird ein UTF8-Text übergeben, wird dieser von StrToUTF8() nur ins Ziel umkopiert. Ob die Konvertierung überhaupt notwendig ist, muss das TAP mittels isUTFToppy() selbst feststellen.


* bool StrMkUTF8(byte *SourceString);

Wie oben, nur dass hier SourceString direkt in UTF8 umgewandelt wird.


* void StrToISO(byte *SourceString, byte *DestString);

Wie oben, jedoch von UTF8 auf ANSI. Diese Funktion kann ohne isUTFToppy()-Prüfung aufgerufen werden, da eine Konvertierung nur dann erfolgt, wenn auch ein UTF-Text übergeben wurde.


* bool StrMkISO(byte *SourceString);

Wie oben.


Probleme mit früheren Lösungen

* MakeValidFileName(chInfo.chName, ControlChars | LFChars);

Diese Funktion wird gerne zum Bereinigen von Texten, vor allem vom Codepage-Zeichen, verwendet. Sie sollte nicht mehr verwendet werden, da sie auch Zeichen entfernt, die Bestandteil von 2-Byte-UTF-Zeichen sein können. Zum Entfernen vom Steuerzeichen am Anfang des Textes kann man z.B. die folgende Sequenz verwenden:

if(chInfo.chName[0] && chInfo.chName[0] < ' ') DeleteAt(chInfo.chName, 0, 1);


UTF8 und die Linux Shell

TBD



To be fortgesetzt...