[RFC] Eliminating the 'summary' field of timers

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Carsten Koch wrote:
> Klaus Schmidinger wrote:
> ...
> 
>> - The 'summary' field in the timer definition becomes a pure
>>   string parameter, into which (external) applications can
>>   write whatever they like. VDR will read and write it, but
>>   otherwise won't do anything with it. The name of this field
>>   would be changed to something like 'aux' or so.
>>
>> - The description of a recording is taken exclusively from its
>>   related EPG data. If an application wants to use a different
>>   description it would have to set it with SVDRP/PUTE and use
>>   table ID 0x00, so that it won't be overwritten (as a side effect,
>>   however, this would also disable VPS for such an event).
>>   An added bonus of this method would be that not only the
>>   'description' can be set, but also 'title' and 'short text'.
> 
> 
> I like the fact that all my recordings have a summary - even those
> that are recorded from channels which do not have any EPG info.
> 
> This is because epg2timers takes the summary from the web EPG
> and enters it into the timer entry. When the actual recording
> takes place, vdr moves the summary into the info.vdr file.
> 
> This is nice as it is. I would consider it a step backwards
> if you break it.
> 
> Carsten.

You could just as well insert the summary into a fake EPG event for
that channel (even with separate "title", "short text" and
"description") and VDR would pick it up when the recording starts.

Note that I'd really like to get rid of the 'summary' mechanism,
so unless you can convince me that the "EPG insertion" method
doesn't work for you, I still plan to make this setp forward ;-)

Klaus


[Index of Archives]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Util Linux NG]     [Xfree86]     [Big List of Linux Books]     [Fedora Users]     [Fedora Women]     [ALSA Devel]     [Linux USB]

  Powered by Linux