Mailing List Archive: MythTV: Dev

Re: [mythtv-commits] Ticket #1502: DVB API requires usleep after certain calls to get reliable tuning on certain drivers (esp Nova-T).

Index | Next | Previous | View Threaded

danielk at cuymedia

Mar 13, 2006, 2:05 PM

Post #1 of 20 (2767 views)
Permalink

Re: [mythtv-commits] Ticket #1502: DVB API requires usleep after certain calls to get reliable tuning on certain drivers (esp Nova-T).

On Mon, 2006-03-13 at 21:05 +0000, MythTV wrote:
> #1502: DVB API requires usleep after certain calls to get reliable tuning on
> certain drivers (esp Nova-T).
> Comment (by dscoular[at]cisco.com):

> 1) the delay used by scan.c is 200000 microseconds which is equal to 0.20
> seconds, not the
> 2 second delay you have set as the default.
Sorry, I miscounted the zeros, I'll fix this soon.

> 2) You have made the usleep only apply if we detect a frontend name of
> "!DiBcom 3000P/M-C DVB-T"
> which ignores the fact that this usleep is a catch all for ALL cards.
I don't want to enable the hack by default because doing so fails to
encourage driver writers to fix their drivers. I think part of the
problem is simply that the driver writers don't know their drivers
are broken because the DVB utils use these hacks by default. Plus,
this hack would down tuning for those of us with working drivers.

> That being said, if you insist that it is conditional...
> can the DVBTuningDelay spinbox also be conditional (just curious really) ?
Sure, but I figured exposing it would let users discover the delay
needed for the driver they are using, and perhaps report it to the
developers...

> And finally just to really drive you nuts...
> Having got reliable tuning on my Nova-T I decided to turn my attention to
> my !AverMedia !AverTV DVB-T USB 2.0 card...
> However, the really interesting thing I found after spending 3 hours
> trying to get the other 4 channels working was that the values in
> dtv_multiplex were really screwed up when compared with any of my
> channels.conf scan.c based scans. When I manually fixed the
> dtv_multiplex to more accurately reflect the channels.conf output...
I've recently enabled new scanning code in SVN, it works great here
for ATSC, but there appears to be a problem with enabling the SDT
pid monitoring (pid 0x11, I believe). If you could fix that, it might
fix the transport problem you are experiencing. You must delete
existing transports before doing a scan however, otherwise the old
transports will be reused.

-- Daniel

_______________________________________________
mythtv-dev mailing list
mythtv-dev[at]mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

robthebob at gmail

Mar 14, 2006, 2:24 AM

Post #2 of 20 (2686 views)
Permalink

Re: [mythtv-commits] Ticket #1502: DVB API requires usleep after certain calls to get reliable tuning on certain drivers (esp Nova-T). [In reply to]

On 3/13/06, Daniel Kristjansson wrote:
> > 2) You have made the usleep only apply if we detect a frontend name of
> > "!DiBcom 3000P/M-C DVB-T"
> > which ignores the fact that this usleep is a catch all for ALL cards.
> I don't want to enable the hack by default because doing so fails to
> encourage driver writers to fix their drivers. I think part of the
> problem is simply that the driver writers don't know their drivers
> are broken because the DVB utils use these hacks by default. Plus,
> this hack would down tuning for those of us with working drivers.
g, and perhaps report it to the
> developers...

Could it be enabled for the "Conexant CX22702 DVB-T" as well please,
as this hack helps my tuning on this card.

Robin
_______________________________________________
mythtv-dev mailing list
mythtv-dev[at]mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

adeffs.mythtv at gmail

Mar 14, 2006, 10:37 AM

Post #3 of 20 (2679 views)
Permalink

Re: [mythtv-commits] Ticket #1502: DVB API requires usleep after certain calls to get reliable tuning on certain drivers (esp Nova-T). [In reply to]

On 3/14/06, Robin Neatherway <robthebob[at]gmail.com> wrote:
> On 3/14/06, Daniel Kristjansson wrote:
> > On Tue, 2006-03-14 at 10:24 +0000, Robin Neatherway wrote:
> > > On 3/13/06, Daniel Kristjansson wrote:
> > > > > 2) You have made the usleep only apply if we detect a frontend name of
> > > > > "!DiBcom 3000P/M-C DVB-T"
> > > > > which ignores the fact that this usleep is a catch all for ALL cards.
> > > > I don't want to enable the hack by default because doing so fails to
> > > > encourage driver writers to fix their drivers. I think part of the
> > > Could it be enabled for the "Conexant CX22702 DVB-T" as well please,
> > > as this hack helps my tuning on this card.
> >
> > How many milliseconds do you need me to slow down the tuning for
> > this driver?
> >
> > Try to find the minimum reliable value, then we'll add a little
> > bit to that for safety.
>
> I'm currently at the two lots of 200000, but I'll have a play later on
> and let you know.
>
> Thanks,
> Robin

has anyone tried this with the HD3000?

--
Steve
_______________________________________________
mythtv-dev mailing list
mythtv-dev[at]mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

dscoular at cisco

Mar 15, 2006, 3:05 AM

Post #4 of 20 (2665 views)
Permalink

