Am Freitag, 18. März 2005 22:57 schrieb Klaus Schmidinger:

Just an announcement so that developers who read timers from SVDRP's LSTT command (or directly from timers.conf) can prepare their tools for the next version of VDR: the 'day' of a timer will be stored as a full date in ISO notation (YYYY-MM-DD) in the next version of VDR. For one, this will allow defining timers that are more than a month in the future, but also (and more important) will solve the problem of single shot timers not being deleted from timers.conf after they have ended.

For compatibility with earlier versions of VDR it will still accept the "day of month" notation (1...31) when reading existing timers.conf files or handling NEWT or MODT commands.

The possible formats for 'day' will be

a. 13 b. 2005-03-13 c. MTWTFSS d. MTWTFSS@13 e. MTWTFSS@2005-03-13

Note that a and d will only be accepted by VDR, but will never be written into timers.conf nor used with LSTT.

Hello Klaus,

what is wrong with a and d? Why not allowing the user to record e.g. the very first "Tagesschau" of every month by setting it to "1" Not that I really need this but someone will need it for sure e.g. due to the fact that the (virtual) series "Words of the month" is always sent on the first day of the month.

The problem was that if the user wanted to specifiy a specific date like 2005-03-13 he had to go a strange way and specify it like "every 13th day of the month (implicitly: until I delete this timer )". You gave the user the possibility to specify exactly what he wanted in this case. This is good.

But on the other side you should not remove the possibility to specify "every 13th day of the month" if this is what the user wants.

Bernd

Moin,

full date timers are a great enhancement for vdr.

but someone will need it for sure e.g. due to the fact that the (virtual) series "Words of the month" is always sent on the first day of the month.

For this it would be more easy to use the autotimers from epgsearch or vdradmin. They watch for the the title of a transmission and maintain timer for it. Very useful for poltical magazines (3-weekly, and often delayed or shifted) and shows like "Wer wird Millionär", which sometimes are transmitted as double feature. Or your favourite movie, you always miss.

Gruss, Walter

On Samstag 19 März 2005 02:45, Udo Richter wrote:

While you're breaking compatibility anyway, please consider allowing bi-weekly timers that only fire every second (fourth?) week. This is a far more common case.

You could also use crontab format for timers :)

You could even use a real crontab job and use SVDRP to tell vdr just in time what to do

Olaf Titz wrote:

...

a. 13 b. 2005-03-13 c. MTWTFSS d. MTWTFSS@13 e. MTWTFSS@2005-03-13

Note that a and d will only be accepted by VDR, but will never be written into timers.conf nor used with LSTT.

Nice. I'll adapt vdrepg accordingly. (Has the (d) format ever been used? It is not documented anyway.)

Olaf

That's more or less a consequence of the changes I had to make for this. A day can now be given either as a simple number ("day of month") or as YYYY-MM-DD. Therefore 'd' is also possible.

Note, though, that a and d are only for _input_ to VDR. A tool that reads timer definitions from SVDRP would only need to be able to handle a for complatibility with older VDR versions. VDR versions after 1.3.22 will write only formats b, c or e.

Klaus

Udo Richter wrote:

Klaus Schmidinger wrote:

...

this will allow defining timers that are more than a month in the future

Nice. Esp. since I already have a (deactivated) timer for Apr. 30 in my timers. ;)

While you're breaking compatibility anyway, please consider allowing bi-weekly timers that only fire every second (fourth?) week. This is a far more common case.

Format suggestion: MTWTFSS*n (fire on next matching day, then skip n times/weeks) MTWTFSS*n@YYYY-MM-DD (fire on YYYY-MM-DD, then skip n times/weeks)

I'm afraid this would make things overly complicated. I also have one timer that records a monthly show, but the distance between shows is not necessarily always exactly four weeks - sometimes it may well be five weeks, for instance. Therefore I have a weekly timer, and usually at the end of a show they announce when the next one will be broadcast - then I set the "first day" of that timer to the given date.

For anything more complicated there are tools like vdradmin, for instance.

Klaus

--Am Samstag, 19. März 2005 15:56 +0100 schrieb Udo Richter udo_richter@gmx.de:

Klaus Schmidinger wrote:

...

I'm afraid this would make things overly complicated. I also have one timer that records a monthly show, but the distance between shows is not necessarily always exactly four weeks

No easy way to catch that, I agree. But a bi-weekly timer should be simple. After recording is done, check for bi-weekly flag, and in that case set a start date 14 days later. Maybe I'll give it a try and develop a patch.

I think, you want a timer with "repeat every x day/week/month" .. (like events in my Palm ..)

KLS: worth to think about?

-----Original Message----- From: vdr-bounces@linuxtv.org [mailto:vdr-bounces@linuxtv.org] On Behalf Of Udo Richter

No easy way to catch that, I agree. But a bi-weekly timer should be simple. After recording is done, check for bi-weekly flag, and in that case set a start date 14 days later. Maybe I'll give it a try and develop a patch.

If you were to write a patch, how about supporting the crontab format for timers? This is pretty standard, very flexible and I'm sure there's code out there which could be reused.

i.e.

Minute Hour DayOfMonth Month DayOfWeek Data

Where each field can have either a number specifying what to match, an asterisk to match any, a comma seperated list of matched values, a range (1-3) or repeating ranges (e.g. */5 for every 5 minutes.)

An example could be: Record at 1pm every Monday and Wednesday of Jan and Feb: 0 13 * 1-2 mon,wed 1:C-61472-7-1204:etc....

Chris

Chris Warren wrote:

If you were to write a patch, how about supporting the crontab format for timers?

Beside the fact that I dont really like crontab format, this format is not very useful here:

-No way to set the timer end time -No one-shot timers -No two-week timers (remember? thats what I wanted) -No start-at-certain-day timers

It /has/ some advantages though: <g> +Repeat timers every minute +Repeat timers every hour +Repeat timers every year

Cheers,

Udo

Klaus.Schmidinger@cadsoft.de(Klaus Schmidinger) 18.03.05 22:57

Just an announcement so that developers who read timers from SVDRP's LSTT command (or directly from timers.conf) can prepare their tools for the next version of VDR: the 'day' of a timer will be stored as a full date in ISO notation (YYYY-MM-DD) in the next version of VDR. For one, this will allow defining timers that are more than a month in the future, but also (and more important) will solve the problem of single shot timers not being deleted from timers.conf after they have ended.

Ah! I always thought it was my fault that the event survived and that's a feature i do not understand ;-) Thanks a lot to solve that.

Anyway: "me too" see a big demand on "week" timers like "record every second week" "record only in the third week of a month" "record only in the last/first week of a month" "record every week"(already implemented ;-))

Storing the complete date this could be implemented now.

It can be programmed similar to the "day of week", as there are only 5 elements

1. -> first week of a month 2. -> second week of a month 3. -> third week of a month 4. -> forth week of a month 5. -> last week of a month 1 -> every week 2 -> every second week. 3 -> every third week. 4 -> every fourth week. 5 -> odd weeks? ;-)

If someone wants more, he's free to add another timer. "." may be "0" key on the RC.

But, Ok, that's complicate to programm but would ease using. (No, crontab can't do that on it's own ;-) )

Rainer