[ANNOUNCE] VDR developer version 2.3.1

Zitat von kls

Magst du bitte mal beliegenden Patch probieren?

Crasht immer noch, Backtrace sieht nun so aus:

Program terminated with signal 7, Aborted.
#0  0xb77ba430 in __kernel_vsyscall ()
(gdb) bt
#0  0xb77ba430 in __kernel_vsyscall ()
#1  0xb73fb661 in *__GI_raise (sig=6)
    at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#2  0xb73fea92 in *__GI_abort () at abort.c:92
#3  0x081a4e4b in cStateKey::Remove (this=0xbf99a218, IncState=true)
    at thread.c:537
#4  0x080e078c in cRecordingsLock::~cRecordingsLock (this=0xbf99a218,
    __in_chrg=<optimized out>) at recording.h:291
#5  0x081561df in cResumeFile::Save (this=0xa88fc64, Index=12)
    at recording.c:319
#6  0x080f7ae9 in cIndexFile::StoreResume (this=0xa88fc48, Index=12)
    at recording.h:476
#7  0x080f528c in cDvbPlayer::Save (this=0xf9e7e58) at dvbplayer.c:398
#8  0x080f4b65 in cDvbPlayer::~cDvbPlayer (this=0xf9e7e58,
    __in_chrg=<optimized out>) at dvbplayer.c:305
#9  0x080f4c93 in cDvbPlayer::~cDvbPlayer (this=0xf9e7e58,
    __in_chrg=<optimized out>) at dvbplayer.c:312
#10 0x080f7718 in cDvbPlayerControl::Stop (this=0xcff1d40) at dvbplayer.c:962
#11 0x081334b5 in cReplayControl::Stop (this=0xcff1d40) at menu.c:5496
#12 0x0813311f in cReplayControl::~cReplayControl (this=0xcff1d40,
    __in_chrg=<optimized out>) at menu.c:5456
#13 0x081331b7 in cReplayControl::~cReplayControl (this=0xcff1d40,
    __in_chrg=<optimized out>) at menu.c:5459
#14 0x081512e7 in cControl::Shutdown () at player.c:105
n cMenuRecordings::Delete (this=0xa8eb360) at menu.c:3112
#16 0x0812580f in cMenuRecordings::ProcessKey (this=0xa8eb360, Key=kYellow)
    at menu.c:3186
#17 0x0814189d in cOsdMenu::ProcessKey (this=0xa944c58, Key=kYellow)
    at osdbase.c:528
#18 0x08125775 in cMenuRecordings::ProcessKey (this=0xa944c58, Key=kYellow)
    at menu.c:3177
#19 0x0814189d in cOsdMenu::ProcessKey (this=0xa3df008, Key=kYellow)
    at osdbase.c:528
#20 0x0812e364 in cMenuMain::ProcessKey (this=0xa3df008, Key=kYellow)
    at menu.c:4372
#21 0x081b68be in main (argc=18, argv=0xbf99aa54) at vdr.c:1354
(gdb)

Edit:
Der erste Patch ist dabei auch noch drin - spielt jedoch vermutlich keine Rolle, oder?

CU
Oliver

Sorry, da fehlte noch eine Zeile.
Anbei ein neuer Versuch.

Der erste Patch soll ruhig drin bleiben.

Klaus

Zitat von Copperhead

Ich fange jetzt doch mal mit Fixen an. Patches landen dann im VDR4Arch Git.

Nachdem ich jetzt auch mal VDR 2.3.1 installiert habe hat sich herausgestellt, dass "es kompiliert" nicht gleich "es funktioniert" heißt. Zumindest mit dem Patch für epgsearch habe ich jetzt Segfaults

Zitat von kls

Sorry, da fehlte noch eine Zeile.
Anbei ein neuer Versuch.

Der erste Patch soll ruhig drin bleiben.

Crasht immer noch:

Program terminated with signal 11, Segmentation fault.
#0  0x08136426 in cList<cRecording>::First (this=0x0) at tools.h:573
573       const T *First(void) const { return (T *)objects; }
(gdb) bt
#0  0x08136426 in cList<cRecording>::First (this=0x0) at tools.h:573
#1  0x0815afb5 in cRecordings::MBperMinute (this=0x0) at recording.c:1573
#2  0x081b9134 in cVideoDiskUsage::HasChanged (State=@0x828fa74: 2)
    at videodir.c:214