Re: [mythtv-commits] Ticket #1502: DVB API requires usleep after certain calls to get reliable tuning on certain drivers (esp Nova-T). [In reply to]

Hi Daniel,
I've just finished doing various testing of my patch versus yours
(well, 9368, actually) and I think we still have a problem.

In your code you are only doing a usleep after the FE_SET_FRONTEND
ioctl but my code does this after all FE_SET_FRONTEND and
FE_READ_STATUS ioctls. Apologies if I am misreading your
code. IMHO I think my implementation is a closer mimickery
of the scan.c code.

Your code fails to tune on my Nova-T for certain channels and
reports random noise for the BER and UNC on both my Nova-T
and AverTV A800 tuners. I also get a blank dialog window when
it fails to get lock after some other signal monitor timeout.

I spent a while last night talking to the linuxtv guys and they are
adamant (remember Ant music ;) the example reference for the API
is linuxtv-apps and they still insist the usleep(200000) is a safety
margin which they have factored into the API design to allow the
driver writers a margin of error. The driver code already has
usleeps throughout it but this extra usleep allows them to tweak
the safety factor across all drivers and leave the kernel code
untouched. If you are doing FE_READ_STATUS without
waiting for their current safety margin of 200,000usecs then
you are likely to get random noise returned as values.

This certainly is bourne out in my testing on both my
Nova-T (TDA1004x) and AverMedia AverTV USB 2.0
A800 tuners.

Would you like me to produce a new prototype patch based on your
latest code ?

Oh, and I had also removed the select(2) call in wait_for_backend
in dvbchannel.cpp (I think the usleep makes it unnecessary but I'm
not 100% sure).

P.S. I really like the way you did the mythtv-setup allowing
all card owners the ability to configure the usleep... nice.
Ooh... and the new fading transitions between mythtv
screens is just so nice!!! Ooh... and... ooh... ;^)

Cheers,

Doug

_______________________________________________
mythtv-dev mailing list
mythtv-dev[at]mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

danielk at cuymedia

Mar 15, 2006, 6:19 AM

Post #5 of 20 (2719 views)
Permalink

Re: [mythtv-commits] Ticket #1502: DVB API requires usleep after certain calls to get reliable tuning on certain drivers (esp Nova-T). [In reply to]

On Wed, 2006-03-15 at 22:05 +1100, Doug Scoular wrote:
> In your code you are only doing a usleep after the FE_SET_FRONTEND
> ioctl but my code does this after all FE_SET_FRONTEND and
> FE_READ_STATUS ioctls. Apologies if I am misreading your
> code. IMHO I think my implementation is a closer mimickery
> of the scan.c code.
I believe the sleep after FE_READ_STATUS in scan is just to give the card
some breathing room. We do the same thing in SignalMonitor::MonitorLoop()
usleep(update_rate * 1000);

> Your code fails to tune on my Nova-T for certain channels and
> reports random noise for the BER and UNC on both my Nova-T
> and AverTV A800 tuners. I also get a blank dialog window when
> it fails to get lock after some other signal monitor timeout.
The BER and UNC are mostly meaningless the way we read them.
These are cumulative values, so we should throw out the first
read and we should also sum these over a time period and report
errors seen in that period, but we do neither. There is a comment
in DVBSignalMonitor::UpdateValues() about this...

We trust the FE_LOCK from the DVB drivers for tuning and these
values aren't anywhere near as useful as signal and s/n for
antenna adjustment so implementing the normalizing code is
pretty low priority for me.

> I spent a while last night talking to the linuxtv guys and they are
> adamant (remember Ant music ;) the example reference for the API
> is linuxtv-apps and they still insist the usleep(200000) is a safety
> margin which they have factored into the API design to allow the
> driver writers a margin of error. The driver code already has
> usleeps throughout it but this extra usleep allows them to tweak
> the safety factor across all drivers and leave the kernel code
> untouched. If you are doing FE_READ_STATUS without
> waiting for their current safety margin of 200,000usecs then
> you are likely to get random noise returned as values.
I think you may have misinterpreted what they said. A delay is needed
for the cumulative values to look less random, but you can and should
sum these values over a larger period than the between read delay.

> Would you like me to produce a new prototype patch based on your
> latest code ?
There is a constant in tv_rec.cpp:
/// How many milliseconds the signal monitor should wait between checks
const uint TVRec::kSignalMonitoringRate = 50; /* msec */
Set this to 250 milliseconds to simulate the code you had in
the original patch.

But you are talking about a huge cumulative delay here, I'm afraid you
might just be getting more successful tuning because you are sleeping
for hundreds of milliseconds. Perhaps this driver never reports anything
but "successfully tuned", so the delay is just waiting until this is
true in the general case, so even if you add all these delays it will
never tell you there is anything wrong with the signal which makes the
signal monitoring pretty useless on the whole...

> Oh, and I had also removed the select(2) call in wait_for_backend
> in dvbchannel.cpp (I think the usleep makes it unnecessary but I'm
> not 100% sure).
It doesn't make it unnecessary for those of us not using the hack :]

> P.S. I really like the way you did the mythtv-setup allowing
> all card owners the ability to configure the usleep... nice.
I think it needs to be that way, a lot of MythTV users are
afraid to change a constant if it requires recompiling :)

