esyslog("ERROR timer %s recording, but EIT present/following missing. This is a bug in VDR, or this channel %d %s (%s) does not provide useable VPS information and you should disable VPS for this channel", Wenn das ein "bug in VDR" ist, dann solltest du den beheben ;-).
Ansonsten würde ich empfehlen, diese Meldung nochmal zu überarbeiten...
Ich finde es etwas übertrieben, an der Stelle einen ganzen "Roman" zu erzählen ;-).
EIT present/following bleibt aus, dafür kann es viele Gründe geben - wenn das vermehrt auftritt muss man es eh debuggen.
Was anderes: warum occupiedPriorityTimeout zusätzlich zu occupiedTimeout?
SetOccupied() wird nur an einer einzigen Stelle aufgerufen, und da nur mit 8 Sekunden Timeout. Das sollte sich doch mit *einer* Variablen erschlagen lassen, ohne die ganzen Fallunterscheidungen. Oder übersehe ich da was?
Dieser Patch ändert das Interface von cDevice::MaySwitchTransponder(). Wenn ich ihn übernehme, müssten alle Plugins, die von cDevice ableiten (z.B. sat-ip, iptv), entsprechend geändert werden. Ein einfaches Neucompilieren würde da nicht reichen.
Welche dieser drei zwei Vorgehensweisen soll es sein?
1. eine neue Developer-Version
2. ein Macro, das diese Änderung aktiviert (default: deaktiviert)
3. einfach einbauen und es "krachen" lassen
Ich würde Nummer 3 auf jeden Fall streichen.
Letztlich gibt es nur zwei realistische Optionen. Entweder die API wird nicht inkompatibel geändert (keine Ahnung wie die dann aussehen müsste) oder sie wird inkompatibel geändert und nach dem "krachen lassen" Prinzip rausgegeben.
Ein Makro mit "standardmäßig deaktiviert" bringt niemandem was wenn ein Plugin dann die neue Schnittstelle benötigt. Der Distributor hat dann nur eine realistische Option: Einschalten.
Und eigentlich haben wir mittlerweile auch theoretisch bessere Chancen denn je eine Änderung in endlicher Zeit bei allen Plugins reinzubekommen.
Was passiert denn, wenn eine Klasse von cDevice ableitet und MaySwitchTransponder selbst nicht implementiert? Dann müsste doch neu kompilieren reichen (?).
Dann ja.
Und was passiert, wenn wenn eine Klasse von cDevice ableitet und MaySwitchTransponder selbst implementiert?
error: 'virtual bool cDevice::MaySwitchTransponder(const cChannel*, int) const'
was hidden [-Werror=overloaded-virtual]
Welche Änderungen mussten damals in den Plugins, die cDevice ableiten, durchgeführt werden?
Sie mussten den neuen Parameter hinzufügen.
Warum muss unbedingt MaySwitchTransponder geändert werden?
Die code Änderungen für satip und iptv wären gering.
Mal abgesehen davon, dass eine Änderung in iptv rein zu bekommen schwierig wird.
Aber der Impact des Patches als solches für VDR Infrastruktur sind nicht ohne..
Was wäre denn stattdessen von folgender Variante zu halten?
--- timers.c 2024/03/03 15:47:09 5.19
+++ timers.c 2024/03/05 10:31:42
@@ -22,6 +22,7 @@
// value!
#define VPSGRACE 15 // seconds we still record after the running status of a VPS event has changed to "not running"
+#define PRIORITYGRACE 1
// --- cTimer ----------------------------------------------------------------
@@ -50,6 +51,7 @@
start = now->tm_hour * 100 + now->tm_min;
stop = 0;
vpsNotRunning = 0;
+ priorityGrace = 0;
if (!Setup.InstantRecordTime && channel && (Instant || Pause)) {
LOCK_SCHEDULES_READ;
if (const cSchedule *Schedule = Schedules->GetSchedule(channel)) {
@@ -190,6 +192,7 @@
remote = NULL;
event = NULL;
vpsNotRunning = 0;
+ priorityGrace = 0;
if (!PatternTimer || PatternTimer->HasFlags(tfVps)) {
if (Event->Vps() && (PatternTimer || Setup.UseVps))
SetFlags(tfVps);
@@ -260,6 +263,7 @@
priority = Timer.priority;
lifetime = Timer.lifetime;
vpsNotRunning = 0;
+ priorityGrace = 0;
strncpy(pattern, Timer.pattern, sizeof(pattern));
strncpy(file, Timer.file, sizeof(file));
free(aux);
@@ -624,7 +628,16 @@
}
else
vpsNotRunning = 0;
- return running || time(NULL) < vpsNotRunning + VPSGRACE;
+ if (running || time(NULL) < vpsNotRunning + VPSGRACE)
+ return true;
+ if (vpsNotRunning && t < event->EndTime()) {
+ if (!priorityGrace)
+ dsyslog("timer %s for event %s set grace priority to %d", *ToDescr(), *Event()->ToDescr(), PRIORITYGRACE);
+ priorityGrace = PRIORITYGRACE;
+ return true;
+ }
+ priorityGrace = 0;
+ return false;
}
// ...otherwise we fall back to normal timer handling below (note: Margin == 0!)
}
@@ -942,6 +955,7 @@
SetFlags(tfRecording);
else
ClrFlags(tfRecording);
+ priorityGrace = 0;
isyslog("timer %s %s", *ToDescr(), Recording ? "start" : "stop");
}
--- timers.h 2024/03/03 15:47:09 5.10
+++ timers.h 2024/03/05 10:08:21
@@ -46,6 +46,7 @@
int start; ///< the start and stop time of this timer as given by the user,
int stop; ///< in the form hhmm, with hh (00..23) and mm (00..59) added as hh*100+mm
int priority;
+ mutable int priorityGrace;
int lifetime;
mutable char pattern[NAME_MAX * 2 + 1]; // same size as 'file', to be able to initially fill 'pattern' with 'file' in the 'Edit timer' menu
mutable char file[NAME_MAX * 2 + 1]; // *2 to be able to hold 'title' and 'episode', which can each be up to 255 characters long
@@ -70,7 +71,7 @@
int WeekDays(void) const { return weekdays; }
int Start(void) const { return start; }
int Stop(void) const { return stop; }
- int Priority(void) const { return priority; }
+ int Priority(void) const { return priorityGrace ? priorityGrace : priority; }
int Lifetime(void) const { return lifetime; }
const char *Pattern(void) const { return pattern; }
const char *File(void) const { return file; }- Ändert keine Interfaces.
- Wenn VPS+VPSGRACE abgelaufen ist, wird mit niedriger Priorität weiter bis zum Ende der Event-Zeit aufgenommen, womit auch gleichzeitig sichergestellt ist, dass der Event aktuell bleibt.
- Evtl. wäre noch darüber nachzudenken, ob priorityGrace '1' sein soll, oder besser 'priority - 1', oder ganz anders.
Welchen Sinn macht es, Timer zu programmieren, von denen man von vornherein weiß, dass sie nicht gleichzeitig aufnehmen können?
Und warum beginnt Timer C verspätet?
MarkusE Kann es sein, dass mit deinem Patch in dem Fall, dass vom Sender keine EIT-Daten kommen (aus welchen Gründen auch immer) die Aufnahme nie startet? In der bisherigen Version würde er zumindest die vorgegebene Zeit aufnehmen, aber durch das 'return false' im Falle, dass die Aufnahme noch nicht begonnen hat, wird sie auch nie beginnen.
In der bisherigen Version würde er zumindest die vorgegebene Zeit aufnehmen
Was passiert ohne Patch, wenn die Sendung um mehr als die Länge verspätet gesendet wird (zum Beispiel wegen aktueller Berichterstattung): Dann ist der Timer im falschen Timeslot abgearbeitet und die eigentliche Sendung wird trotz korrektem VPS Signal nicht aufgenommen. Oder nicht ?
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!
