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?
_______________________________________________
mythtv-dev mailing list
[email protected]
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
