dscoular at cisco
Mar 11, 2006, 6:07 PM
Post #24 of 43
(8119 views)
Permalink
|
Hi All,
After discussing this on the linuxtv dvb irc list I have a fix
that gives me reliable channel tuning on the Nova-T.
First, let me warn you that I am at the limits of my ability to
analyse C++ code... and what follows may not be 100% correct.
danielk wrote:
> FE_GET_FRONTEND works on some cards, in that it waits for pending
> tune to complete before telling you about the tuning params. But
> on at least one DVB card it doesn't work where FE_READ_STATUS does.
> So far no card has been seen where FE_GET_FRONTEND works where
> FE_READ_STATUS doesn't, so we don't do both.
In irc, Manu Abraham kindly set me straight on the above... basically
he says that the only guaranteed way to tune across all supported cards
is to follow what is done in linuxtv-dvb-app's util/scan/scan.c.
Looking at the code in scan.c, we see that a usleep(200000) is done
after each call to FE_SET_FRONTEND and FE_READ_STATUS.
It appears that mythtv only uses a select with timeout after a
FE_SET_FRONTEND. However, it seems that if the select detects
that a read would be non-blocking it will continue, presumably,
before the card is ready.
If I replace the select(...) with a usleep(200000) at line 825
in mythtv/libs/libmythtv/dvbchannel.cpp and introduce another
usleep after line 548 in mythtv/libs/libmythtv/dvbsignalmonitor.cpp
e.g.
int fd_frontend = channel->GetFd();
ioctl(fd_frontend, FE_READ_STATUS, &status);
if (HasFlags(kDTVSigMon_WaitForSig))
becomes:
int fd_frontend = channel->GetFd();
ioctl(fd_frontend, FE_READ_STATUS, &status);
usleep(200000); // Need to sleep post fe_set_frontend fe_read_status.
if (HasFlags(kDTVSigMon_WaitForSig))
Doing this gives me reliable tuning on my Nova-T and according
to Manu should work for all other cards.
Here is a transcript of the discussion with Manu (I've added inline
comments where needed):
dscoular: Is there a definitive way to tune... mythtv's danielk is saying they've tried 4 different algorithms. /* I got this a bit wrong, sorry danielk */
|MA| algorithms ?
|MA| you may take a look at scan.c
|MA| in dvb-apps
dscoular: I looked at tzap.c it just does a usleep() after FE_READ_STATUS
|MA| that's what i mentioned previously
dscoular: Just doing a usleep doesn't seem particularly robust
dscoular: Looking at scan.c now
mrec I think this approach is ok
mrec not perfect for all devices but usable
|MA| there can be other approaches, but that requires changes at driver level
dscoular: Have a look at http://pastebin.ca/45276 for current problems in mythtv tuning
dscoular: This is from danielk
|MA| Hmm.. i find that not to be quite true
|MA| probably that explains bad tuning for MythTV
|MA| as some said
dscoular: Xactly
dscoular: I found putting in a usleep after FE_READ_STATUS made tuning perfect on the Nova-T
|MA| I thought you were mentioning driver level algorithms /* oops */
dscoular: If no-one understands how to use the driver API from the user-level...
|MA| at userspace as it is algorithms are useless..
|MA| just use just like what scan does..
|MA| that will help
dscoular: But people would be more comfortable understanding why
|MA| scan depends on many drivers, and all drivers don't behave the same
|MA| and hence
|MA| some drivers might go ahead without that delay, but _will_ require some delay
|MA| It all depends on the driver implementation
dscoular: So, looking at scan.c, we usleep after FE_SET_FRONTEND
dscoular: And then loop with a usleep calling FE_READ_STATUS
|MA| tuners are not that fast
|MA| so need a sleep
dscoular: scan is using a usleep(200000) while tzap uses 1000000
dscoular: Where exactly is the sleep needed... after the FE_SET_FRONTEND or FE_READ_STATUS ?
|MA| It might take a while to get a lock after a FE_SET_FRONTEND
|MA| but again the delays would depend a lot on the driver implementation
dscoular: Ah... okay... it seems this is the cause of a lot of confusion among user space authors.
|MA| most apps does it right, i hear only MythTV did it different
dscoular: Okay, immediately after the call to FE_SET_FRONTEND they call this routine in mythtv: http://pastebin.ca/45279
dscoular: They are doing a select rather than the usleep
dscoular: Is this what's wrong with mythtv dvb-t tuning ?
|MA| It should look only for a FE_HAS_LOCK
|MA| i mean only that is sufficient IMHO
|MA| imean set_frontend, sleep for a while, check for LOCK
|MA| you can even use the same sleep values ib scan
dscoular: So am I right in thinking that this mythtv code is flawed according to the linuxtv dvb people ?
nou: it's not only according to the linuxtv people
|MA| Maybe there are more ways than one, a person sees the world
dscoular: :^) Ok, I'll try replacing the select with a usleep and see if that fixes my issues
dscoular: Many, many thanks!!!
Presumably, we should use a user settable timeout... anyway let
me know if this works for other Nova-T users suffering from
poor channel tuning reliability.
I note that the frontend regularly stops responding to input
under 0.19-fixes (9277) with or without this fix.
Daniel, I'd be interested to hear what your thoughts are on
mythtv versus scan.c.
Cheers,
Doug
--
"The big print giveth and the small print taketh away"
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
|
smime.p7s
1
