Starting/stopping recordings (was:Re: Problems with 20 Timers)

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

 



dvb@xxxxxxxxxx(Chris Warren)  25.02.05 17:27


>> -----Original Message-----
>> From: vdr-bounces@xxxxxxxxxxx
>> [mailto:vdr-bounces@xxxxxxxxxxx] On Behalf Of C.Y.M
>>
>> Have you noticed that the show summaries (Recordings
>> descriptions) are wrong on recorded events when you use a
>> timer?  I am curious if this behavior has to do with what you
>> are describing.  The only way I can get the summaries to
>> display the correct information is if I record a minute
>> longer after the show ends. For example, lets say a show
>> starts at 1:00 and ends at 2:00. If you set a timer for 1:00
>> to 2:00, then in the schedule will show a little "t" next to
>> the show you have set to record.  But, if you set a timer for
>> 1:00 to 2:01, then the schedule shows a capital "T" next to
>> the show being recorded and two little "t"'s before and after
>> the scheduled show.  The first method will use the Summary of
>> the previously scheduled show and the second method seems to
>> use the correct information.
>>
>Yes, I get this too - it's because of the following line in
>cTimer::Matches(time_t, bool) of timers.c:

>     return startTime <= t && t < stopTime; // must stop *before*
>stopTime to allow adjacent timers

>If your end time is exactly the same as the end of the event, it will
>match the start time, but not the end time. It'll only get marked as a
>partial match.

That's an old vdr specific problem too.
It's caused by using only minute stamps, it's a quantization, under
sampling/aliasing problem, if you like to call it that way ;-)

The solution is to use a higher sampling rate or, as we
"know" the "clock" and can synchronize to the foreign "data" stream, 
a phase shift. (Currently VDR is low pass "filtering" the input "data":
one timer can one match approx 2..3 minutes)

That means, a recording printed out "2:00-2:59" must actually 
start at 1:59:50 and stop at 2:59:49(*), givin a 10sec "phase shift" margin.
That would ensure that VDR records what the user expected.
Of cource VDR is fooling the user. But as long as he gets
what he expected it's OK.
IMHO it not OK to expect the user to subtract/add these technically
required margins.
If one likes he may set cutting marks automatically to the "real"
start/stop points (detected by VPS?). 
(BTW: Meanwhile i removed allmost all VPS timers. Klaus is right: 
it does not work.
I missed recordings because the VPS time was changed or no card was
tuned to the right transceiver/polarization (i have to turn EPG scan 
of as it is not compatible with my singel LNB setup), but worse:
VDR often missed the VPS stop points and make an xx hour long recording
causing all other timers to fail because of disk full and nothing left to
delete. (It not easy to find that big recordings) Many VPS recordings 
where "duping": Immediately after the recoding stops (at the
right moment!) a record of the following programm is started wasting
further space on disk.)






(*)
It might be worth a discussion if the margin should be 10 or 5 sec.
But it's not OK to start a recording at 2:00:00
as this is impossible to do.
When VDR started 4 years ago there was no way to "synchonize" the
clock so the 1..2min margin was required and OK, talking about "seconds" 
would have been rediculous.
But meanwhile clock synchronization possible and works quite well.
(At least the programs i see use the same time. Maybe it's required to
add a "time zone" or "time offset" for other programs on other 
time zones and a non synchronized clock?)



[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