Ich bin ein Stück weiter:
Um den Fehler weiter einzugrenzen habe ich die Datenbank gelöscht,
$ rm /var/packages/sundtek/opt/bin/sundtek.dbDann habe ich putty so konfiguriert, dass der gesamte Output in eine Datei geschrieben wird (angehängt) und den Streaming Server unter root so gestartet: $ /var/packages/sundtek/opt/bin/rtspd -v und den Sender-Suchlauf über die Weboberfläche gestartet.
Hier sind die letzten Zeilen des Outputs:
**** SAVING LNB CONFIG: 0 0 0
>> insert into sundtek_channel_master(f_id, group_description, group_description_length, plist_type) values(1, 'DVB-S/S2 (2024-01-20 13:20:09)', '30', 0)
token: insert
token: into
token: sundtek_channel_master
token: f_id
token: group_description
token: group_description_length
token: plist_type
token: values
token: 1
token: DVB-S/S2 (2024-01-20 13:20:09)
token: 30
token: 0
>> insert into sundtek_channels(f_id, pmt_pid, program_number, transport_stream_id, delsys) values(1, 1024, 29850, 0)
token: insert
token: into
token: sundtek_channels
token: f_id
token: pmt_pid
token: program_number
token: transport_stream_id
token: delsys
token: values
token: 1
token: 1024
token: 29850
token: 0
Segmentation fault (core dumped)
Der Server stirbt also, sobald der erste Channel in die Datenbank geschrieben wird.
Nach meinem Verständnis ist das betreffende sql-Statement fehlerhaft:
Dort sollen in der Tabelle sundtek_channels 5 Spalten befüllt werden, aber es werden nur 4 Werte angegeben. Ist das zulässig? Ist das so gewollt?
Abgesehen davon wundert mich, dass ein SQL-Fehler zu einem Segmentation fault führt, hier fehlt's wohl an der Fehlerbehandlung...
BTW: Der Server kann auch mit der Option --logpath gestartet werden. Wenn man so startet, landen allerdings die letzten Zeilen nicht mehr in der Datei. Ursache ist wohl, dass beim Segmentation fault der letzte Buffer des Logfiles nicht mehr auf die Platte geschrieben wird.
