Posts by rell

Jetzt wirds kompliziert, diesmal ein segfault:

Aber das ist doch kein segfault? Ich versuchs nochmal...

[softhddevice-drm]

ist möglicherweise dasselbe. Damals hatte ich mit gdb festgestellt, dass frame hier NULL ist. Die Zeile ist natürlich mittlerweile die 908.

Falls noch benötigt, mache ich morgen nochmal ein bt.

Ja, liefere ich dir morgen

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!?

rell wrote:

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

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

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

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

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

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

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.

zillerbaer wrote:

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

Stimmt. Mein Fehler.

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:

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

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

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

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

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?

Also, hier mal ein Log: https://pastebin.com/raw/nYUp6ej7

und das dazugehörige Syslog https://pastebin.com/raw/hG3c1kcS

Vielleicht kannst du damit was anfangen. Das war meine Version ohne gles kompiliert. Wenn du weitere Infos benötigst, bitte melden.

Gruß

Andreas

https://github.com/LibreELEC/L…ges/linux/package.mk#L113

Ich denke, dass abhängig von der Variable der Kernel und mesa oder die out-of-tree treiber mit binary verwendet werden. Sollte eigentlich der Kernel sein. Und vainfo betrifft doch Vaapi bzw. libva, was du gar nicht brauchst?

Kodi nach libreelec ohne Vdpau und Vaapi zu bauen klappt nicht?

Es würde mich wundern, wenn das für H6 so ausgefallen wäre. Der Kerneltreiber sollte mainline sein und für kodi gibts nur die Deinterlacer Patches für Allwinner.

Braucht man libva überhaupt? Vaapi wird ja nicht benötigt.

... nur so als vage Vermutung

JoeBar wrote:

Kann es sein dass rell da was in seiner Version vergessen hat, also die Benennung des softhddevice-drm.

https://github.com/rellla/vdr-…ommits/drm-atomic-v3-gles

setzt direkt auf zillerbaer auf. Wenn, dann könnte es nur an den Anpassungen in softhddevice-drm.cpp liegen, was ich aber nicht glaube. Hast du den richtigen branch?