Aufbau CRID-Dateien

[Lemmi]

Vorlage für karlo.h, der dieses Thema bisher gewartet hat.
Altes Forum: Aufbau CRID-Dateien (http://software.ftb-net.de/m740av/YaBB.cgi?board=softwarebox;action=display;num=1103 216269)

P.S.: Wenn ich es kopieren würde, dann könnte karlo es nicht editieren

[karlo.h]

Vorlage für karlo.h, der dieses Thema bisher gewartet hat.
Altes Forum: Aufbau CRID-Dateien (http://software.ftb-net.de/m740av/YaBB.cgi?board=softwarebox;action=display;num=1103 216269)

Der Zaunpfahl ist angekommen ;)


P.S.: Wenn ich es kopieren würde, dann könnte karlo es nicht editieren
Wäre auch nicht soooo schlimm gewesen *g*

Hier also die bisher identifizierten Felder der CRID-Datei. Wenn irgendwo ein Fragezeichen steht, deutet es auf eine (mehr oder weniger fundierte) Vermutung hin, auch wenn danach noch Details kommen. Also bitte genau hinschauen. Die Länge ist jeweils in Bytes, nn steht für eine variable Länge. Die Länge ist bei "unbekannt" oder ähnlichem auch nur eine Vermutung...

Ich werde diese Liste aktuell halten, wenn es neue Erkenntnisse gibt. (Hallo Siemensianer, gebt doch mal ein paar Tipps ;))



Dateiformat

Länge Beschreibung
4 Versionsbyte? In allen Dateien = 2
8 CID, 1E6 (oder 1E5) mal programmierte Startzeit + SenderID (siehe /var/etc/eps_mapping.txt)
4 Status: 1=noch nicht aufgenommen, 2=während der Aufnahme, 3=fertig aufgenommen, 4=Aufnahmefehler
4 Beginn der aufgenommenen Sendung in Sek. seit 1.1.1970
4 Ende der aufgenommenen Sendung in Sek. seit 1.1.1970
4 unbekannt, in allen Dateien = 0
4 unbekannt, in allen Dateien = -1
4 unbekannt, in allen Dateien = -1
4 Aufnahmeflag: 1=EPG, 2=Timer, 4=Serie, 32=manuell
4 Serienflag: 0=keine Serie, >0 = Serien-ID, wird scheinbar fortlaufend vergeben
2 Sperrflag? wenn = 0: nicht gesperrt; wenn = 1: gesperrt
4 Länge des Titels
nn Titel des Strings
4 Anzahl nachfolgender Dateinamenblöcke, normalerweise 1 bei vollständiger Aufnahme. ? Es gehören die nächsten fünf Felder zu einem Block
==== Block ====
4 Länge der Dateinamens-Basis
x Dateinamensbasis aller dazugehörenden Dateien
4 tatsächliche Startzeit der Aufnahme in Sek. seit 1.1.1970
8 SCR (System Clock Reference) zu Beginn des Blocks
8 SCR zu Ende des Blocks
==== Ende Block ====

4 Länge von Genre/Herkunft
nn Genre/Herkunft, z.B. "Spielfilm Deutschland 2000"
4 Länge der Beschreibung
nn Beschreibung
4 Flag, ob der Film bereits gestartet wurde. 0 = nein, ansonsten Position in der Aufnahme in Sekunden (?)
?? Füllbytes? Einige Dateien haben noch einen Block unterschiedlicher Länge mit 0-Bytes

[Lemmi]

Der Zaunpfahl ist angekommen ;)

Hoffentlich hat es nicht zu weh getan ;)

Ich hatte halt was nachgeschaut und mußte selbst die alten Seiten aufsuchen. Und da habe ich gleich an dich gedacht.

[MSchmidke]

Schätze, daß es nicht nur ein Flag ist, "ob der Film gestartet wurde", da er sich ja auch irgendwo merkt, bis wohin man gespielt hat, und die CRID-Datei ist die einzige, die sich beim Ankucken ändert - meiner Beobachtung zufolge.

[tier]

Ich glaube zu wissen, was in den 4 Bytes steht, die hinter dem Titel-String kommen.