#3  0x081b921e in cVideoDiskUsage::String () at videodir.c:231
#4  0x0816f3f8 in cSkinClassicDisplayMenu::DrawTitle (this=0xb2f4108)
    at skinclassic.c:282
#5  0x0816f541 in cSkinClassicDisplayMenu::SetTitle (this=0xb2f4108,
    Title=0x9e6cd50 "Abenteuer Leben - täglich neu entdecken")
    at skinclassic.c:288
#6  0x0814077e in cOsdMenu::Display (this=0xa4b1f88) at osdbase.c:238
#7  0x081251f9 in cMenuRecordings::Delete (this=0xa4b1f88) at menu.c:3121
#8  0x0812580f in cMenuRecordings::ProcessKey (this=0xa4b1f88, Key=kYellow)
    at menu.c:3186
#9  0x0814189d in cOsdMenu::ProcessKey (this=0xb34bee8, Key=kYellow)
    at osdbase.c:528
#10 0x08125775 in cMenuRecordings::ProcessKey (this=0xb34bee8, Key=kYellow)
    at menu.c:3177
#11 0x0814189d in cOsdMenu::ProcessKey (this=0xb319ee8, Key=kYellow)
    at osdbase.c:528
#12 0x0812e364 in cMenuMain::ProcessKey (this=0xb319ee8, Key=kYellow)
    at menu.c:4372
#13 0x081b68c6 in main (argc=17, argv=0xbfaf2784) at vdr.c:1354
(gdb)

CU
Oliver

Zitat von Copperhead

Nachdem ich jetzt auch mal VDR 2.3.1 installiert habe hat sich herausgestellt, dass "es kompiliert" nicht gleich "es funktioniert" heißt. Zumindest mit dem Patch für epgsearch habe ich jetzt Segfaults

Da wäre es hilfreich zu erfahren, bei welcher Aktion und unter welchen Umständen das passiert. Und ein Backtrace könnte auch nicht schaden ;-).

Klaus

#0  0x00007f33af3d6ee7 in cTimersLock::cTimersLock (Write=false, this=0x7f33a3859a10)
    at /usr/include/vdr/timers.h:204
No locals.
#1  cSearchExt::GetTimerList (this=this@entry=0x7f339d0fa5c0, timerList=0x7f339d0d96a0, 
    timerList@entry=0x0) at epgsearchext.c:1375
        TimersLock = {stateKey = {stateLock = 0x0, write = false, state = -1, timedOut = false}, 
          list = 0x0}
#2  0x00007f33af43bbd6 in cSearchTimerThread::Action (this=0xf4a1b0) at searchtimer_thread.c:254
        pSearchResults = <optimized out>
        localSearchExts = 0x7f339c0008e0
        searchExt = 0x7f339d0fa5c0
        TimersLock = {stateKey = {stateLock = 0x7fece0 <cTimers::timers+32>, write = true, 
            state = -1, timedOut = false}, list = 0x7fecc0 <cTimers::timers>}
        pOutdatedTimers = 0x0
        now = 1442749319
        needUpdate = <optimized out>
        nextUpdate = <optimized out>
#3  0x0000000000520249 in cThread::StartThread (Thread=0xf4a1b0) at thread.c:272
No locals.
#4  0x00007f33b43064a4 in start_thread () from /usr/lib/libpthread.so.0
No symbol table info available.
#5  0x00007f33b2ca413d in clone () from /usr/lib/libc.so.6
No symbol table info available.

Hier mal ein Backtrace. Und hier der Patch: https://github.com/VDR4Arch/vd…earch-vdr2.3.1compat.diff
Ich bin mir sicher, dass ich das mit meinen Halbwissen verpfuscht habe.

Copperhead:

Zum konkreten Crash kann ich noch nichts sagen.
Aber grundsätzlich ist sowas natürlich nicht schön:

@@ -47,8 +47,9 @@ cBlacklist::cBlacklist(void)
     startTime = 0000;
     stopTime = 2359;
     useChannel = false;
