Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: MythTV: Users

DVB-T tzap versus mythtv 0.19

 

 

First page Previous page 1 2 Next page Last page  View All MythTV users RSS feed   Index | Next | Previous | View Threaded


dscoular at cisco

Mar 4, 2006, 1:04 AM

Post #1 of 43 (10356 views)
Permalink
DVB-T tzap versus mythtv 0.19

Hi All,
A number of my colleagues and I have just upgraded our systems
to mythtv 0.19.

I'm running a gentoo system with a genkernel 2.6.15-gentoo-r5 kernel.

I have a Hauppauge Nova-T DVB-T card as my primary tuner and
an AVerMedia AverTV DVB-T USB 2.0 (A800) external tuner.
While my colleagues all have Nova-T based systems.

0.18.1 changed channels and worked perfectly for the Nova-T but
I always had problems with using the A800 (although tzap worked
fine with both cards).

Now that we've upgaded to 0.19 changing channels takes significantly
longer for the Nova-T, sometimes fails to get LOCK and occasionally
locks up the frontend too.

Is anyone running mythtv 0.19 with a Nova-T and getting similar
speed channel changing compared with 0.18.1 ? None of us are.

Also, my A800 never gets LOCK at all and reports S/N 0.0dB and BE 65535
but a signal of 99%... however it works perfectly with tzap!?!!

spug log # tzap -a 1 'NINE DIGITAL' -r
using '/dev/dvb/adapter1/frontend0' and '/dev/dvb/adapter1/demux0'
reading channels from file '/root/.tzap/channels.conf'
tuning to 191625000 Hz
video pid 0x0207, audio pid 0x02d0
status 03 | signal ad31 | snr 0000 | ber 001fffff | unc 0000ffff |
status 1f | signal ad32 | snr 0000 | ber 00000000 | unc 00000000 |
FE_HAS_LOCK
status 1f | signal 0000 | snr ffff | ber 00000000 | unc 00000000 |
FE_HAS_LOCK
status 1f | signal 0000 | snr ffff | ber 00000000 | unc 00000000 |
FE_HAS_LOCK

And yes, all channels were rescanned using mythtv 0.19. I
also increased both the A800 tuning timeouts in mythtv-setup
by tenfold. I'm wondering if the fact the driver is indicating
that the signal is zero once tuned in the above. For comparison
here's the same output from tzap for the Nova-T card:

spug szap # tzap -a 0 'NINE DIGITAL' -r
using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
reading channels from file '/root/.tzap/channels.conf'
tuning to 191625000 Hz
video pid 0x0207, audio pid 0x02d0
status 00 | signal c4c4 | snr ffff | ber 0001fffe | unc 00000000 |
status 1f | signal c3c3 | snr fefe | ber 00000422 | unc 00000000 |
FE_HAS_LOCK
status 1f | signal c3c3 | snr fefe | ber 00000700 | unc 00000000 |
FE_HAS_LOCK
status 1f | signal c3c3 | snr fefe | ber 00000642 | unc 00000000 |
FE_HAS_LOCK
status 1f | signal c4c4 | snr fcfc | ber 00000570 | unc 00000000 |
FE_HAS_LOCK
status 1f | signal c4c4 | snr fefe | ber 000004dc | unc 00000000 |
FE_HAS_LOCK

These figures look far more realistic compared to the A800 output.

Any thoughts much appreciated...

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


mikeparkins at ntlworld

Mar 5, 2006, 2:18 AM

Post #2 of 43 (10181 views)
Permalink
Re: DVB-T tzap versus mythtv 0.19 [In reply to]

