epgsearch für vdr 2.3.x

Zitat von jasminj

Sag Stefan, wie reproduziert man das am besten?

Direkt beim starten des VDR passiert es sowieso, und wenn ich es reproduzieren will brauch ich die Suche nur manuell über das Menü anschieben. Im Setup habe ich "Suche" auf "Blau" gestellt. Kann dann im "Programmführer" auf Taste Blau "Suche" gehen, dort auf "Aktion" und wähle dann "Suchtimer jetzt aktualisieren". Kurz danach lässt sich der VDR nicht mer bedienen und im Log sieht es dann, gekürzt auf die relevanten Teile, so aus.

May  1 13:59:01 vdr-server vdr: [807] confirm: Suchtimer-Update ausführen?
May  1 13:59:01 vdr-server vdr: [807] warning: Suchtimer-Update ausführen?
May  1 13:59:04 vdr-server vdr: video: 22:12:50.556  +17  259   0/\ms   5+7+4 v-buf
May  1 13:59:08 vdr-server vdr: [807] confirmed
May  1 13:59:08 vdr-server vdr: [841] EPGSearch: search timer update started
May  1 13:59:52 vdr-server vdr: [1029] animator thread thread ended (pid=807, tid=1029)
May  1 13:59:53 vdr-server vdr: [841] EPGSearch: search timer update finished
May  1 13:59:53 vdr-server vdr: [841] EPGSearch: check for timer conflicts
May  1 13:59:53 vdr-server vdr: [841] EPGSearch: check for timer conflicts - done
May  1 13:59:53 vdr-server vdr: [855] VNSI: Requesting clients to reload recordings list
May  1 13:59:53 vdr-server vdr: [855] VNSI: Requesting clients to reload timers
May  1 13:59:54 vdr-server vdr: [807] info: Suchtimer-Update durchgeführt!
May  1 13:59:54 vdr-server vdr: [807] [softhddev]CreateOsd: left 96, top 864, level 0, using OpenGL OSD support
May  1 13:59:54 vdr-server vdr: [807] [softhddev]cOglOsd osdLeft 96 osdTop 864 screenWidth 1920 screenHeight 1080

Die von mir zuvor genannten 20 Sekunden waren geschätzt und wohl geschmeichelt , es sind hier zumindest 46 Sekunden die ich mit dem VDR nix anfangen kann.

Gruss

Stefan

Zitat von fnu

Commit 0001-Fix-warning-in-pending_notifications.c.diff ...

Den müssen wir leider wieder löschen, weil in VDR 2.3.4 hat Klaus den Datentyp wieder zurück geändert, das das Warning verursacht hat. Das geht mit:

git revert --strategy resolve 374311f7650d03d2f59cb81a321b7d721e7ce5eb

Sorry, aber ich habe erst jetzt das Plugin für VDR 2.3.4 übersetzt.

Zitat von fnu

Die Quellen habe ich in HISTORY/HISTORY.DE referenziert.

Danke!
Sehr schön hat er das gemacht!

Wenn der 0001-Fix-warning-in-pending_notifications.c.diff wieder weg ist, dann brauchst ihn einfach nur aus der History löschen. Ist ja alles eine Beta Version und da passt das schon so.

Apropos: Ich würde die Version nicht 1.0.1betaX, sondern 1.1.0betaX oder 1.0.2betaX nennen, weil es ja die Beta für eine neue und ned die alte Version ist. Außerdem bevorzuge ich "rc-X" für "Release Candidate", aber auch das ist Geschmackssache.
Und du musst dir Überlegen wie du die Release Nummern zählst. Wenn es wie beim VDR ist, dann wären Betas 1.1.x und die Release wäre dann 1.2.0.
Diese Zählweise ist zwar ungewöhnlich, aber der VDR macht es so und deshalb mach ich es beim ddci2 auch so.
Wie auch immer, das darf der Maintainer entscheiden

Zitat von Hollywood

Code

May  1 13:59:08 vdr-server vdr: [841] EPGSearch: search timer update started
May  1 13:59:53 vdr-server vdr: [841] EPGSearch: search timer update finished

Sieht so aus, als wäre es hier, aber der Lock ist in einem eigenen Block:

// wait if TimersWriteLock is set or waited for
         {
             LOCK_TIMERS_READ;
         }

