[Matthias]

Ja, genau die dsyslog Aufrufe sind natürlich weiterhin enthalten und kann bei jeder MLD Installation im Wegif (System / Konfiguration / System ==> Loglevel) eingestellt werden. Wir löschen nur die erweiterten Debugobjekte, aber die brauchst Du ja aktuell auch nicht.

Gruß,

Pit

Pit
Welches Loglevel benötigt Eike für die Fehlersuche?

Matthias

[clausmuus]

Ich vermute das bei den VDR Aufrufargumenten der das -l1 durch ein -l3 ersetzt werden muss. Interessant dürfte für Ihn dann die /var/log/messages sein (die gibt's auch im Webif).

[Matthias]

Interessant dürfte für Ihn dann die /var/log/messages sein (die gibt's auch im Webif).

Na so doof bin ich auch nicht 

[Matthias]

Wenn Du mehr oder andere Infos benötigst lass es mich bitte wissen.

Ich hab die Daten bekommen, aber da ist keine einzige Log-Ausgabe von Permashift drin.
Hast du den Loglevel geändert?
Siehe Anleitung von Pit:

Ja, genau die dsyslog Aufrufe sind natürlich weiterhin enthalten und kann bei jeder MLD Installation im Wegif (System / Konfiguration / System ==> Loglevel) eingestellt werden.

Wenn du an die Logs rankommst, kannst du sie mir auch direkt schicken (gerne als PM).

Gesundheit!
  Eike

Bitte schön ;-)
Ab hier fange ich an zu zappen:
Jun 22 09:18:07 MLD user.debug vdr: [2072] permashift: 200 MB live video data in buff

[P3f]

Hallo Eike,

ich hänge nun mal auch meine Umgebung hier mit rein. Es ist zwar schon der VDR 2.5.5, aber das Fehlerverhalten beim Zappen habe ich auch, sobald das Permashift Plugin aktiv ist.

Und ja der Loglevel ist beim VDR-Argument auf "l -3" gesetzt und dann auch das /var/log/message File beschreiben lassen. Also so wie es Matthias auch bereitstellt. Danke...

Das komplette Debug-Log hänge ich direkt zum Download an.

Gruß,

Pit

[rfehr]

Hi Zusammen,

Ich habe das vermehrt nur wenn ich mehr als 1 DVB Device habe.

Gruß,
  Roland

[Matthias]

Hi Zusammen,

Ich habe das vermehrt nur wenn ich mehr als 1 DVB Device habe.

Gruß,
  Roland

Bei mir sind es 3 Devices über Sat Over IP - falls das weiterhilft

[rfehr]

Hi Zusammen,

Ich habe das vermehrt nur wenn ich mehr als 1 DVB Device habe.

Gruß,
  Roland

Bei mir sind es 3 Devices über Sat Over IP - falls das weiterhilft

Ich habe auch SatIp, du kannst ja mal testen ob es besser ist, wenn die MLD nur 1 Device hat.

Gruß,
  Roland

[Matthias]

Bei mir ist es egal ob ich 1, 2 oder 3 Devices aktiviere

[P3f]

Hi,

bei mir ist es sogar bei jedem Kanalwechsel provozierbar. Und ich habe nur lokale DVB-Karte drin (1xDD Dual PCI-Express)

Sollte unabhängig von Anzahl der DVB Device und Satip vs. lokale Einspeisung sein

Der Fehler liegt woanders, IMHO

Pit

[Ein Eike]

Hallo,

scheint der Destruktor von cBufferReceiver zu sein.
Pit, kannst du nochmal mit dem aktuelle Git probieren und das Log schicken?

Gesundheit,
  Eike

[P3f]

Hallo EIke,

das mache ich gerne, habe auch gesehen, dass Du in deinem GIT ein paar Log-ausgaben mit eingebunden hast. Weiterhin habe ich auch noch ein wenig ausprobiert. Und seit ca 2 Stunden läuft bei mir der VDR -mit häufigem Kanalwechsel- mit permashift stabil.

Ich habe gesehen, das sobald die NaluDump Erweiterung im VDR entfernt ist, alles scheinbar funktioniert. Es kommt kein Notausstieg mehr und im /var/log/messages stehen auch einige Logeinträge. Das aktuelle Debug-Log habe ich hier mal angehängt.

Also ich vermute, das bei EInbindung vom NaluDump-Funktion im VDR via Patch der cBufferReceiver gekillt wird. Weisst Du wie man das sucht? Aktuell könnte ich damit leben, das wir kein NaluDump für die Aufnahmen haben.

Und dann muß ich noch etwas gestehen, wie wird denn Permashift bedient? Aktuell bin ich froh, das der VDR stabil läuft mit Permashift. Muß morgen mal in deinen Anleitung die Bedienung nachlesen.

@MAtthias: Wenn Du diese Installation auch auf deinem NUC mal probieren willst, dann bitte in deiner MLD 5.5 unstable (x86) in der /etc/rc.config den Eintrag

Code: [Select]

APT_DEVELOPER="Buster" einfügen. Zeile ist dort schon vorhanden, nur der Developer muß dort eingetragen werden. Danach bitte 2x apt-get update und dann kommt das Update komplett zu Dir.

Am besten vorher noch prüfen, ob die automatische Datensicherung aktiv ist, dann kannst Du jederzeit zurück.

Ok?

Gruß,

Pit

[Ein Eike]

Hallo!

Das sind ja mal gute Nachrichten!

das mache ich gerne, habe auch gesehen, dass Du in deinem GIT ein paar Log-ausgaben mit eingebunden hast. Weiterhin habe ich auch noch ein wenig ausprobiert. Und seit ca 2 Stunden läuft bei mir der VDR -mit häufigem Kanalwechsel- mit permashift stabil.

Ich habe gesehen, das sobald die NaluDump Erweiterung im VDR entfernt ist, alles scheinbar funktioniert. Es kommt kein Notausstieg mehr und im /var/log/messages stehen auch einige Logeinträge. Das aktuelle Debug-Log habe ich hier mal angehängt.

Also ich vermute, das bei EInbindung vom NaluDump-Funktion im VDR via Patch der cBufferReceiver gekillt wird. Weisst Du wie man das sucht? Aktuell könnte ich damit leben, das wir kein NaluDump für die Aufnahmen haben.

Macht absolut Sinn, der vertut sich hier wohl...

Jun 22 19:51:02 MLD user.info vdr: [22825] NALU fill dumper: -16777216 of 0 packets dropped, 0%

"-16777216" Pakete, wer weiß, was er da tut...!

In deinem Log habe ich nichts Spannendes gefunden - ich vermute, das war der Gutfall?
Aber die Zusammenarbeit mit NaluDump scheint ja der richtige Pfad zu sein.
Vielleicht kann man da noch tiefer reinschauen.
Es klingt schon nach einer erhaltenswerten Funktionalität.

Und dann muß ich noch etwas gestehen, wie wird denn Permashift bedient? Aktuell bin ich froh, das der VDR stabil läuft mit Permashift. Muß morgen mal in deinen Anleitung die Bedienung nachlesen.

Asche auf dein Haupt!
In der Theorie kannst du während des Fernsehens einfach zurückspulen oder pausieren.
In der Praxis ist es manchmal hakelig (er versucht gleichzeitig, den RAM-Buffer rückwärts zu speichern,
davon das Zurückspulen zu befriedigen und natürlich weiterhin aufzunehmen - klappt nicht immer schön).
Bedientechnisch bist du dann im Abspielen eines Recordings mit den von da bekannten Tasten.
Außerdem würde eine beim Live Fernsehen gestartete Aufnahme mit dem RAM-Buffer anfangen,
man könnte also, wenn man sich früh in einem Film entscheidet, den aufzunehmen,
den schon gesehenen Anfang automatisch mitnehmen. (Ich hatte das mal mit Old Boy.)

Gesundheit!
  Eike

PS: Ab Montag werde ich erstmal zwei Wochen lang wenig Zeit haben...

[Ein Eike]

An die Programmierer unter euch...

Also, ich habe das Gefühl,
der Member naluStreamProcessor in cRecorder ist uninitialisiert und beim delete passiert dann der Mist.

Was ich allerdings nicht verstehe, weil mein Konstruktor den Basiskonstruktor aufruft...

Code: [Select]

cBufferReceiver::cBufferReceiver() : cRecorder(NULL, NULL, -1),

... und der den Member nicht unschön hinterlassen sollte:

Code: [Select]

cRecorder::cRecorder(const char *FileName, const cChannel *Channel, int Priority)
:cReceiver(Channel, Priority)
,cThread("recording")
{
  recordingName = strdup(FileName);

  // Make sure the disk is up and running:

  SpinUpDisk(FileName);

  ringBuffer = new cRingBufferLinear(RECORDERBUFSIZE, MIN_TS_PACKETS_FOR_FRAME_DETECTOR * TS_SIZE, true, "Recorder");
  ringBuffer->SetTimeouts(0, 100);
  ringBuffer->SetIoThrottle();

  int Pid = Channel->Vpid();
  int Type = Channel->Vtype();
  if (!Pid && Channel->Apid(0)) {
     Pid = Channel->Apid(0);
     Type = 0x04;
     }
  if (!Pid && Channel->Dpid(0)) {
     Pid = Channel->Dpid(0);
     Type = 0x06;
     }
if (   Type == 0x1B // MPEG4 video
&& (Setup.DumpNaluFill ? (strstr(FileName, "NALUKEEP") == NULL) : (strstr(FileName, "NALUDUMP") != NULL))) { // MPEG4
isyslog("Starting NALU fill dumper");
naluStreamProcessor = new cNaluStreamProcessor();
naluStreamProcessor->SetPid(Pid);
}
else
naluStreamProcessor = NULL;

[rfehr]

An die Programmierer unter euch...

Also, ich habe das Gefühl,
der Member naluStreamProcessor in cRecorder ist uninitialisiert und beim delete passiert dann der Mist.

Was ich allerdings nicht verstehe, weil mein Konstruktor den Basiskonstruktor aufruft...

Code: [Select]

cBufferReceiver::cBufferReceiver() : cRecorder(NULL, NULL, -1),

... und der den Member nicht unschön hinterlassen sollte:

Code: [Select]

cRecorder::cRecorder(const char *FileName, const cChannel *Channel, int Priority)
:cReceiver(Channel, Priority)
,cThread("recording")
{
  recordingName = strdup(FileName);

  // Make sure the disk is up and running:

  SpinUpDisk(FileName);

  ringBuffer = new cRingBufferLinear(RECORDERBUFSIZE, MIN_TS_PACKETS_FOR_FRAME_DETECTOR * TS_SIZE, true, "Recorder");
  ringBuffer->SetTimeouts(0, 100);
  ringBuffer->SetIoThrottle();

  int Pid = Channel->Vpid();
  int Type = Channel->Vtype();
  if (!Pid && Channel->Apid(0)) {
     Pid = Channel->Apid(0);
     Type = 0x04;
     }
  if (!Pid && Channel->Dpid(0)) {
     Pid = Channel->Dpid(0);
     Type = 0x06;
     }
if (   Type == 0x1B // MPEG4 video
&& (Setup.DumpNaluFill ? (strstr(FileName, "NALUKEEP") == NULL) : (strstr(FileName, "NALUDUMP") != NULL))) { // MPEG4
isyslog("Starting NALU fill dumper");
naluStreamProcessor = new cNaluStreamProcessor();
naluStreamProcessor->SetPid(Pid);
}
else
naluStreamProcessor = NULL;

Hi Eike,

hast du mal die Stelle wo das delet gemacht wird,
denn naluStreamProcessor kann ja auch 'NULL' sein.

Gruß,
  Roland