In den meisten Aufnahmen ist der Wert=1, ich hatte letztens aber auch mal eine 2 dort stehen, und zwar dann, wenn man einen Teil einer Sendung manuell aufnimmt, dann stoppt und dann wieder weiteraufnimmt. Dann entstehen 2 FMPGs, und dieser Wert ist die Anzahl der Teile.

Sind es mehr als 1 Teil, dann kommt hinter dem ersten Dateinamen in der CRID-Datei noch der zweite und dann erst das Art/Herkunft-Feld.

Wird zwar selten vorkommen, sollte man aber nicht vernachlässigen.

Könnt Ihr das bestätigen?

cya,
tier.

[Lemmi]

4 Flag, ob der Film bereits gestartet wurde. 0 = nein, ansonsten ein noch unbekannter Wert, bisher gefunden: 0x50, 0x1d0


Das ist definitiv die relative Pauseposition in Sekunden.

Hatte in einem Film 6 Pausen gemacht und die CRID-Dateien rüberkopiert und analysiert.
Es lebe telnet ;)

[vsw]

Habe ich nur geschlafen (ich geh ja gleich ins Bett...), Tomaten auf den Augen oder hab einfach nur die Suchfunktion im Forum nicht ausgereizt?

Zu den crid-Dateien hätte ich noch die Frage/Hinweis, ob der Aufbau der Dateien im Aufnahmeordner mit dem im Verzeichnis /data/.timer identisch ist?

Wenn ja, wäre es doch ein evtl. ein Leichtes, die fummelige Timer-Programmierung über die Fernbedienung zu umgehen, wenn dazu nur die entsprechende crid-Datei am richtigen Platz vonnöten ist (oder als Backup oder Apache/PHP remote oder ...).

Nun ja, man bekommt -- gerade um die Weihnachtszeit herum (Menge der "sehenswerten" Filme) -- ein wenig Übung mit der Neuprogrammierung des Timers bei einem FW Up-/Downgrade. Aber nur um meine o.g. Hypothese zu verifizieren, habe ich jetzt keine Lust ein manuelles Backup von /data/.timer anzufertigen, die 1.18 wieder aufzuspielen, um dann zu dieser Uhrzeit zum dritten Mal den Timer für die nächsten Tage "einzuradieren" :)

... evtl. mal nach Weihnachten...

Gruß Jan + gute n8 & frohes Fest

[USB-2]

Hallo (vielleicht karlo.h?)

ich möchte ein kleines Progrämmchen zur Umbenennung von Titeln in den Crid Dateien schreiben. Mit Binärdateien kenne ich mich noch nicht so gut aus, deshalb kann ich mir die folgende Frage nicht selbst beantworten:

Wie komme ich von den u.a. Hex Zahlen 00, 00, 18(dez 24) und 5(dez 5) auf eine dezimale Länge von 23? Das ist nämlich die Lange des Titels "Ein Herz und eine Seele")?

Danke im Vorraus

[popelheini]

Hallo (vielleicht karlo.h?)

Wie komme ich von den u.a. Hex Zahlen 00, 00, 18(dez 24) und 5(dez 5) auf eine dezimale Länge von 23? Das ist nämlich die Lange des Titels "Ein Herz und eine Seele")?

Danke im Vorraus

mal ein Schuss ins Blaue:

Titel + abschliesendes "\0"

Wenn Du einen String definieren wuerdest, muesste er diese Laenge haben. Schliesst der Titel moeglicherweise mit 0x00 ab?

Popel

[karlo.h]

Hallo (vielleicht karlo.h?)

ich möchte ein kleines Progrämmchen zur Umbenennung von Titeln in den Crid Dateien schreiben. Mit Binärdateien kenne ich mich noch nicht so gut aus, deshalb kann ich mir die folgende Frage nicht selbst beantworten:

Wie komme ich von den u.a. Hex Zahlen 00, 00, 18(dez 24) und 5(dez 5) auf eine dezimale Länge von 23? Das ist nämlich die Lange des Titels "Ein Herz und eine Seele")?

Danke im Vorraus

Die 5 gehört zum String, der also 0x18 (=24) Bytes lang ist. Bedeutung der 5 war im alten Forum. Hatte was mit der Codierung des Strings zu tun. Weiß jemand ob der Thread noch existiert?

