Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Ein Eike

1
Der Permashift-Patch ändert den Konstruktor von cRecorder,
dadurch scheint die Initialisierung von "naluStreamProcessor" nicht zum Zuge zu kommen.

Ob es die Funktionalität komplett erhalten würde, weiß ich nicht,
aber ich würde vorschlagen, den naludump-Patch so zu ändern:

Statt...

Code: [Select]
+++ vdr-2.4.1-naludump-0.1/recorder.h   2014-03-30 17:47:25.000000000 +0200
@@ -21,6 +21,7 @@
   cRingBufferLinear *ringBuffer;
   cFrameDetector *frameDetector;
   cPatPmtGenerator patPmtGenerator;
+  cNaluStreamProcessor *naluStreamProcessor;
   cFileName *fileName;
   cIndexFile *index;
   cUnbufferedFile *recordFile;

... besser ...

Code: [Select]
+++ vdr-2.4.1-naludump-0.1/recorder.h   2014-03-30 17:47:25.000000000 +0200
@@ -21,6 +21,7 @@
   cRingBufferLinear *ringBuffer;
   cFrameDetector *frameDetector;
   cPatPmtGenerator patPmtGenerator;
+  cNaluStreamProcessor *naluStreamProcessor = NULL;
   cFileName *fileName;
   cIndexFile *index;
   cUnbufferedFile *recordFile;

Probiert das mal.

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

Sieht sauber aus:

Code: [Select]
cRecorder::~cRecorder()
{
  Detach();
  if (naluStreamProcessor) {
     long long int TotalPackets = naluStreamProcessor->GetTotalPackets();
     long long int DroppedPackets = naluStreamProcessor->GetDroppedPackets();
     isyslog("NALU fill dumper: %lld of %lld packets dropped, %lli%%", DroppedPackets, TotalPackets, TotalPackets ? DroppedPackets*100/TotalPackets : 0);
     delete naluStreamProcessor;
     }


(delete auf NULL wäre übrigens sogar legal: https://stackoverflow.com/a/4190733 )

3
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;

4
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. :D

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...

5
Hallo,

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

Gesundheit,
  Eike

6
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

7
Die Debug Logs habe ich hochgeladen:
Dein Upload Code lautet: HF9lKk

Laut Hilfeseite kann ich darauf wohl nicht zugreifen.
Pit, kannst du mir das zukommen lassen?

Ich möchte erstmal über Debug-Ausgaben versuchen, der Sache näherzukommen...
(Wird sicherlich ein paar Runden brauchen.)

8
Nur mal eine kurze Zwischenfrage: Eike, hast Du Dir zum testen eine MLD installiert?

Ich habe kein MLD.
An meinem PC hab ich seit der DVB-T-Abschaltung kein Signal mehr und mein "Produktiv"-System möchte ich nicht anrühren.
Deshalb bin ich auf Mithilfe und Stochern angewiesen...

9
Lass uns erst mal das für den VDR 2.4.7 vollenden, für den VDR 2.5.5 sollte dann der Aufwand (für mich) überschaubar sein und die notwendsigen Anpassungen einbauen. Das also später.

Ich bin leider etwas pessimistisch. Der Fehler scheint ja sporadisch zu sein - das sind die fiesesten...

Ja, wir nutzen bei jedem Neubau vom Permashift den aktuellsten Permashift aus dem Mastergit bei Dir. Ist es Problem? (Weil bereits Anpassungen für den VDR 2.5.x eingeflossen sind?)

Das ist prima; vielleicht hast du vorhin sogar ein paar neue Syslog-Aufrufe mitgenommen.
Der Plan ist, dass Permashift mit jeder Stable VDR-Version der letzten und zukünftigen Jahre läuft, ich baue nicht (absichtlich) Imkompatibilitäten ein. Zur Not gäb's ein "#if VDRVERSNUM > ...".

10
Hallo!

Allerdings verstehe ich nicht deine Anmerkungen zu dem zusätzlichen Parameter der übergeben werden sollte. Aktuell ist der Patch so aufgebaut wie Du ihn zitiert hast. Soll nun die Zeile (mit dem "reused") enthalten sein, oder nicht?

Das bezog sich auf dem defect-Patch.
Für die Akten:
"RecordControls = new cRecordControl(device, Timers, Timer, Pause);" ist das Original und sollte rausgepatch sein (da fehlte das Minus davor),
"RecordControls = new cRecordControl(device, Timers, Timer, Pause, reused);" ist richtig und sollte reingepatcht werden.
Aber das hat sich ja erledigt, wenn der Patch nicht zur Anwendung kommt.

Natürlcih sind wir auch in der Vorbereitung für den VDR 2.5.5, wo wir gerne Permashift übernehmen. Wenn ich Dir einen Link zum Dwonload bereitstellen darf so gebe gerne Bescheid.

Du darfst mir immer alles bereitstellen, aber ich würd' erstmal auf den aktuellen Bug kucken.

Wenn wir ein paar Debugausgaben einbauen sollen, gib mir bitte entsprechende Positionen, dann baue ich es gerne ein.... Aktuell sind die Debugobjekte nicht mit in der Bereitstellung.

Ich meinte dsyslog-Aufrufe, die dann bei entsprechender Logging-Stufe (kann man die in MLD einstellen?)
im Syslog landen sollten. Ich hab schon mal ein paar in den Permashift-Code eingebaut.
(Mit Debugobjekten meinst du Binaries? Die braucht die Methode nicht.)
Versteh ich das richtig, dass MLD beim Bauen automatisch den jeweiligen Master-Stand von permashift verwendet?

Gesundheit!
  Eike

11
So, ich habe gestern die Installation Schritt für Schritt durchgeführt und es ist das Permashift Plugin, welches die Abstürze verursacht

Kannst du die Debug-Ausgaben aktivieren und ins Syslog schauen?
Permashift sollte gelegentlich sowas melden wie ..."live video data in buffer"
Wenn wir sowas sehen, könnten wir den Code mit zusätzlichen Debug-Ausgaben spicken, um dem Problem näherzukommen.

12
In den Sourcen finden sich zwei Permashift-Patches für den VDR:
vdr/src/27_vdr_permashift.patch 
vdr/src/27_vdr_permashift.patch_defect

Der, der MLD-27_vdr_permashift.patch_defect heißt, ist (erstaunlicherweise ;) ) defekt.
Es sollte eine Zeile ausgewechselt werden, um einen zusätzlichen Parameter zu übergeben,
stattdessen wird der Aufruf doppelt gemacht, einmal mit und einmal ohne Zusatzparameter:

Code: [Select]
@@ -6436,6 +6458,7 @@
            for (int i = 0; i < MAXRECORDCONTROLS; i++) {
                if (!RecordControls[i]) {
                   RecordControls[i] = new cRecordControl(device, Timers, Timer, Pause);
+                 RecordControls[i] = new cRecordControl(device, Timers, Timer, Pause, reused);
                   cStatus::MsgRecordingFile(RecordControls[i]->FileName());  // PIN PATCH
                   return RecordControls[i]->Process(time(NULL));
                   }
Außerdem fehlt der Kamel-Fix:
https://www.vdr-portal.de/forum/index.php?thread/134171-permashift-1-0-4-f%C3%BCr-vdr-2-4-betaversion/&postID=1335480#post1335480

Ich hoffe/vermute, der "*defect"-Patch ist nicht aktiv?

13
Hallo,

der Permashift-Entwickler hier.

Wo finde ich die Sourcen, die da verwendet werden?
Über eure Hauptseite habe diese Git-Quellen gefunden,
das werden wohl nicht die aktuellen sein:
https://www.minidvblinux.de/git/?a=summary&p=vdr-plugin-permashift

*edit*
Die VDR-Patches habe ich - hoffe ich - gefunden,
falsch war wohl git clone http://minidvblinux.de/git-5/MLD.git vdr
erfolgreicher git clone http://minidvblinux.de/git-5/vdr.git vdr

*mehredit*
MLD 5.5 unstable verwendet VDR 2.4.7, ist das richtig?

Ciao,
  Eike

14
x86 Systeme (PC) / Permashift MLD 5.4 testing
« on: April 26, 2021, 17:32:13 »
Hallo Pit,

ich bin 2017 stolzer Zwillings-Vater geworden... und hab leider bis heute praktisch keine Zeit für nix.
Es läuft ja grundsätzlich bei anderen im VDR (siehe Beta-Thread im VDR-Portal).
Was ich machen könnte wär ein Code-Review, wenn ihr mir zeigt, wo ich die Quellen mit euren Patches bekomme (git, tgz, ...).
Letztens 2014 ;) hatte das ja schon mal geholfen.

Gesundheit!
  Eike

15
x86 Systeme (PC) / Permashift MLD 5.4 testing
« on: April 25, 2021, 20:55:42 »
Hallo!

ich habe mal deine Sourcen nun neu eingebunden, und das für die MLD 5.5 unstable bereitgestellt.

Allerdings bitte ich Dich um eine aktive Testung, da wir beim letzten Mal starke Seiteneffekte hatten. Daher nahmen wir erstmal die Funktion Permashift raus.
In der MLD 5.5 ist auch schon der VDR 2.4.7 enthalten, somit also die aktuelleste Version.

Danke, fürs Testen und Rückmeldung geben.

Ich weiß nicht, ob wir nun ein Missverständnis hatten:
Ich würde mich freuen, wenn Permashift in MLD bleibt, weil ich Permashift geschrieben habe.
Bei mir läuft was anderes (ein altes EasyVDR).
Ich hab leider auch kaum noch die Möglichkeit, an meinem Desktop zu testen (seit DVB-T abgeschaltet ist).

@razie: Ich hoffe, du kannst testen?

Gesundheit!
  Eike