Posts by kfb77

kfb77 · Jun 19th 2020

Ja das mit den Endmarken ist schwierig, weil oft wirklich kein Ende erkennbar ist und nahtlos die nächste Sendung beginnt. Dann setzte ich lieber die Marke ans Ende der Aufnahme, bevor ich das Ende abschneide. Man kann ja abschalten, wenn man sieht, dass die Sendung zu Ende ist. Wenn du mir mal ein Log File hast, wo man ein Ende erkennen kann (Logo fehlt lange genug, dass es erkennbar ist, Balken sind weg, Ton Kanäle ändern sich oder Bild Seitenverhältnis ändert sich) dann schaue ich gerne mal rein, ob ich hier noch was verbessern kann.

Es würde auch noch einen anderen Ansatz zur Lösung des Problems geben: Zumindest die ÖR senden ein gutes VPS Signal mit einer recht zuverlässigen Start und Ende Informationen. Ich denke, die meisten von uns haben aber schon schlechte Erfahrungen mit VPS Aufnahmen gemacht. Wenn es dumm läuft, dann hat man keine Aufnahme.

Ich hatte schon vor ein paar Wochen die Idee, im markad Plugin mir die VPS Events zu holen, zu prüfen und wenn sie sinnvoll erscheinen, als Start und Ende Information zu verwenden. Das Problem dabei ist nur, wenn epg2vdr installiert ist, werden die Events so umgebogen, dass ich sie nicht mehr zuordnen kann. Ich hätte dafür aber auch einen Vorschlag für einen Patch in epg2vdr. Ich werde aber keine Version meines Plugins releasen, dass abhängig ist von einem Patch in einem anderen Plugin, da mache ich mich bei den Distributoren unbeliebt

horchi : bitte melde dich mal hier, damit wir uns dazu austauschen können.

Falls du Interesse hast meinem Prototypen zu testen, melde dich, dann push ich meinen Test Branch. Das zusätzliche Feature funktioniert aber nur bei ÖR, der Rest sendet willkürliche Start Events und keine Stop Events.

kfb77 · Jun 18th 2020

Eine neue Version 2.1.4 ist auf vdr-plugin-markad verfügbar. Neben einiger kleineren Optimierungen wurde vor allem das Suchen des Logos in der Aufnahme optimiert.

kfb77 · Jun 16th 2020

MegaV0lt wrote:

Das Problem ist, dass dann das EPG vom DVB-Stream nicht verwendet wird!

Oder keines gesendet wird. Ich hatte bis 11:00 auch ein wirres EPG an dem Sender, DVB EPG fehlte teilweise, teilweise war es falsch. Seit 11:00 Uhr geht es bei mir wieder.

kfb77 · Jun 12th 2020

Vielen Dank für das Lob.

Durch den Speicherverbrauch Beitrag bin ich auf die Idee gekommen, auch mal cppcheck drüber laufen zu lassen. Da kam einiges dabei raus …

Ich hoffe mal, ich habe damit nichts "kaputt gefixed".

kfb77 · Jun 12th 2020

Eine neue Version 2.1.3 ist auf vdr-plugin-markad verfügbar. Es sind einige Bug Fixes und viele interne Code Optimierungen drin. Außerdem habe ich auch noch versucht, einen Beitrag zum Thema Speicherverbrauch zu leisten:

- 14 Byte Leak pro Aufnahme gefixed (ok, nicht viel, aber Leak ist Leak)

- zum Suchen eventuell vorhandener Leaks habe ich Code hinzugefügt, der sich merkt, für welche Variablen Speicher allokiert oder freigegeben wird. Der Code kann im Plugin Makefile durch Entfernen des Kommentars in der Zeile DEBUGMEMPLUGIN=1 aktiviert werden. Den Status kann man dann über svdrpsend abrufen:

Code

root@VDR-1804:~# svdrpsend PLUG markad DEBUGMEM
220 VDR-1804 SVDRP VideoDiskRecorder 2.4.2; Fri Jun 12 10:36:47 2020; UTF-8
900-markad: unmachted alloc 1 times 9 bytes, line 30, file markad.cpp, variable: bindir
900-markad: unmachted alloc 1 times 16 bytes, line 33, file markad.cpp, variable: logodir
900 markad: unmachted alloc 1 times 22600 bytes, line 217, file markad.cpp, variable: statusMonitor
221 VDR-1804 closing connection

Die Hauptfunktion steckt im, aus VDR Sicht externen Programm, markad. Das Plugin macht fast nichts und startet eigentlich nur markad beim Start einer Aufnahme. Es hat gerade mal 3 Variablen dynamisch allokiert. Beim Start einer Aufnahme kommen noch ein paar dazu, die am Ende der Aufnahme wieder frei gegeben werden.

kfb77 · Jun 10th 2020

kls wrote:

Es ist nicht überraschend, dass die beiden Werte unterschiedlich sind

Vielen Dank fürs überprüfen, ich habe wieder was dazu gelernt.

kfb77 · Jun 10th 2020