Also wird es das nicht sein. Zumindest nicht offensichtlich für mich erkennbar.

Da muss man wohl doch mit dem GDB ran.

LG,
Jasmin

Zitat von jasminj

Wenn es wie beim VDR ist, dann wären Betas 1.1.x und die Release wäre dann 1.2.0.
Diese Zählweise ist zwar ungewöhnlich, aber der VDR macht es so

Das hat der Linux Kernel früher auch so gemacht, von da hab ich das übernommen.
Nur daß ich halt bei dieser Konvention bleibe und sie nicht - wie der Kernel - wieder über Bord werfe... ;-).

Klaus

Zitat von jasminj

Den müssen wir leider wieder löschen, weil in VDR 2.3.4 hat Klaus den Datentyp wieder zurück geändert, das das Warning verursacht hat. Das geht mit:

Ja, rofafor hat da auch drauf hingewiesen, hab ihn aber nicht rausgenommen, sondern drin gelassen, weil bis 2.3.3 war es offensichtlich richtig. Nun gibt es eben einen weiteren Commit der das wieder ändert, ausdrücklich für VDR 2.3.4+ ...

Den Stand vor all den neuen Commits habe ich als stable Branch für "vdr-2.2.x" eingefroren, da alle Änderungen seither/von heute rein auf VDR 2.3.x abzielen.

Das mit der Version habe ich mir heute auch schon überlegt. Ich finde das beta lässt man einfach irgendwann weg und versioniert schlicht 1.1.0 wenn man sich einig ist, die Version läuft wie gewünscht mit VDR 2.3.x ... evtl. pusht man master jetzt auf 1.0.2 ...

Regards
fnu

Zitat von jasminj

Und du musst dir Überlegen wie du die Release Nummern zählst. Wenn es wie beim VDR ist, dann wären Betas 1.1.x und die Release wäre dann 1.2.0.

So könnten wir es machen ... eigentlich will ich das gar nicht entscheiden, hätte ich mal bloß "weg gesagt" ...

Im Prinzip könnte man den Branch vdr-2.2.x als Version 1.0.2 (stable) festlegen, der Stand ist ja viele Jahre geprüft und vielfach stabil im Einsatz, Einwände?

Master mache ich jetzt zu Version 1.1.0 (developer). Einwände?

Ich war noch ein Freund von diesen -beta oder -rc Anhängen, Release Candidate für 6 Jahre oder so ...

Regards
fnu

Zitat von fnu

Ich war noch ein Freund von diesen -beta oder -rc Anhängen, Release Candidate für 6 Jahre oder so ...

Kann es sein, daß hier ein "nie" fehlt?

BTW: bezüglich der Versionsnummerierung gibt es eigentlich seit jeher eine Vorgabe in der PLUGINS.html.

Zitat

A new plugin project should start with version number 0.0.1 and should reach version 1.0.0 once it is completely operative and well tested. Following the Linux kernel version numbering scheme, versions with even release numbers (like 1.0.x, 1.2.x, 1.4.x...) should be stable releases, while those with odd release numbers (like 1.1.x, 1.3.x, 1.5.x...) are usually considered "under development". The three parts of a version number are not limited to single digits, so a version number of 1.2.15 would be acceptable.

Klaus

Zitat von kls

Kann es sein, daß hier ein "nie" fehlt?

Hehe, jepp, mal wieder zu langsame Finger für den Gedanken ...

Jetzt passt ja epgsearch da rein, stable ist 1.0.2, developer ist 1.1.1 ...

[EDIT] Versionen sind nun stable vdr-2.2.x Branch: epgsearch 2.2.0 & master (developer) branch: epgsearch 2.3.1, um die entsprechende jeweilige VDR Kompatibilität zu visualisieren.

=> https://projects.vdr-developer…vdr-plugin-epgsearch.git/

Gruß
Frank

Hollywood:
In dem Logausschnitt sieht man, dass der Skindesigner aktiv ist. Dieser hat ja auch eine Schnittstelle zu epgsearch - ist aber bei mir nicht im Einsatz. Tritt diese Verzögerung auch ohne Skindesigner mit dem Standardskin bei Dir auf?

Hi TomJoad,

das habe ich grade mal ausprobiert, und auch ohne Skindesigner verhält sich mein VDR genau so.

