[gelöst] epgsearch - segfault seit dem gestrigen Debian Testing update

Hab noch einen neuen Segfault (nach Auskommentieren des letzten Fehlers oben):

Thread 13 "EPGSearch: conf" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7f01b2ffd700 (LWP 11294)]
0x00007f01f16e1458 in cConflictCheck::ProcessCheckTime(cConflictCheckTime*) () from /usr/lib/vdr/plugins/libvdr-epgsearch.so.2.4.0
(gdb) bt
#0  0x00007f01f16e1458 in cConflictCheck::ProcessCheckTime(cConflictCheckTime*) () at /usr/lib/vdr/plugins/libvdr-epgsearch.so.2.4.0
#1  0x00007f01f16e15a4 in cConflictCheck::CreateConflictList(cList<cConflictCheckTime>*, cList<cConflictCheckTimerObj>*) () at /usr/lib/vdr/plugins/libvdr-epgsearch.so.2.4.0
#2  0x00007f01f16e1814 in cConflictCheck::Check() () at /usr/lib/vdr/plugins/libvdr-epgsearch.so.2.4.0
#3  0x00007f01f16e3277 in cConflictCheckThread::Action() () at /usr/lib/vdr/plugins/libvdr-epgsearch.so.2.4.0
#4  0x0000557ae6df83a1 in cThread::StartThread(cThread*) (Thread=0x557ae7dfe2a0) at thread.c:293
#5  0x00007f01fc7b4fa3 in start_thread (arg=<optimized out>) at pthread_create.c:486
#6  0x00007f01fc0ac88f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Backtrace vom "laufenden Betrieb" der plötzlich (Re-)Startenden Kiste...

Log endet da:

vdr: epg2vdr: Recording of 'It Comes at Night' has 'started' [/srv/vdr/video/local/It_Comes_at_Night/2019-01-06.18.25.100-0.rec]
vdr: [11988] duplicates: Scanning of duplicate recordings started.
vdr: scraper2vdr: Calling mysql_init(11998)
vdr: scraper2vdr: Connection established successfull!
vdr: epg2vdr: Info: Marked 410 recordings as deleted
vdr: [11969] writing timer id '3@roadrunner' to /srv/vdr/video/local/It_Comes_at_Night/2019-01-06.18.25.100-0.rec/.timer
vdr: [11983] EPGSearch: search timer update started
vdr: [11984] EPGSearch: timer conflict check started

==> /var/log/syslog <==
kernel: [25197.506214] EPGSearch: conf[11984] segfault at 1000018 ip 00007f1eba8aa458 sp 00007f1e73ffeba0 error 4 in libvdr-epgsearch.so.2.4.0[7f1eba893000+91000]
kernel: [25197.506235] Code: 89 c3 4c 01 f7 48 8d 47 08 48 39 c3 0f 84 0d fe ff ff 49 8b 75 18 4c 89 ff e8 e4 a6 fe ff 48 8b 45 c8 48 89 45 80 48 8b 43 20 <48> 8b 50 18 48 8b 7a 48 48 85 ff 0f 85 1f ff ff ff 48 8d 15 ea 03
lircd-0.10.1[2307]: Info: removed client
lircd-0.10.1[2307]: Info: closing '/dev/input/event5'
runvdr: restarting VDR

Stefan

Wenn ich das richtig verstehe, bleibt nach einem Erase lediglich das Start-Element der Iteration gültig.

Ein for() Loop ist demnach eher ungünstig, wenn man alle Elemente löscht.

Hab das jetzt mal so gepachted - so läuft es erstmal und scheint noch zu funktionieren.

--- a/conflictcheck.c
+++ b/conflictcheck.c
@@ -584,12 +584,23 @@

     LogFile.Log(3, "add pending timers");
     // if we have pending timers add them to the current start list