You are not alone - My 0.19 system takes about 10 to 12 seconds to change
channels. I asked about this once but the only reply I had was from some
bright spark who suggested I should only be watching recorded programs... :(

mike.

On Saturday 04 Mar 2006 09:04, Doug Scoular wrote:
> Hi All,
> A number of my colleagues and I have just upgraded our systems
> to mythtv 0.19.
>
> I'm running a gentoo system with a genkernel 2.6.15-gentoo-r5 kernel.
>
> I have a Hauppauge Nova-T DVB-T card as my primary tuner and
> an AVerMedia AverTV DVB-T USB 2.0 (A800) external tuner.
> While my colleagues all have Nova-T based systems.
>
> 0.18.1 changed channels and worked perfectly for the Nova-T but
> I always had problems with using the A800 (although tzap worked
> fine with both cards).
>
> Now that we've upgaded to 0.19 changing channels takes significantly
> longer for the Nova-T, sometimes fails to get LOCK and occasionally
> locks up the frontend too.
>
> Is anyone running mythtv 0.19 with a Nova-T and getting similar
> speed channel changing compared with 0.18.1 ? None of us are.
>
> Also, my A800 never gets LOCK at all and reports S/N 0.0dB and BE 65535
> but a signal of 99%... however it works perfectly with tzap!?!!
>
> spug log # tzap -a 1 'NINE DIGITAL' -r
> using '/dev/dvb/adapter1/frontend0' and '/dev/dvb/adapter1/demux0'
> reading channels from file '/root/.tzap/channels.conf'
> tuning to 191625000 Hz
> video pid 0x0207, audio pid 0x02d0
> status 03 | signal ad31 | snr 0000 | ber 001fffff | unc 0000ffff |
> status 1f | signal ad32 | snr 0000 | ber 00000000 | unc 00000000 |
> FE_HAS_LOCK
> status 1f | signal 0000 | snr ffff | ber 00000000 | unc 00000000 |
> FE_HAS_LOCK
> status 1f | signal 0000 | snr ffff | ber 00000000 | unc 00000000 |
> FE_HAS_LOCK
>
> And yes, all channels were rescanned using mythtv 0.19. I
> also increased both the A800 tuning timeouts in mythtv-setup
> by tenfold. I'm wondering if the fact the driver is indicating
> that the signal is zero once tuned in the above. For comparison
> here's the same output from tzap for the Nova-T card:
>
> spug szap # tzap -a 0 'NINE DIGITAL' -r
> using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
> reading channels from file '/root/.tzap/channels.conf'
> tuning to 191625000 Hz
> video pid 0x0207, audio pid 0x02d0
> status 00 | signal c4c4 | snr ffff | ber 0001fffe | unc 00000000 |
> status 1f | signal c3c3 | snr fefe | ber 00000422 | unc 00000000 |
> FE_HAS_LOCK
> status 1f | signal c3c3 | snr fefe | ber 00000700 | unc 00000000 |
> FE_HAS_LOCK
> status 1f | signal c3c3 | snr fefe | ber 00000642 | unc 00000000 |
> FE_HAS_LOCK
> status 1f | signal c4c4 | snr fcfc | ber 00000570 | unc 00000000 |
> FE_HAS_LOCK
> status 1f | signal c4c4 | snr fefe | ber 000004dc | unc 00000000 |
> FE_HAS_LOCK
>
> These figures look far more realistic compared to the A800 output.
>
> Any thoughts much appreciated...
>
> 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
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users


nick at craig-wood

Mar 5, 2006, 2:48 AM

Post #3 of 43 (10156 views)
Permalink
Re: DVB-T tzap versus mythtv 0.19 [In reply to]

On Sun, Mar 05, 2006 at 10:18:16AM +0000, Mike Parkins wrote:
> You are not alone - My 0.19 system takes about 10 to 12 seconds to change
> channels. I asked about this once but the only reply I had was from some
> bright spark who suggested I should only be watching recorded programs... :(

I had a similar experience with my twin Nova-t backend. I upgraded
from a perfectly working mythtv 0.15. Recordings work just fine on
0.19 as does tzap.

However entering LiveTV just sits there with a blank screen for 40
seconds then returns to the menu. The frontend and backend seem to
miscommunicate about which file the livetv is actually being saved to
- perhaps because of the very long initial tuning times?

Here are the frontend and backend logs for the period.

http://www.craig-wood.com/nick/pub/livetvprob
http://www.craig-wood.com/nick/pub/livetvprob-fe

To be honest I'm not that bothered about LiveTV. It would be nice to
have it working again because it used to work quite well, but I don't
really need it - watching TV in real time is so 20th century ;-)

--
Nick Craig-Wood <nick [at] craig-wood> -- http://www.craig-wood.com/nick
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users


mtdean at thirdcontact

Mar 5, 2006, 10:41 AM

Post #4 of 43 (10169 views)
Permalink
Re: DVB-T tzap versus mythtv 0.19 [In reply to]

On 03/05/2006 05:48 AM, Nick Craig-Wood wrote:
> On Sun, Mar 05, 2006 at 10:18:16AM +0000, Mike Parkins wrote:
>
>> You are not alone - My 0.19 system takes about 10 to 12 seconds to change
>> channels. I asked about this once but the only reply I had was from some
>> bright spark who suggested I should only be watching recorded programs... :(

Heh. I had to look that up because it sounded a lot like something I
would say. Sure enough, I'm the bright spark. :)

> I had a similar experience with my twin Nova-t backend. I upgraded
> from a perfectly working mythtv 0.15. Recordings work just fine on
> 0.19 as does tzap.
>
> However entering LiveTV just sits there with a blank screen for 40
> seconds then returns to the menu. The frontend and backend seem to
> miscommunicate about which file the livetv is actually being saved to
> - perhaps because of the very long initial tuning times?
>
> Here are the frontend and backend logs for the period.
>
> http://www.craig-wood.com/nick/pub/livetvprob
> http://www.craig-wood.com/nick/pub/livetvprob-fe
>
> To be honest I'm not that bothered about LiveTV. It would be nice to
> have it working again because it used to work quite well, but I don't
> really need it - watching TV in real time is so 20th century ;-)
>

This sounds a lot like the file attribute caching issue.

NFS:
http://www.gossamer-threads.com/lists/mythtv/dev/184374#184374
SMB:
http://www.gossamer-threads.com/lists/mythtv/dev/184628#184628
CIFS:
http://www.gossamer-threads.com/lists/mythtv/users/186545#186545

Mike



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


nick at craig-wood

Mar 5, 2006, 12:57 PM

Post #5 of 43 (10170 views)
Permalink
Re: DVB-T tzap versus mythtv 0.19 [In reply to]

On Sun, Mar 05, 2006 at 01:41:35PM -0500, Michael T. Dean wrote:
> On 03/05/2006 05:48 AM, Nick Craig-Wood wrote:
> > However entering LiveTV just sits there with a blank screen for 40
> > seconds then returns to the menu. The frontend and backend seem to
> > miscommunicate about which file the livetv is actually being saved to
> > - perhaps because of the very long initial tuning times?
> >
> > Here are the frontend and backend logs for the period.
> >
> > http://www.craig-wood.com/nick/pub/livetvprob
> > http://www.craig-wood.com/nick/pub/livetvprob-fe
>
> This sounds a lot like the file attribute caching issue.
>
> NFS:
> http://www.gossamer-threads.com/lists/mythtv/dev/184374#184374
> SMB:
> http://www.gossamer-threads.com/lists/mythtv/dev/184628#184628
> CIFS:
> http://www.gossamer-threads.com/lists/mythtv/users/186545#186545

I haven't set up any shared directories between frontend and backend.
I don't even know how! I presume I'm using the mythtv protocol for
livetv and recording just like I always used to under 0.15.

--
Nick Craig-Wood <nick [at] craig-wood> -- http://www.craig-wood.com/nick
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users


kell4now at yahoo

Mar 9, 2006, 1:49 PM

Post #6 of 43 (10125 views)
Permalink
Re: DVB-T tzap versus mythtv 0.19 [In reply to]

On Saturday 04 Mar 2006 09:04, Doug Scoular wrote:
> Hi All,
> A number of my colleagues and I have just upgraded
> our systems
> to mythtv 0.19.
>
> I'm running a gentoo system with a genkernel
2.6.15-gentoo-r5 kernel.
>
> I have a Hauppauge Nova-T DVB-T card as my primary
tuner and
> an AVerMedia AverTV DVB-T USB 2.0 (A800) external
tuner.
> While my colleagues all have Nova-T based systems.
>
> 0.18.1 changed channels and worked perfectly for the
Nova-T but
> I always had problems with using the A800 (although
tzap worked
> fine with both cards).
>
> Now that we've upgaded to 0.19 changing channels
takes significantly
> longer for the Nova-T, sometimes fails to get LOCK
and occasionally
> locks up the frontend too.
>
> Is anyone running mythtv 0.19 with a Nova-T and
getting similar
> speed channel changing compared with 0.18.1 ? None
of us are.
>
> Also, my A800 never gets LOCK at all and reports S/N
0.0dB and BE 65535
> but a signal of 99%... however it works perfectly
with tzap!?!!
>
> spug log # tzap -a 1 'NINE DIGITAL' -r
> using '/dev/dvb/adapter1/frontend0' and
'/dev/dvb/adapter1/demux0'
> reading channels from file
'/root/.tzap/channels.conf'
> tuning to 191625000 Hz
> video pid 0x0207, audio pid 0x02d0
> status 03 | signal ad31 | snr 0000 | ber 001fffff |
unc 0000ffff |
> status 1f | signal ad32 | snr 0000 | ber 00000000 |
unc 00000000 |
> FE_HAS_LOCK
> status 1f | signal 0000 | snr ffff | ber 00000000 |
unc 00000000 |
> FE_HAS_LOCK
> status 1f | signal 0000 | snr ffff | ber 00000000 |
unc 00000000 |
> FE_HAS_LOCK
>
> And yes, all channels were rescanned using mythtv
0.19. I
> also increased both the A800 tuning timeouts in
mythtv-setup
> by tenfold. I'm wondering if the fact the driver is
indicating
> that the signal is zero once tuned in the above. For
comparison
> here's the same output from tzap for the Nova-T
card:
>
> spug szap # tzap -a 0 'NINE DIGITAL' -r
> using '/dev/dvb/adapter0/frontend0' and
'/dev/dvb/adapter0/demux0'
> reading channels from file
'/root/.tzap/channels.conf'
> tuning to 191625000 Hz
> video pid 0x0207, audio pid 0x02d0
> status 00 | signal c4c4 | snr ffff | ber 0001fffe |
unc 00000000 |
> status 1f | signal c3c3 | snr fefe | ber 00000422 |
unc 00000000 |
> FE_HAS_LOCK
> status 1f | signal c3c3 | snr fefe | ber 00000700 |
unc 00000000 |
> FE_HAS_LOCK
> status 1f | signal c3c3 | snr fefe | ber 00000642 |
unc 00000000 |
> FE_HAS_LOCK
> status 1f | signal c4c4 | snr fcfc | ber 00000570 |
unc 00000000 |
> FE_HAS_LOCK
> status 1f | signal c4c4 | snr fefe | ber 000004dc |
unc 00000000 |
> FE_HAS_LOCK
>
> These figures look far more realistic compared to
the A800 output.
>
> Any thoughts much appreciated...
>
> Doug
>
> --
> "The big print giveth and the small print taketh
away."

I'm seeing the same thing on Myth 19. When starting
LiveTV it takes about 6-10 secs to start, which is a
problem, but far worse is that that is that the card
(Nova-T DVB-T) fails to tune about 50% of the time.
Myth 18 worked perfectly.

If I tzap it, the card tunes in first time, every
time.

Quite often LiveTV will also lock up mythfrontend.

Any tips/tricks ?






____________________________________________________
On Yahoo!7
Messenger - Make free PC-to-PC calls to your friends overseas.
http://au.messenger.yahoo.com

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


dscoular at cisco

Mar 9, 2006, 2:53 PM

Post #7 of 43 (10121 views)
Permalink
Re: DVB-T tzap versus mythtv 0.19 [In reply to]

Hi All,

> 'm seeing the same thing on Myth 19. When starting
> LiveTV it takes about 6-10 secs to start, which is a
> problem, but far worse is that that is that the card
> (Nova-T DVB-T) fails to tune about 50% of the time.
> Myth 18 worked perfectly.
>
> If I tzap it, the card tunes in first time, every
> time.
>
> Quite often LiveTV will also lock up mythfrontend.

I wonder how many 0.19 users with DVB cards are
having tuning problems ? All my colleagues with 0.19
and DVB-T cards are experiencing tuning issues.

That being said everyone I know is based in Australia,
so maybe its specific to Australian TV... I'm not sure.

Is anyone outwith Australia having DVB-T tuning problems ?

I'm not too concerned with the 6-10 seconds to change
channels... it's the lack of actual tuning reliability and
the frequency of frontend death/lockup thats causing me
the most pain.

Under 0.18.1 if I got LOCK I got a picture... now I get
very variable Partial Lock... Full Lock... L... LA... LAM
under 0.19. Tuning under 0.18.1 was rock solid on my
setup... no antenna or card setup has changed at all. Frontend
crashes were very rare.

I'm hoping to go through the source this weekend to see
if I can figure out what the problem is. I also posted on
the LinuxTV DVB list and they said that the values
returned from a DVB driver for signal should be ignored
as the scale is not linear and varies from driver to driver.
BER and UNC being a better measure. As per this from Patrick
Boettcher:

> I have to admit, the way the signal strength is currently calculated
> is wrong and stupid.
>
> Problem is, to have really correct RF power calculation we need more
> information on the board and floating point operations in the kernel.
>
> OTOH, I repeat myself here, I don't see the reason, why MythTV is
> taking the Signal strength into account and drops a receiver from the
> list, when it is zero. In DVB we have much easier values to see if the
> stream is maybe garbled or not and this is the UNC and BER.
>
> Maybe it is worth for mythtv to add an option to disable the
> consideration of signal strength and SNR when using it with DVB.
>
> regards,
> Patrick.

Now, I don't know if MythTV uses UNC and BER and ignores SNR
and Signal when tuning... but that's what I hope to figure out over the
weekend. Also, if they are erroneous why display them ?

Any help much appreciated... I love my MythTV!

Cheers,

Doug





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


peterw at tux

Mar 9, 2006, 3:13 PM

Post #8 of 43 (10109 views)
Permalink
Re: DVB-T tzap versus mythtv 0.19 - HDTV and BER [In reply to]

On Fri, Mar 10, 2006 at 09:53:41AM +1100, Doug Scoular wrote:

> I'm hoping to go through the source this weekend to see
> if I can figure out what the problem is. I also posted on
> the LinuxTV DVB list and they said that the values
> returned from a DVB driver for signal should be ignored
> as the scale is not linear and varies from driver to driver.
> BER and UNC being a better measure. As per this from Patrick
> Boettcher:

> > OTOH, I repeat myself here, I don't see the reason, why MythTV is
> > taking the Signal strength into account and drops a receiver from the
> > list, when it is zero. In DVB we have much easier values to see if the
> > stream is maybe garbled or not and this is the UNC and BER.
> >
> > Maybe it is worth for mythtv to add an option to disable the
> > consideration of signal strength and SNR when using it with DVB.

I've heard that some DVB devices -- perhaps most notably the PCHDTV HD2000
and HD3000 -- do not support BER. Here's a web page with more details:
http://www.penlug.org/twiki/bin/view/Main/DigitalTelevisionDVB

In my experience with MythTV 0.19 and an HD3000 as a DVB device for
capturing OTA/ATSC, the signal strength % displayed when tuning an ATSC
channel has appeared to be useful/accurate, e.g. I can tell a difference
between a 70% signal (noticably pixelated) and an 85% signal (pretty good).

-Peter

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


danielk at cuymedia

Mar 9, 2006, 3:40 PM

Post #9 of 43 (10099 views)
Permalink
Re: DVB-T tzap versus mythtv 0.19 [In reply to]

On Sat, 2006-03-04 at 20:04 +1100, Doug Scoular wrote:
> Hi All,
> A number of my colleagues and I have just upgraded our systems
> to mythtv 0.19.
>
> I'm running a gentoo system with a genkernel 2.6.15-gentoo-r5 kernel.
>
> I have a Hauppauge Nova-T DVB-T card as my primary tuner and
> an AVerMedia AverTV DVB-T USB 2.0 (A800) external tuner.
> While my colleagues all have Nova-T based systems.

The Nova-T driver is broken, it reports a lock when there isn't a lock.
One of the DVB driver folks told me this would be fixed in 2.6.12...
No such luck.

But the main problem with DVB is that none of the regular MythTV
developers uses DVB-x, it basically is maintained as a side-effect
of having ATSC support in MythTV.

-- Daniel


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


dscoular at cisco

Mar 9, 2006, 7:27 PM

Post #10 of 43 (10104 views)
Permalink
Re: DVB-T tzap versus mythtv 0.19 [In reply to]

Hi Myth users,

Daniel at cuymedia wrote:

> The Nova-T driver is broken, it reports a lock when there isn't a lock.
> One of the DVB driver folks told me this would be fixed in 2.6.12...
> No such luck.
>
> But the main problem with DVB is that none of the regular MythTV
> developers uses DVB-x, it basically is maintained as a side-effect
> of having ATSC support in MythTV.

Ah... but then why did MythTV 0.18.1 work flawlessly when
MythTV 0.19 is so problematic ?

I haven't had any problems using tzap or kaffeine or mplayer to
tune to the channels found in my channels.conf. Changing
channels is quick and reliable. I'm running 2.6.15-gentoo-r5 so
I don't think you can really say the DVB Nova-T driver is all
that broken when I've only experienced problems when using
it with MythTV 0.19.

Now, I have no real problem with slow channel changing as I
understand a little about the buffering. I just want to have reliable
channel changing back and I really don't want to have to downgrade.
It's also not just that I'm a live-tv watcher... I'm having the odd
empty recording because the Nova-T fails to fully lock.

Also, keep in mind that there are a number of us experiencing these
issues.

Anyone else having problems or care to offer some insight before
I dive into the source ?

Cheers,

Doug



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


kuphal at dls

Mar 9, 2006, 7:31 PM

Post #11 of 43 (10114 views)
Permalink
Re: DVB-T tzap versus mythtv 0.19 [In reply to]

Nick Craig-Wood wrote:
> On Sun, Mar 05, 2006 at 10:18:16AM +0000, Mike Parkins wrote:
>
>> You are not alone - My 0.19 system takes about 10 to 12 seconds to change
>> channels. I asked about this once but the only reply I had was from some
>> bright spark who suggested I should only be watching recorded programs... :(
>>
>
> I had a similar experience with my twin Nova-t backend. I upgraded
> from a perfectly working mythtv 0.15. Recordings work just fine on
> 0.19 as does tzap.
>
> However entering LiveTV just sits there with a blank screen for 40
> seconds then returns to the menu. The frontend and backend seem to
> miscommunicate about which file the livetv is actually being saved to
> - perhaps because of the very long initial tuning times?
>
> Here are the frontend and backend logs for the period.
>
> http://www.craig-wood.com/nick/pub/livetvprob
> http://www.craig-wood.com/nick/pub/livetvprob-fe
>
> To be honest I'm not that bothered about LiveTV. It would be nice to
> have it working again because it used to work quite well, but I don't
> really need it - watching TV in real time is so 20th century ;-)
>
>
There are a number of fixes in the 0.19-fixes branch for these types of
issues (LiveTV filename changing). Are you running from that branch or
the stock 0.19 release?

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


dscoular at cisco

Mar 9, 2006, 9:28 PM

Post #12 of 43 (10098 views)
Permalink
Re: DVB-T tzap versus mythtv 0.19 [In reply to]

Hi All,

Kevin wrote:

> There are a number of fixes in the 0.19-fixes branch for these types of
> issues (LiveTV filename changing). Are you running from that branch or
> the stock 0.19 release?
>
> Kevin

I think this thread is getting a little mixed up with Craig's question
about slow channel changing. As I said slow channel changing
is not as big a concern for me... it's the reliability of tuning
with DVB-T and the use of BER and UNC that I'm interested in.
I'm running a single box frontend/master backend. I think Craig's
set up is more complex.

A group of us wind up with empty recordings due to DVB-T
tuning failures... we had flawless tuning on 0.18.1.

That said, however, I will try installing the 0.19-fixes release. I
had hoped an official 0.19.1 would hit the streets before I had to
do this. I'm also going to go through the source and try and figure
out how tuning has changed between 0.18.1 and 0.19.

Any pointers or thoughts much appreciated.

Cheers,

Doug



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


frank.paulsen at gmx

Mar 10, 2006, 12:29 AM

Post #13 of 43 (10110 views)
Permalink
Re: DVB-T tzap versus mythtv 0.19 [In reply to]

Doug Scoular <dscoular [at] cisco> writes:

> I wonder how many 0.19 users with DVB cards are
> having tuning problems ? All my colleagues with 0.19
> and DVB-T cards are experiencing tuning issues.

i just did a quick comparison between 0.18.1 and 0.19

card: HAMA DVB-T USB
position: Germany
Linux: Gentoo with kernel 2.6.15

time to see a picture after selecting new channel from EPG:
0.18.1 between two and four seconds
0.19 between eight and 25 seconds

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


neil at fnxweb

Mar 10, 2006, 12:42 AM

Post #14 of 43 (10103 views)
Permalink
Re: DVB-T tzap versus mythtv 0.19 [In reply to]

Around about 09/03/06 22:53, Doug Scoular typed ...
> Is anyone outwith Australia having DVB-T tuning problems ?
>
> I'm hoping to go through the source this weekend to see
> if I can figure out what the problem is.

As I've posted elsewhere, I'm getting a near-total failure to record
scheduled progs. [.LiveTV seems OK all the time, including 'R' record of the
current prog.]. Others have seen a similar thing no the list (with no
resolution as yet) although seemingly not as often as me, and a friend here
with the same card has also noticed it for some of his recordings: no errors,
no actual .mpg, but an entry in the 'recorded' list and logs indicating
ongoing working recording. It's exasperating.

If you're jumping into the code in the near future, maybe you could point
me to the right place as that was pretty much *my* next stop. I want to try
to find out if there's anywhere around the start of DVB recordings that
*doesn't* log if it's not working. I've not touched the Myth code before ...

--
[neil [at] fn ~]# rm -f .signature
[neil [at] fn ~]# ls -l .signature
ls: .signature: No such file or directory
[neil [at] fn ~]# exit
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users


nick at craig-wood

Mar 10, 2006, 4:21 AM

Post #15 of 43 (10106 views)
Permalink
Re: DVB-T tzap versus mythtv 0.19 [In reply to]

On Thu, Mar 09, 2006 at 09:31:46PM -0600, Kevin Kuphal wrote:
> > However entering LiveTV just sits there with a blank screen for 40
> > seconds then returns to the menu. The frontend and backend seem to
> > miscommunicate about which file the livetv is actually being saved to
> > - perhaps because of the very long initial tuning times?
> >
> > Here are the frontend and backend logs for the period.
> >
> > http://www.craig-wood.com/nick/pub/livetvprob
> > http://www.craig-wood.com/nick/pub/livetvprob-fe
> >
> There are a number of fixes in the 0.19-fixes branch for these types of
> issues (LiveTV filename changing). Are you running from that branch or
> the stock 0.19 release?

I compiled myself some debian packages from

http://svn.mythtv.org/svn/branches/release-0-19-fixes/mythtv

Revision 9277 (7 March) and saw the same symptoms :-(

Here are some logs from that version

http://www.craig-wood.com/nick/pub/livetvprob-frontend-log-2
http://www.craig-wood.com/nick/pub/livetvprob-backend-log-2

This does appear to have solved the mis-communication about file names
- there is only one .mpg file name mentioned in those logs, but LiveTV
still doesn't work :-( This appears as about 40s of black screen then
it returns to the menu.

Thanks

Nick
--
Nick Craig-Wood <nick [at] craig-wood> -- http://www.craig-wood.com/nick
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users


nick at craig-wood

Mar 10, 2006, 4:37 AM

Post #16 of 43 (10116 views)
Permalink
Re: DVB-T tzap versus mythtv 0.19 [In reply to]

On Thu, Mar 09, 2006 at 06:40:29PM -0500, Daniel Kristjansson wrote:
> On Sat, 2006-03-04 at 20:04 +1100, Doug Scoular wrote:
> > Hi All,
> > A number of my colleagues and I have just upgraded our systems
> > to mythtv 0.19.
> >
> > I'm running a gentoo system with a genkernel 2.6.15-gentoo-r5 kernel.
> >
> > I have a Hauppauge Nova-T DVB-T card as my primary tuner and
> > an AVerMedia AverTV DVB-T USB 2.0 (A800) external tuner.
> > While my colleagues all have Nova-T based systems.
>
> The Nova-T driver is broken, it reports a lock when there isn't a lock.
> One of the DVB driver folks told me this would be fixed in 2.6.12...
> No such luck.

Interesting. I have two of the original Nova-Ts (over 2 years old
now), not the newer 990 ones you can buy now, on kernel 2.6.15.

I'm having the opposite problem - all my recordings have been fine,
but I can't get LiveTV to work at all!

A possible data point - the channel scanner in MythTV didn't work very
well. I tried it 5 times and it only detected a couple of multiplexes
(out of 6 possible). I did a scan with 'scan' and made a
channels.conf and imported that in the end.

> But the main problem with DVB is that none of the regular MythTV
> developers uses DVB-x, it basically is maintained as a side-effect
> of having ATSC support in MythTV.

:-(

--
Nick Craig-Wood <nick [at] craig-wood> -- http://www.craig-wood.com/nick
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users


matthew at sleeper

Mar 10, 2006, 5:00 AM

Post #17 of 43 (10089 views)
Permalink
Re: DVB-T tzap versus mythtv 0.19 [In reply to]

Doug Scoular wrote:

>
> I think this thread is getting a little mixed up with Craig's question
> about slow channel changing. As I said slow channel changing
> is not as big a concern for me... it's the reliability of tuning
> with DVB-T and the use of BER and UNC that I'm interested in.
> I'm running a single box frontend/master backend. I think Craig's
> set up is more complex.
>
> A group of us wind up with empty recordings due to DVB-T
> tuning failures... we had flawless tuning on 0.18.1.

I've got a DNTV-Live and that works fine under 0.19. (In Sydney)
Channel changing/ startup could be faster, but thats not a major
concern. (Don't watch much 'live' TV).
I have a Nova-T at work, but that machine is multicast streaming the
transport streams onto our LAN..

I'm having absolutely no backend/tuning problems. Can't say the same
for the front end, which now randomly crashes. Often it takes 3 or 4
front end restarts to watch a movie. I've taken to setting a bookmark
every couple of minutes so I don't have to fast forward that far when
the next front end crash occurs. (Fedora Core 4, ATRPMS). It's kinda
hard to debug as I can't actually read the text in the terminal windows
via TV out - i'm using composite TV out, so the xterm text is very fuzzy.
Attachments: smime.p7s (3.27 KB)


danielk at cuymedia

Mar 10, 2006, 6:42 AM

Post #18 of 43 (10104 views)
Permalink
Re: DVB-T tzap versus mythtv 0.19 [In reply to]

On Fri, 2006-03-10 at 14:27 +1100, Doug Scoular wrote:
> Daniel at cuymedia wrote:
> > The Nova-T driver is broken, it reports a lock when there isn't a lock.
> > One of the DVB driver folks told me this would be fixed in 2.6.12...
> > No such luck.
> >
> > But the main problem with DVB is that none of the regular MythTV
> > developers uses DVB-x, it basically is maintained as a side-effect
> > of having ATSC support in MythTV.
>
> Ah... but then why did MythTV 0.18.1 work flawlessly when
> MythTV 0.19 is so problematic ?
We changed the tuning because for many people the tuning in 0.18.1
caused a lot of zero length recordings. Search the dev archives for
all the iterations we went through. The current tuning works for
most DVB-T people, but does not yet work well for DVB-S people.
The remaining problems in DVB-T are with the Nova-T DVB driver.

> I don't think you can really say the DVB Nova-T driver is all
> that broken when I've only experienced problems when using
> it with MythTV 0.19.
The Nova-T DVB driver hasn't been fixed yet. Until it is, I can say it's broken :)

> Now, I have no real problem with slow channel changing as I
> understand a little about the buffering.
Actually this will be getting a little faster in SVN after we finish
refactoring the EIT scanner...

> Anyone else having problems or care to offer some insight before
> I dive into the source ?
Have a read through the archives, look for Aafloy's posts.
The code in question is in dvbchannel.cpp, mostly in the
wait_for_backend() function.

-- Daniel

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


Niels at Dybdahl

Mar 10, 2006, 7:10 AM

Post #19 of 43 (10089 views)
Permalink
Re: DVB-T tzap versus mythtv 0.19 [In reply to]

>
> > I don't think you can really say the DVB Nova-T driver is all
> > that broken when I've only experienced problems when using
> > it with MythTV 0.19.
> The Nova-T DVB driver hasn't been fixed yet. Until it is, I can say it's
> broken :)


Is the 'broken' Nova-T driver part of the Linux distribution or part of
MythTV ?

I have recently upgraded to 0.19 and just bought a Nova-T that I would like
to install soon, so I would like to know more about this.

If the broken driver is part of Linux, which kernels are affected ? (I am
running 2.6.11-1.35_FC3)

Would it be possible to put the Nova-T in a MythTV 0.18.1 box, do the
scanning and move the database information to my 0.19 system ?


Niels Dybdahl


tait at digitallaw

Mar 10, 2006, 11:35 AM

Post #20 of 43 (10086 views)
Permalink
Re: DVB-T tzap versus mythtv 0.19 [In reply to]

On Saturday 04 March 2006 09:04, Doug Scoular wrote:
> Hi All,
> A number of my colleagues and I have just upgraded our systems
> to mythtv 0.19.
>
> I'm running a gentoo system with a genkernel 2.6.15-gentoo-r5 kernel.
>
> I have a Hauppauge Nova-T DVB-T card as my primary tuner and
> an AVerMedia AverTV DVB-T USB 2.0 (A800) external tuner.
> While my colleagues all have Nova-T based systems.
>
> 0.18.1 changed channels and worked perfectly for the Nova-T but
> I always had problems with using the A800 (although tzap worked
> fine with both cards).
>
> Now that we've upgaded to 0.19 changing channels takes significantly
> longer for the Nova-T, sometimes fails to get LOCK and occasionally
> locks up the frontend too.
>
> Is anyone running mythtv 0.19 with a Nova-T and getting similar
> speed channel changing compared with 0.18.1 ? None of us are.
>
> Also, my A800 never gets LOCK at all and reports S/N 0.0dB and BE 65535
> but a signal of 99%... however it works perfectly with tzap!?!!
>

Just to confirm, I seem to be having the exact same problem since my upgrade
to 0.19.

Setup is two backends, one with a Nova-T 909 and an Avermedia 771 (PCI), and a
slave backend with another Nova-T 909. Scanning and tuning in 0.18.1 worked
perfectly, and it's only since the upgrade that things have gone funky -
particularly annoying since it's meant I've missed a boatload of Pinky and
the Brain re-runs on CBBC!

Watching Live TV works periodically, but changing channels can take upwards of
30 seconds. I'm not that bothered about Live TV since I never use it, but
some channels (such as the aforementioned CBBC) don't seem to be tunable at
all, despite the fact that tzap, Xine and Kaffeine have no problem whatsoever
tuning in (from a scan dvb-t channels.conf and Kaffeine's inbuilt scanner
respectively). Because of this, I've had a few recordings fail because the
tuner can't get a lock, resulting in alot of empty recordings. I've tried
getting Myth to re-scan the channels and importing my channels.conf, but to
no avail.

I've just bumped the Avermedia card to the highest priority in the system so
that (hopefully) important stuff will be recorded with that, and I'll be able
to see if this really is a problem with the Nova-T more than anything else -
although I'm mystified as to why it worked in 0.18 and not in 0.19. I suspect
something os awry with Myth's channel changing (not surprising if the head
devs don't have DVB cards themselves I guess - if there are any devs in the
UK I wouldn't mind ponying up some cash to get them a Nova-T).

Like Doug, I'm also running a Gentoo system. Kernel is 2.6.15 CK2 (SMP).

If there is a -fixes branch knocking about where the tuning works reliably,
does anyone have any idea when it'll make it's way into a semi-official
0.19.1 (or something) release a la 0.18.1?
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users


dscoular at cisco

Mar 10, 2006, 5:57 PM

Post #21 of 43 (10117 views)
Permalink
Re: DVB-T tzap versus mythtv 0.19 [In reply to]

Hi All,
I've upgraded to release-0.19-fixes (9277) and am still
having problems with channel tuning and the Nova-T.

DanielK wrote:
> The Nova-T DVB driver hasn't been fixed yet. Until it is, I can say
it's broken :)

I bow to your greater knowledge... however, I've asked Patrick
Boettcher on
the linux DVB mailing list to confirm or refute this problem being
with the
Nova-T driver. Hope this is okay.

The 0.19-fixes (9277) release does seem a little faster to change
channels (not that
this is my concern in this thread) but it is just as unreliable at
tuning. I get
amazingly incoherent results from the OSD signal monitor... sometimes
giving me terrible figures for BE (65535), sometimes BE (0),
sometimes I get
No Lock, sometimes partial, sometimes full... and every combination of
the above can randomly lead to a picture or not. Sometimes I get a
picture but the frontend no longer accepts input. Also, I occasionally
get a completely blank OSD signal monitor timeout dialog (this is
new to me post 0.19-fixes).

I'm going through the code right now trying to figure it out. It appears
0.18.1 simply waited for FE_HAS_LOCK. 0.19.1 is much more complex;
interrogating the card via ioctls for the features it supports and then
using these in combination to see if they are "allgood".

Neil wrote:
> If you're jumping into the code in the near future, maybe you could
point
> me to the right place as that was pretty much *my* next stop. I want
to try
> to find out if there's anywhere around the start of DVB recordings that
> *doesn't* log if it's not working. I've not touched the Myth code
before ...

Me neither but here's what I've gleaned so far... please correct me
if I'm wrong...

It looks like tv_play.cpp calls TV::RunTV which starts an event loop
running. Each time the loop iterates it calls TV::UpdateSignalOSD.
UpdateSignalOSD calls SignalMonitorValue::Parse which uses extra
"SIGNAL" event data to determine what card parameters are to
be monitored.

Oops, maybe I'm getting ahead of myself... when we
change channels the event triggers a call to TV::ChangeChannel
which in turn calls TV::SetChannel. This adds a tuning request
to a queue and waits for it to tune. TVRec::HandleTuning
in tv_rec.cpp deals with this request.

TVRec::HandleTuning, in turn, calls TVRec::TuningFrequency.
This figures out the channel name, and possibly the
input name we need to pass to "channel" and then calls
channel appropriately. Then it adds any filters and sets any
video capture attributes that need to be set.

The card specific signal monitoring is started. When the
signal monitor determines that all monitored card parameters
are "good" then it switches the channel and stops the OSD
monitor. I think it is the combination of what parameters are
being monitored and the IsAllGood() method that is the
crux of the code. The IsAllGood method ensures that all the
monitored card parameters meet the IsGood() method's
criteria of what is good. The IsGood method checks a
value against a previously set threshold.

> Have a read through the archives, look for Aafloy's posts.
> The code in question is in dvbchannel.cpp, mostly in the
> wait_for_backend() function.

Thanks for the pointer... I did look through Kenneth's posts
but I'm pretty out my depth now.

Ooh... my head hurts. I want to debug what the thresholds are
and how they are being combined in IsAllGood()... but I need
to lie down now :^/

Anyway, I'll get back to the thread on what I find (if anything).

Cheers,

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


robthebob at gmail

Mar 11, 2006, 6:24 AM

Post #22 of 43 (10078 views)
Permalink
Re: DVB-T tzap versus mythtv 0.19 [In reply to]

On 3/11/06, Doug Scoular wrote:
> Hi All,
> I've upgraded to release-0.19-fixes (9277) and am still
> having problems with channel tuning and the Nova-T.
>
> DanielK wrote:
> > The Nova-T DVB driver hasn't been fixed yet. Until it is, I can say
> it's broken :)
>
> I bow to your greater knowledge... however, I've asked Patrick
> Boettcher on
> the linux DVB mailing list to confirm or refute this problem being
> with the
> Nova-T driver. Hope this is okay.

I'm having similar problems, and I think the thread on LiveTV taking a
long time is pretty much down to this Nova-T/0.19 incompatibility.

DanielK, having said the driver is broken, can you please tell us what
you think the problem is so I can go off and have a poke around. This
is quite a problem for UK users as the Nova-T is a really common card
over here and DVB is spreading more and more, especially among the
kind of people who use Myth.

What are the reasons behind the move away from the FE_HAS_LOCK change?
Would some cards report this incorrectly? Maybe this could be made an
option.

Doug, could you point me at Kenneth's posts, my searches turned up
some pretty old ones that didn't seem related.

Thanks,

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


danielk at cuymedia

Mar 11, 2006, 7:09 AM

Post #23 of 43 (10063 views)
Permalink
Re: DVB-T tzap versus mythtv 0.19 [In reply to]

On Sat, 2006-03-11 at 14:24 +0000, Robin Neatherway wrote:
> On 3/11/06, Doug Scoular wrote:
> > Hi All,
> > I've upgraded to release-0.19-fixes (9277) and am still
> > having problems with channel tuning and the Nova-T.

> I'm having similar problems, and I think the thread on LiveTV taking a
> long time is pretty much down to this Nova-T/0.19 incompatibility.
AFAIK

> DanielK, having said the driver is broken, can you please tell us what
> you think the problem is so I can go off and have a poke around. This
> is quite a problem for UK users as the Nova-T is a really common card
> over here and DVB is spreading more and more, especially among the
> kind of people who use Myth.
> What are the reasons behind the move away from the FE_HAS_LOCK change?
> Would some cards report this incorrectly? Maybe this could be made an
> option.

We haven't moved away from using FE_HAS_LOCK, in fact it is the
only hardware info that has a threshold in dvbsignalmonitor.

The problem is that unless the hardware has finished tuning to
a new transport when we get the lock, the driver can report a
lock on the previous transport. To prevent this from happening,
we use FE_READ_STATUS, this should assure that the pending
tuning requests from the DVB driver's frontend are processed
by the DVB driver's backend. With the Nova-T this synchronization
appears not to work.

There are at least two other methods to assure that the tuning
request has completed.

DVB Events are sent by most drivers whenever the tuner changes
frequency. However in practice there are four problems with this
approach: first some drivers do not send the events, second the
event is not sent if the card already happens to be on the
requested transport, third some cards delete the events from the
event queue before we get a chance to see them, and fourth,
according to Aafloy, DVB Event notification has been deprecated
and so the problems won't be fixed.

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.

After the FE_READ_STATUS, we fire up the dvbsignalmonitor, it waits
for an FE_HAS_LOCK, and then for the PAT & PMT tables matching the
values in the DB. Now if it waited on a matching SDT table instead,
it probably wouldn't be as huge a problem if FE_READ_STATUS returned
prematurely since SDT tables are presumably unique, unlike most
PAT and PMT tables.

-- Daniel

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


dscoular at cisco

Mar 11, 2006, 6:07 PM

Post #24 of 43 (10083 views)
Permalink
Re: DVB-T tzap versus mythtv 0.19 [In reply to]

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


danielk at cuymedia

Mar 11, 2006, 8:06 PM

Post #25 of 43 (10058 views)
Permalink
Re: DVB-T tzap versus mythtv 0.19 [In reply to]

On Sun, 2006-03-12 at 13:07 +1100, Doug Scoular wrote:
> 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.

Requiring usleep[s] is in a word asinine.

The "API" is that you have no idea when the tuning actually
starts or finishes, but just have to guess as to when it has
completed. You have hope the kernel wasn't too busy doing
other things to attend to the DVB driver in the interval you
have allotted and need to proceed on the assumption that the
potentially failing command you issued has been honored and
completed successfully.

It only exposes how fundamentally broken the DVB API is and makes
me question Linus' acceptance of that code into the kernel.

But I already knew the drivers were broken, it just continues to
frustrate me. I would accept a patch that did the usleep[s] for
some per card configurable period of time, so long as it defaults
to off (you can autodetect the Nova-T and enable the hack for it.)

-- Daniel

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

First page Previous page 1 2 Next page Last page  View All MythTV users RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.