Etwas frist Speicher VDR, Streamdev, SoftHdDevice, ffmpeg, VDPAU? VDR

Am besten vielleicht so:

printf("%p realloc(%d -> %d) - %p -> %p\n", this, size, NewSize, data, NewData);

Und in cTsToPes::cTsToPes() bitte noch

printf("%p c'tor\n", this);

und in cTsToPes::~cTsToPes()

printf("%p d'tor %p %d\n", this, data, size);

Klaus

Und ich habe kein System, auf dem dieses Problem auftritt, kann daher leider nicht aktiv testen.

Nachdem du ja die printf()-Zeile für die ersten Ausgaben bereits einbauen konntest, sollte es dir ein Leichtes sein, diese wie oben beschrieben abzuändern und die beiden zusätzlichen printf()-Zeilen jeweils im Constructor und Destructor von cTsToPes einzufügen (gleich am Anfang, vor allen anderen Zeilen in diesen Funktionen).

Wenn du willst, kann ich dir auch einen entsprechenden Patch oder gleich das ganze veränderte remux.c schicken.

Klaus

Wenn der Fehler auch mit dummydevice auftritt, dann sehe ich aber nicht, wie da cTsToPes eine Rolle spielen kann. In cDummyDevice sind alle Ausgabefunktionen quasi leer und machen nur ein 'return Length;'. Es kann also gar nicht dazu kommen, daß jemals ein cTsToPes ins Spiel kommt. Oder übersehe ich da was?

Klaus

Ach so, sorry, das hatte ich übersehen.

Wie gesagt, ich habe leider kein passendes System, mit dem ich selber testen könnte.
Wenn also vielleicht jemand anderes (bei dem der Fehler auftritt) mal den Vorschlag von hier ausprobieren könnte, wäre das vielleicht hilfreich.

Klaus

Ich kann zumindest mal versuchen, ob ich es am Wochenende nachgestellt bekomme.

Lars.

Quote from johns

Der Fehler tritt auch mit DummyDevice (mit Patch=Kommentar) und RpiHdDevice auf. Sobald das Ausgabeplugin die Funktion PlayVideo verwendet und nicht PlayTS.

Moment mal, der Raspberry Pi ist doch ein 32bit System, oder?
Ich dachte, das Problem tritt nur auf, wenn VDR im 64bit-Mode arbeitet!?

Klaus

Hallo Klaus,

bitte sende doch mal den Patch mit den debug printf's. Ich denke ich sehe das Problem auch mit meiner WeTek Play.

Gruß, ollo

Ich habe mal meine Himbeere mit dem Patch über Nacht auf dem Ersten HD laufen lassen - Patch und log habe ich angehängt.

Beim rpihddevice habe ich nach wie vor das (mir unerklärliche) Problem, dass nach einiger Zeit auf dem selben Kanal (24..48h) die Wiedergabe plötzlich abbricht und das Plugin anschliessend beim Umschalten hängenbleibt. Den VDR neu zu starten löst das Problem, auf die Idee, den Speicherverbrauch zu messen bin ich bisher nicht gekommen. Das Problem tritt bei mir übrigens auch mit MPEG2-SD-Streams ab DVB-T auf.

Gruss
Thomas

AFAICS hat der bestehende cTsToPes::GetPes() Code ein Problem, falls
- repeatLast == true und
- Speicherblock bei realloc() verschoben wird
Dann zeigt lastData auf einen ungültigen Speicherblock.

Edit:
Derartige Probleme könnte man vermeiden, wenn man nicht den Pointer, sondern den Offset im Puffer speichern würde.
Aber ehrlich gesagt, verstehe ich den GetPes()-Code noch nicht so recht...

Edit2:
Steht allerdings auch im Kommentar:
"The returned pointer is only valid until the next call to PutTs() or Reset(), or until this object is destroyed."

CU
Oliver