-    channelMin = Channels.GetByNumber(cDevice::CurrentChannel());
-    channelMax = Channels.GetByNumber(cDevice::CurrentChannel());
+    LOCK_CHANNELS_READ;
+    channelMin = (cChannel*) Channels->GetByNumber(cDevice::CurrentChannel());
+    channelMax = (cChannel*) Channels->GetByNumber(cDevice::CurrentChannel());
     channelGroup = NULL;
     useCase = false;
     mode = 0;

Anstatt hier das 'const' wegzucasten sollten lieber channelMin und channelMax zu 'const cChannel *' gemacht werden. Gilt auch für alle anderen entsprechenden Stellen, wie etwa

@@ -518,9 +521,9 @@ cEvent * cBlacklist::GetEventByBlacklist(const cSchedule *schedules, const cEven
   cEvent *p1 = NULL;
 
   if (Start)
-      p1 = schedules->Events()->Next(Start);
+      p1 = (cEvent*) schedules->Events()->Next(Start);
   else
-      p1 = schedules->Events()->First();
+      p1 = (cEvent*) schedules->Events()->First();
 
   time_t tNow=time(NULL);
   char* szTest = NULL;

Auch hier

@@ -263,12 +262,13 @@ cList<cConflictCheckTimerObj>* cConflictCheck::CreateCurrentTimerList()
     // collect single event timers
     time_t tMax = 0;
     cTimer* ti = NULL;
-    for (ti = Timers.First(); ti; ti = Timers.Next(ti))
+    LOCK_TIMERS_READ;
+    for (const cTimer* ti = Timers->First(); ti; ti = Timers->Next(ti))
     {
 	tMax = max(tMax, ti->StartTime());
 	if (!ti->IsSingleEvent()) continue;
         // already recording?
-	int deviceNr = gl_recStatusMonitor->TimerRecDevice(ti)-1;
+	int deviceNr = gl_recStatusMonitor->TimerRecDevice((cTimer*)ti)-1;
 
         // create a copy of this timer
         cTimer* clone = new cTimer(*ti);

sollte der Parameter von TimerRecDevice() zu 'const cTimer *' geändert werden.

Bei sowas hier

--- a/conflictcheck.h
+++ b/conflictcheck.h
@@ -59,7 +59,7 @@ class cConflictCheckTimerObj : public cTimerObj
     const cEvent* Event();
     const cEvent* SetEventFromSchedule();
     int Matches(const cEvent *Event, int *Overlap) const;
-    cTimer* OrigTimer() {return Timers.GetTimer(timer); }
+    cTimer* OrigTimer() {LOCK_TIMERS_WRITE; return Timers->GetTimer(timer); }
 };
 
 class TimerObjSort

sollte der Funktion OrigTimer() die Timers-Liste vom Aufrufer übergeben werden, da dieser den Lock halten sollte. Und es sollte auch überlegt werden, ob es wirkllich ein Write-Lock sein muß. Mit denen sollte man möglichst sparsam umgehen.

DerTypecast hier

-   cTimer *ti = Timers.First();
+   LOCK_TIMERS_WRITE;
+   cTimer *ti = (cTimer*) Timers->First();

ist unnötig.

Hier (und auch an anderen Stellen)

@@ -232,7 +232,9 @@ cString cPluginEpgsearch::SVDRPCommand(const char *Command, const char *Option,
             {
                LogFile.Log(1,"search '%s' deleted via SVDRP", search->search);
                cMutexLock SearchExtsLock(&SearchExts);
-               if (delTimers && !Timers.BeingEdited())
+               LOCK_TIMERS_WRITE;
+               Timers->SetExplicitModify();
+               if (delTimers)
                   search->DeleteAllTimers();
                SearchExts.Del(search);
                SearchExts.Save();

wird Timers->SetExplicitModify() gesetzt, aber es folgt nirgendwo ein Timers->SetModified().

Mein Rat: erstmal die ganzen Typecasts, mit denen 'const' weggecastet wird, entfernen und lieber die entsprechenden Variablen und Parameter zu 'const' machen.
Dann genau überlegen, ob es an der ein oder anderen Stelle wirklich ein Write-Lock sein muß, oder ob nicht ein Read-Lock auch reicht. Write-Locks sollten nur gemacht werden, wenn auch wirklich etwas verändert werden soll.

Im Backtrace wird searchtimer_thread.c:254 angegeben, aber im Diff hat sich in der Gegend anscheinend gar nichts geändert.

Alles in Allem sollte sich vielleicht auch mal der Original-Autor dieses Plugins mit der Sache befassen, weil der vielleicht auch den besseren Überblick hat, was genau wo geschehen soll. Ich habe jetzt nur mal rein mechanisch drübergeschaut, ohne das alles im Einzelnen zu verstehen. Dafür ist der Code viel zu lang...

Klaus

Der Original-Autor braucht mir aber zu lange. Außerdem versuche ich daraus auch was zu lernen.

Das ganze casten kann ich scheinbar komplett umgehen. Hätte ich mal gleich so machen sollen...
Ich mach den neuen Patch mal fertig. Vielleicht funktioniert es ja dann schon.

Hallo,

der aktuelle GIT-Stand von EnigmaNG & ExtRecMenu kompilieren nun mit VDR 2.3.1. Soweit ich es testen konnte, funktionieren sie auch. Bugs bitte melden.

@Klaus:
cRecordings::StateChanged() und cRecordings::ChangeState() gibt's ja nun nicht mehr. Im ExtRecMenu wurde das genutzt.
Ich bin mir nicht ganz sicher, wie man das in der neuen Version nutzen kann.

Gruß
Andreas

kls
Hast Du den letzten Backtrace Link übersehen? Passiert nach wie vor beim Löschen einer Aufnahme während der Wiedergabe.

CU
Oliver

Zitat von amair

ExtRecMenu kompilieren nun mit VDR 2.3.1. Soweit ich es testen konnte, funktionieren sie auch. Bugs bitte melden.

extrecmenu baut in der letzten Version bei mir nicht mehr gegen den VDR 2.2.0:

g++ -g -O3 -Wall -Werror=overloaded-virtual -Wno-parentheses -fPIC -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -c -DPLUGIN_NAME_I18N='"extrecmenu"' -DUSE_GRAPHTFT -DUSE_PINPLUGIN -DUSE_VDR_CUTTER  -o extrecmenu.o extrecmenu.c
g++ -g -O3 -Wall -Werror=overloaded-virtual -Wno-parentheses -fPIC -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -c -DPLUGIN_NAME_I18N='"extrecmenu"' -DUSE_GRAPHTFT -DUSE_PINPLUGIN -DUSE_VDR_CUTTER  -o mymenurecordings.o mymenurecordings.c
g++ -g -O3 -Wall -Werror=overloaded-virtual -Wno-parentheses -fPIC -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -c -DPLUGIN_NAME_I18N='"extrecmenu"' -DUSE_GRAPHTFT -DUSE_PINPLUGIN -DUSE_VDR_CUTTER  -o mymenueditrecording.o mymenueditrecording.c
g++ -g -O3 -Wall -Werror=overloaded-virtual -Wno-parentheses -fPIC -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -c -DPLUGIN_NAME_I18N='"extrecmenu"' -DUSE_GRAPHTFT -DUSE_PINPLUGIN -DUSE_VDR_CUTTER  -o myreplaycontrol.o myreplaycontrol.c
g++ -g -O3 -Wall -Werror=overloaded-virtual -Wno-parentheses -fPIC -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -c -DPLUGIN_NAME_I18N='"extrecmenu"' -DUSE_GRAPHTFT -DUSE_PINPLUGIN -DUSE_VDR_CUTTER  -o mymenucommands.o mymenucommands.c
g++ -g -O3 -Wall -Werror=overloaded-virtual -Wno-parentheses -fPIC -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -c -DPLUGIN_NAME_I18N='"extrecmenu"' -DUSE_GRAPHTFT -DUSE_PINPLUGIN -DUSE_VDR_CUTTER  -o mymenusetup.o mymenusetup.c
g++ -g -O3 -Wall -Werror=overloaded-virtual -Wno-parentheses -fPIC -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -c -DPLUGIN_NAME_I18N='"extrecmenu"' -DUSE_GRAPHTFT -DUSE_PINPLUGIN -DUSE_VDR_CUTTER  -o tools.o tools.c
tools.c:209:1: error: prototype for 'myRecListItem::myRecListItem(const cRecording*)' does not match any in class 'myRecListItem'
 myRecListItem::myRecListItem(const cRecording *Recording)
 ^
In file included from tools.c:13:0:
tools.h:30:7: error: candidates are: myRecListItem::myRecListItem(const myRecListItem&)
 class myRecListItem:public cListObject
       ^
tools.h:44:5: error:                 myRecListItem::myRecListItem(cRecording*)
     myRecListItem(cRecording *Recording);
     ^
make[2]: *** [tools.o] Error 1

Liegt das eventuell daran, dass das Argument für myRecListItem::myRecListItem auf const cRecording *Recording umgestellt wird, ohne auf die VDRVERSNUM zu prüfen?

@@ -195,9 +206,9 @@ bool MoveRename(const char *OldName,const char *NewName,cRecording *Recording,bo
 // --- myRecListItem ----------------------------------------------------------
 bool myRecListItem::SortByName=false;
 
-myRecListItem::myRecListItem(cRecording *Recording)
+myRecListItem::myRecListItem(const cRecording *Recording)
 {
-  recording=Recording;
+  recording=(cRecording *)Recording;
   filename=strdup(recording->FileName());
   sortBufferName = sortBufferTime = NULL;
 }

Zitat von UFO

kls
Hast Du den letzten Backtrace Link übersehen? Passiert nach wie vor beim Löschen einer Aufnahme während der Wiedergabe.

Hab ich gesehen, bin nur noch nicht dazu gekommen, mich ausführlicher damit zu beschäftigen.
Ein Problem ist auch, daß es mir nich nicht gelungen ist, den Fehler hier nachzuvollziehen. Entweder ich mache da was falsch oder es ist ein Timing-Problem.
Ich schau es mir auf alle Fälle noch an. Zur Zeit bin ich nur leider zeitlich etwas knapp, es kann also etwas dauern...

Klaus

Zitat von amair

cRecordings::StateChanged() und cRecordings::ChangeState() gibt's ja nun nicht mehr. Im ExtRecMenu wurde das genutzt.
Ich bin mir nicht ganz sicher, wie man das in der neuen Version nutzen kann.

static const cTimers *GetTimersRead(cStateKey &StateKey, int TimeoutMs = 0);
      ///< Gets the list of timers for read access. If TimeoutMs is given,
      ///< it will wait that long to get a write lock before giving up.
      ///< Otherwise it will wait indefinitely. If no read lock can be
      ///< obtained within the given timeout, NULL will be returned.
      ///< The list is locked and a pointer to it is returned if the state
      ///< of the list is different than the state of the given StateKey.
      ///< If both states are equal, the list of timers has not been modified
      ///< since the last call with the same StateKey, and NULL will be
      ///< returned (and the list is not locked). After the returned list of
      ///< timers is no longer needed, the StateKey's Remove() function must
      ///< be called to release the list. The time between calling
      ///< cTimers::GetTimersRead() and StateKey.Remove() should be as short
      ///< as possible. After calling StateKey.Remove() the list returned from
      ///< this call must not be accessed any more. If you need to access the
      ///< timers again later, a new call to GetTimersRead() must be made.
      ///< A typical code sequence would look like this:
      ///< cStateKey StateKey;
      ///< if (const cTimers *Timers = cTimers::GetTimersRead(StateKey)) {
      ///<    // access the timers
      ///<    StateKey.Remove();
      ///<    }

Gilt entsprechend auch für cRecordings.
Wenn du den cStateKey "langlebig" machst, dann bekommst du den Pointer nur dann übergeben, wenn sich was geändert hat.

Klaus

Zitat von kls

Hab ich gesehen, bin nur noch nicht dazu gekommen, mich ausführlicher damit zu beschäftigen.
Ein Problem ist auch, daß es mir nich nicht gelungen ist, den Fehler hier nachzuvollziehen. Entweder ich mache da was falsch oder es ist ein Timing-Problem.
Ich schau es mir auf alle Fälle noch an. Zur Zeit bin ich nur leider zeitlich etwas knapp, es kann also etwas dauern...

Kein Problem. Hier noch einmal das Setup:
- vdr 2.3.1 + vdr-2.3.1-fixcrashdelrec.diff + vdr-2.3.1-grantrecursivewritelocks-2.diff
- dvbsddevice
- remote 0.7
- Classic Skin

Laut Backtrace passiert der Crash irgendwie bei der Ausgabe im Classic Skin.

CU
Oliver

An die Patch-Autoren:
Es wäre klasse, wenn die Plugins auch weiterhin mit vdr 2.2.0 bauen. Also müssen wahrscheinlich ein paar hässliche ifdefs rein. Solange es keinen vdr 2.4 gibt, sollte vdr 2.2 noch unterstützt werden.

Danke!

Lars

Ich wäre ja froh, wenn meine Patches überhaupt funktionieren würden.

Die Fehlermeldungen von GCC sagen mir leider überhaupt nix. Mal sehen, was clang anzeigt...
Edit: Cool. Das hilft ja wirklich.

Edit2: Ich habe die ganze Zeit angenommen, dass es nicht kompiliert, wenn man einen Writelock braucht, aber nur einen Readlock verwendet. Wie sich heraustellt. Kann ich überall Readlocks verwenden und es kompiliert trotzdem.
Ich mag jetzt wirklich nicht mehr. Thread Locking soll doch der Teufel holen.

Zitat von UFO

Hier noch einmal das Setup:
- vdr 2.3.1 + vdr-2.3.1-fixcrashdelrec.diff + vdr-2.3.1-grantrecursivewritelocks-2.diff
- dvbsddevice
- remote 0.7
- Classic Skin

Daß es am Ausgabedevice liegt kann ich mir schlecht vorstellen, denn das dvbsddevice hat mit den globalen Listen nichts zu tun.
Ich habe leider keinen VDR mit dvbsddevice mehr in Betrieb, daher kann ich es damit nicht ausprobieren.
An Skins habe ich alle drei Standardskins probiert, aber keine hat Probleme gemacht. Ich sehe aber durchaus im Code, daß es da ein Locking-Problem geben könnte. Nur ist es mir bisher noch nicht gelungen, es zu forcieren.

Kannst du bitte mal testen, ob das auch mit der LCARS-Skin auftritt?
Und vielleicht zur Sicherheit mal ohne 'remote' Plugin, damit wir auch das ausschließen können.
Machst du eine Sofortaufnahme oder eine normale Timer-Aufnahme?

Ich hab die kommende Woche ziemlich viel zu tun, daher werde ich nicht viel zum Debuggen kommen. Ich schau es mir aber näher an, sobald ich wieder mehr Zeit habe.
Rolf Ahrenberg hat mir heute übrigens das gleiche Problem berichtet, ich weiß nur noch nicht, welche Umgebung er betreibt. Auf jeden Fall bist du mit dem Fehler nicht der Einzige.

Klaus

Zitat von mini73

Es wäre klasse, wenn die Plugins auch weiterhin mit vdr 2.2.0 bauen

Ich bin ja nu noch ein Frischling was das angeht, daher die Frage:

Um diverse ifdefs zu sparen würde ich gern Beispielsweise sowas machen:

#if APIVERSNUM > 20300
    LOCK_CHANNELS_READ;
    const cChannels& channels = *Channels;
#else
    cChannels& channels = Channels;
#endif
    const cChannel* = channels.GetByChannelID(m_channel);

Anstatt:

#if APIVERSNUM > 20300
    LOCK_CHANNELS_READ;
    const cChannel* = Channels->GetByChannelID(m_channel);
#else
    const cChannel* = Channels.GetByChannelID(m_channel);
#endif

Ich kann dann mit einer Referenz weiterarbeiten statt an jeder Stelle in meinem Block an denen ich etwas von den Channels will ein ifdef einzubauen nur um den Punkt gegen den Pfeil auszutauschen.
Müffelt das für euch irgendwie komisch? Zumindest funktioniert der obere Code mit vdr-2.2.0.

Ich sehe nichts, was dagegen sprechen würde.

Klaus

Sehr schön. Das macht den Code dann um einiges übersichtlicher.

Danke