[USB-2]

Tja,

wees ick nich :-/ Aber die komplette CRID-Datei ist im Editorfenster abgebildet (evt. rechte Maustaste, Bild speichern unter... ausführen). Bei einigen Dateien stimmt die Sache auch. Eine Aufnahme mit ProSieben zeigt im Byte direkt vor dem Titel tatsächlich "9" an. Aber so logisch ist es halt nur manchmal, nicht immer...

[karlo.h]

Tja,

wees ick nich :-/ Aber die komplette CRID-Datei ist im Editorfenster abgebildet (evt. rechte Maustaste, Bild speichern unter... ausführen). Bei einigen Dateien stimmt die Sache auch. Eine Aufnahme mit Arte zeigt im Byte direkt vor dem Titel tatsächlich "4" an. Aber so logisch ist es halt nur manchmal, nicht immer...

Vermutlich senden nicht alle Sender das vollständige Format. Jedenfalls hat es was mit EPG im DVB-T zu tun, nicht mit der Box. Siehe http://www.google.de/search?q=cache:0prclCQJIVQJ:www.bjpace.com.cn/data/tec/tec-DVB/DVB%2520BlueBooks%2520Standards/Specifications%2520and%2520Standards/multiplexing/dvb-si/A005r1.pdf+epg+bjpace&hl=de&client=firefox-a

[Lemmi]

Im alten Forum hatte drei folgendes zitiert:
------------------------

Auf die Quelle hatte ich schon weiter oben hingewiesen, hat außer mir aber wohl keiner nachgelesen. Jetzt klappt der Zugriff auch wieder, dort lassen sich alle relevanten Normen als PDF herunterladen. Viel zu lesen, aber hochinteressant. Auszug aus EN 300 468:

A.1 Control codes
The codes in the range 0x80 to 0x9F are assigned to control functions as shown in table A.1.
Table A.1: Single Byte Control codes
Control code Description
0x80 to 0x85 reserved for future use
0x86 character emphasis on
0x87 character emphasis off
0x88 to 0x89 reserved for future use
0x8A CR/LF
0x8B to 0x9F user defined
For two-byte character tables, the codes in the range 0xE080 to 0xE09F are assigned to control functions as shown in
table A.2.
Table A.2: DVB codes within Private Use Area of ISO/IEC 10646-1 [1]
Control code Description
0xE080 to 0xE085 reserved for future use
0xE086 character emphasis on
0xE087 character emphasis off
0xE088 to 0xE089 reserved for future use
0xE08A CR/LF
0xE08B to 0xE09F reserved for future use
A.2 Selection of character table
Text fields can optionally start with non-spacing, non-displayed data which specifies the alternative character table to be
used for the remainder of the text item. The selection of character table is indicated as follows:
- if the first byte of the text field has a value in the range "0x20" to "0xFF" then this and all subsequent bytes in the
text item are coded using the default character coding table (table 00 - Latin alphabet) of figure A.1;
- if the first byte of the text field has a value in the range "0x01" to "0x05" then the remaining bytes in the text item
are coded in accordance with character coding tables 01 to 05 respectively, which are given in figures A.2 to A.6
respectively;
- if the first byte of the text field has a value "0x10" then the following two bytes carry a 16-bit value (uimsbf) N to
indicate that the remaining data of the text field is coded using the character code table specified by
ISO Standard 8859 [5], Parts 1 to 9.
- if the first byte of the text field has a value "0x11" then the remaining bytes in the text item are coded in pairs in
accordance with the Basic Multilingual Plane of ISO/IEC 10646-1 [8].
Values for the first byte of "0x00", "0x06" to "0x0F", and "0x12" to "0x1F" are reserved for future use.

[USB-2]

> Die 5 gehört zum String, der also 0x18 (=24) Bytes lang ist.

Vielen Dank, Rätzel gelöst. Hätte auch mal selber die Zeichen von vorne anstatt vom Titel rückwärts zählen können.

Ich denke mal (ganz naiv), dass ich beim Rausschreiben des Crids den Wert 05 einfach weglassen kann(?)