Die Klasse cListObject hat einen virtual Destruktor. Soll das heißen, sizeof zeigt zwar die Größe der Basisklasse an, delete gibt aber die richtige Größe frei ? Wenn das so ist, wie soll man da Leaks finden ?

kfb77 · Jun 10th 2020

Mist, copy und paste Fehler aus meinem Test branch.

Ja, der Unterschied ist tatsächlich sogar größer.

Diff

diff --git a/eit.c b/eit.c
index ffdec41..91e7d53 100644
--- a/eit.c
+++ b/eit.c
@@ -38,6 +38,7 @@ cEIT::cEIT(cSectionSyncerHash &SectionSyncerHash, int Source, u_char Tid, const
cSectionSyncerEntry *SectionSyncerEntry = SectionSyncerHash.Get(HashId);
if (!SectionSyncerEntry) {
SectionSyncerEntry = new cSectionSyncerEntry;
+ printf("alloc %ld bytes\n", sizeof(*SectionSyncerEntry)); // alloc 72 bytes
SectionSyncerHash.Add(SectionSyncerEntry, HashId);
}
bool Process = SectionSyncerEntry->Sync(getVersionNumber(), getSectionNumber(), getLastSectionNumber());
diff --git a/tools.c b/tools.c
index 7330fce..1993f5e 100644
--- a/tools.c
+++ b/tools.c
@@ -27,6 +27,7 @@ extern "C" {
#include <utime.h>
#include "i18n.h"
#include "thread.h"
+#include "eit.h"
int SysLogLevel = 3;
@@ -2375,8 +2376,13 @@ void cHashBase::Clear(void)
if (ownObjects) {
cList<cHashObject> *list = hashTable[i];
if (list) {
- for (cHashObject *hob = list->First(); hob; hob = list->Next(hob))
- delete hob->object;
+ for (cHashObject *hob = list->First(); hob; hob = list->Next(hob)) {
+ printf("size hob %ld\n", sizeof(*hob->object)); // 24 bytes of cListObject
+ cSectionSyncerEntry *tmp = (cSectionSyncerEntry *) hob->object; // cast to correct type
+ printf("free %ld bytes \n", sizeof(*tmp)); // size now 72 bytes match alloc size
+ delete tmp; // free 72 bytes
+// delete hob->object; // free 24 bytes
+ }
}
}
delete hashTable[i];

Display More

kfb77 · Jun 10th 2020

kls

Ich versuche es hiermit nochmal einen Beitrag zum finden des Leaks zu leisten:

Mir ist am dem von dir angesprochen Leak Patch aufgefallen, dass hier noch was nicht stimmen könnte.

In der eit.c wird ein Objekt vom Type cSectionSyncerEntry (child object von cListObject und cSectionSyncer und somit größer als cListObject) allokiert, in der tools.c wird aber ein Objekt vom Type cListObject wieder freigegeben. Und das ist 32 Bytes kleiner.

Patch, der das Problem aufzeigt und fixed (sollte jemand das verwenden wollen, bitte erst die printf entfernen, die sind nur zum Aufzeigen des Speichers drin):

Diff

diff --git a/eit.c b/eit.c
index ffdec41..91e7d53 100644
--- a/eit.c
+++ b/eit.c
@@ -38,6 +38,7 @@ cEIT::cEIT(cSectionSyncerHash &SectionSyncerHash, int Source, u_char Tid, const
cSectionSyncerEntry *SectionSyncerEntry = SectionSyncerHash.Get(HashId);
if (!SectionSyncerEntry) {
SectionSyncerEntry = new cSectionSyncerEntry;
+ printf("alloc %ld bytes\n", sizeof(*SectionSyncerEntry)); // alloc 72 bytes
SectionSyncerHash.Add(SectionSyncerEntry, HashId);
}
bool Process = SectionSyncerEntry->Sync(getVersionNumber(), getSectionNumber(), getLastSectionNumber());
diff --git a/tools.c b/tools.c
index 7330fce..7328463 100644
--- a/tools.c
+++ b/tools.c
@@ -27,6 +27,7 @@ extern "C" {
#include <utime.h>
#include "i18n.h"
#include "thread.h"
+#include "eit.h"
int SysLogLevel = 3;
@@ -2375,8 +2376,13 @@ void cHashBase::Clear(void)
if (ownObjects) {
cList<cHashObject> *list = hashTable[i];
if (list) {
- for (cHashObject *hob = list->First(); hob; hob = list->Next(hob))
- delete hob->object;
+ for (cHashObject *hob = list->First(); hob; hob = list->Next(hob)) {
+ printf("size hob %ld\n", sizeof(*hob)); // 40 bytes of cListObject
+ cSectionSyncerEntry *tmp = (cSectionSyncerEntry *) hob->object; // cast to correct type
+ printf("free %ld bytes \n", sizeof(*tmp)); // size now 72 bytes match alloc size
+ delete tmp; // free 72 bytes
+// delete hob->object; // free 40 bytes
+ }
}
}
delete hashTable[i];

Display More

Deine Meinung dazu ?

kfb77 · Jun 7th 2020

Ich widerspreche hier mir mal selber: Die Größe wird über allocated verwaltet, size bestimmt nur die belegte Objekte. Somit alles richtig.

Sorry for the noise.

kfb77 · Jun 7th 2020

Jetzt haben sich die Posts überschnitten.

kls wrote:

Ich denke nicht, denn hier wird ja innerhalb eines bestehenden Speicherblocks ein Teil davon "nach vorne" verschoben. Der Speicherblock als Ganzes bleibt unverändert.

Stimmt, müsste dann aber nicht size gleich bleiben, damit der freie Platz hinten auch wieder für ein neues Element verwendet wird.

kfb77 · Jun 7th 2020

Mir fällt grade auf, dass das satip Plugin crashed mit dem Patch, also besser mal nicht verwenden:

kfb77 · Jun 7th 2020

kls

Ich glaube, ich habe einen Leak gefunden: Müsste nach einem memmove nicht auch ein realloc kommen, um den Speicher freizugeben ?

Diff

diff --git a/tools.h b/tools.h
index 614130d..d9bef46 100644
--- a/tools.h
+++ b/tools.h
@@ -755,6 +755,7 @@ public:
if (Index < size - 1)
memmove(&data[Index], &data[Index + 1], (size - Index) * sizeof(T));
size--;
+ data = (T *)realloc(data, size * sizeof(T));
}
bool RemoveElement(const T &Data)
{

Display More

kfb77 · Jun 4th 2020

stimmt, das ist ein Nachteil davon.

kfb77 · Jun 4th 2020

Warum unbedingt ein VDR Plugin. Ich nutze dafür minidlna.

kfb77 · Jun 4th 2020

CKone und ofenheizer

Wenn ich das richtig verstanden habe, startet ihr markad aus einem eigenen Befehl in der Reccmds.conf. Zumindest habe ich im VDR Standard Menü nichts gefunden, mit dem man markad manuell starten könnte.

Wenn ihr das unbedingt so beibehalten wollt, nur markad auf dem Server starten wollt, gibt es eine ganz einfache Lösung:

Ändert in eurem Skript den Aufruf von markad <Pfad zur Aufnahme auf dem Client> in:

svdrpsend -d <Server Name oder IP> PLUG markad mark <Pfad zur Aufnahme auf dem Server>

Die Funktion markad über svdrpsend zu starten gab es schon immer.

kfb77 · Jun 4th 2020

Das muss man doch nicht von Hand starten:

Einstellungen -> Plugins -> markad -> Ausführung: während

Dann startet der Server markad immer selbst, wenn eine Aufnahme gestartet wird.

kfb77 · Jun 4th 2020

CKone

OK, die Anwendung verstehe ich, aber warum dann nicht gleich grundsätzlich markad über das Plugin auf dem Server starten ?

kfb77 · Jun 4th 2020

ofenheizer

Ich habe eine Anleitung gebaut:

Code

markad_videos
This programm let markad run on a video directory to build all missing markad files.
See markad_video -h and markad_video.conf for more informations.
Install instruction to execute markad_video each hour:
Requirements:
- anacron runs on your system
- you have a user vdr with write access to the video directory
- execute the commands as root or with sudo ...
cd <path to the contrib directory of the source code of markad>
cp markad_videos /usr/local/bin/
chmod a+x /usr/local/bin/markad_videos
cp markad_videos.conf /etc
chmod a+r /etc/markad_videos.conf
cp start_markad_videos /etc/cron.hourly
chown root:root /etc/cron.hourly/start_markad_videos
chmod a+rx /etc/cron.hourly/start_markad_videos
chmod o-w /etc/cron.hourly/start_markad_videos
Edit /etc/markad_videos.conf to fit your requirements (especially path=...)

Display More

Die fehlende Datei und die o.g. Anleitung findest du auf dem aktuellen Entwickler Branch im git:

git clone -b V02 https://github.com/kfb77/vdr-plugin-markad

kfb77 · Jun 4th 2020

Eine neue Version 2.1.2 ist auf vdr-plugin-markad verfügbar. Es sind einige Bug Fixes drin. Die wichtigste Änderung:

Fix marks for channels who always send AC3 with 6 channels. Change of value Cx to Dx in logo file for channels that continuously transmit 6 audio channels is no longer necessary.

Posts by kfb77

[markad] überarbeiteter Decoder

[markad] überarbeiteter Decoder

[epgd] Kein EPG bei Downloadfehler?

[markad] überarbeiteter Decoder

[markad] überarbeiteter Decoder

Speicherverbrauch steigt mit der Zeit

Speicherverbrauch steigt mit der Zeit

Speicherverbrauch steigt mit der Zeit

Speicherverbrauch steigt mit der Zeit

Speicherverbrauch steigt mit der Zeit

Speicherverbrauch steigt mit der Zeit

Speicherverbrauch steigt mit der Zeit

Speicherverbrauch steigt mit der Zeit

yavdr ansible

yavdr ansible

[markad] überarbeiteter Decoder

[markad] überarbeiteter Decoder

[markad] überarbeiteter Decoder

[markad] überarbeiteter Decoder

[markad] überarbeiteter Decoder