Francisco Eduardo Álvarez Solano wrote:
> Just last night I've had a problem with the record server in 1.7.0-rc1
> that may be related: I programmed a show to record from 22:00 to 23:40.
> As I have set TV_RECORD_PADDING_PRE to 300 and TV_RECORD_PADDING_POST to
> 600, the show had to be recorded fr
Try RECORDSERVER_DEBUG = 2 in your local_conf.py. It gives a lot more
info.
OK. I'll see and tell you
The only thing that I can think of is there is a second recording that
overlaps the first.
When the end is 1 minute too soon then it will be a boundary condition
problem.
Yes, I was mak
Duncan Webb a écrit :
> Pascal Schirrmann wrote:
>
>> Hi,
>>
>>
> Interesting, when TV_RECORD_PADDING_PRE and TV_RECORD_PADDING_POST are
> not set they should default to TV_RECORD_PADDING and the default for
> TV_RECORD_PADDING is 0 * 60 :)
>
> Duncan
>
Oups,
Did I really forget to say
Just last night I've had a problem with the record server in 1.7.0-rc1 that
may be related: I programmed a show to record from 22:00 to 23:40. As I have
set TV_RECORD_PADDING_PRE to 300 and TV_RECORD_PADDING_POST to 600, the show
had to be recorded from 21:55 to 23:50. Although the recording start
Pascal Schirrmann wrote:
> Hi,
>
> Me again...
>
> (I think Duncan had asked for testers for this release, and since I
> cannot do a lot more ...)
>
> It seems to me that, since I started to use the svn version of freevo
> 1.7, the TV_RECORD_PADDING didn't work anymore : I used to have 10
> m
Hi,
Me again...
(I think Duncan had asked for testers for this release, and since I
cannot do a lot more ...)
It seems to me that, since I started to use the svn version of freevo
1.7, the TV_RECORD_PADDING didn't work anymore : I used to have 10
minutes more before and after the show, and th