[Lemmi]

> Die 5 gehört zum String, der also 0x18 (=24) Bytes lang ist.

Vielen Dank, Rätzel gelöst. Hätte auch mal selber die Zeichen von vorne anstatt vom Titel rückwärts zählen können.

Ich denke mal (ganz naiv), dass ich beim Rausschreiben des Crids den Wert 05 einfach weglassen kann(?)

Ich zitiere nochmals aus meinem vorherigen Posting:


if the first byte of the text field has a value in the range "0x01" to "0x05" then the remaining bytes in the text item are coded in accordance with character coding tables 01 to 05 respectively, which are given in figures A.2 to A.6 respectively;
Die '5' gibt also eine Kodier-Tabelle an und kann daher tatsächlich weggelassen werden. Sie hat allerdings Einfluß (welchen?) auf die folgenden Zeichen.

[karlo.h]

Ich zitiere nochmals aus meinem vorherigen Posting:
Die '5' gibt also eine Kodier-Tabelle an und kann daher tatsächlich weggelassen werden. Sie hat allerdings Einfluß (welchen?) auf die folgenden Zeichen.

'5' ist Latin-1, dürfte in unserer Gegend also das einzig vorkommende Zeichen sein. Andere sind z.B. irgendwas kyrillisches oder arabisches.

[locke]

Hi zusammen,

bei Interesse sollte ich eine CRID-Datei liefern können, bei der die Aufnahme irgendwie mit einem Fehler abgebrochen wurde (Der 740er brachte übrigens beim nächsten Einschalten die Meldung, das er nicht korrekt abgeschaltet wurde.). In der Aufnahmenliste des 740 steht hinter der Aufnahme kein grünes Symbol, sondern ein kleines rotes Dreieck.

Vielleicht kann die Datei ja dazu beitragen, von einem weiteren Feld die Schleier des Unbekannten zu lüften. :)

Könnte evtl. noch ein paar Tage dauern, bis ich die Platte wieder an den PC anschliesse.

Gruß
Stefan

[bebibaer]

Hier sind meine Ergänzungen zum Aufbau der .crid-Dateien im Aufnahmeorder und im Verzeichnis /data/.timer:

Dateiformat

Länge Beschreibung
4 Versionsbyte? In allen Dateien 2
8 CID
4 Status: 1=noch nicht aufgenommen, 2=während der Aufnahme, 3=fertig aufgenommen
4 programmierter Beginn der Sendung (Unix-Timestamp)
4 programmiertes Ende der Sendung (Unix-Timestamp)
4 unbekannt, in allen Dateien 0
4 unbekannt, in allen Dateien -1
4 unbekannt, in allen Dateien -1
4 EPG-Flag? wenn = 1, ist es eine EPG-Aufnahme; wenn = 2 ist es eine frei programmierte Aufnahme
4 unbekannt, in allen Dateien 0
2 Sperrflag? wenn = 0: nicht gesperrt; wenn = 1: gesperrt
4 Stringlänge
nn Titel
4 1=fertig aufgenommen, 0=noch nicht aufgenommen => die nächsten 7 Felder sind nicht vorhanden
4 Stringlänge
nn Dateinamenprefix aller dazugehörenden Dateien
4 tatsächliche Startzeit der Aufnahme (Unix-Timestamp)
4 unbekannt
4 unbekannt
4 unbekannt
4 unbekannt
4 Stringlänge
nn Genre, Episode
4 Stringlänge
nn EPG-Beschreibung
4 Flag, ob der Film bereits gestartet wurde. 0 = nein, ansonsten Position in der Aufnahme in Sekunden (?)
?? Füllbytes? Einige Dateien haben noch einen Block unterschiedlicher Länge mit 0-Bytes

Zeitzone ist UTC
Zeiten werden in Sekunden seit 1970-01-01T00:00:00Z gerechnet (Unix-Timestamp)
CID ist 1E+5 oder 1E+6 mal programmierte Startzeit + SenderID (siehe /var/etc/eps_mapping.txt)
Standardfaktor für CID ist 1E+5, manchmal wird 1E+6 genommen (Kollisionsvermeidung?)
Strings werden werden als Länge+Text ohne abschließendes \0 abgespeichert.
Strings mit EPG-Daten können Steuerzeichen enthalten, typisch $05 und $8A (fester Zeilenumbruch)
Dateinamenprefix ergibt sich aus Ethernet-MAC, den Unterstrich und tatsächlicher Startzeit (in dezimaler Darstellung)