+    it = pendingTimers.begin();
+    while (it != pendingTimers.end())
+      {
+        if ((*it) && (*it)->stop > checkTime->evaltime)
+          checkTime->startingTimers.insert(*it);
+        pendingTimers.erase(*it);
+        it = pendingTimers.begin();
+      }
+
+/*
     for (it = pendingTimers.begin(); it != pendingTimers.end(); ++it) {
         if ((*it) && (*it)->stop > checkTime->evaltime)
             checkTime->startingTimers.insert(*it);
         pendingTimers.erase(*it);
     }

+*/
     LogFile.Log(3, "attach starting timers");
     // handle starting timers
     for (it = checkTime->startingTimers.begin(); it != checkTime->startingTimers.end(); ++it) {
@@ -600,12 +611,20 @@
             if (NeedsDetachReceivers) { // but needs to detach all others?
                 // disable running timers
                 std::set<cConflictCheckTimerObj*, TimerObjSort>::iterator it2 = devices[device].recTimers.begin();
-                for (; it2 != devices[device].recTimers.end(); ++it2) {
+                while (it2 != devices[device].recTimers.end()) {
+                    LogFile.Log(3, "stopping timer '%s' (%s, channel %s) at %s on device %d because of higher priority", (*it2)->timer->File(), DAYDATETIME((*it2)->start), CHANNELNAME((*it2)->time$
+                    AddConflict((*it2), checkTime, pendingTimers);
+                    devices[device].recTimers.erase(*it2);
+                   it2 = devices[device].recTimers.begin();
+                    Conflicts++;
+                }
+/*                for (; it2 != devices[device].recTimers.end(); ++it2) {
                     LogFile.Log(3, "stopping timer '%s' (%s, channel %s) at %s on device %d because of higher priority", (*it2)->timer->File(), DAYDATETIME((*it2)->start), CHANNELNAME((*it2)->time$
                     AddConflict((*it2), checkTime, pendingTimers);
                     devices[device].recTimers.erase(*it2);
                     Conflicts++;
                 }
+*/
             }
             devices[device].recTimers.insert(*it);
             (*it)->device = device;

Stefan

Fourty2

Der Patch scheint zu funktionieren. Bei mir trat der Seqfault nur auf wenn tatsächlich ein Timerkonflikt vorlag und das geht jetzt wieder. Timerkonflikte werden also wieder angezeigt.

Allerdings scheint es im Patch einen Fehler zu geben. Die Zeilen 33 und 40 sehen bei mir so aus:

LogFile.Log(3, "stopping timer '%s' (%s, channel %s) at %s on device %d because of higher priority", (*it2)->timer->File(), DAYDATETIME((*it2)->start), CHANNELNAME((*it2)->timer->Channel()), DAYDATETIME(checkTime->evaltime), device + 1);

kamel5

kamel5

Ja stimmt, der Patch ist kaputt. Hab mal wieder aus dem Nano kopiert, ohne vorher ESC+$ zu drücken... Arrgh.

Also fehlt, was rechts nicht im Fenster war.

Anbei der komplette Patch (mit entferntem Alt-Code)

Stefan

Wenn keine negativen Rückmeldungen mehr kommen, werde ich den Patch von Fourty2 ins git übernehmen, da er im Gegensatz zu den bisherigen Vorschlägen auch mit älten clib-Versionen kompiliert.

Ich hätte einen einfacheren Patch, der das Problem auch an der Wurzel packt und noch dazu effektiver implemetiert ist, weil er das sinnlose iterative entfernen der Objekte im set<T> vermeidet.

fix-UB.patch

Zitat von maazl

Ich hätte einen einfacheren Patch, der das Problem auch an der Wurzel packt und noch dazu effektiver implemetiert ist, weil er das sinnlose iterative entfernen der Objekte im set<T> vermeidet.

fix-UB.patch

Funktioniert bei mir bislang einwandfrei!

Danke,

S:oren

Sieht auch für mich vernünftig aus

Gibt es schon ein Repository mit dem Patch von maazl?

Falls nicht, wo finde ich denn ein Repository mit dem letzten Stand von epgsearch (also auch Anpassungen an VDR 2.4., ...)?

Zitat von klak

Hier Debian Testing (gefreezed - {tolles Wort}) . Hab ich 'ne Chance, dass in absehbarer Zeit der Patch ankommt oder sollte ich mich auf den Weg eines selbstkompilierten VDR machen? Habe taeglich 10 - 30 Aufnahmen und ohne epgsearch ist das ein muehseliges Unterfangen.

Es genügt, wenn du dir die aktuelle Version von epgsearch baust, den VDR (und die anderen von dir genutzten Plugins) musst du deswegen nicht selber bauen. Wenn du das als Debian-Paket haben willst, kannst du das Quellpaket aus dem yavdr-PPA nehmen:

sudo apt install vdr-dev build-essential devscripts pkg-config
sudo apt build-dep vdr-plugin-epgsearch
dget -xu https://launchpad.net/~yavdr/+archive/ubuntu/experimental-vdr/+sourcefiles/vdr-plugin-epgsearch/2.4.0+git20190116-1-49ba796-0yavdr0~bionic/vdr-plugin-epgsearch_2.4.0+git20190116-1-49ba796-0yavdr0~bionic.dsc
cd vdr-plugin-epgsearch*
dpkg-buildpackage -us -uc
sudo apt install ../vdr-plugin-epgsearch*.deb

Zitat von MarkusE

Gibt es schon ein Repository mit dem Patch von maazl?

Falls nicht, wo finde ich denn ein Repository mit dem letzten Stand von epgsearch (also auch Anpassungen an VDR 2.4., ...)?

https://projects.vdr-developer…f0ebba68a25ddfc92d3d70aad

https://launchpad.net/~yavdr/+…e/ubuntu/experimental-vdr

Ich habe den Überblick verloren und stehe hier grad total aufm Schlauch. Ich konnte anhand der Logfiles des VDR das vdr-plugin-epgsearch als Segmentaion fault verursachendes Plugin Identifizieren. Aber jetzt geht der Mist wieder los ( Debian 10 / vdr 2.4.0 aus main Repos )

Nachgelesen = o.g. Plugin hat im Programmcode eine Fehler in einem Loop => selbst kompilieren

Dann bin ich nach o.g. Anweisungen vorgegangen ( dget -xu https://launchpad.net/~yavdr/+…9ba796-0yavdr0~bionic.dsc ) => Datei Offline

Dann habe ich auf GIT Hub nach e-Tobis code gesucht, in der Repoliste steht eien gepachte version drin, aber ich diese nicht herunterladen.

Als auch das nicht erfolgreich war habe ich nach einer Debian 10 Quelle für das EPG search Plugin gesucht : (https://packages.e-tobi.net/vd…ch/binary/vdr-multipatch/

wget https://packages.e-tobi.net/vdr-experimental/pool-stretch/binary/vdr-multipatch/vdr-plugin-epgsearch_2.4.0%2bgit20190507-1_amd64.deb
--2019-10-07 12:20:03--  https://packages.e-tobi.net/vdr-experimental/pool-stretch/binary/vdr-multipatch/vdr-plugin-epgsearch_2.4.0%2bgit20190507-1_amd64.deb
Auflösen des Hostnamens packages.e-tobi.net (packages.e-tobi.net)… 85.214.78.111
Verbindungsaufbau zu packages.e-tobi.net (packages.e-tobi.net)|85.214.78.111|:443 … verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet … 200 OK
Länge: 636678 (622K) [application/octet-stream]
Wird in »vdr-plugin-epgsearch_2.4.0+git20190507-1_amd64.deb« gespeichert.

vdr-plugin-epgsearch_2.4.0+git20190507-1_amd64 100%[=================================================================================================>] 621,76K  1,43MB/s    in 0,4s

2019-10-07 12:20:03 (1,43 MB/s) - »vdr-plugin-epgsearch_2.4.0+git20190507-1_amd64.deb« gespeichert [636678/636678]

root@ngNAS:~# ll
insgesamt 1,1M
-rw-r--r-- 1 root root 622K Jul 15 01:40 vdr-plugin-epgsearch_2.4.0+git20190507-1_amd64.deb
drwxrwxr-x 8 root root 4,0K Jan 16  2019 vdr-plugin-epgsearch-49ba796fe6298abf0ebba68a25ddfc92d3d70aad
-rw-r--r-- 1 root root 469K Okt  7 12:10 vdr-plugin-epgsearch-49ba796fe6298abf0ebba68a25ddfc92d3d70aad.tar.gz
root@ngNAS:~# dpkg -i vdr-plugin-epgsearch_2.4.0+git20190507-1_amd64.deb
Vormals nicht ausgewähltes Paket vdr-plugin-epgsearch wird gewählt.
(Lese Datenbank ... 80100 Dateien und Verzeichnisse sind derzeit installiert.)
Vorbereitung zum Entpacken von vdr-plugin-epgsearch_2.4.0+git20190507-1_amd64.deb ...
Entpacken von vdr-plugin-epgsearch (2.4.0+git20190507-1) ...
dpkg: Abhängigkeitsprobleme verhindern Konfiguration von vdr-plugin-epgsearch:
vdr-plugin-epgsearch hängt ab von vdr-abi-2.4.1-multipatch-1; aber:
Paket vdr-abi-2.4.1-multipatch-1 ist nicht installiert.

dpkg: Fehler beim Bearbeiten des Paketes vdr-plugin-epgsearch (--install):
Abhängigkeitsprobleme - verbleibt unkonfiguriert
Trigger für man-db (2.8.5-2) werden verarbeitet ...
Fehler traten auf beim Bearbeiten von:
vdr-plugin-epgsearch

Wie fast immer bei den verfluchten VDR Kompilations Horror lief auch das nicht wirklich.

Es ist jede mal der gleich Mist : Beim VDR Update läuft danach erstmal nichts stabil und richtig.

Hier auch : https://salsa.debian.org/vdr-team/vdr-plugin-epgsearch: lt VDR version läuft alles auf vdr 2.4.0.. Die Kopilation endet dann wieder mit :

dpkg-buildpackage -us -uc
dpkg-buildpackage: Information: Quellpaket vdr-plugin-epgsearch
dpkg-buildpackage: Information: Quellversion 2.4.0+git20190507-2
dpkg-buildpackage: Information: Quelldistribution unstable
dpkg-buildpackage: Information: Quelle geändert durch Tobias Grimm <etobi@debian.org>
dpkg-buildpackage: Information: Host-Architektur amd64
 dpkg-source --before-build .
dpkg-checkbuilddeps: Fehler: Nicht erfüllte Bauabhängigkeiten: vdr-dev (>= 2.4.1)
dpkg-buildpackage: Warnung: Bauabhängigkeiten/-konflikte nicht erfüllt; Abbruch
dpkg-buildpackage: Warnung: (Verwenden Sie -d, um sich darüber hinwegzusetzen.)

Warum wird vdr-dev 2.4.1 verlangt wenn doch 2.4.0 als Code Grundlage genutzt wird ?

Es wäre nett wenn mir helfen könnte, wie ich das vdr-plugin-live kompilieren kann, was ich außer den Standartkpompilertools noch brauche und wo ich welche Software herbekomme, was ich genau an Paketen installieren muss.

Gibt es keine Möglichkeit, das System anhand des installierten VDR kompilierbereit zu machen ( apt install "alles was zum kompilieren von $(dpgk -l | grep vdr ) nötig ist ) , dann den aktuellen passenden Plugin Quellcode von "keine was wozu wie passt" laden und kompilieren. Was bei viele anderen Programmen recht Problemlos klappt endet beim VDR jedes mal in Tagelangen Read-Compile-Frustration Horror.

EDIT : lt. :

dpkg -l | grep epg
ii  vdr-plugin-epgsearch                 2.2.0+git20170817-2              amd64        VDR plugin that provides extensive EPG searching capabilities

ist jetzt eine 2te Version des Plugins installiert worden. Ist das EPG Search Confict Programmteil deaktiviert worden ? Der VDR läuft zwat jetzt ( stabil ??? ) auch mit dem epg search plugin, meldet nur keine Timerkonflikte mehr. Wäre für mich akzeptabe solange der vdr denn endlich stabil läuft und die Suchtimer laufen.

Grad getestet : In Version :

show_sources vdr vdr-plugin-epgsearch
       vdr | 2.4.0-1+b1 | http://deb.debian.org/debian buster/main amd64 Packages
       vdr |    2.4.0-1 | http://deb.debian.org/debian buster/main Sources
vdr-plugin-epgsearch | 2.2.0+git20170817-2 | http://deb.debian.org/debian buster/main amd64 Packages
vdr-plugin-epgsearch | 2.2.0+git20170817-2 | http://deb.debian.org/debian buster/main Sources

wurde der epg conflict check deaktiviert. Der VDR läuft stabil, Timer etc läuft alles, Timerkonflikte werden ignoriert. Frei nach dem Prinzip " Wer zuerst kommt mahlt zuerst" werden die Timer abgearbeitet.

Bin mal gespannt ob der VDR länger 1-2 Stunden läuft ....

Hallo,

Zitat von speefak

Dann bin ich nach o.g. Anweisungen vorgegangen ( dget -xu https://launchpad.net/~yavdr/+…9ba796-0yavdr0~bionic.dsc )

=> Datei Offline

da musst du das aktuelle Paket mit "dget -xu" holen.

https://launchpad.net/~yavdr/+archive/ubuntu/experimental-vdr/+sourcefiles/vdr-plugin-epgsearch/2.4.0+git20190919-8-84811de-0yavdr0~bionic/vdr-plugin-epgsearch_2.4.0+git20190919-8-84811de-0yavdr0~bionic.dsc

Gruss

Wolfgang

Zum Kompilieren von Plugins benötigst du die Header-Dateien (und pkgbuild-Informationen) der installierten VDR-Version. Die stecken bei den Debian-Paketen seit jeher im Paket vdr-dev, das bei deinem Paketbauversuch auch als fehlend angemeckert wurde.

Um die Bau-Abhängigkeiten eines Paketes aufzulösen, kannst du entweder einen Blick in debian/control des Quellpakets werfen oder mk-build-deps -i (aus dem devscripts Paket) aufrufen (vgl. https://manpages.debian.org/st…s/mk-build-deps.1.en.html ), das dir ein Paket baut, das die benötigten Build-Dependencies als Abhängigkeiten hat und das Paket zusammen mit diesen installiert.

Dann solltest du vermeiden die Versionen des VDR und von Plugins durcheinander zu werfen. Wenn epgsearch die Version 2.4.0 hat und der VDR die Version 2.4.1 stört das nicht, solange die API des VDR auf Quellcodeebene noch passt.

Das virtuelle Paket vdr-abi-<VERSION> ist an das VDR-Paket gebunden (wird über debian/abi-version im Quellpaket für den VDR und https://salsa.debian.org/vdr-t…b/master/debian/rules#L38 f. festgelegt) und Pakete für Plugins, die dagegen gebaut wurden, werden auf exakt diese ABI-Version festgelegt, weil alles andere nicht sicher binärkompatibel wäre. Das hat den (beabsichtigten) Effekt, dass man nicht wahllos Plugins aus anderen Paketquellen installieren kann, sondern sie im Zweifelsfall neu aus den Sourcen bauen muss.

Intern hängt die ABI aber vor allem von der VDR-Version und den zusätzlich auf den VDR-Quellcode angewendeten Patches ab, daher sollte man die ABI-Version immer ändern, wenn man das VDR-Paket mit ABI-brechenden Änderungen neu baut.

Ich kann dir nur empfehlen endlich mal die verfügbare Debian-Dokumentation zum Paketbau zu lesen und mit dem Wissen nachzuvollziehen, was in den Quellpaketen für den VDR und der Plugins passiert, statt sich jahrelang immer wieder zu wundern, warum es nicht funktioniert, wenn man versucht Probleme mit blindem Aktionismus zu lösen statt die Problemstellung mal ordentlich durchzuarbeiten und zu verstehen wie das ganze funktioniert.

Zitat von wolfi.m

Hallo,

da musst du das aktuelle Paket mit "dget -xu" holen.

Code

https://launchpad.net/~yavdr/+archive/ubuntu/experimental-vdr/+sourcefiles/vdr-plugin-epgsearch/2.4.0+git20190919-8-84811de-0yavdr0~bionic/vdr-plugin-epgsearch_2.4.0+git20190919-8-84811de-0yavdr0~bionic.dsc

Gruss

Wolfgang

Alles anzeigen

wie bist du an den Link gekommen ? Unter "https://launchpad.net/~yavdr" fand ich nichts ?!

funktioniert :

sudo apt install vdr-dev build-essential devscripts pkg-config libpcre3-dev
sudo apt build-dep vdr-plugin-epgsearch
dget -xu https://launchpad.net/~yavdr/+archive/ubuntu/experimental-vdr/+sourcefiles/vdr-plugin-epgsearch/2.4.0+git20190919-8-84811de-0yavdr0~bionic/vdr-plugin-epgsearch_2.4.0+git20190919-8-84811de-0yavdr0~bionic.dsc
cd vdr-plugin-epgsearch*
dpkg-buildpackage -us -uc
dpkg -i ../vdr-plugin-epgsearch_2.4.0+git20190919-8-84811de-0yavdr0~bionic_amd64.deb

Zitat von seahawk1986

Zum Kompilieren von Plugins benötigst du die Header-Dateien (und pkgbuild-Informationen) der installierten VDR-Version. Die stecken bei den Debian-Paketen seit jeher im Paket vdr-dev, das bei deinem Paketbauversuch auch als fehlend angemeckert wurde.

Um die Bau-Abhängigkeiten eines Paketes aufzulösen, kannst du entweder einen Blick in debian/control des Quellpakets werfen oder mk-build-deps -i (aus dem devscripts Paket) aufrufen (vgl. https://manpages.debian.org/st…s/mk-build-deps.1.en.html ), das dir ein Paket baut, das die benötigten Build-Dependencies als Abhängigkeiten hat und das Paket zusammen mit diesen installiert.

Danke für die Info: mk-build-deps -i <packetname>. Die Installation von vdr-dev als Sourcecodebasis habe ich erfolgreich vorgenommen ( und die der anderen Kompilertools )

Zitat von seahawk1986

Dann solltest du vermeiden die Versionen des VDR und von Plugins durcheinander zu werfen. Wenn epgsearch die Version 2.4.0 hat und der VDR die Version 2.4.1 stört das nicht, solange die API des VDR auf Quellcodeebene noch passt.

Das ist mir seit dem letzten Umsteig von Debian 8 auf 9 klar geworden. Darum wunderte ich mich ja über die Angabe des vdr-plugin-epgsearch Quellcodes aus den o.g. Quellen auf Basis des VDR 2.4.0 und dann wurde vdr-dev 2.4.1 statt 2.4.0 verlangt. 2.4.1 ist aber nicht in den Repos verfügbar und bevor ich mein System wieder mit zig Quellen überlade dachte ich mir es muss auch mit vdr-dev 2.4.0 gehen ( was es mit dem Quellcode link von wolfi-m auch tat. ).

Die Suche nach dem Passenden Quellcode war nicht so einfach.

Zitat von seahawk1986

Das virtuelle Paket vdr-abi-<VERSION> ist an das VDR-Paket gebunden (wird über debian/abi-version im Quellpaket für den VDR und https://salsa.debian.org/vdr-t…b/master/debian/rules#L38 f. festgelegt) und Pakete für Plugins, die dagegen gebaut wurden, werden auf exakt diese ABI-Version festgelegt, weil alles andere nicht sicher binärkompatibel wäre. Das hat den (beabsichtigten) Effekt, dass man nicht wahllos Plugins aus anderen Paketquellen installieren kann, sondern sie im Zweifelsfall neu aus den Sourcen bauen muss.

Intern hängt die ABI aber vor allem von der VDR-Version und den zusätzlich auf den VDR-Quellcode angewendeten Patches ab, daher sollte man die ABI-Version immer ändern, wenn man das VDR-Paket mit ABI-brechenden Änderungen neu baut.

Darum suchte ich ja eine gepachte vdr-plugin-epgsearch Version die kompatibel zum vdr-dev 2.4.0 ist. Und daran scheiterte es dann. Die VDR ABI zu ändern habe ich seit dem letzten update gelernt möglichst zu vermeiden, da in Folge dessen noch mehr Fehler auftraten.

Zitat von seahawk1986

Ich kann dir nur empfehlen endlich mal die verfügbare Debian-Dokumentation zum Paketbau zu lesen und mit dem Wissen nachzuvollziehen, was in den Quellpaketen für den VDR und der Plugins passiert, statt sich jahrelang immer wieder zu wundern, warum es nicht funktioniert, wenn man versucht Probleme mit blindem Aktionismus zu lösen statt die Problemstellung mal ordentlich durchzuarbeiten und zu verstehen wie das ganze funktioniert.

Nimm es mir nicht übel aber das habe ich vor knapp 3 Jahren schon einmal gemacht und es klappte auch alles wunderbar - Nur leider ist mein Hirn kein USB Stick oder Kristallspeicher und verliert daher die ein oder andere Information in Abhängigkeit des Faktors Zeit. Analytisch bin vorgegangen, einfach nach dem "Try and Error" Prinzip vorzugehen endet beim Kompilieren meist in Chaos.

In dem Sinn Danke für Infos.

EDIT : Ein Test Ergab gerade Folgendes Szenario :

EPG Konflikte werden genau 1 mal im Live Plugin angezeigt, aktualisiert man den Browser nach der Anzeige wird kein Konflikt mehr angezeigt - Timerkonflikt besteht allerdings weiterhin.

Klickt man im Live Plugin auf den Timerkonflikt wird dieser nicht angezeigt. DAS fenster und der Header der Liste wird angezeigt, aber nicht der Timerkonflikt selbst.

Solange der Rest stabil läuft kann ich damit leben.