Beiträge von kfb77

kfb77 · 3. Dezember 2022

Ich zitiere mal aus der Dokumentation:

Zitat

Um in group_vars/all definierte Variablen anzupassen, sollte man eine Datei host_vars/localhost anlegen und darin die gewünschten Anpassungen vornehmen. Die in dieser Datei definierten Variablen übersteuern die Vorgabewerte aus dem Playbook und der group_vars/all.

Live wird nicht per Default installiert, du musst das in deiner individuellen host_vars/localhost bei "vdr_plugins" angeben.

kfb77 · 30. November 2022

Zitat von MarkusE

Junge, ist der anspruchsvoll

Das ist ne Mimose, am neuen VDR hat er auch gleich gemeckert.

kfb77 · 30. November 2022

Nein, das reicht nicht.

Code

CC remux.o
In file included from i18n.h:14,
                 from config.h:19,
                 from channels.h:13,
                 from remux.h:13,
                 from remux.c:10:
remux.c: In member function 'void cH265Parser::ParseSequenceParameterSet()':
tools.h:37:64: warning: format not a string literal and no format arguments [-Wformat-security]
   37 | #define dsyslog(a...) void( (SysLogLevel > 2) ? syslog_with_tid(LOG_DEBUG, a) : void() )
      |                                                 ~~~~~~~~~~~~~~~^~~~~~~~~~~~~~
remux.c:1911:6: note: in expansion of macro 'dsyslog'
 1911 |      dsyslog(*s);
      |      ^~~~~~~
LD vdr

Alles anzeigen

kfb77 · 30. November 2022

kls

Vielen Dank für die neue Version.

Ich bekomme damit eine Compiler warning:

Code

CC remux.o
In file included from i18n.h:14,
                 from config.h:19,
                 from channels.h:13,
                 from remux.h:13,
                 from remux.c:10:
remux.c: In member function 'virtual int cMpeg2Parser::Parse(const uchar*, int, int)':
tools.h:37:64: warning: format not a string literal and no format arguments [-Wformat-security]
   37 | #define dsyslog(a...) void( (SysLogLevel > 2) ? syslog_with_tid(LOG_DEBUG, a) : void() )
      |                                                 ~~~~~~~~~~~~~~~^~~~~~~~~~~~~~
remux.c:1336:16: note: in expansion of macro 'dsyslog'
 1336 |                dsyslog(s);
      |                ^~~~~~~
remux.c: In member function 'void cH264Parser::ParseSequenceParameterSet()':
tools.h:37:64: warning: format not a string literal and no format arguments [-Wformat-security]
   37 | #define dsyslog(a...) void( (SysLogLevel > 2) ? syslog_with_tid(LOG_DEBUG, a) : void() )
      |                                                 ~~~~~~~~~~~~~~~^~~~~~~~~~~~~~
remux.c:1610:9: note: in expansion of macro 'dsyslog'
 1610 |         dsyslog(s);
      |         ^~~~~~~
remux.c: In member function 'void cH265Parser::ParseSequenceParameterSet()':
tools.h:37:64: warning: format not a string literal and no format arguments [-Wformat-security]
   37 | #define dsyslog(a...) void( (SysLogLevel > 2) ? syslog_with_tid(LOG_DEBUG, a) : void() )
      |                                                 ~~~~~~~~~~~~~~~^~~~~~~~~~~~~~
remux.c:1911:6: note: in expansion of macro 'dsyslog'
 1911 |      dsyslog(s);
      |      ^~~~~~~
CC ringbuffer.o

Alles anzeigen

gcc --version

gcc (Ubuntu 11.3.0-1ubuntu1~22.04) 11.3.0

This is free software; see the source for copying conditions. There is NO

warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Sieht so aus, als ob mein Compiler auf den Format String besteht.

Dies beseitigt die Warning:

Diff