Gruss

Stefan

Man könnte noch mit den Parametern -l "/tmp/epgsearch.log" -v 3
detaillierter sehn, was das Plugin so macht.

Mir ist aufgefallen, daß das epgsearch-plugin (aktuelles git von heute) die fertigen Aufnahmen nicht mehr in die "epgsearchdone.data" schreibt und dadurch Sendungen mehrfach aufgenommen werden.
Vielleicht kann das ja mal jemand verifizieren.

Jedenfalls habe ich jetzt festgestellt, das in der "recstatus.c" ein ganzer Codeblock für vdr-2.3 auskommentiert wurde. Dafür gab es sicher mal Gründe, funktionieren tut es so aber scheinbar nicht.

Ich habe jetzt diesen Codeblock mit folgendem Patch reaktiviert und an vdr-2.3 angepasst:

diff -Nur epgsearch-cvs-170503/recstatus.c epgsearch-cvs-170503a/recstatus.c
--- epgsearch-cvs-170503/recstatus.c	2017-05-02 20:48:31.000000000 +0200
+++ epgsearch-cvs-170503a/recstatus.c   2017-05-03 13:47:53.148711312 +0200
@@ -27,14 +27,10 @@
 #include "conflictcheck_thread.h"
 #include "epgsearchcfg.h"
 #include <math.h>
-#if VDRVERSNUM > 20300
-#include "status_thread.h"
-#else
 #define ALLOWED_BREAK_INSECS 2
 
 extern int updateForced;
 extern int gl_InfoConflict;
-#endif
 
 
 cRecStatusMonitor* gl_recStatusMonitor = NULL;