> Ooh... and the new fading transitions between mythtv
> screens is just so nice!!! Ooh... and... ooh... ;^)
That's all Isaac :)

-- Daniel

_______________________________________________
mythtv-dev mailing list
mythtv-dev[at]mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

dscoular at cisco

Mar 15, 2006, 4:01 PM

Post #6 of 20 (2656 views)
Permalink

Re: [mythtv-commits] Ticket #1502: DVB API requires usleep after certain calls to get reliable tuning on certain drivers (esp Nova-T). [In reply to]

Hi Daniel et al,

Danielk wrote:
> I believe the sleep after FE_READ_STATUS in scan is just to give the card
> some breathing room. We do the same thing in SignalMonitor::MonitorLoop()
> usleep(update_rate * 1000);

Ah, okay I'll play with the update_rate.

Danielk wrote:
> The BER and UNC are mostly meaningless the way we read them.
> These are cumulative values, so we should throw out the first
> read and we should also sum these over a time period and report
> errors seen in that period, but we do neither. There is a comment
> in DVBSignalMonitor::UpdateValues() about this...

Yes, I read that and I really don't care that much
about BER/UNC stats... just whether FE_HAS_LOCK is
reliable.

Danielk wrote:
> We trust the FE_LOCK from the DVB drivers for tuning and these
> values aren't anywhere near as useful as signal and s/n for
> antenna adjustment so implementing the normalizing code is
> pretty low priority for me.

I understand... and as I said it is FE_HAS_LOCK that
I really care about too.

Danielk wrote:
> I think you may have misinterpreted what they said. A delay is needed
> for the cumulative values to look less random, but you can and should
> sum these values over a larger period than the between read delay.

I think the delay is also needed to determine whether
the tuner has reliably achieved FE_HAS_LOCK.

Danielk wrote:
> There is a constant in tv_rec.cpp:
> /// How many milliseconds the signal monitor should wait between checks
> const uint TVRec::kSignalMonitoringRate = 50; /* msec */
> Set this to 250 milliseconds to simulate the code you had in
> the original patch.

Cool, I'll check that out too.

Danielk wrote:
> But you are talking about a huge cumulative delay here, I'm afraid you
> might just be getting more successful tuning because you are sleeping
> for hundreds of milliseconds. Perhaps this driver never reports anything
> but "successfully tuned", so the delay is just waiting until this is
> true in the general case, so even if you add all these delays it will
> never tell you there is anything wrong with the signal which makes the
> signal monitoring pretty useless on the whole...

I'm beginning to think the signal monitoring is fairly
meaningless... but at least people can use it as a very, very
rough guide (signal anyway). I'm thinking that we may only
need the 200,000 microsecond usleep on the first FE_READ_STATUS
before checking for FE_HAS_LOCK.

I'll do some more experimentation tonight and see if I can
come up with a new prototype patch... ok ?

I might also look over how the DVR project deal with tuning
on DVB cards... ah... actually I'm off to the pub tonight
so it might be a day or so till I have some results or a patch.

Cheers,

Doug
--
"The big print giveth and the small print taketh away"
_______________________________________________
mythtv-dev mailing list
mythtv-dev[at]mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

abraham.manu at gmail

Mar 15, 2006, 4:13 PM

Post #7 of 20 (2645 views)
Permalink

Re: [mythtv-commits] Ticket #1502: DVB API requires usleep after certain calls to get reliable tuning on certain drivers (esp Nova-T). [In reply to]

Doug Scoular wrote:
> Hi Daniel et al,
>
> Danielk wrote:
> > I believe the sleep after FE_READ_STATUS in scan is just to give the card
> > some breathing room. We do the same thing in SignalMonitor::MonitorLoop()
> > usleep(update_rate * 1000);
>
> Ah, okay I'll play with the update_rate.
>
> Danielk wrote:
> > The BER and UNC are mostly meaningless the way we read them.
> > These are cumulative values, so we should throw out the first
> > read and we should also sum these over a time period and report
> > errors seen in that period, but we do neither. There is a comment
> > in DVBSignalMonitor::UpdateValues() about this...
>
> Yes, I read that and I really don't care that much
> about BER/UNC stats... just whether FE_HAS_LOCK is
> reliable.
>
>

It depends on the driver how this averaging is done, so the app should
probably handle the value that it get's through, but it doesn't hurt to
average the values either. But there are cards where this is totally
meaningless.

> I understand... and as I said it is FE_HAS_LOCK that
> I really care about too.
>
>

For testing whether the tuning has succeded, checking for FE_HAS_LOCK
should be sufficient.

> I think the delay is also needed to determine whether
> the tuner has reliably achieved FE_HAS_LOCK.
>

Yes. It can be considered as a Factor Of Safety. All applications do
abide by this except for MythTV. IIRC Marcus Metzler did send a pacth to
fix this issue, but that patch was thrown away.

> I'm beginning to think the signal monitoring is fairly
> meaningless...
>

Signal monitoring is meaningless on some cards, since different tuners
have different values etc, and there is not much of a standardization
there, but this will change in the future.

> I might also look over how the DVR project deal with tuning
> on DVB cards...

You can take a look at scan, VDR, Mplayer, VLC or anything. All the
applications out there tune properly except for MythTV. In fact Marcus
Metzler had sent a patch to fix this issue. Any ideas what happened to it ?

