API-Unterschiede TF5k - TMS - Kommentare

[BluField62]

dein Problem bezieht sich auf eine Firmwareroutine, meine Bemerkung auf eine Änderung der API, die eine Fehlfunktion in einem TAP zur Folge hat, die mit dieser fehlenden Info zu lösen sind.....

Danke dir, auch wenn ich das mit der FW Routine nicht verstanden habe

[FireBird]

Ich stelle mal einen Punkt zur Diskussion, da er viele TAP-Programmierer betrifft. Es handelt sich nicht um einen Unterschied zwischen 5k und TMS, sondern um Australien und Europa.

John De Angelis hat mir erzählt, daß die Australischen Töpfe seit einem Firmware-Update vor einiger Zeit nicht mehr .rec-Dateien, sondern .mpg produzieren. Der Inhalt ist der gleiche, .recs lassen sich abspielen, aber alle TAPs, die nur nach .rec-Dateien Ausschau halten, sind praktisch nicht zu gebrauchen.

Man muss also nach beiden Erweiterungen suchen und darf diese keinesfalls irgendwo hard coden. Ich habe derzeit leider keine Idee, wie man das allgemein lösen könnte (à la TAPAPIFix beim 5k).

[BluField62]

Wollte TF im nächsten Update nicht die TAP API fixen? Vielleicht dauert es deshalb länger
Oder hat das damit nichts zu tun?

[FireBird]

Oder hat das damit nichts zu tun?

Hat nichts damit zu tun. Das hier fällt in die Kategorie „TAP-Programmierer ärgern“, da bei jedem Gerät eine Kleinigkeit anders ist und man all diese Kleinigkeiten in seine TAPs einpflegen darf.

[BluField62]

Okay, hab verstanden.

[deangelj]

Ich stelle mal einen Punkt zur Diskussion, da er viele TAP-Programmierer betrifft. Es handelt sich nicht um einen Unterschied zwischen 5k und TMS, sondern um Australien und Europa.

Thank you for thinking about us!

And I will of course tell our programmer(s) to do the same for .rec :

[Twilight]

And I will of course tell our programmer(s) to do the same for .rec

twilight

[Gerti]

Hi!

Arg...das habe ich ja völlig vergessen...dann muss ich QuickPlay wohl heute an einigen Stellen nochmal anpassen...

Gruß,
Gerti

[xyzzyx]

Das heißt dann aber trotzdem, dass diese .mpg im DataFiles Ordner einen REC-Header haben, oder?
Man kann sie also nur aufgrund ihres Ordners von den MPG-Dateien im MediaFiles Ordner unterscheiden.

[FireBird]

[quote="xyzzyx"]Das heißt dann aber trotzdem, dass diese .mpg im DataFiles Ordner einen REC-Header haben, oder?[/quote]
Ja. Die Zusatzdateien heissen dann .mpg.inf und .mpg.nav.

[BluField62]

@Erdnussnase

mmmh...Fortschritte unterm spoiler

[Töppi]

diesen Thread bitte sauber halten, dafür haben wir den Kommentarthread!

[FireBird]

Sauber gemacht.

[Töppi]

danke schöön....

[Erdnussnase]

Danke für die Info.
Da iTiNa keine australische Version hat betrifft es mich wohl nicht.
Denke da aber gerade an folgendes:
char *RecEnd[2][4] = { ".rec", ".mpg" };
bauen und einen Einstellungs Menü Eintrag der den Index zwischen 0 und 1 umschaltet, je nachdem welche FW man hat.

Falls das jetzt nicht kompletter Unsinn ist, könnte man doch so etwas in die Lib packen ? Dann würde der Einstellungsparameter entfallen. Die diveresen Tests in den Taps gehen dann halt nicht mit lokalen Strings, sondern den Lib eigenen.

Oder übersehe ich da gerade etwas ?

[FireBird]

Ich versuche das transparent (hatten wir das Thema heute nicht schon? : ) zu machen, indem ich auf beide Endungen prüfe. Da die Änderung mit einem Firmware-Update kam, haben die Leute .rec und .mpg auf der Platte.

[Erdnussnase]

Wenn Du da noch etwas machst hätte ich etwas. Ist nicht wichtig, ist in der derzeitigen Situatiuon aber inkonsistent.
HDD_Move verschiebt auch die inf und nav Datei mit. Delete und Rename behandlen die aber nicht mit.
Ich habe mir dafür meine eigenen geschrieben. Wäre vielleicht gut das auch in der Lib anzubieten. Kann Dir den Kram schicken, ist aber natürlich nicht besonders aufregender Code.

[Happy]

Beim MP3 abspielen:
TYPE_PlayInfo.currentBlock enthält wie auch schon beim 5k die schon abgespielten Sekunden. Leider wird ein nicht konstanter Offset dazuaddiert sobald man während der Wiedergabe die Dateiliste öffnet. (so was um 1793890).

PlayInfo.evtInfo.eventName und PlayInfo.evtInfo.description enthielten beim 5k Immer Künstler und Titel des MP3. Da steht bei mir nur noch YST o.ä. (das Y st das mit den 2 Punkten =0xff), selbst wenn der TMS im OSD die richtigen Tags anzeigt.
Könnte man beides auch in die API-Bugliste mit aufnehmen.

Gruß,
Happy

[Twilight]

@firebird: was sagst du dazu?

twilight

[Happy]

Hallo,l

habe das noch weiter untersucht.
Der TMS liest ID3v2 Tags (beim 5K nur ID3v1)
Also die Tags werden prinzipiell immer noch über die API, wie oben beschrieben, geliefert. Jedoch funktioniert das nur, wenn die Tags den ISO-8859-1 Zeichensatz verwenden. Wird Unicode 16bit verwendet, dann beginnen die Tags mit Hex 0xFFFE (das ist die Unicodekennung für Utf-16). Die 3 Buchstaben, die als Tag geliefert werden sind dann die Kennung und der erste Buchstabe (das 4. Zeichen ist dann ein Nullcharacter und die normale Stringverarbeitung endet dann in C).
UTF-8 Tags gehen dann auch wieder.
Das als Bug zu melden ist schon wieder etwas kompliziert, zumal ich ein MP3 habe, welches auch offensichtlich ein UTF-16 ist aber im Archiv richtig angezeigt wird, andere werden falsch angezeigt.
Vielleicht schreibt mein Tagger auch nicht ganz konforme Tags.
Vorschlag lass die Tags als Bugs weg.

Das mit den abgespielten Sekunden könnte man aber aufnehmen, falls Alex zustimmt

Gruß,
Happy