Leider ist es mir nicht gelungen, eine Aufnahme durch Anlegen einer .crid-Datei im Verzeichnis /data/.timer zu starten. Da fehlt noch das Zusammenspiel mit den Dateien /data/SM_FILE und /data/RA_FILE. Interessant ist auch die Datei /data/RECORDER_LOG.

[USB-2]

Ich habe so die Vermutung, dass einige der noch unbekannten Bytes vielleicht auf einen Sender in der Sendertabelle zeigen. Schön wäre es jedenfalls, da ich dies für Criditor sehr gut gebrauchen könnte. Vielleicht findet's ja jemand heraus...

[bebibaer]

Schau mal bei meinen Ergänzungen unter CID (die Bezeichnung habe ich aus RECORDER_LOG geklaut). Dort bzw. auch im Dateinamen selbst ist der Sender verschlüsselt.

[karlo.h]

Hi zusammen,

bei Interesse sollte ich eine CRID-Datei liefern können, bei der die Aufnahme irgendwie mit einem Fehler abgebrochen wurde (Der 740er brachte übrigens beim nächsten Einschalten die Meldung, das er nicht korrekt abgeschaltet wurde.). In der Aufnahmenliste des 740 steht hinter der Aufnahme kein grünes Symbol, sondern ein kleines rotes Dreieck.

Vielleicht kann die Datei ja dazu beitragen, von einem weiteren Feld die Schleier des Unbekannten zu lüften. :)

Könnte evtl. noch ein paar Tage dauern, bis ich die Platte wieder an den PC anschliesse.

Gruß
Stefan

Und? Hast Du die Datei? Ich wäre interessiert...

[locke]

Und? Hast Du die Datei? Ich wäre interessiert...

Sorry, nachdem nach den ersten Tagen keine Reaktion kam, habe ich die Aufnahme dann nach dem Schneiden ganz gewohnheitsmäßig gelöscht. :rolleyes:

Gruß
Stefan

[genrich]

Hab mich auch mal ran gemacht, die CRID Dateien zu entschlüsseln...
Ich hab schwierigkeiten beim EPG-Flag und dem Sperrflag... Das EPG-Flag liegt ja bei ByteNr[36:40] nur ich bekomme mehr als 1 oder 2 herraus... Nämlich auch 32 (bei einer Aufnahme die gerade läuft) und auch einmal eine 8, ohne zu wissen was das bedeuten soll...

Und ich denke das Sperrflag setzt sich auch auf 4Bytes zusammen ByteNr[42:46] denn nur so bekomme ich dort die richtigen Werte...

Meine Bisherige Tabelle:


Start:End Länge Beschreibung
0:4 4 Versionsbyte? In allen Dateien 2
8 CID
12:16 4 Status: 1=noch nicht aufgenommen, 2=während der Aufnahme, 3=fertig aufgenommen
16:20 4 programmierter Beginn der Sendung (Unix-Timestamp)
20:24 4 programmiertes Ende der Sendung (Unix-Timestamp)
4 unbekannt, in allen Dateien 0
4 unbekannt, in allen Dateien -1
4 unbekannt, in allen Dateien -1
36:40 4 EPG-Flag? wenn = 1, ist es eine EPG-Aufnahme; wenn = 2 ist es eine frei programmierte Aufnahme
2 unbekannt, in allen Dateien 0
42:46 2 Sperrflag wenn = 0: nicht gesperrt; wenn = 1: gesperrt
46:50 4 Stringlänge
50:nn nn Titel

Achja, und der Titel stimmt wohl noch nicht ganz... Zumindest hab ich hin und wieder ein ENQ-Zeichen vorm Titel. Das Ende ist aber immer richtig?!?!


Existiert auch nähere Info's zu den *.fmpg Dateien??? Darin sind die zugehörigen MPG Dateien hinterlegt, was man auf dem ersten Blick sieht...