Manu

_______________________________________________
mythtv-dev mailing list
mythtv-dev[at]mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

danielk at cuymedia

Mar 16, 2006, 6:46 AM

Post #8 of 20 (2642 views)
Permalink

Re: [mythtv-commits] Ticket #1502: DVB API requires usleep after certain calls to get reliable tuning on certain drivers (esp Nova-T). [In reply to]

On Thu, 2006-03-16 at 04:13 +0400, Manu Abraham wrote:
> Doug Scoular wrote:
> It depends on the driver how this averaging is done, so the app should
> probably handle the value that it get's through, but it doesn't hurt to
> average the values either. But there are cards where this is totally
> meaningless.
Yup, the averaging is in my long term todo, it just doesn't have a
terribly high priority because it doesn't serve any purpose in MythTV
yet. Many cards don't even report these values.

> For testing whether the tuning has succeded, checking for FE_HAS_LOCK
> should be sufficient.
This is the only thing we use to detect the signal quality for DVB drivers.
Then we look for the MGT/VCT or PAT/PMT depending on the tuning params
we have, that part is the more important part of the signal monitor
for tuning. Part of the problem is that we don't look for NIT/SDT
so we can tune to the wrong transponder... There is a ticket for this
and a MythTV user volunteered a DVB-land locate machine for me to test
fixes for this, but I'm maxed out on my wife enforced MythTV hours
per week, so it may take a while for me to get to it.

> > I think the delay is also needed to determine whether
> > the tuner has reliably achieved FE_HAS_LOCK.
> Yes. It can be considered as a Factor Of Safety. All applications do
> abide by this except for MythTV. IIRC Marcus Metzler did send a pacth to
> fix this issue, but that patch was thrown away.
I don't recall any patch from him for this issue. I've only been
maintaining the DVB stuff for a few months so it may have been
before I started tracking DVB patches. There was a period after
Taylor Jacob ran out of time and before I picked it up, if it was
sent during that period it would have fallen into a black hole.

> > I'm beginning to think the signal monitoring is fairly
> > meaningless...
> Signal monitoring is meaningless on some cards, since different tuners
> have different values etc, and there is not much of a standardization
> there, but this will change in the future.
The monitoring of the signal & s/n values is mostly to support antenna
adjust mode (F7). But it is reported when changing channels so that
the user has some idea of what the normal values are for his driver.
I'd love to see some standardization in this area. API 4.0 is already
an improvement, since the int16_t -> uint16_t change we no longer
see drivers that report decreasing negative values for a better signal.
The well coded drivers mostly used the safe 0..2^15 range anyway, so
it looks like all cards are reporting somewhat sane values now.

> > I might also look over how the DVR project deal with tuning
> > on DVB cards...
> You can take a look at scan, VDR, Mplayer, VLC or anything. All the
> applications out there tune properly except for MythTV.
"Everyone else is doing it" doesn't make it right. I would much
rather have a 'maintain lock for x msec' threshold rather than
a have lock at 'magic moment y' threshold. We actually used to
use the same tuning regime as those programs, and it resulted
in shads of zero-length recordings... Now zero-length recordings
are only happening for Nova-T and DVB-S people, so from where
I stand (admittedly with non-broken cards) it looks like an
improvement. That doesn't mean I don't want to improve the
tuning, it just means I'm sceptical of modeling our tuning
on these forms of magic moment tuning we've abandoned after
their utter failure in MythTV.

> In fact Marcus Metzler had sent a patch to fix this issue.
> Any ideas what happened to it ?
I tried searching the archives and didn't find anything for this.
I have applied patches from him, so he's not a total unknown
around here...

-- Daniel

_______________________________________________
mythtv-dev mailing list
mythtv-dev[at]mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

abraham.manu at gmail

Mar 16, 2006, 8:35 AM

Post #9 of 20 (2652 views)
Permalink

Re: [mythtv-commits] Ticket #1502: DVB API requires usleep after certain calls to get reliable tuning on certain drivers (esp Nova-T). [In reply to]

Daniel Kristjansson wrote:
> Yup, the averaging is in my long term todo, it just doesn't have a
> terribly high priority because it doesn't serve any purpose in MythTV
> yet. Many cards don't even report these values.
>

You are right, we are looking at this aspect, but this involves some
changes like getting math operations into kernel/moving frontend drivers
out to userspace. We have some thoughts on this, but don't bet on it,
since there are quite some issues to be considered.

And when this is done, in most cases you wouldn't have to do the
averaging, the driver will do the averaging according to the specs from
the chipset vendor.

Another one of the reasons why drivers are in such a state is that many
drivers are Reverse Engineered , since vendors don't release
specifications / information on them. But for some of them due to
certain reasons some things cannot be implemented in kernel as it is.

We are looking at userspace libraries to fix issues like this, so that
all such information like this can be contained in them such that
applications do not have to be bothered by issues like this. It will
not be too long for them.

> I don't recall any patch from him for this issue. I've only been
> maintaining the DVB stuff for a few months so it may have been
> before I started tracking DVB patches. There was a period after
> Taylor Jacob ran out of time and before I picked it up, if it was
> sent during that period it would have fallen into a black hole.
>
>

