support for file format .lst?

[omegaminus]

SerialLoader v2.6 produces .lst files reading an old Hofer/Aldi gran prix str 760 DVB-T/-S receiver channel list. Do you (or anybody else) have a clue about the file structure? Is there a similar structure reader in ChannelSort? Ultimately I could write my own sorter. Mny tnks in advance, Chris

[PredatH0r]

So far I have never heard about SerialLoader, that particular receiver or a .lst channel list format. Do you have an example file?

[omegaminus]

Hallo Horst,

vielen Dank für die rasche Antwort. Ich meine, im Mail können wir zu Deutsch zurückkehren, oder?

Folgendes zur Klarstellung:

Der Receiver ist, wie erwähnt, ein alter Hofer/Aldi DVB-T/S mit CI Slot (deswegen habe ich den herausgekramt), HDMI und einer seriellen Schnittstelle.

Nach vielen vergeblichen Versuchen habe ich den SerialLoader gefunden, der mit dem Ding kommunizieren kann. Das ist ein Tool von HL-ElectronicService, der Supportfirma von LaSAT (http://www.hl-electronicservice.de/hdsoft.php).

Die Binärdatei hat, nach erstem Ansehen, folgenden Aufbau:

Am Anfang scheinen einige Offsets und auch Versionsinfo zu stehen, die eigentlichen Senderrecords stehen ab 0x7C mit diesem Aufbau:

88 – vmtl. ein Bitfeld

UINT16 – SID

UINT16 - ???

UINT16 – VPID

UINT16 – PCRPID

UINT16 - ???

UINT16 – VTPID

UINT16 – APID

UINT16 - ???

String(20) – Sendername

Also alles zusammen Länge 0x2A. Habe noch keine Frequenzeinträge gefunden.

Nach den Senderrecords eine Art Table (evtl. Transponderfrequenzen?), am Ende Satellitenrecords. Konnte noch keine Offsets im Header dafür finden.

Beispieldatei anbei.

LG Chris

Von: Horst Beham notifications@github.com Gesendet: Dienstag, 22. Dezember 2020 16:52 An: PredatH0r/ChanSort ChanSort@noreply.github.com Cc: omegaminus hans-christian.caluba@gmx.at; Author author@noreply.github.com Betreff: Re: [PredatH0r/ChanSort] support for file format .lst? (#210)

So far I have never heard about SerialLoader, that particular receiver or a .lst channel list format. Do you have an example file?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/PredatH0r/ChanSort/issues/210#issuecomment-749612785 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AMDC5PGEEFEHKT4SAFG2BO3SWC6BBANCNFSM4VFW5A7Q . https://github.com/notifications/beacon/AMDC5PDI3OHMILYXDHUWSADSWC6BBA5CNFSM4VFW5A72YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOFSXC54I.gif

[PredatH0r]

Hallo Chris!

Leider war hier keine .lst Datei dabei. Vermutlich entfernt Github Anhänge, wenn man per mail-reply auf github threads antwortet. Die Antworten landen dann auch öffentlichsichbar im Thread auf der Github website.

Wie du richtig erkannt hast, bei den meisten Listen steht beim Sender/Service selbst keine Frequenz sondern nur ein Verweis auf einen Transponder (entweder als Index oder als ONID+TSID) und dort steht dann die Frequenz. Manchmal in Hz, manchmal in kHz.

[omegaminus]

OK, zweiter Versuch mit der .lst! gp.zip

[PredatH0r]

Diesmal hat's funktioniert 👍 Bevor man hier allzuviel Zeit reinsteckt, sollte abgeklärt werden, ob in der Datei eventuell eine Prüfsumme enthalten ist. Kannst du am Receiver selbst z.B. die ersten beiden Sender vertauschen und die Liste erneut exportieren? Am Diff zwischen der alten und neuen Datei erkennt man dann hoffentlich auch, wie der Receiver selbst die Sendernummerierung verwaltet. Manche erwarten, dass die Datensätze in der Datei in der richtigen Reihenfolge stehen, andere haben einfach nur die Programmnummer im Datensatz stehen und sortieren dann selber, andere erwarten beides, ... Vorallem sollte dann auch gleich auffallen, ob die ersten beiden Bytes in der Datei eventuell ein CRC16 o.ä. sind.

[omegaminus]

Ja, Schande, bei der Fernbedienung ist der Knopf fürs Menü (für die Listensortierung und ggf. Suchlauf etc.) kaputt. Bin froh, dass ich wenigstens die Werkseinstellungen habe, ☺! Deswegen wollte ich's am PC sortieren, nachtragen usw. usf. Die Nummerierung ist offenbar die Reihenfolge der Records, zumindest kommen die so wie in der .lst. Die angesprochen Tabelle in der Dateimitte ist offenbar wirklich die Transponderliste, habe dort Einträge für Symbolrate, Frequenz, TSID etc. gefunden

[PredatH0r]

Du könntest versuchen, per Hexedit einen Sendernamen ändern und das dann in den Receiver hochladen. Wenn irgendwo eine Prüfsumme im Spiel ist, sollte das dann fehlschlagen. Ob man am Fernseher dann auch wirklich den geänderten Namen sieht, ist fraglich. Manche Receiver aktualisieren die Senderlistendaten automatisch mit den Infos aus dem DVB-Stream, u.a. auch die Sendernamen.

Du könntest einfach auch per Copy/Paste in einem Hexeditor die kompletten ersten beiden Datensätze austauschen. Dann wüsste man, ob es reicht, die Datensätze neu anzuordnen um die Senderreihenfolge zu ändern - oder ob da eventuell doch auch im Datensatz noch wo eine Programmnummer steht. Die wäre derzeit vermutlich fortlaufend 1-... in den einzelnen Records

[omegaminus]

Ja, guter Tipp, mache ich gleich

[omegaminus]

So simpel ist es offenbar nicht, irgendwo geistert eine Checksumme 'rum. MsgBox: Der Receiver hat eine Datei abgelehnt

[PredatH0r]

Ich habe jetzt viele Varianten mit CRC32 und CRC16 durchgespielt, konnte aber keine Lösung finden. Gibt halt leider zu viele Möglichkeiten bei CRCs, ob sie MSBit oder LSBit arbeiten, welches Polynomial, ab welchem Startoffset der Datei und welche Länge, ... Ich vermute aber, dass die ersten beiden Bytes in der Datei eine 16bit Prüfsumme sind. Die Datei selbst hat wie du gesagt hast 0x7C bytes header, dann 4000 Senderdatensätze zu 0x2A byte Länge, dann 2000 Transponderdatensätze zu 8 byte Länge, dann 30 Satellitendatensätze zu 30 byte Länge und dann noch 2 Bytes hinten dran mit den werten 0x0A 0x0D. Denke nicht, dass die beiden die Prüfsumme sind, weil da untypisch viele 0-bits drin sind. Könnte sowas wie Ländereinstellung und Sprache sein.

[PredatH0r]

War da wohl auf dem Holzweg mit den ersten beiden bytes als CRC. Die ersten 4 Bytes sind ein int32, dessen Wert genau 30 weniger ist als die Dateilänge. Somit dürfte da ein 30byte Header am Anfang stehen. Danach kommen nochmal ein Header mit 94 byte Länge.

Hast du eine Möglichkeit, am Receiver einen neuen Sendersuchlauf zu machen? Meistens ist dann immer irgendwas minimal anders, was dann aber im Vergleich der Dateien aufzeigen sollte, wo eine Prüfsumme steht. Deren Wert ist dann im Regelfall nicht einmal ähnlich zum vorigen, während alles andere ähnlich geblieben sein sollte.

[PredatH0r]

Ich habe jetzt eine Möglichkeit gefunden, deine Liste mit einem Programm zu öffnen. Diskutiert wird dort: https://www.lasat.de/phpBB/viewtopic.php?f=14&t=798 Teil 1: https://www.lasat.de/phpBB/download/file.php?id=280 Teil 2: https://www.lasat.de/phpBB/download/file.php?id=181 und dann brauch man noch eine Java Runtime (JRE). Danach kann man per Doppelklick den Lasateditor_v0_82.jar starten.

Beim Laden deiner Datei meckert es, dass die Datenlänge nicht stimmt - und zeigt dann auch nichts an. Mit dem Hexeditor habe ich dann deine Datei geändert und den int32 ganz am Anfang um 2 erhöht auf a6 d2 02 00. Damit konnte sie der Lasateditor nun einlesen. Ob sie der Receiver in dieser Form dann akzeptiert ist eine andere Frage. Und nachträgliches Zurückändern auf a4 d2 02 00 könnte theoretisch wieder Checksum-Probleme verursachen (denke aber nicht, dass der Header in der Checksum berücksichtigt wird, die steht da ja selber irgendwo drin).

[PredatH0r]

Hab jetzt auch rausgefunden, wie das mit den Prüfsummen aussieht. CRC32 Algorithmus mit "MSBit first" (mit left-shift operatoren und 0x80000000 bei Initialisieren der Tabelle) Polynomial: 0x04C11DB7 Init-Value: 0xFFFFFFFF Exit-XOR: 0x00000000

Dateioffset 0: int32 mit "Datenbereichlänge" Dateioffset 8: crc32 über den "Datenbereich" (offset 28, length "Datenbereichlänge") Dateioffset 28: Beginn des Datenbereichs Dateioffset 80: crc32 über die Headerdaten (offset 96, length 28) Dateioffset 84: crc32 über die Senderdaten (offset 124, length 4000 42) Dateioffset 88: crc32 über die Transponderdaten (offset 168124, length 2000 8) Dateioffset 92: crc32 über die Satellitendaten (offset 184124, length 30 * 30) Hinter dem "Datenbereich" kommen dann noch die beiden Bytes 0A 0D in deiner Datei, die in keinem CRC berücksichtigt sind.

Dass man vor dem Öffnen mit LasatEditor den int32 mit der Datenbereichlänge ändern muss, dürfte ein Bug des Editors sein. So wie ich das sehe, erwartet der Receiver den Originalwert beim Einspielen.

Damit ist für mich die Weihnachtliche Kobelei einmal erledigt. Die Infos sollten jetzt reichen, falls du selber etwas programmieren willst. Wenn du ein ChanSort-Loader-Modul schreiben willst, kann ich dir gerne weiterhelfen. In ChaSort.Api.Crc32 ist z.B. der CRC-32 algorithmus implementiert (Variante "Normal")

[omegaminus]

Hey, du hast das Weihnachtsrätsel der Times geknackt. Vielen Dank für die Links und Infos, muss mich da durchkauen. Bzgl. ChanSort Modul - auch da muss ich mich durchfransen, bin zwar ein vb-Typ, aber cs kann ich zur Not auch noch. Aber jetzt ist erst einmal Weihnachten, dann sehen wir weiter. Komme gerne auf dein Angebot zurück, vD!

[PredatH0r]

Vermutlich werde ich für dieses Format keinen Loader schreiben (außer mir wird einmal wirklich SEHR langweilig). Das Format habe ich aber noch näher analysiert: https://github.com/PredatH0r/ChanSort/blob/master/source/Information/FileStructures_for_HHD_Hex_Editor_Neo/LaSat_lst.h