[vdr] [RFC] Eliminating the 'summary' field of timers

Klaus Schmidinger Klaus.Schmidinger at cadsoft.de
Tue Feb 21 22:14:40 CET 2006

Christian Wieninger wrote:
> Hi Klaus,
> this change would also affect epgsearch and its 'search timers'. Since I don't 
> use event ids, the changes would be small. 
> But there is one thing, that will be lost with it: Timers created by epgsearch 
> have additional information at the bottom of the description, like the 
> channel from which the recording will be done

The channel from which to record has always been part of the timer
definition (the second field) - am I missing something?

> or the search timer that was
> responsible for the timer. I think, VDRAdmin works the same way. After the 
> recording is done this info was available til now in the recordings 
> description. 
> If I understood you right, this info should now be moved to the 'aux' field. 
> Do you plan any way, to display the 'aux' value for timers and recordings in 
> VDR's OSD?

The recorded channel is already stored in the 'C' record of the info.vdr
file. If necessary, that information can be displayed in the
cSkin::SetRecording() function. The actual "aux" value of a timer has no
conceivable meaning to VDR, so there's no point in displaying it, I'd say.

> BTW: if this change becomes true, it would be nice to have a pre-Patch to give 
> the people, that are concerned with it, some time to prepare their stuff. I 
> think some scripts/plugins will need heavy changes ;-)

Well, we're still in a development phase, so changes can be many and heavy.
Since there are only two weekends left before CeBIT, and that's when
I want to have at least a release candidate of version 1.4 ready, I'm
afraid there's no time for pre-patches. However, since this thread is
supposed to define exactly how things are going to be changed, you should be
able to prepare your particular tool accordingly.

I'll add a remark to the release notes, telling people who use external tools
for timer programming to wait until those tools have been adapted before using
the next version of VDR (not that I have high hopes, though, that anybody
will actually read it... ;-).


More information about the vdr mailing list