Hmm.. I was talking to Ralph Metzler, he told me that Marcus Metzler
sent you guys a patch to fix the issue properly. If Marcus sends you a
patch i can assure you that you that you can use that patch as it is.

> The well coded drivers mostly used the safe 0..2^15 range anyway, so
> it looks like all cards are reporting somewhat sane values now.
>
>

AFAIK, the values are simply mapped and on different hardware it has
different meanings. It might need further processing to display
something really sane enough.

> "Everyone else is doing it" doesn't make it right. I would much
> rather have a 'maintain lock for x msec' threshold rather than
> a have lock at 'magic moment y' threshold. We actually used to
> use the same tuning regime as those programs, and it resulted
> in shads of zero-length recordings...

I understand what you are saying, but if you say that if you want
drivers to be fixed, then it would be as good as talking terms to the
kernel folks to have certain features in the kernel. So IMHO if you
think that things should remain broken for that period till LK folks
agree, then MythTV will remain broken for all those time.

IMHO you guys should adapt to something what's acceptable to the rest of
the world for the time being and later on use the stuff whatcomes out as
a good solution. First fix the immediate problem, then go for the finer
fix. Don't wait for the fine fix to be your first and final fix.

>
> I tried searching the archives and didn't find anything for this.
> I have applied patches from him, so he's not a total unknown
> around here...
>
>

I will ask him to send again, in case you guys are interested.

Manu

_______________________________________________
mythtv-dev mailing list
mythtv-dev[at]mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

abraham.manu at gmail

Mar 16, 2006, 10:24 AM

Post #10 of 20 (2642 views)
Permalink

Re: [mythtv-commits] Ticket #1502: DVB API requires usleep after certain calls to get reliable tuning on certain drivers (esp Nova-T). [In reply to]

Daniel Kristjansson wrote:
> I tried searching the archives and didn't find anything for this.
> I have applied patches from him, so he's not a total unknown
> around here...
>

I have attached the old mail/patch sent by Marcus a while back. It might
not be now suitable as it is for your code now, that sufficient time has
passed by, but you can get the idea out of it.

Manu

Attachments:

message-rfc822.eml (5.14 KB)

lists at ebourne

Mar 17, 2006, 3:19 AM

Post #11 of 20 (2626 views)
Permalink

Re: [mythtv-commits] Ticket #1502: DVB API requires usleep after certain calls to get reliable tuning on certain drivers (esp Nova-T). [In reply to]

On Thu, 16 Mar 2006 20:35:18 +0400, Manu Abraham wrote:
> I understand what you are saying, but if you say that if you want drivers
> to be fixed, then it would be as good as talking terms to the kernel folks
> to have certain features in the kernel. So IMHO if you think that things
> should remain broken for that period till LK folks agree, then MythTV will
> remain broken for all those time.
>
> IMHO you guys should adapt to something what's acceptable to the rest of
> the world for the time being and later on use the stuff whatcomes out as a
> good solution. First fix the immediate problem, then go for the finer fix.
> Don't wait for the fine fix to be your first and final fix.

From a users perspective what Daniel's done is a massive improvement, so
he must be getting something right.

I have two Twinhan Vision+ and a Nova-T. I used to get about 5% failed
recordings with the old point in time tuning code, and now don't get any
on the Twinhan cards. The Nova-T still has occasional problems tuning
which are known about (hopefully fixed by the latest delay change when I
get chance to update).

Maybe the reason the other programs don't have so many issues is that they
don't get hit so hard as MythTV. I find it very likely that MythTV has
many more users doing more recordings on more hardware than any of the
other programs, as it's clearly the no.1 PVR on Linux.

I use mplayer and tzap/scan sometimes for testing and if they fail to tune
I just try again (yes, I have seen tzap fail to tune on the first
attempt). If MythTV fails to tune then I get a missed recording and
usually an earful from the wife as well - that I care about!

Cheers,

Martin.

_______________________________________________
mythtv-dev mailing list
mythtv-dev[at]mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

abraham.manu at gmail

Mar 17, 2006, 5:45 AM

Post #12 of 20 (2634 views)
Permalink

Re: [mythtv-commits] Ticket #1502: DVB API requires usleep after certain calls to get reliable tuning on certain drivers (esp Nova-T). [In reply to]

Martin Ebourne wrote:
> On Thu, 16 Mar 2006 20:35:18 +0400, Manu Abraham wrote:
>
>> I understand what you are saying, but if you say that if you want drivers
>> to be fixed, then it would be as good as talking terms to the kernel folks
>> to have certain features in the kernel. So IMHO if you think that things
>> should remain broken for that period till LK folks agree, then MythTV will
>> remain broken for all those time.
>>
>> IMHO you guys should adapt to something what's acceptable to the rest of
>> the world for the time being and later on use the stuff whatcomes out as a
>> good solution. First fix the immediate problem, then go for the finer fix.
>> Don't wait for the fine fix to be your first and final fix.
>>
>
> >From a users perspective what Daniel's done is a massive improvement, so
> he must be getting something right.
>
> I have two Twinhan Vision+ and a Nova-T. I used to get about 5% failed
> recordings with the old point in time tuning code, and now don't get any
> on the Twinhan cards.

