Gstreamer: ** Message: don't know how to handle text/html

[Barabbas]

Hallo zusammen,

ich nutze für meinen Streaming-Player GTK und Gstreamer. Ich streame jeweils Musikstücke von Jamendo und habe das Problem, dass Jamendo ab und an - auf Grund hoher Serverlast vermutlich - keinen Stream sondern eine Fehlerseite sendet.

Dies führt nun schlicht und ergreifend dazu, dass mein Programm mit folgender Meldung abschmiert:

** Message: don't know how to handle text/html
Segmentation fault

Meine Factory / mein Bus sieht wie folgt aus:

Code: Alles auswählen

        self.player = gst.element_factory_make("playbin", "player")
        bus = self.player.get_bus()
        bus.enable_sync_message_emission()
        bus.add_signal_watch()
        bus.connect('sync-message::element', self.on_sync_message)
        bus.connect('message', self.on_message)

Wie ihr seht, fange ich "message" bereits ab - darin sind normalerweise auch Fehler enthalten. Vor dem oben genannten Fehler bekomme ich über 'message' aber keine Nachricht rein.

Vielleicht hat jemand von euch eine Idee - vorher zu testen, ob Jamendo einen Stream oder eine Datei sendet finde ich a) unschön und b) nicht hinreichend, weil es ja noch immer sein kann, dass ich im Test einen Stream bekomme und beim Streamen doch wieder eine Datei.

Danke schonmal!

Daniel

[Trundle]

Segmentation fault klingt aber sehr nach Bug in gstreamer selbst oder den Bindings, das sollte IMHO eigentlich nicht passieren. Ich würde das Limit für Core-Dumps erhöhen, so dass man einen Core-Dump erhält, den man dann debuggen kann (und eben bei Bedarf die verwendete Software noch als Debug-Build bauen).

[Barabbas]

Hi Trundle,

jo, sieht tatsächlich nach einem Bug aus - zumindest sollte eine Streaming-Bibliothek nicht direkt abstürzen / das Hauptprogramm mitreißen wenn es mal einen 404 o.ä. bekommt.
Wie kann man den core dumps limitieren? Habe dazu nichts gefunden?

Schönen Gruß,

Daniel

[Trundle]

Alles unter der Annahme, dass du Linux bzw. ein vergleichbares Betriebssystem hast: Mit der bash und zsh geht es z.B. mit ``ulimit -c unlimited``, dann dürfen Core Dumps beliebig groß sein (idR ist das Limit heute standardmäßig 0, dann werden keine Core Dumps erstellt). Wenn du das Programm jetzt aus dieser Shell heraus startest, für die du Core Dumps erlaubt hast, dann wird dir beim nächsten Segfault eine Datei "core" bzw. "core.$PID" (so in die Richtung, kommt eben auf die Einstellungen an) angelegt. Dann kann man das Programm post mortem mit gdb debuggen.