diff --git a/remux.c b/remux.c
index 391fd6ff..54fc50fd 100644
--- a/remux.c
+++ b/remux.c
@@ -1333,7 +1333,7 @@ int cMpeg2Parser::Parse(const uchar *Data, int Length, int Pid)
             seenScanType = true;
             if (debug) {
                cString s = cString::sprintf("MPEG2: %d x %d%c %.2f fps", frameWidth, frameHeight, progressive ? 'p' : 'i', framesPerSecond);
-               dsyslog(s);
+               dsyslog("%s",*s);
                dbgframes("\n%s", *s);
                }
             }
@@ -1607,7 +1607,7 @@ void cH264Parser::ParseSequenceParameterSet(void)
         }
      if (debug) {
         cString s = cString::sprintf("H.264: %d x %d%c %.2f fps %d Bit", frameWidth, frameHeight, progressive ? 'p':'i', framesPerSecond, bitDepth);
-        dsyslog(s);
+        dsyslog("%s", *s);
         dbgframes("\n%s", *s);
         }
      }
@@ -1908,7 +1908,7 @@ void cH265Parser::ParseSequenceParameterSet(void)
      }
   if (debug) {
      cString s = cString::sprintf("H.265: %d x %d%c %.2f fps %d Bit", frameWidth, frameHeight, progressive ? 'p':'i', framesPerSecond, bitDepth);
-     dsyslog(s);
+     dsyslog("%s", *s);
      dbgframes("\n%s", *s);
      }
 }

Alles anzeigen

kfb77 · 30. November 2022

MarkusE

Machst du bitte mal bei Gelegenheit ein unnötiges blank am Zeilenende raus, mein Compiler gefällt das nicht.

Code

multischedule.ecpp:521: warning: trailing white space after closing tag

kfb77 · 20. November 2022

Zitat von kamel5

Diese Warnung kommt nicht beim Core-VDR, sondern durch den patch-for-permashift.

Ja genau,

kls: Du brauchst hier nichts ändern, im ungepatchen VDR kommt die Warnung nicht.

Zitat von kamel5

Wenn man also recorder.h so lässt, wie es war und dafür recorder.c entsprechend ändert, ist die Warnung auch weg:

Stimmt, das wäre besser, weil näher am original VDR dran.

kfb77 · 20. November 2022

Zitat von kls

Ich verstehe die Warnung nicht.

So ging es mir auch. Ich wollte trotzdem die unwichtige warning los haben, damit man die wichtigen Meldungen besser sehen kann.

kfb77 · 19. November 2022

Nachdem ich wegen dem Timeout Thema oft den VDR kompiliert hatte, ist mir eine warning bei yavdr aufgefallen.

Der o.g. Patch erzeugt folgende Compiler Warnung:

Code

In file included from recorder.c:10:
recorder.h: In constructor 'cRecorder::cRecorder(const char*, const cChannel*, int)':
recorder.h:30:19: warning: 'cRecorder::recordingInfo' will be initialized after [-Wreorder]
   30 |   cRecordingInfo *recordingInfo;
      |                   ^~~~~~~~~~~~~
recorder.h:26:22: warning:   'cRingBufferLinear* cRecorder::ringBuffer' [-Wreorder]
   26 |   cRingBufferLinear *ringBuffer;
      |                      ^~~~~~~~~~
recorder.c:164:1: warning:   when initialized here [-Wreorder]
  164 | cRecorder::cRecorder(const char *FileName, const cChannel *Channel, int Priority)
      | ^~~~~~~~~

Alles anzeigen

Hier ein Fix dazu:

Diff

