[mythtv] dvbchannel patch

Mark Weaver mark-clist at npsl.co.uk
Wed Aug 31 15:19:26 UTC 2005


>>Basically this happens when changing frequencies -- it's not getting the
>>right PAT, fails to find the program, and then locks up. �At least, this
>>is how I read the log (see attached). �Any ideas?
> 
> 
> Wondering, where is this patch? Tried searching gossamer and there is
> nothing in trac.
It got posted to the list a few days ago, I've sent you a copy to save 
you having to dig around.

It's not right, because it is reading the possibly old event queue so 
could be picking up old events.  I'm guessing my card just happens to 
starts with an empty queue, and after the tune there are no further 
events, thus everything stays in sync. I can see the point that 
FE_GET_EVENT is a bit broken, and polling the status seems like a better 
solution to me.

As far as I read drivers/media/dvb/dvb-core/dvb_frontend.c, it isn't 
necessary to wait for N lock events.  After ioctl(FE_SET_FRONTEND), 
FE_READ_STATUS will return 0 until the tune has completed, so the first 
lock status ought to be good enough.  Could also save a bit of CPU with 
poll() rather than the usleep() loop I suppose, but that's an aside.

> 
> I belive I saw this today too, it refused to read pat/pmt no matter how
> good the signal was. After starting it up a few times it got it, has
> anyone checked this with valgrind? Also strangely, while this was going
> on one of my cams refused to boot.
> 
Hmm, this is suprising -- I would have thought that this couldn't be the 
case as the table monitor is not created until after DVBChannel::Tune() 
has been called.  Given that you are waiting for a lock I can't see how 
you'd get the wrong PAT.  Do you have a -v channel,record,siparser log 
handy so I can see if it looks like the same issue?


More information about the mythtv-dev mailing list