[Lemmi]

Achja, und der Titel stimmt wohl noch nicht ganz... Zumindest hab ich hin und wieder ein ENQ-Zeichen vorm Titel. Das Ende ist aber immer richtig?!?!

ENQ (ASCII==5) wurde schon geklärt:

if the first byte of the text field has a value in the range "0x01" to "0x05" then the remaining bytes in the text item are coded in accordance with character coding tables 01 to 05 respectively, which are given in figures A.2 to A.6 respectively;Weiter oben gibt es weitere detailierte Infos und auch die Tabellen.

[genrich]

Aha... Naja, ich schneide es einfach raus ;)

Hab noch was entdeckt... Nach "programmiertes Ende der Sendung (Unix-Timestamp)" gibt der nächste Wert [24:28] an, ob die Aufnahme gerade abgespielt wird =1 oder nicht =0... Kann das jemand bestätigen?

Kann noch jemand was zum oben erwähnten EPG-Flag = 32 sagen???


EDIT: Es ist wohl doch nicht 1=Wird gerade abgespielt... Aber zumindest gibt es bei mit eine Aufnahme, die letzte, bei der an dieser Stelle eine 1 ist... Diese hat auch einen EPG-Flag von 32... :confused:

[karlo.h]

Und ich denke das Sperrflag setzt sich auch auf 4Bytes zusammen ByteNr[42:46] denn nur so bekomme ich dort die richtigen Werte...


Hatte mich eh' gewundert mit den zwei Bytes. Weiß auch nicht mehr, wieso ich darauf gekommen war. Wenn da auch andere Werte drinstehen, könnte das ein bit-kodiertes-Flag-Feld sein.

[schnoedel]

moin.

ich hatte mir auch schon ein tool geschrieben, das mir die aufnahmen einfach nur umbenennt, und mir deswegen auch den kopf zerbrochen an den crids.

jetzt erst finde ich diesen sehr interessanten thread;)

ich kann leider nur eine vermutung beisteuern:

4x4 unbekannten byte nach dem dateinamenpraefix und der startzeit muessten die position innerhalb des gespeicherten ts angeben in dem sich die aufnahme befindet.
denn wenn man eine aufnahme aus dem timeshift buffer erstellt, dann geht die aufnahme ja weiter auch wenn die sendung schon zuende ist, wenn man nicht umschaltet. trozdem wird bei der wiedergabe nur die gewuenschte sendung selber abgespielt.
ich kann mir vorstellen dass die werte irgendwie mit den (m)idx dateien zusammenhaengt

gruss schnoedel

[roland]

Und? Hast Du die Datei? Ich wäre interessiert...

Hallo Forum!

Nachdem meine Box heute mitten in zwei laufenden Aufnahmen rumgesponnen hatte, hatte ich sie durch Steckerziehen neu gestartet. Danach hatte ich auch zwei abgebrochene Aufnahmen mit einem roten Dreieck in der Aufnahmeliste.

Der Unterschied zu den anderen CRID-Files: das Feld , das hier mit "Status" bezeichnet wird, trägt dann eine "4".

Gruß an alle
Roland

[superrudi]

Tach zusammen!

Der letzte Eintrag ist ja schon rel. alt, deshalb wißt Ihr wahrscheinlich schon, dass Siemens die Dateiformate zum Download anbietet: http://communications.siemens.com/cds/frontdoor/0,2241,de_de_0_24400_rArNrNrNrN_prodId%3A76522,00. html

[Treteimer]

Tach zusammen!

Der letzte Eintrag ist ja schon rel. alt, deshalb wißt Ihr wahrscheinlich schon, dass Siemens die Dateiformate zum Download anbietet: http://communications.siemens.com/cds/frontdoor/0,2241,de_de_0_24400_rArNrNrNrN_prodId%3A76522,00. html

Nur leider ist die im aktuell verlinkten File:
http://download.benqmobile.com/download.jsp?file=95959
falsch!


long CRID-Version; /* always 2 */

Es sind aber nur 32 bit = int CRID-Version;
Ebenso Recording-State usw.

[bebibaer]