Mit dem ungültigen Speicherbereich hast du Recht. Wenn PutTs() und GetPes() von unterschiedlichen Threads aus aufgerufen würden, dann wäre das echt ein Problem. Das ist aber hier (zum Glück nicht der Fall. Ich halte das aber trotzdem mal fest.

Das Log von reufer erscheint unauffällig. Zumindest sehe ich nichts, was sofort ein "Aha" auslösen würde.

Ich protokolliere jetzt auf meinen RasPis mal den Speicherverbrauch mit, vielleicht sehe ich da ja was...

Klaus

Vorläufiges Ergebnis:
Diese Codestelle ist - zumindest beim Banana-Pi - nicht für den wachsenden Speicherbedarf verantwortlich. Der Block wird bis auf ca. 400 KB vergrößert, dann erfolgt kein realloc mehr. Der Speicherverbrauch von vdr steigt jedoch weiter...

CU
Oliver

Ich protokolliere ja schon seit langem den Speicherbedarf meines Wohnzimmer-VDR (TT S2-6400, 3 x TT S2-3200, 1 x TechniSat AirStar 2), und das sieht z.B. für die letzte Woche so aus wie im ersten angehängten Bild.

Für meine beiden Raspberry Pis (einen im Normalbetrieb und einem zum Testen) habe ich das Protokoll seit gestern Mittag mitlaufen lassen (Bild 2 und 3; der Test-RasPi wurde um ca. 18 Uhr neu gestartet, daher die Unterbrechung).

Wie man sehen kann bleibt der Speicherbedarf recht stabil gleich. Beim Wohnzimmer-VDR gibt es natürlich immer mal wieder Spitzen, wenn Aufnahmen oder Wiedergaben laufen, aber insgesamt kann ich keine steigende Tendenz feststellen.

Von daher würde ich mal sagen, es muß an etwas liegen, das nicht in einer "normalen" Konstellation vorkommt.

Klaus

Sieht gut aus. Womit protokollierst Du das?

Dem Speicherverbrauch nach zu urteilen, ist das 6400er-System eine 32-Bit-Maschine. Richtig?

Bei mir läuft die 6400er auf einem 64-Bit-System (HW: TT-S2-6400, DD Cine S2, Plugins: dvbhddevice, remote, femon). Hier ist der Speicherbedarf mittlerweile auf 285MB (RES) angewachsen...

CU
Oliver

Quote from UFO

Womit protokollierst Du das?

Mit rrdtool. Das Script, das ich hierfür als Datenquelle verwende, sieht so aus:

#!/usr/bin/perl


sub MB
{
  my $s = shift;
  $s /= 1000 unless ($s =~ s/m$//);
  return $s;
}


if ($ARGV[0]) {
   $s = `/usr/bin/top -b -n 1 | grep -w $ARGV[0] | head -1`;
   chomp($s);
   if ($s) {
      $s =~ s/^ *//;
      @a = split(/ +/, $s);
      $Virt = MB($a[4]);
      $Res  = MB($a[5]);
      print "$Virt\n$Res\n";
      exit 0;
      }
   }
print "U\nU\n"

Quote

Dem Speicherverbrauch nach zu urteilen, ist das 6400er-System eine 32-Bit-Maschine. Richtig?

Die Hardware könnte zwar 64bit, aber ich habe ein 32bit-System installiert.

Quote

Bei mir läuft die 6400er auf einem 64-Bit-System (HW: TT-S2-6400, DD Cine S2, Plugins: dvbhddevice, remote, femon). Hier ist der Speicherbedarf mittlerweile auf 285MB (RES) angewachsen...

So ganz sehe ich den Vorteil einer 64bit-Version für VDR eigentlich nicht. Verbraucht nur unnötig viel Speicher...

Klaus

Johns, mini73, and UFO... Just for clarity, are you seeing the memleak on a 32bit or 64bit VDR binary? In my case I see it using Debian testing 64bit, running a 64bit VDR binary.

Quote from kls

So ganz sehe ich den Vorteil einer 64bit-Version für VDR eigentlich nicht. Verbraucht nur unnötig viel Speicher...

Die Disksussion wird immer wieder geführt, aber 64-bit ist heut State-of-the-art überall und das nicht ohne Grund. Auf allen Plattformen ziechnet sich das durch höhere Stabilität aus, weil viele alte 32-bit Zöpfe einfach nicht beachtet werden müssen, ausserdem ist 64-bit vielfach nachgewiesen deutlich schneller. Du findest hier im Portal etliche Threads dazu ... wie auch im WWW.

Ich betreibe seit 2004 ausschließlich 64-bit VDRs und habe keine Probleme, die man nicht auch mit 32-bit hat, Softwarefehler etc.

Regards
fnu