Nice to know. The Twinhan cards (the dst module) is a completely
different card compared to other cards. So making it a reference point
for any aspect cannot solve any issues.

BTW, if you use the new drivers from my repository at,
http://thadathil.net:8000/cgi-bin/hgwebdir.cgi/v4l-algo-test
you will get faster tunings since the driver now tries to improve
previous situations. There is a module parameter dst_algo. For the time
being one needs to use dst_algo=0 (SW Algorithm) since the HW Algorithm
is not stable for some people. Check it out, would be interesting to see
how it fares.

Manu

_______________________________________________
mythtv-dev mailing list
mythtv-dev[at]mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

dscoular at cisco

Mar 17, 2006, 4:37 PM

Post #13 of 20 (2602 views)
Permalink

Re: [mythtv-commits] Ticket #1502: DVB API requires usleep after certain calls to get reliable tuning on certain drivers (esp Nova-T). [In reply to]

Hi Daniel et al,
I updated this ticket with a new patch which does the usleep after
the first FE_READ_STATUS prior to checking for initial FE_HAS_LOCK.

Please have a look at it and see if you think it has merit.

It looks like the dvb api will evolve into a userspace library which
should
remove the need for all these ugly usleeps from future myth code.
Manu has some
great plans for a libdvb which will take over responsibility for a
lot of
these, currently, problematic irritations.

Cheers,

Doug
_______________________________________________
mythtv-dev mailing list
mythtv-dev[at]mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

danielk at cuymedia

Mar 18, 2006, 7:54 AM

Post #14 of 20 (2607 views)
Permalink

Re: [mythtv-commits] Ticket #1502: DVB API requires usleep after certain calls to get reliable tuning on certain drivers (esp Nova-T). [In reply to]

On Thu, 2006-03-16 at 22:24 +0400, Manu Abraham wrote:
> Daniel Kristjansson wrote:
> > I tried searching the archives and didn't find anything for this.
> > I have applied patches from him, so he's not a total unknown
> > around here...
> >
>
> I have attached the old mail/patch sent by Marcus a while back. It might
> not be now suitable as it is for your code now, that sufficient time has
> passed by, but you can get the idea out of it.
>
>
> Manu

Heh, this is exactly the what we use in the dvbsignalmonitor loop
in 0.19, obviously it has problems... :)

-- Daniel

_______________________________________________
mythtv-dev mailing list
mythtv-dev[at]mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

danielk at cuymedia

Mar 18, 2006, 8:47 AM

Post #15 of 20 (2598 views)
Permalink

Re: [mythtv-commits] Ticket #1502: DVB API requires usleep after certain calls to get reliable tuning on certain drivers (esp Nova-T). [In reply to]

On Thu, 2006-03-16 at 20:35 +0400, Manu Abraham wrote:
> Daniel Kristjansson wrote:
> > Yup, the averaging is in my long term todo, it just doesn't have a
> > terribly high priority because it doesn't serve any purpose in MythTV
> > yet. Many cards don't even report these values.
> You are right, we are looking at this aspect, but this involves some
> changes like getting math operations into kernel/moving frontend drivers
> out to userspace. We have some thoughts on this, but don't bet on it,
> since there are quite some issues to be considered.
You can do this in the drivers with a short fixed point math macros.
Google "fixed point arithmetic", probably most of the stuff you will
find will be from a computer graphics viewpoint, so sq, sqrt, and divide
will be the most documented, but implementations abound other functions.

> Another one of the reasons why drivers are in such a state is that many
> drivers are Reverse Engineered , since vendors don't release
> specifications / information on them. But for some of them due to
> certain reasons some things cannot be implemented in kernel as it is.
I understand that, I give the drivers a lot of leeway for not
normalizing the signal to noise ratio, etc. I'm more concerned
that the DVB API doesn't specify what one should expect with
the ideal driver. For instance, for the signal to noise ratio to
have any accuracy the signal has to be multiplied by something.
Or it has to be in decibels, and even that would have to have a
fixed point or the only values you would ever see are 0, 1, 2 or 3.

> We are looking at userspace libraries to fix issues like this, so that
> all such information like this can be contained in them such that
> applications do not have to be bothered by issues like this. It will
> not be too long for them.
That would be nice :)

> Hmm.. I was talking to Ralph Metzler, he told me that Marcus Metzler
> sent you guys a patch to fix the issue properly. If Marcus sends you a
> patch i can assure you that you that you can use that patch as it is.
It turns out I already switched to something like this, the only
difference is the delay I used was shorter. This works with many
more drivers than the old code. But I then added the wait_for_backend
function in addition to this loop, which made even more drivers work,
but we still have problems.

> > The well coded drivers mostly used the safe 0..2^15 range anyway, so
> > it looks like all cards are reporting somewhat sane values now.
> AFAIK, the values are simply mapped and on different hardware it has
> different meanings. It might need further processing to display
> something really sane enough.
I don't mind processing, but the processing should be the same for
each driver. But the API is still unclear on what these things should
return. Right now we report the signal value as percentage 0-100%
and report the S/N in dB after taking log10f on the value, but this
was arrived at through experimentation, the DVB API is non-informative.

