[vdr] Re: GRAB always gives gray image

[Klaus Schmidinger <Klaus.Schmidinger@cadsoft.de>]

Jan Ekholm wrote:
> 
> On Tue, 2 Mar 2004 oliviervdr@free.fr wrote:
> 
> >> I experimented a bit with the SVDRP command GRAB to get screenshots, but
> >> it always seems to return a solid gray image, such as this one:
> >>
> >>     http://www.infa.abo.fi/~chakie/media/dvb/test.jpg
> >
> >Jan,
> >
> >do you have another v4l device on your PC (like analog TV card)?
> 
> No other cards, only one DVB-c card.
> 
> >If yes, then this should be fixed since 1.2.6pre1 (and you have 1.3.5).
> >(from HISTORY:
> >- Fixed detecting the /dev/videoN devices for GRAB in case there are others
> >  before the DVB devices (thanks to Andreas Kool).
> >)
> >
> >You could take a look at cDvbDevice::GrabImage in dvbdevice.c and try to
> >override devVideoIndex variable to see if it is wrongly set.
> >If you succeed, then we should try to look why this doesn't work for you.
> 
> It seems to use:
> 
>         device index: 0, device name: /dev/video0
> 
> which is correct on this system. Right now when I test (remotely) I can't
> get a single GRAB to work, it just freezes VDR and then the watchdog
> performs an emergency exit.
> 
> Doing a reboot now... Ok, that cured the grabbing problems, now I get the
> same gray images again.
> 
> Another thing I noticed while monitoring VDR is that it has started to
> take a lot more CPU than before (not sure since when). Not one thread sits
> in a tight loop and does nothing more than this:
> 
> select(1024, [23], NULL, NULL, {0, 10000}) = 0 (Timeout)
> time(NULL)                              = 1078300591
> gettimeofday({1078300591, 801847}, NULL) = 0
> rt_sigprocmask(SIG_BLOCK, NULL, [RTMIN], 8) = 0
> rt_sigprocmask(SIG_UNBLOCK, [RTMIN], [RTMIN], 8) = 0
> gettimeofday({1078300591, 802801}, NULL) = 0
> nanosleep({0, 9046000}, NULL)           = 0
> rt_sigprocmask(SIG_SETMASK, [RTMIN], NULL, 8) = 0
> alarm(60)                               = 60
> time(NULL)                              = 1078300591
> time(NULL)                              = 1078300591
> time(NULL)                              = 1078300591
> 
> I'm not sure what descriptor 23 is, but it seems to wait for access to
> that descriptor. This keeps on running as long as VDR is alive, and does
> not seem to have any negative effects apart from hogging 25% of the CPU
> (an Epia 800) all the time. Some more tests show that the function can
> also be accept() instead of select().

Can you find out exactly which thread this is?
From the "alarm(60)" call I would assume that it is the main VDR thread,
and then what it waits for is probably some user input.

That doesn't explain the high CPU load, though...

Klaus


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