[softhddevice-drm]

  • Mit streamdev-server. Ich schau mal, ob ich da am client und server irgendwelche logs einschalten kann. Und dann versuch ichs auch mal mit einer Aufnahme.

    Die Aufnahme über deinen Player oder über die VDR-Wiedergabe?

  • Es scheint erstmal ein Problem auf dem Server zu sein, da steht einiges im Log. Mal sehen was das ist.

  • Wahrscheinlich nerve ich schon, aber hier ein log, das wohl den gleichen Fehler zeigt: https://pastebin.com/raw/JuVnCwpy

    Den segfault gibt's nachdem ich mit Strg-C abbreche.

    Hier ist das zugehörige Log vom Server: https://pastebin.com/raw/KJ2MBSC1

    Wenn ich es richtig mitbekommen habe, beginnt das Problem auf dem Server, nämlich hier:

    Code
    Mär 01 14:44:44 server01 vdr[22665]: [22669] SDT: channel 1 NID/TID (1/1101) not found, got 133/5
    Mär 01 14:44:44 server01 vdr[22665]: [22668] frontend 0/0 is not receiving transponder 111837 for channel 1 (Das Erste) - retuning

    Um 14:45:09 kommt dann mein Strg-C.

    Das Material kommt von Streamdev-Server, auf "Das Erste (SD)" getunt. Solche Meldungen habe ich zwar mehrere im Log, allerdings scheint es logischerweise nur ein Problem zu geben, wenn gerade das frontend 0/0 betroffen ist, das den streamdev-client bedient. Möglichweise ist das der Auslöser, dass (zumindest zeitweise) kein vernünftiger Stream mehr am Client ankommt, aber den kann ich wohl auch zukünftig nicht durchgehend garantieren.

    Deshalb denke ich, dass das am client abgefangen werden muss, damit der nicht gleich abschmiert. Ob man das in streamdev oder in softhddevice machen sollte, weiß ich nicht. Warum

    Code
    [mpeg2video @ 0xa59828b0] v4l2_request_buffer_alloc: create buffers failed for type 2, Kein Hauptspeicher für den Puffer verfügbar (105)

    den Speicher anmeckert, weiß ich nicht. Lt. /proc/meminfo sollten noch ca. 55MB vom CMA übrig sein... Aber das ist wohl ein Folgefehler.

    Letztendlich wird das Log von

    Code
    FilterHandlerThread: can't get filtered frame: Das Argument ist ungültig

    geflutet, bis ich abbreche.

    Es wäre mir geholfen, wenn softhddevice das irgenwie abfangen kann, da ich bezweifle, dass man den Server dazu verdonnern kann, fehlerfrei zu streamen.

    Ich kanns auch nochmal mit einer Aufnahme probieren, aber ich glaube der Auslöser des Problems ist der Fehler am Server.


    Damit nicht genug, auch folgenden segfault hatte ich https://pastebin.com/raw/z5qNx9Ri - Der hat aber wohl nichts mit dem anderen Problem zu tun ;)


    Für mich ist es schwierig, das ganze zu reproduzieren, da es nur beim Kanalwechsel/Tunen auftaucht - und da halt irgendwann einfach.


    Bin für jede Hilfe dankbar!

    Andreas

    Einmal editiert, zuletzt von rell ()

  • Es wäre mir geholfen, wenn softhddevice das irgenwie abfangen kann, da ich bezweifle, dass man den Server dazu verdonnern kann, fehlerfrei zu streamen.

    Den Server der nicht fehlerfrei streamed würde ich fristlos feuern! Da sollte angesetzt werden.

    den Speicher anmeckert, weiß ich nicht. Lt. /proc/meminfo sollten noch ca. 55MB vom CMA übrig sein

    Wenn ein Buffer mit 0 Byte angefordert wird ist der Fehler der gleiche.

    Damit nicht genug, auch folgenden segfault hatte ich

    Das ist KEIN segfault! Da wird Abgebrochen! Ein FB mit size 0 kann nicht angelegt werden.


    Ich stimme Dir zu das der Decoder ein solches AVFrame nicht weitergeben sollte. Das passiert in der FFmpeg. Da müsste dafür ein Patch erstellt werden.


    Aber vorher geht das Packet durch den Server, durch streamdev Server / Client , wieder vdr und softhddevice-drm, als letztes in der Kette bricht dann ab weil es nix damit anfangen kann. Mann könnte im Decoder ReveiveFrame abprüfen hat das Frame Höhe Breite FD hat. Das würde dann zu einem Programm Abbruch führen.

  • Das ist KEIN segfault! Da wird Abgebrochen! Ein FB mit size 0 kann nicht angelegt werden.

    Stimmt. Mein Fehler.

  • Ich hab gefunden, wo in softhddevice ich es lösen/abfangen könnte. Ich probier das jetzt einfach mal...

    Den Server kann ich momentan nicht beeinflussen. Da ist aktuellster VDR mit sundtek sticks und aktuellen Treibern drauf. Die haben bisher nie Probleme gemacht. Ich bleibe bei meiner Meinung, dass der Client nicht gleich in die Knie gehen darf, wenn der Server Fälscher spielt... Wo auch immer man das abfängt.

    Einmal editiert, zuletzt von rell ()

  • ;) So, gefällt dir wahrscheinlich nicht, dass ich mehrere Baustellen gleichzeitig aufmache, aber folgendes passiert, wenn ich auf den Kanal "Inforadio" schalte:


    Die Meldung oben wiederholt sich oft, dann verabschiedet sich VDR.


    Gruß

    Andreas

  • Danke. Die "Soundkarte" ist das hdmi meines H3...

  • Ja, das ist mein Kernel: https://github.com/rellla/linu…i/commits/vdr-5.10.4-test

    Müssten alle notwendigen von damals drin sein. Habe in der letzten Zeit nicht mehr geschaut, ob sich was geändert hat.


    Ich lasse gerade per Skript alle Kanäle anschalten, "K-TV" taucht mit einer Samplerate von 24000 auf, was ebenfalls zum Crash führt:


    ... nicht dass ich K-TV unbedingt bräuchte ;)

  • Im Ergebnis ist für mich Crash == Abbruch.

  • Ich gebe dir schon recht. Das Problem ist aber doch nicht, ob ich jetzt ein Wort falsch benutzt habe, sondern dass der VDR danach nicht mehr läuft ;)

  • Ich hab gefunden, wo in softhddevice ich es lösen/abfangen könnte. Ich probier das jetzt einfach mal...

    Den Server kann ich momentan nicht beeinflussen. Da ist aktuellster VDR mit sundtek sticks und aktuellen Treibern drauf. Die haben bisher nie Probleme gemacht. Ich bleibe bei meiner Meinung, dass der Client nicht gleich in die Knie gehen darf, wenn der Server Fälscher spielt... Wo auch immer man das abfängt.

    Ich weiß nicht, was streamdev genau macht, aber m.M. nach sollte es die Pakete vom Server-Stream unverändert an den Client durchreichen. Am Ende sitzt halt das Ausgabeplugin. Aber das muss mit den negativen Rückgabewerten von ffmpeg dann auch richtig umgehen, wenn es ffmpeg nutzt. Ein Fehler ist ja auch ein erlaubter Rückgabewert.


    Mit diesen Änderungen hatte ich bisher keine "Ausfälle" mehr, was Stream/Video/Codec-Fehler betrifft. Vielleicht ist ja was dabei, was nützlich ist.


    Gruß

    Andreas

  • Nein, löst es nicht.

    Soweit ich es durchblicke, liegt das eigentliche Problem darin, dass nur 0 oder EAGAIN als Rückgabe von avcodec_send_packet() behandelt werden. Wenn ffmpeg einen anderen Fehler liefert, gibt CodecVideoSendPacket() 0 zurück und läuft in https://github.com/zillevdr/vd…lob/drm/softhddev.c#L1108, was er wohl nicht sollte!?

    Einmal editiert, zuletzt von rell ()

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!