> I understand what you are saying, but if you say that if you want
> drivers to be fixed, then it would be as good as talking terms to the
> kernel folks to have certain features in the kernel. So IMHO if you
> think that things should remain broken for that period till LK folks
> agree, then MythTV will remain broken for all those time.
All I want to know is when the driver has told the hardware to switch
to a new frequency and the hardware is no longer locked on the old
frequency.

If I were making a wish list I'd also want to know which frequency
we are locked to when we get an FE_LOCK, right now you can tune and
immediately see an FE_LOCK, but in fact it just means you either have
a lock on the old transport OR the new transport. You can query what
frequency you are on, and you will see the frequency you just tuned
to, but in fact the hardware is still tuned to the old frequency.

You can see why this can drive a driver user crazy? Also, I don't
really see this being due to the drivers being reverse engineered,
if the driver writer doesn't know how to query something from the
hardware he should figure out how long the hardware takes and return
some value other than FE_LOCK or the new frequency/old frequency
while this delay expires. That way the user space application can
use the same calls with drivers which do have this information as
with those which do not.

Even more wish listy, I'd also want to be able to query the
vendor name and backend name for the card in addition to the
frontend name, I would also like multiple input cards like the
HD-2000 to have all their inputs supported so I could drop support
for the V4L digital driver for this card. For scanning, I would
like to be able to tell the driver to tune to a frequency and not
have the driver go looking for the closest working frequency,
though of course any PLL in the hardware shouldn't be disabled.

> IMHO you guys should adapt to something what's acceptable to the rest of
> the world for the time being and later on use the stuff whatcomes out as
> a good solution. First fix the immediate problem, then go for the finer
> fix. Don't wait for the fine fix to be your first and final fix.
Yeah, I think I'll add some fixed delay to 0.19-fixes for the drivers
that need it, and hope for a better solution for 0.20.

-- Daniel

_______________________________________________
mythtv-dev mailing list
mythtv-dev[at]mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

mocm at mocm

Mar 18, 2006, 8:55 AM

Post #16 of 20 (2603 views)
Permalink

Re: [mythtv-commits] Ticket #1502: DVB API requires usleep after certain calls to get reliable tuning on certain drivers (esp Nova-T). [In reply to]

>>>>> "Daniel" == Daniel Kristjansson <danielk[at]cuymedia.net> writes:

Daniel> On Thu, 2006-03-16 at 22:24 +0400, Manu Abraham wrote:
>> Daniel Kristjansson wrote: > I tried searching the archives and
>> didn't find anything for this. > I have applied patches from
>> him, so he's not a total unknown > around here...
>> >
>>
>> I have attached the old mail/patch sent by Marcus a while
>> back. It might not be now suitable as it is for your code now,
>> that sufficient time has passed by, but you can get the idea
>> out of it.
>>
>>
>> Manu

Daniel> Heh, this is exactly the what we use in the
Daniel> dvbsignalmonitor loop in 0.19, obviously it has
Daniel> problems... :)

There are several problems that have to be taken into account. First
of all, there really are some cards that take up to 4 seconds to tune
(mostly DVB-S which also have to switch diseqc). Some cards get
confused when you hit the i2c bus too often (i.e. check status) and
may not tune in that case.

So what I do is :

1) Set the diseqc and voltage and wait for 10000 usecs.
2) set the frontend
3) wait 300000 usecs check status
4) if you get a has_lock, everything is fine, otherwise repeat step 3
for a couple of times (3 times).
5) If there is still no lock (very rare) repeat 3)+4)
6) still no lock try resetting the diseqc (if there is one) and repeat
from 29.

I implemented that in my libdvb and also added a check for tuning
times and I got times from 0.2s to 4s for DVB-S cards, always
characteristic for the respective card.
I did not test many DVB-T cards, but they usually tune much faster.

For some cards the usleeps can be shorter, but I put in values that
fit all the cards I could test.

In any case you can forget about the FE_GET_EVENT, this was a relict
from the original Nokia API which was made for some specific Nokia
API.
Most drivers don't implement the events because you would have to
implement a polling loop in the driver which you can do just as well
with steps 3) and 4).

Marcus
_______________________________________________
mythtv-dev mailing list
mythtv-dev[at]mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

abraham.manu at gmail

Mar 19, 2006, 2:52 AM

Post #17 of 20 (2583 views)
Permalink

Re: [mythtv-commits] Ticket #1502: DVB API requires usleep after certain calls to get reliable tuning on certain drivers (esp Nova-T). [In reply to]

Daniel Kristjansson wrote:
> You can do this in the drivers with a short fixed point math macros.
> Google "fixed point arithmetic", probably most of the stuff you will
> find will be from a computer graphics viewpoint, so sq, sqrt, and divide
> will be the most documented, but implementations abound other functions.
>

The issue is not on the code. Imagine if MythTV guys have a big issue in
for a small code change to make it alright, imagine Linux kernel !

> I understand that, I give the drivers a lot of leeway for not
> normalizing the signal to noise ratio, etc. I'm more concerned
> that the DVB API doesn't specify what one should expect with
>

For the ideal driver, things are explained here ..
http://www.linuxtv.org/cgi-bin/viewcvs.cgi/dvb-apps/util/szap/README?rev=1.4&view=markup

