[vdr] Re: Bug, or just me? - Victory! ?

[Dennis <dennis.noordsij@wiral.com>]

Whoops. Having been annoyed for hours now that I can not get things to work 
stably, even though it worked absolutely perfectly the day before yesterday, 
with the exact same config that is failing me today, I now noticed a big err 
on my side :-)

When I downloaded VDR it was through an -as it turned out- outdated link on 
some page, and I got version 1.1.8. THAT is the version I used when 
everything worked great. 

So, between 1.1.8 and 1.1.11 something broke, with 1.1.8 there is less CPU 
being used for recording (also appears to be only 1 thread doing any 
noticable work as opposed to 2 threads with 1.1.11), and when the recording 
is stopped CPU drops all the way down as it should (but doesn't for me with 
1.1.11)

During recording with 1.1.8 there are no glitches, no stuttering, no "buffer 
empty" messages from the kernel, and no tuning problems (whereas 1.1.11 had 
all of these for me).

I feel better now :-)) 

----------

I do have one minor nitpick though :-) I have changed a line in dvbdevice.c to 
get the modulation type depending on the disqec value in channels.conf. VDR 
does not like to switch between different QAM bouquets though. If I start VDR 
with the card being tuned to a QAM_128 mux, it only likes to zap between 
other channels on a (not necessarily the same) QAM_128 mux.
If I start VDR with the card being tuned to QAM_64, it only likes to zap 
between channels on QAM_64 bouquets.

However, dvbtune commandline will switch any channel on the first try, where 
VDR does not (i.e. quit vdr, use dvbtune, start vdr). 1.1.8 not anyway, but 
1.1.11 behaved the same in that regard. So I guess the reason lies somewhere 
in VDR? I know you (Klaus) said you are going to add multiple QAM setting 
support anyway, and you'll do a much better job than I could :-) So unless 
someone already knows what is wrong, it can wait until after that.


Virtual beers for everyone on this mailinglist :-)
Best wishes,
Dennis








On Thursday 03 October 2002 13:58, you wrote:
> Hi,
>
> Using vdr-1.1.11 on a Pentium 133 (experiment :-) , 98 MB memory, Gentoo
> Linux, kernel 2.4.19-gentoo-r9, using a single Hauppauge rev 2.1 DVB-C
> card.
>
> I am using the NEWSTRUCT dvb driver branch, without the new firmware (i.e.
> the time shifting with one card one).
>
> In normal viewing mode vdr takes nearly no CPU (as it should of course).
>
> When recording however (live record, not through a timer), there are 2 vdr
> threads which immediately eat up 50% of CPU time each, causing major
> distortions in the "live" viewing as well as in the recording.
>
> When stopping the recording, this continues! That's the weird part. Still 2
> threads, eating all CPU, and distorting the live viewing.
>
> However, as soon as I re-tune to the same channel (menu->channels->same
> channel), CPU drops to 1% or so and the video is smooth again.
>
> When I play back the recording, it does so with only 6% or so of CPU time,
> however the picture is distorted because of the recording process.
>
> It doesn't seem right that recording needs 100% CPU and playback only 6% ?
>
> Note, I had about 1 gb left, and the low disk space warning appeared
> throughout the recording process (don't know if that makes a difference).
>
> I'm having some weird issues with dvbtune as well, so it could be caused by
> something else, but just curious as to wether this is normal or not :-)
>
> I've seen reports of people using a 100MHz recording and playing back over
> ethernet, with no problems.
>
> Best regards,
> Dennis




--
Info:
To unsubscribe send a mail to listar@linuxtv.org with "unsubscribe vdr" as subject.