Hat sich etwas an den CRID-Dateien ab FW 2.3.15 geändert? Dort sind nur Verweise mit 0001xxxxxxxx_iiiiiiii.fmpg eingetragen, aber keine Unterscheidung, ob das eine Datei (vor FW 2.3.15) oder ein Verzeichnis (ab FW 2.3.15) unterhalb von .rec ist.

[karlo.h]

Nein, es hat sich nichts geändert. Unterscheidung der Formate durch Test der FMPG-Datei: im selben Verzeichnis wie die CRID-Datei --> altes Format, sonst neues Format.

[karlo.h]

Ich fürchte ich muss mich selbst korrigieren: die Verweise auf die FMPG sind zwar unverändert, aber scheinbar werden weitere Daten in der CRID hinten angehängt. Bei mir sind zumindest alle CRIDs seit 2.3.15 länger als erwartet und es ist in einem HEX-Editor z.B. der Sendername, von dem aufgenommen wurde, in Klarschrift zu lesen. Auch scheinen noch weitere Infos abgelegt zu sein. Inhalt bisher: :confused:

Sollten diese Infos eine Bedeutung haben (und nicht z.B. nur durch einen falsch/versehentlich weggeschriebenen Puffer o.ä. entstanden sein), wäre es unschön, dass die Versionsnummer in der Datei unverändert geblieben ist.

Mal sehen, was so rauskommt...

[kille]

Hi,

ich fand es schon unschön (damals, vor langer, langer Zeit), dass die Pfadangaben für die FMPG-Dateien nicht ausgewertet wurden. Ebenso die Sache jetzt mit der neuen Ablage der FMPG-Dateien, ist aber ein "Folge-Unschön" ;)

Aber mit der neuen FW scheint sich wirklich was verändert zu haben. Auf dein Posting hin habe ich mal die aktuellen CRIDs in einem Hex Editor begutachtet, die so auf meiner Festplatte rum lagen.

Wie du beobachtest hast, sind auch bei mir die CRID-Dateien länger als vermutet.

Ich habe eine bunte Mischung aus zwei Timerarten: zum einen programmiere ich Serien manuell, also nicht als aus dem EPG. Da stehen anders wie bei dir keine Klartext-Sendername drin. Zum anderen programmiere ich Einzelaufnahmen aus dem EPG herraus. Dort steht der Sender im Klartext mit drin.

Fasziniered finde ich allerdings meine "Verlieb in Berlin" Aufnahmen *schäm*. Die habe ich als Manuelle Serienaufnahme programmiert. Klappt auch wunderbar, das ist nicht das interessante. Interessant ist: ich habe die Aufnahme manuell umbenannt von "SAT_1_19:15-19:45" (oder wie immer die automatisch benannt wird) in ViB. Das wird auch als Titel in der CRID Datei abgespeichert und angezeigt.

Als "EPG Short Title" steht da aber "Verliebt in Berlin". Das muss sich die Box irgendwie aus dem EPG zusammengereimt haben. Die Aufnahme ist manuell genau so programmiert wurden, wie sie auch im EPG vorkommt (Anfangs- und Endzeit).

Noch abgefahrener ist, dass sogar der passende "EPG Long Text" in den CRID-Dateien gespeichert wurde. Bei meinen anderen Serienaufnahmen ist das nicht so (oh wunder, die gehen meist auch über mehr als eine Serie, zB Dienstags Chramed, Desperate Housewives & Grey's Anatomie).

Habe ich da jetzt etwas nicht mitbekommen, oder ist dieses Verhalten jetzt neu.

Die CRID-Dateien stell' ich gerne zur Verfügung, in den ViB Aufnahmen steht übrigens "recording type" auf 8, also manuelle Serienaufnahme (Timer).

Kille

[karlo.h]

Klingt ja so, als wenn da neue Features in Vorbereitung sind - wenn sie denn drin sind, wäre eine neue Versionsnummer nicht schlecht.

[Silas]

Meine Erfahrung, bei manueller Serienprogrammierung mit der 2.3.15 waren folgende:

Wenn die Anfangszeit übereinstimmt werden die EPG Infos mit abgespeichert, dies war unabhängig von der Endzeit.

Beispiel: Verliebt in Berlin 19:15-19:45Uhr

Manuelle Serie: Sat1 19:16-19:45Uhr --> keine EPG Daten
Manuelle Serie: Sat1 19:15-19:40Uhr --> EPG Daten werden übernommen

Und die gleiche Erfahrung wie Kille: EPG Serie programmiert, z.B Desperate Housewifes ---> keine EPG Daten

Ist im übrigen schön, das ich nicht der einzige bin, der sich für Vib gucken ein bisschen schämt, in diesem "Science Fiction" und "coole Männerserien"(CSI etc.) Forum. ;)