> the ideal driver. For instance, for the signal to noise ratio to
> have any accuracy the signal has to be multiplied by something.
> Or it has to be in decibels, and even that would have to have a
> fixed point or the only values you would ever see are 0, 1, 2 or 3.
>

Currently it is not in dbuv, since there are no log functions used to
compute it. It is ATM a value which is "conveniently" mapped to an
existing range. But don't expect things to remain the same.

> It turns out I already switched to something like this, the only
> difference is the delay I used was shorter. This works with many
> more drivers than the old code. But I then added the wait_for_backend
> function in addition to this loop, which made even more drivers work,
> but we still have problems.
>
>

Sometimes a small delay can make a difference between life and death.
> I don't mind processing, but the processing should be the same for
> each driver. But the API is still unclear on what these things should
> return. Right now we report the signal value as percentage 0-100%
> and report the S/N in dB after taking log10f on the value, but this
> was arrived at through experimentation, the DVB API is non-informative.
>

It is not the API that is non-informative, but certain things can't be
done as it is , just like that in kernel drivers.
The reason being different hardware vendors do the same thing in
different ways.

> All I want to know is when the driver has told the hardware to switch
> to a new frequency and the hardware is no longer locked on the old
> frequency.
>
>

I don't think this can be done at all.

> If I were making a wish list I'd also want to know which frequency
> we are locked to when we get an FE_LOCK, right now you can tune and
> immediately see an FE_LOCK, but in fact it just means you either have
> a lock on the old transport OR the new transport. You can query what
> frequency you are on, and you will see the frequency you just tuned
> to, but in fact the hardware is still tuned to the old frequency.
>
>

Once you have a FE_HAS_LOCK, you can read the dvb_frontend_parameters

> You can see why this can drive a driver user crazy? Also, I don't
> really see this being due to the drivers being reverse engineered,
> if the driver writer doesn't know how to query something from the
> hardware he should figure out how long the hardware takes and return
> some value other than FE_LOCK or the new frequency/old frequency
> while this delay expires. That way the user space application can
> use the same calls with drivers which do have this information as
> with those which do not.
>

Hmm.. some hardware doesn't work as you expect. For the ideal hardware
yes, one should be able to query etc.

> Even more wish listy, I'd also want to be able to query the
> vendor name and backend name for the card in addition to the
> frontend name, I would also like multiple input cards like the
> HD-2000 to have all their inputs supported so I could drop support
> for the V4L digital driver for this card. For scanning, I would
> like to be able to tell the driver to tune to a frequency and not
> have the driver go looking for the closest working frequency,
> though of course any PLL in the hardware shouldn't be disabled.
>

The features what you are asking for are in the TODO list for the
library. The library will even have card specific information and PCI
ID's *if* all goes well.

Manu

_______________________________________________
mythtv-dev mailing list
mythtv-dev[at]mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

danielk at cuymedia

Mar 19, 2006, 9:04 AM

Post #18 of 20 (2591 views)
Permalink

Re: [mythtv-commits] Ticket #1502: DVB API requires usleep after certain calls to get reliable tuning on certain drivers (esp Nova-T). [In reply to]

On Sat, 2006-03-18 at 17:55 +0100, Marcus Metzler wrote:
> Some cards get confused when you hit the i2c bus too often
> (i.e. check status) and may not tune in that case.
I've seen this happen when you check the signal while a recording
is in progress. Ideally the driver would prevent too much i2c
communication for any particular hardware.

> So what I do is :
<snip>
I've created a task ticket to incorporate this into the MythTV tuning.
I will probably address #1049 first, since it causes most of the
problems with DVB-S.

> I implemented that in my libdvb and also added a check for tuning
> times and I got times from 0.2s to 4s for DVB-S cards, always
> characteristic for the respective card.
http://www.metzlerbros.org/dvb/index.html ?
I'll have a look..

> I did not test many DVB-T cards, but they usually tune much faster.
Yup, I'm concerned about using such a huge delay on those cards, so
I will probably use 50 ms for DVB-T & ATSC PCI cards and 300 ms for
everything else (including the DVB-T over USB cards).

> In any case you can forget about the FE_GET_EVENT, this was a relict
> from the original Nokia API which was made for some specific Nokia
Yup, I learned that when I first tried to fix the zero-length recording
problem.

-- Daniel

_______________________________________________
mythtv-dev mailing list
mythtv-dev[at]mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

abraham.manu at gmail

Mar 19, 2006, 11:33 AM

Post #19 of 20 (2594 views)
Permalink

Re: [mythtv-commits] Ticket #1502: DVB API requires usleep after certain calls to get reliable tuning on certain drivers (esp Nova-T). [In reply to]

dscoular at cisco

Mar 19, 2006, 12:49 PM

Post #20 of 20 (2594 views)
Permalink

Re: [mythtv-commits] Ticket #1502: DVB API requires usleep after certain calls to get reliable tuning on certain drivers (esp Nova-T). [In reply to]

Hi Daniel,
Having had a chance to look at Marcus' patch I reckon
it's superior to my one. Glad to see you are considering
a task to implement his technique.

Keep up the excellent and highly appreciated work!

Cheers,

Doug
_______________________________________________
mythtv-dev mailing list
mythtv-dev[at]mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact lists@gossamer-threads.com