index 9850581d..3db80225 100644
--- a/recorder.h
+++ b/recorder.h
@@ -23,11 +23,11 @@ class cRecorder : public cReceiver, protected cThread {
 protected:
   cTsChecker *tsChecker;
   cFrameChecker *frameChecker;
+  cRecordingInfo *recordingInfo;
   cRingBufferLinear *ringBuffer;
   cFrameDetector *frameDetector;
   cPatPmtGenerator patPmtGenerator;
   cFileName *fileName;
-  cRecordingInfo *recordingInfo;
   cIndexFile *index;
   cUnbufferedFile *recordFile;
   char *recordingName;

Alles anzeigen

kfb77 · 19. November 2022

Sieht gut aus, timeouts sind weg, habe auch keine anderen Probleme festgestellt. Kann aus meiner Sicht so in die nächste Version übernommen werden.

Vielen Dank für deine Mühen zu dem Thema.

kfb77 · 18. November 2022

Das sieht gut aus, seit einer Stunde drin und bis jetzt keinen Timeout. Mal einen Tag abwarten ...

kfb77 · 18. November 2022

Poste mal einen Screenshot von Live.

kfb77 · 17. November 2022

Da muss ich passen, die Oberfläche kenne ich nicht. Nehme entweder das Live Plugin oder die originale VDR Oberfläche.

kfb77 · 17. November 2022

nein, ich meine : "Compare subtitle", das ist weiter unten.

kfb77 · 17. November 2022

Ist beim Suchtimer "vergleiche Untertitel: ja" gesetzt ?

kfb77 · 17. November 2022

Hier nochmals die wesentlichen Einträge, eigentlich sieht das für mich gleich aus wie vorher.

Code

Nov 17 18:24:56 user.debug      VDR-2204-Dev    vdr: [169076] Action 741
Nov 17 18:24:56 user.debug      VDR-2204-Dev    vdr: [169076] Action 743
Nov 17 18:24:56 user.debug      VDR-2204-Dev    vdr: [169076] ProcessConnections 657
Nov 17 18:24:56 user.debug      VDR-2204-Dev    vdr: [169076] ProcessConnections 659    # 1. lock mutex OK
Nov 17 18:24:56 user.debug      VDR-2204-Dev    vdr: [169075] CmdPOLL 2421
Nov 17 18:24:56 user.debug      VDR-2204-Dev    vdr: [169075] TriggerFetchingTimers 780   # 2. lock mutex wartet
Nov 17 18:24:56 user.debug      VDR-2204-Dev    vdr: [169076] ProcessConnections 694
Nov 17 18:24:56 user.debug      VDR-2204-Dev    vdr: [169076] ProcessConnections 696
Nov 17 18:24:56 user.debug      VDR-2204-Dev    vdr: [169076] ProcessConnections 698
Nov 17 18:25:01 user.debug      VDR-2204-Dev    vdr: [169076] ProcessConnections 701
Nov 17 18:25:01 user.debug      VDR-2204-Dev    vdr: [169076] Action 745
Nov 17 18:25:01 user.err        VDR-2204        vdr: [150506] SVDRP VDR-2204 < 10.1.5.143:6419 timeout while waiting for response from 'VDR-2204-Dev'
Nov 17 18:25:01 user.err        VDR-2204        vdr: [150506] ERROR: can't send 'POLL VDR-2204 TIMERS' to 'VDR-2204-Dev'
Nov 17 18:25:01 user.debug      VDR-2204-Dev    vdr: [169075] TriggerFetchingTimers 782    # 2. lock mutex OK, aber nach timeout
Nov 17 18:25:01 user.debug      VDR-2204-Dev    vdr: [169075] TriggerFetchingTimers 784
Nov 17 18:25:01 user.debug      VDR-2204-Dev    vdr: [169075] TriggerFetchingTimers 786

Alles anzeigen

kfb77 · 17. November 2022

Nein, die timeouts bleiben leider.

kfb77 · 17. November 2022

Kein Problem, habe es eh erst nach dem 2. Post gelesen.

fix 4 ist drin, jetzt ist wieder warten auf timeouts angesagt, oder hoffentlich nicht ...

kfb77 · 16. November 2022

Ich habe mich inzwischen dran gewagt, deine Logs zu interpretieren. Sie bestätigen meinen Verdacht des Deadlocks meiner Meinung nach.

Minimaler Auszug aus o.g. syslog:

Code

Nov 16 08:19:58 VDR-2204 vdr: [121367] Action 732                # Action Loop, erfolgreicher lock auf mutex
Nov 16 08:19:58 VDR-2204 vdr: [121367] Action 734
Nov 16 08:19:58 VDR-2204 vdr: [121367] Action 736

Nov 16 08:19:58 VDR-2204 vdr: [121366] CmdPOLL 2414
Nov 16 08:19:58 VDR-2204 vdr: [121366] TriggerFetchingTimers 773       # Bearbeiten des Requests vom anderen VDR, das erfordert den gleichen Lock, den er aber nicht mehr bekommt

Nov 16 08:20:03 VDR-2204 vdr: [121366] TriggerFetchingTimers 775    # nachdem sein Request abgearbeitet wurde, bekommt er den Lock und kann den Request des anderen VDR abarbeiten, aber zu spät
Nov 16 08:20:03 VDR-2204 vdr: [121366] TriggerFetchingTimers 777
Nov 16 08:20:03 VDR-2204 vdr: [121366] TriggerFetchingTimers 779

Nov 16 08:20:03 user.err        VDR-2204-Dev    vdr: [123885] SVDRP VDR-2204-Dev < 10.1.5.144:6419 timeout while waiting for response from 'VDR-2204'
Nov 16 08:20:03 user.err        VDR-2204-Dev    vdr: [123885] ERROR: can't send 'POLL VDR-2204-Dev TIMERS' to 'VDR-2204'

Alles anzeigen

kfb77 · 16. November 2022

Hier das Syslog davon. Erstaunlicherweise hatte mein zentraler syslog Server kein Problem mit der Flut an Meldungen.

kfb77 · 15. November 2022

Ich habe noch ein Log mit mehr Debug Infos:

Code

Nov 15 17:36:08 user.debug      VDR-2204-Dev    vdr: [46226] epg data writer thread started (pid=46090, tid=46226, prio=low)
Nov 15 17:36:08 user.info       VDR-2204-Dev    vdr: [46090] timer 10@VDR-2204 (1 1848-1955 'Series~WaPo Bodensee~Staffel 07~11. Die Affäre') set to event Di. 15.11.2022 18:50-19:45 (VPS: 15.11. 18:50) 'WaPo Bodensee'
Nov 15 17:36:08 user.info       VDR-2204-Dev    vdr: [46090] timer 37@VDR-2204 (1 2348-0045 'Archiv 1~Die Carolin Kebekus Show~2022-11-17 23:50-Comedyshow (D 2022)') set to event Do. 17.11.2022 23:50-00:35 (VPS: 17.11. 23:55) 'Die Carolin Kebekus Show'


# beide VDRs (fast) gleichzeitig POLL TIMERS
Nov 15 17:36:08 daemon.info     VDR-2204-Dev    vdr[46090]: > C VDR-2204: POLL VDR-2204-Dev TIMERS
Nov 15 17:36:08 daemon.info     VDR-2204        vdr[92728]: < S VDR-2204-Dev: POLL VDR-2204-Dev TIMERS
Nov 15 17:36:08 user.debug      VDR-2204        vdr: [92755] cSVDRPClientHandler::TriggerFetchingTimers: want mutex
Nov 15 17:36:08 daemon.info     VDR-2204        vdr[92728]: > C VDR-2204-Dev: POLL VDR-2204 TIMERS
Nov 15 17:36:08 daemon.info     VDR-2204-Dev    vdr[46090]: < S VDR-2204: POLL VDR-2204 TIMERS

Nov 15 17:36:08 user.debug      VDR-2204-Dev    vdr: [46111] cSVDRPClientHandler::TriggerFetchingTimers: want mutex
Nov 15 17:36:09 user.debug      VDR-2204-Dev    vdr: [46226] epg data writer thread ended (pid=46090, tid=46226)

# hier ist 4s Lücke (ungefähr =timeout)

Nov 15 17:36:13 user.err        VDR-2204-Dev    vdr: [46112] SVDRP VDR-2204-Dev < 10.1.5.144:6419 timeout while waiting for response from 'VDR-2204'
Nov 15 17:36:13 user.err        VDR-2204-Dev    vdr: [46112] ERROR: can't send 'POLL VDR-2204-Dev TIMERS' to 'VDR-2204'
Nov 15 17:36:13 daemon.info     VDR-2204-Dev    vdr[46090]: > S VDR-2204: 250 OK
Nov 15 17:36:13 daemon.info     VDR-2204-Dev    vdr[46090]: < C VDR-2204: 250 OK
Nov 15 17:36:13 daemon.info     VDR-2204-Dev    vdr[46090]: > C VDR-2204: LSTT ID

# erst danach bekommen beide VDRs den lock

Nov 15 17:36:13 user.debug      VDR-2204-Dev    vdr: [46111] cSVDRPClientHandler::TriggerFetchingTimers:  got mutex
Nov 15 17:36:13 daemon.info     VDR-2204        vdr[92728]: < C VDR-2204-Dev: 250 OK
Nov 15 17:36:13 daemon.info     VDR-2204        vdr[92728]: > S VDR-2204-Dev: 250 OK
Nov 15 17:36:13 user.debug      VDR-2204        vdr: [92755] cSVDRPClientHandler::TriggerFetchingTimers:  got mutex


Nov 15 17:36:13 daemon.info     VDR-2204-Dev    vdr[46090]: < C VDR-2204: 250-1 1:S19.2E-1-1107-17500:2022-11-15:2012:2125:98:99:Series~Navy CIS~Staffel 19~20. Ein Cent pro Dollar:<epgsearch><channel>21 - SAT.1</channel><searchtimer>Navy CIS</searchtimer><start>1668539520</start><stop>1668543900</stop><s-id>223</s-id><eventid>340205</eventid></epgsearch>
Nov 15 17:36:13 daemon.info     VDR-2204        vdr[92728]: < S VDR-2204-Dev: LSTT ID
Nov 15 17:36:13 daemon.info     VDR-2204        vdr[92728]: > S VDR-2204-Dev: 250-1 1:S19.2E-1-1107-17500:2022-11-15:2012:2125:98:99:Series~Navy CIS~Staffel 19~20. Ein Cent pro Dollar:<epgsearch><channel>21 - SAT.1</channel><searchtimer>Navy CIS</searchtimer><start>1668539520</start><stop>1668543900</stop><s-id>223</s-id><eventid>340205</eventid></epgsearch>
Nov 15 17:36:13 daemon.info     VDR-2204        vdr[92728]: > S VDR-2204-Dev: 250-2 1:S19.2E-1-1107-17500:2022-11-15:2113:2225:98:99:Series~Navy CIS~Staffel 19~21. Einer von uns:<epgsearch><channel>21 - SAT.1</channel><searchtimer>Navy CIS</searchtimer><start>1668543180</start><stop>1668547500</stop><s-id>223</s-id><eventid>340206</eventid></epgsearch>
Nov 15 17:36:13 daemon.info     VDR-2204        vdr[92728]: > S VDR-2204-Dev: 250-3 1:S19.2E-1-1107-17500:2022-11-15:2213:2323:98:99:Series~Navy CIS~Staffel 18~08. Sonne und Sand:<epgsearch><channel>21 - SAT.1</channel><searchtimer>Navy CIS</searchtimer><start>1668546780</start><stop>1668550980</stop><s-id>223</s-id><eventid>340207</eventid></epgsearch>
Nov 15 17:36:13 daemon.info     VDR-2204        vdr[92728]: > S VDR-2204-Dev: 250-4 1:S19.2E-1-1107-17500:2022-11-15:2311:0022:97:99:Series~Bull~Staffel 06~18. Brokkoli und Pizza:<epgsearch><channel>21 - SAT.1</channel><searchtimer>Bull</searchtimer><start>1668550260</start><stop>1668554520</stop><s-id>257</s-id><eventid>340208</eventid></epgsearch>
Nov 15 17:36:13 daemon.info     VDR-2204        vdr[92728]: > S VDR-2204-Dev: 250-5 1:S19.2E-1-1107-17500:2022-11-16:0010:0118:97:99:Series~Bull~Staffel 03~04. Blutiges Geld:<epgsearch><channel>21 - SAT.1</channel><searchtimer>Bull</searchtimer><start>1668553800</start><stop>1668557880</stop><s-id>257</s-id><eventid>340209</eventid></epgsearch>


---------------------------------------
good case, nur ein VDR macht POLL TIMERS

Nov 15 17:36:14 daemon.info     VDR-2204        vdr[92728]: > C VDR-2204-Dev: POLL VDR-2204 TIMERS
Nov 15 17:36:14 daemon.info     VDR-2204-Dev    vdr[46090]: < S VDR-2204: POLL VDR-2204 TIMERS
Nov 15 17:36:14 user.debug      VDR-2204-Dev    vdr: [46111] cSVDRPClientHandler::TriggerFetchingTimers: want mutex
Nov 15 17:36:14 user.debug      VDR-2204-Dev    vdr: [46111] cSVDRPClientHandler::TriggerFetchingTimers:  got mutex

Alles anzeigen

Für sieht das so aus, als ob es einen deadlock über die beiden VDRs gibt. Jeder locked den gleichen Mutex für seinen eigenen SVDRP Client Request und zur Bearbeitung des ankommenden Server Request.

Im Log habe ich nur den Lock vom Server Teil, den vom Client habe ich noch nicht gefunden.

Eigentlich müsste der doch hier sein:

Code

bool cSVDRPClientHandler::Execute(const char *ServerName, const char *Command, cStringList *Response)
{
  dsyslog("cSVDRPClientHandler::Execute want mutex");
  cMutexLock MutexLock(&mutex);
  dsyslog("cSVDRPClientHandler::Execute  got mutex");
  if (cSVDRPClient *Client = GetClientForServer(ServerName))
     return Client->Execute(Command, Response);
  return false;
}

Aber da bekomme ich keine Log Ausgabe ???

Beiträge von kfb77

Yavdr headless: live Plugin, Admin Oberfläche und Externer Zugriff fehlt

[live], 3.1.12

[ANNOUNCE] VDR Version 2.6.2 freigegeben

[ANNOUNCE] VDR Version 2.6.2 freigegeben

[live], 3.1.12

yavdr vdr-2.5.4-patch-for-permashift.diff compiler warning

yavdr vdr-2.5.4-patch-for-permashift.diff compiler warning

yavdr vdr-2.5.4-patch-for-permashift.diff compiler warning

[Gelöst] VDR 2.6.1 SVDRP POLL TIMERS: timeout while waiting for response

[Gelöst] VDR 2.6.1 SVDRP POLL TIMERS: timeout while waiting for response

EPGsearch timers - Wiederholung vermeiden und gar kein Searchtimer wird erstellt

EPGsearch timers - Wiederholung vermeiden und gar kein Searchtimer wird erstellt

EPGsearch timers - Wiederholung vermeiden und gar kein Searchtimer wird erstellt

EPGsearch timers - Wiederholung vermeiden und gar kein Searchtimer wird erstellt

[Gelöst] VDR 2.6.1 SVDRP POLL TIMERS: timeout while waiting for response

[Gelöst] VDR 2.6.1 SVDRP POLL TIMERS: timeout while waiting for response

[Gelöst] VDR 2.6.1 SVDRP POLL TIMERS: timeout while waiting for response

[Gelöst] VDR 2.6.1 SVDRP POLL TIMERS: timeout while waiting for response

[Gelöst] VDR 2.6.1 SVDRP POLL TIMERS: timeout while waiting for response

[Gelöst] VDR 2.6.1 SVDRP POLL TIMERS: timeout while waiting for response