@@ -45,17 +41,19 @@
 
 void cRecStatusMonitor::Recording(const cDevice *Device, const char *Name, const char* Filename, bool On)
 {
-#if VDRVERSNUM > 20300
-   cStatusThread::Init(Device,Name,Filename,On);
-#else
	time_t now = time(NULL);
	// insert new timers currently recording in TimersRecording
	if (On && Name)
	{
   	if (EPGSearchConfig.checkTimerConflOnRecording)
      	cConflictCheckThread::Init((cPluginEpgsearch*)cPluginManager::GetPlugin("epgsearch"), true);
-
-  	for (cTimer *ti = Timers.First(); ti; ti = Timers.Next(ti))
+#if VDRVERSNUM > 20300
+  	LOCK_TIMERS_READ;
+  	const cTimers *vdrtimers = Timers;
+#else
+  	cTimers *vdrtimers = &Timers;
+#endif
+  	for (const cTimer *ti = vdrtimers->First(); ti; ti = vdrtimers->Next(ti))
      	if (ti->Recording())
      	{
         	// check if this is a new entry
@@ -119,7 +117,13 @@
   	{
      	// check if timer still exists
      	bool found = false;
-     	for (cTimer *ti = Timers.First(); ti; ti = Timers.Next(ti))
+#if VDRVERSNUM > 20300
+     	LOCK_TIMERS_READ;
+     	const cTimers *vdrtimers = Timers;
+#else
+     	cTimers *vdrtimers = &Timers;
+#endif
+     	for (const cTimer *ti = vdrtimers->First(); ti; ti = vdrtimers->Next(ti))
         	if (ti == tiR->timer)
         	{
            	found = true;
@@ -203,7 +207,6 @@
      	tiR = TimersRecording.Next(tiR);
   	}
	}
-#endif
 }
 
 int cRecStatusMonitor::TimerRecDevice(const cTimer* timer)

Im Ergebnis gab es dann folgende Fehlermeldung am Ende einer Serienaufnahme:

EPGSearch: Epgsearch recstatus_thread called too fast

Ich habe dann in der "status_thread.c", wo die Fehlermeldung herkommt, mit folgendem Patch ein sleep eingebaut:

diff -Nur epgsearch-cvs-170503/status_thread.c epgsearch-cvs-170503a/status_thread.c
--- epgsearch-cvs-170503/status_thread.c    	2017-05-02 20:48:31.000000000 +0200
+++ epgsearch-cvs-170503a/status_thread.c   	2017-05-03 12:57:41.518729639 +0200
@@ -64,6 +64,7 @@
 }
 
 void cStatusThread::Init(const cDevice *Device, const char *Name, const char *Filename, bool On) {
+	cCondWait::SleepMs(300);
 	if (m_Instance == NULL) {
     	m_Instance = new cStatusThread;
 	}

Die "epgsearchdone.data" wird jetzt wieder wie erwartet geschrieben.

Die 300ms Wartezeit sind jetzt einfach so aus der Luft gegriffen, ein erster Versuch mit 30ms hatte nicht funktioniert.
Vielleicht findet sich hier noch eine bessere Lösung, um eine minimale Wartezeit zu realisieren.
Ich kann auch nicht sagen, ob diese Wartezeit sich an anderer Stelle negativ auswirkt.

Im Moment kann ich hier leider keine weiteren Tests machen, bei mir steht jetzt erst mal Urlaub an.

Die Wartezeiten, die bei @Hollywood auftreten, kann ich hier nicht feststellen.

Allerdings habe ich die Meldungen, die @Perlbo im anderen Beitrag beschreibt, auch schon gesehen, allerdings nicht regelmäßig:

SVDRP < 127.0.0.1:41362 client connection accepted
SVDRP < 127.0.0.1:41362 connection closed
EPGSearch: command 'DELT 11' failed

Gruß
k5

Zitat von kamel5

Mir ist aufgefallen, daß das epgsearch-plugin (aktuelles git von heute) die fertigen Aufnahmen nicht mehr in die "epgsearchdone.data" schreibt und dadurch Sendungen mehrfach aufgenommen werden.
Vielleicht kann das ja mal jemand verifizieren.

Habe meine VDR 2.3.4 Installation mal soweit aufgemotzt, das die Plugins auch was tun, werde das mal beobachten.

Zitat von kamel5

Die Wartezeiten, die bei Hollywood auftreten, kann ich hier nicht feststellen.

Ditto, hier auch nicht, hab mehrfach Timer gelöscht und Suchtimer aktualisieren lassen, läuft ...

Zitat von kamel5

Allerdings habe ich die Meldungen, die Perlbo im anderen Beitrag beschreibt, auch schon gesehen, allerdings nicht regelmäßig:

Das habe ich auch direkt ein paar wenige im syslog gesehen.

Regards
fnu

Ich kann die Meldungen provozieren, wenn ich über vdrlive auf Suchtimer aktualisieren gehe.

Haben Timer nun auch eindeutige Nummern während der Laufzeit? Ich dachte das wären nur die Aufnahmen?

Ich denke, timer bräuchten auch eine eindeutige Nummer.
Ich kann reproduzieren, dass epgsearchdone.data nicht mehr geschrieben wird. Ich schaue gerade, ob das Auslagern in einen eigenen Thread überhaupt noch nötig is. Mit vdr 2.3.1 gab es ohne ihn Abstürze, weil der Readlock einen Nullpointer zurückgab.
Eigentlich macht der status_thread genau das, was vorher in recdone.c gemacht wurde, es kommt aber wohl oft (oder jetzt immer?) zu dem "too fast".

Hi,

komisch, dass das Problem nur bei mir auftritt. Ich habe nun mal die ca. 1,5 MB grosse Datei epgsearchdone.data gelöscht und nun startet der VDR wieder normal.

Ist natürlich keine Lösung, nun weiss epgsearch ja nicht mehr was schon aufgenommen wurde . Soll die Abarbeitung dieser Datei den VDR solange lahmlegen, oder kann innerhalb der Datei irgendein Fehler sein (Zeichencodierung oder sowas) der für die langen Pausen verantwortlich ist. Gibts nen Tip wie ich da weiter vorgehen kann ?

Gruss

Stefan

Zitat von TomJoad

Ich kann reproduzieren, dass epgsearchdone.data nicht mehr geschrieben wird.

Kann ich bestätigen, keine der inzwischen getätigten Such-Timer Aufnahmen wurde auf meinem VDR 2.3.4 Test-Gerät in dieser Datei vermerkt.

Prinzipiell funktioniert damit "Wiederholung vermeiden" nicht, kein so großer Beinbruch, besser als Episoden zu verpassen ...

mini73

Ah, ok, ist lange her, dann müssten wohl die entsprechenden (sequentiellen?) Suchen in epgsearch angepasst werden ...

Gruß
Frank