Grüße Silas

[kille]

Hi,

ich habe mir die neuen CRIDs auf meiner Platte (sind nur 12, wobei 5 Stück zur gleichen Serienprogrammierung gehören) mal etwas genauer angeschaut. Viel ist es nicht, was ich dabei an (für mich) neuen Erkenntnissen gesammelt habe.

Es geht los, wo die Siemensbeschreibung aufhört (also nach "long playback timestamp;") und ich verwende die gleichen Typen wie Siemens in ihrer PDF. Ansonsten ist das ganze hoch spekulativ und an einigen Stellen auch einfach nur ausgewürfelt (ist das nun ein long long oder zwei long...).

Als erstes kommen einfach 4 Nullen (also ein long).

Dann scheint wieder etwas vom Typ long zu kommen (also 4 Bytes). Das ist auch bei allen meinen 12 CRIDs Dateien gleich: 00 00 47 11 (Hexadezimal).

Alternativ kann es auch sein, dass beide zusammen ein long long bilden (also 8 Bytes) und sozusagen andeuten, dass es sich um eine Unterversion handelt.

Dann scheint was vom Typ long long zu kommen, genauer die Sender ID (die vorher ja aus der CRID-ID berechnet worden musste). Es kann natürlich auch sein, dass erst etwas vom Typ long kommt und der Wert immer 0 ist, und dann ein weiteres Teil vom Typ long kommt, dass die Sender ID enthält.

Jetzt kommt etwas vom Typ long (da bin ich mir ausnahmsweise mal sicher). Dadrin wird gespeichert, wie lang der anschliessend kommende Teil mit dem Sender im Klartext (also zB ZDF oder Sat.1) ist. Wert ist bei meinen CRIDs immer (hexadezimal) 0 oder 19.

Dann kommt der Sendername im Klartext. Genauer kommt er nur, wenn die Länge größer als Null ist (klar). Der Sendername im Klartext ist immer 25 Zeichen lang, aufgefüllt wird mit Leerzeichen. Ab und an fängt der String mit (hexadezimal) 5 an, das hat dann sicher die gleiche Bedeutung wie beim Titel der Aufnahme (Zeichensatz oder -codrierung, mehr dazu in diesem Thread, irgendwo am Anfang/Mitte). Aber wenn er da steht (er, der Sendername im Klartext), sind es immer 25 Zeichen inkl. der (wenn vorhanden) führenden 5 und den abschliessenden Leerzeichen.

Ab jetzt kommt nichts mehr interessantes von mir, allgemein kommen bei meinen CRIDs jetzt viele, viele Nullen.

Es fängt an mit einem Wert vom Typ long long oder zwei vom Typ long. Nur Nullen.

Dann kommt wieder entweder ein long long oder zwei longs. Aufjedenfall enthält dieser Teil (bzw. der 2. long, je nach Betrachtungsweise) als Wert bei allen meinen CRIDs (hexadezimal) 21 14.

Dann kommt etwas vom Typ long. Den genauen Zweck kann ich nicht ergründen, hat aber auf jeden Fall etwas mit dem Sender zu tun, denn diese 4 Bytes sind immer gleich wenn es der gleiche Sender ist (egal ob EPG oder manueller Timer). Beispiele aus meinen CRIDs:
40 18 0C 02 = Sat.1
02 02 02 02 = ZDF
40 13 0C 02 = Pro 7
40 15 0B 02 = RTL

Danach kommt wieder ein long long, bei allen meinen CRIDs (hexadezimal) 20.

Danach kommen einfach nur noch 32 Bytes voller Nullen.

Kille