Mailing List Archive

On Mon, Oct 11, 2004 at 01:39:31PM -0400, Cory Papenfuss wrote:
> Slightly OT, but does anyone know the status of:
>
> - HD-3000 card status, and
> - HD-[23]000 support for QAM?
>
> I looked through the code once and looks like "pseudo"
> open-source... i.e. regular data structures and device setup, but then a
> *huge* chunk of obscure hex data to blindly dump to the card to make it
> go. If QAM could be made to work on this thing, I'd say it's a no-brainer
> of a card to go with.
>
> Thanks,
> -Cory
>

I probably should open a new thread for this but anyway.. I took a
little trip over to pcHDTV and took a fresh box (except the new hd-3000
driver was working on this already) and installed Mythtv. Nothing odd
came up at all. Myth started right up, live-tv and recording. TV
signals also worked, which the dev from pcHDTV didn't think would work.
The HD-3000 uses Video4linux 2, and everything but the signal check
should work using regular v4l. .. They're going to see why signal
checking does work. :) So no need to worry about support for the
HD-3000, it works right off.

Now for QAM. pcHDTV does have the micro code for the QAM on the
HD-3000 card. This means support will be coming. pcHDTV was not able
to get the microcode (yet?) for the HD-2000 and it's a shot in the dark
at getting stable QAM support working on the HD-2000, but it's not
impossible. It would probably be easier to try and convience them to
give pcHDTV the microcode than hack at it from how things were stated to
me.

Other than QAM, there isn't much difference in what people can expect.
There's a little more multi-path rejection in the hd-3000, but not
enough to make a deal of. That's really all to say.

Pre-sales are to start in the next week or two, shipping a week or two
after that.

--Brandon

> I probably should open a new thread for this but anyway.. I took a
> little trip over to pcHDTV and took a fresh box (except the new hd-3000
> driver was working on this already) and installed Mythtv. Nothing odd
> came up at all. Myth started right up, live-tv and recording. TV
> signals also worked, which the dev from pcHDTV didn't think would work.
> The HD-3000 uses Video4linux 2, and everything but the signal check
> should work using regular v4l. .. They're going to see why signal
> checking does work. :) So no need to worry about support for the
> HD-3000, it works right off.
>
> Now for QAM. pcHDTV does have the micro code for the QAM on the
> HD-3000 card. This means support will be coming. pcHDTV was not able
> to get the microcode (yet?) for the HD-2000 and it's a shot in the dark
> at getting stable QAM support working on the HD-2000, but it's not
> impossible. It would probably be easier to try and convience them to
> give pcHDTV the microcode than hack at it from how things were stated to
> me.
Sounds about right. Microcode for the Oren chip. Fairly unloved
hex code. As long as QAM support is planned eventually, that sound good.

>
> Other than QAM, there isn't much difference in what people can expect.
> There's a little more multi-path rejection in the hd-3000, but not
> enough to make a deal of. That's really all to say.
... and 3.3v pci rather than 5v, right?
>
> Pre-sales are to start in the next week or two, shipping a week or two
> after that.
>
> --Brandon
>
OK... that's what I was looking for. I think it was basically a
cost-reduction and parts-availibility redesign.

On Mon, Oct 11, 2004 at 02:43:07PM -0400, Cory Papenfuss wrote:
> >I probably should open a new thread for this but anyway.. I took a
> >little trip over to pcHDTV and took a fresh box (except the new hd-3000
> >driver was working on this already) and installed Mythtv. Nothing odd
> >came up at all. Myth started right up, live-tv and recording. TV
> >signals also worked, which the dev from pcHDTV didn't think would work.
> >The HD-3000 uses Video4linux 2, and everything but the signal check
> >should work using regular v4l. .. They're going to see why signal
> >checking does work. :) So no need to worry about support for the
> >HD-3000, it works right off.
> >
> >Now for QAM. pcHDTV does have the micro code for the QAM on the
> >HD-3000 card. This means support will be coming. pcHDTV was not able
> >to get the microcode (yet?) for the HD-2000 and it's a shot in the dark
> >at getting stable QAM support working on the HD-2000, but it's not
> >impossible. It would probably be easier to try and convience them to
> >give pcHDTV the microcode than hack at it from how things were stated to
> >me.
> Sounds about right. Microcode for the Oren chip. Fairly unloved
> hex code. As long as QAM support is planned eventually, that sound good.
>
> >
> >Other than QAM, there isn't much difference in what people can expect.
> >There's a little more multi-path rejection in the hd-3000, but not
> >enough to make a deal of. That's really all to say.
> ... and 3.3v pci rather than 5v, right?

Correct.

> >
> >Pre-sales are to start in the next week or two, shipping a week or two
> >after that.
> >
> >--Brandon
> >
> OK... that's what I was looking for. I think it was basically a
> cost-reduction and parts-availibility redesign.

parts-availibility was 99.9% and the last place the card was made burnt
down. I'm not sure on the cost, from what I've been told it will be
selling for nearly the same amount.

--Brandon

On Monday 11 October 2004 08:08, Steve Frank wrote:
> mythtv-users-bounces@mythtv.org wrote:
> > On Oct 10, 2004, at 17:21, Joe Barnhart wrote:
> >> I have noticed that my "myth" question has not received a flood of
> >> messages like "I'm using it and it works great."
> >
> > I'm using it and it works great. :-)
> >
> > I flipped down to ALSA 1.0.5a, rebuilt Myth against it, and
> > all my 720p problems were gone. I get excellent quality
> > playback of both 720p and 1080i content now, all using Xv.
>
> When you rebuilt it, did you do any optimization changes specifically
> for the Athlon platform?

Yes, I have my own derivatives of Axel's Myth rpms, which I built with
--target=athlon. However, it seems to make little or no difference over
building without that (i.e., just using the stock .i386.rpm).

> Are you using a stock kernel or customer
> build?

Built my own kernel off 2.6.7 kernel.org sources with the 2.6.6 pcHDTV version
1.3 patches, and Ulmo's patches on top of that.

--
Jarod C. Wilson, RHCE
jcw@wilsonet.com

Got a question? Read this first...
http://catb.org/~esr/faqs/smart-questions.html
MythTV, Fedora Core & ATrpms documentation:
http://wilsonet.com/mythtv/
MythTV Searchable Mailing List Archive
http://www.gossamer-threads.com/lists/mythtv/

On Monday 11 October 2004 09:58, Brandon Beattie wrote:
> On Mon, Oct 11, 2004 at 10:10:30AM -0600, John Patrick Poet wrote:
> > <snip>
> >
> > 5) Recording, Watching and Commercial flagging could not all be done at
> > the same time. That system was just too slow.
> > 6) Xv is better than XvMC -- if you have enough horsepower.
> >
> > John
>
> My experience has been with XV, I could commercial detect 1-2 shows if I
> was not de-interlacing on my 2.6Ghz. When using XVMC, I could commercial
> detect from 4-7 shows at once without much stuttering. I believe most
> of this stuttering was more data over the bus rather than CPU because I
> would see pauses even when the CPU was not maxed. Now that myth lets
> you pick the # of shows to detect/transcode at once and I set it to 1,
> stuttering has vanished. But again, if you're running backend and
> frontend on the same system you are likely not going to be able to run
> XV without stuttering, unless it's a P4 3.4 or faster. You do give up
> some quality with XvMC but not much, and I recommend it for anyone who
> is running a backend on a frontend.

~2.2GHz proc churning along nicely here w/Xv (Athlon XP 3200+, 400MHz FSB,
dual-channel DDR-400 RAM, GeForce FX 5200, nForce2 motherboard). Combined
frontend/slave backend, does all commercial-detection on HD content without a
stutter while playing back 720p or 1080i without a flaw. OSD fades aren't
always perfectly smooth when commercial-detection is also running, but
acceptable.

I've only got one card, so I'm not taxing the PCI bus nearly as much as
Brandon, but I'm definitely looking to add a pcHDTV HD-3000, especially if I
can manage to get some of my cable HD channels with it in addition to the OTA
I get right now...

--
Jarod C. Wilson, RHCE
jcw@wilsonet.com

Got a question? Read this first...
http://catb.org/~esr/faqs/smart-questions.html
MythTV, Fedora Core & ATrpms documentation:
http://wilsonet.com/mythtv/
MythTV Searchable Mailing List Archive
http://www.gossamer-threads.com/lists/mythtv/

On Sunday 10 October 2004 23:21, Joe Barnhart wrote:
> On the other hand, I just want to get a stable working
> system, so maybe I'll trash the mobo and get an
> Athlon64 and let someone else worry about XvMC.

There are still some issues w/Athlon64, I'd recommend a fast P4 if you really
want to go trouble-free. (There was a post by Kyle Rose about excessively
high cpu usage on a dual Opteron system in 32-bit mode just recently, and
only 34% idle when running in 64-bit mode, while my Athlon XP 3200+ regularly
sits at 30% idle).

> Don't
> take this wrong, but in a way I'm sorry you fixed your
> problem.  ;-)  It was nice having a lead blocker who
> is so well known in the Myth community.

:-p

> As a
> newcomer, I don't expect to be taken as seriously.

Perhaps not as seriously (being a vet does have its privileges, I guess ;-),
but I think you're definitely being taken seriously. Its just very hard for
anyone else to do anything about it when they can't reproduce the behavior
you're seeing (or, in my case, I thought we had the same problem, and my
fixes aren't working for you). :-(

Perhaps everything is good on the hardware side now, and you have some
hardware-level issues to overcome, as Brandon indicated could be the case.
What sort of cache and bus speed is that 2800 running with?

--
Jarod C. Wilson, RHCE
jcw@wilsonet.com

Got a question? Read this first...
http://catb.org/~esr/faqs/smart-questions.html
MythTV, Fedora Core & ATrpms documentation:
http://wilsonet.com/mythtv/
MythTV Searchable Mailing List Archive
http://www.gossamer-threads.com/lists/mythtv/

On Mon, 11 Oct 2004, Brandon Beattie wrote:

> I probably should open a new thread for this but anyway.. I took a
> little trip over to pcHDTV and took a fresh box (except the new hd-3000
> driver was working on this already) and installed Mythtv. Nothing odd
> came up at all. Myth started right up, live-tv and recording. TV
> signals also worked, which the dev from pcHDTV didn't think would work.
> The HD-3000 uses Video4linux 2, and everything but the signal check
> should work using regular v4l. .. They're going to see why signal
> checking does work. :) So no need to worry about support for the
> HD-3000, it works right off.


What kernel/s is/are supported for the HD-3000 so far? Do they have a
2.6.9 patch ready?

Thanks,

John

On Mon, Oct 11, 2004 at 04:20:26PM -0600, John Patrick Poet wrote:
> On Mon, 11 Oct 2004, Brandon Beattie wrote:
>
> > I probably should open a new thread for this but anyway.. I took a
> > little trip over to pcHDTV and took a fresh box (except the new hd-3000
> > driver was working on this already) and installed Mythtv. Nothing odd
> > came up at all. Myth started right up, live-tv and recording. TV
> > signals also worked, which the dev from pcHDTV didn't think would work.
> > The HD-3000 uses Video4linux 2, and everything but the signal check
> > should work using regular v4l. .. They're going to see why signal
> > checking does work. :) So no need to worry about support for the
> > HD-3000, it works right off.
>
>
> What kernel/s is/are supported for the HD-3000 so far? Do they have a
> 2.6.9 patch ready?
>
> Thanks,
>
> John
>

The box I worked with was 2.6.3 and 2.6.7. I don't believe 2.6.9 has
been attempted.

--Brandon

I had pretty much all the problems you described but I knocked them off one
by one on an AMD64 3400. The one I can't get rid of is signal strength... I
can only get into the high 80's on one channel at a time with a highly
directional antenna (the silver sensor). If I move it around I can get just
about any channel in my area but I can't be doing that all the time. For the
most part I just leave it on the WB and use cat /dev/video32 when I want to
record Smallville with xine as a player (much better than mythtv). Otherwise
the cable companies HD PVR gets it for me.

Mythtv works great with my pvr250's though =)

On Oct 11, 2004, at 18:13, jack wrote:

> I had pretty much all the problems you described but I knocked them
> off one
> by one on an AMD64 3400. The one I can't get rid of is signal
> strength... I
> can only get into the high 80's on one channel at a time with a highly
> directional antenna (the silver sensor).

You don't need a high 80s signal to get a good recording though. My
*strongest* signals (I live about 20 miles outside Seattle) are in the
high 60s. All the high 60s recordings are perfect. A few of my stations
come in with signals in the low 50s, and while I get the occasional
failed recording due to lack of signal lock, when they do record, 99%
of the video is perfectly fine (every once in a blue moon, there's some
pixelization in the video stream where I presume the signal dropped a
bit).

> Mythtv works great with my pvr250's though =)

Yeah, stability is a little better there, but there's no comparison in
picture quality. I record anything and everything I can in HD now, and
I'm still amazed at how BAD standard-def video looks after watching a
few programs in HD. ;-)

--
Jarod C. Wilson, RHCE
jcw@wilsonet.com

Got a question? Read this first...
http://catb.org/~esr/faqs/smart-questions.html
MythTV, Fedora Core & ATrpms documentation:
http://wilsonet.com/mythtv/
MythTV Searchable Mailing List Archive
http://www.gossamer-threads.com/lists/mythtv/

> -----Original Message-----
> From: mythtv-users-bounces@mythtv.org [mailto:mythtv-users-
> bounces@mythtv.org] On Behalf Of Jarod Wilson
> Sent: Monday, October 11, 2004 9:26 PM
> To: Discussion about mythtv
> Subject: Re: [mythtv-users] HDTV on Myth -- is it a "myth?"
>
> On Oct 11, 2004, at 18:13, jack wrote:
>
> > I had pretty much all the problems you described but I knocked them
> > off one
> > by one on an AMD64 3400. The one I can't get rid of is signal
> > strength... I
> > can only get into the high 80's on one channel at a time with a highly
> > directional antenna (the silver sensor).
>
> You don't need a high 80s signal to get a good recording though. My
> *strongest* signals (I live about 20 miles outside Seattle) are in the
> high 60s. All the high 60s recordings are perfect. A few of my stations
> come in with signals in the low 50s, and while I get the occasional
> failed recording due to lack of signal lock, when they do record, 99%
> of the video is perfectly fine (every once in a blue moon, there's some
> pixelization in the video stream where I presume the signal dropped a
> bit).
>

Really?! I thought the signal quality was what was holding me back. Gonna
have to go back and investigate more, but I am almost positive if the signal
strength isn't 85 or better mythtv just craps out early on in the stream. I
am almost 50 miles away from the tower, for some reason I don't think my
high 85 equals one of your low 60's =p

On Tue, 12 Oct 2004, jack wrote:

> > -----Original Message-----
> > From: mythtv-users-bounces@mythtv.org [mailto:mythtv-users-
> > bounces@mythtv.org] On Behalf Of Jarod Wilson
> > Sent: Monday, October 11, 2004 9:26 PM
> > To: Discussion about mythtv
> > Subject: Re: [mythtv-users] HDTV on Myth -- is it a "myth?"
> >
> > On Oct 11, 2004, at 18:13, jack wrote:
> >
> > > I had pretty much all the problems you described but I knocked them
> > > off one
> > > by one on an AMD64 3400. The one I can't get rid of is signal
> > > strength... I
> > > can only get into the high 80's on one channel at a time with a highly
> > > directional antenna (the silver sensor).
> >
> > You don't need a high 80s signal to get a good recording though. My
> > *strongest* signals (I live about 20 miles outside Seattle) are in the
> > high 60s. All the high 60s recordings are perfect. A few of my stations
> > come in with signals in the low 50s, and while I get the occasional
> > failed recording due to lack of signal lock, when they do record, 99%
> > of the video is perfectly fine (every once in a blue moon, there's some
> > pixelization in the video stream where I presume the signal dropped a
> > bit).
> >
>
> Really?! I thought the signal quality was what was holding me back. Gonna
> have to go back and investigate more, but I am almost positive if the signal
> strength isn't 85 or better mythtv just craps out early on in the stream. I
> am almost 50 miles away from the tower, for some reason I don't think my
> high 85 equals one of your low 60's =p
>

My *best* signal strength is somewhere arround 89. Most of my stations fall
between 73 and 85. In general, all but one is watchable with little
pixelization. I am 9 miles from the towers, with direct line-of-sight.

The one station that gives me problems, admits they are broadcasting at less
the 1/4 power. They claim they have to build a whole new tower before they
can up the power.

You can actually get pixelization from "other" factors. If your hard disk
is too slow, it may not be able to feed the data to mythfrontend fast
enough for it to decode and display the entire frame. Or maybe the data is
not getting written to your hard drive fast enough, and it is loosing data.

I use my mythbackend box for lots of other tasks. If I get too many going
at once, I start seeing pixelization issues.

John

On Mon, Oct 11, 2004 at 09:26:04PM -0700, Jarod Wilson wrote:
> On Oct 11, 2004, at 18:13, jack wrote:
>
> You don't need a high 80s signal to get a good recording though. My
> *strongest* signals (I live about 20 miles outside Seattle) are in the
> high 60s. All the high 60s recordings are perfect. A few of my stations
> come in with signals in the low 50s, and while I get the occasional
> failed recording due to lack of signal lock, when they do record, 99%
> of the video is perfectly fine (every once in a blue moon, there's some
> pixelization in the video stream where I presume the signal dropped a
> bit).

I'm about 18 miles from the tower and all my signals are 85%-93%. I also
have a giant oak tree with branches that are possibly high enough to
block some signal. I also run through 150' of RG6 cable. I don't
use an amplifier though. The antenna I use is a $20 yagi I bought from
radio shack. The biggest help I've had is keeping the antenna outdoors
and using cell phones to watch signal as I moved the antenna. I do get
some video and audio corruption (Possibly the tree) at times. I do get
enough during winter that it may not be the tree. I may be getting quite
a bit of multipath. Another good tip is get your antenna as high and
stable (wind) as possible. Never use an antenna indoors. One sheet of
flywood in my attice was enough to take my signal down to 20%.
You may also want to try an amplifier, but pay attention to how much
noise it may add and what DB it adds. I have seen some that add 10db for
$50 and others that add 25db for $15. In this case, the signal to noise
ratio was better on the $15 one too. (I found really no difference in
signal when I tried mine, and I did because 150' of RG6 is a lot of
cable and usually drops a few DB.)

As for hard drive access causing the audio/video corruption I doubt it,
because I've rewound and watched the segment again and it is still
there.

--Brandon

On Tue, 12 Oct 2004, Brandon Beattie wrote:

> As for hard drive access causing the audio/video corruption I doubt it,
> because I've rewound and watched the segment again and it is still
> there.


I have watched a show just a few minutes behind as it was recording. My
backend was doing lot's of other tasks and I was seeing pixelization. I
could rewind, and see the exact same pixelization.

I shut down those other tasks, and the pixelization went away. I could
rewind back to the begining and see the pixelization, but once I caught up
to the point where I shut down the other processes, the corruption was gone.

I never see any errors in the mythbackend log indicating it could not write
to the disk fast enough, but it sure looks like that can happen. Maybe it
is not a problem with myth writing the file, but with myth reading from the
HD-2000 buffer fast enough? Maybe the HD-2000 driver needs a larger buffer?

John

On Tue, Oct 12, 2004 at 10:45:10AM -0600, John Patrick Poet wrote:
>
> On Tue, 12 Oct 2004, Brandon Beattie wrote:
>
> > As for hard drive access causing the audio/video corruption I doubt it,
> > because I've rewound and watched the segment again and it is still
> > there.
>
>
> I have watched a show just a few minutes behind as it was recording. My
> backend was doing lot's of other tasks and I was seeing pixelization. I
> could rewind, and see the exact same pixelization.
>
> I shut down those other tasks, and the pixelization went away. I could
> rewind back to the begining and see the pixelization, but once I caught up
> to the point where I shut down the other processes, the corruption was gone.
>
> I never see any errors in the mythbackend log indicating it could not write
> to the disk fast enough, but it sure looks like that can happen. Maybe it
> is not a problem with myth writing the file, but with myth reading from the
> HD-2000 buffer fast enough? Maybe the HD-2000 driver needs a larger buffer?
>
> John

I've wondered about this for some time, but have not had time to prove
it. I also thought that the kernel should take care of holding the data
in memory until it has the time to write it to disk? Am I wrong with
this thought? Adding a buffer may be helpful though.

--Brandon

> _______________________________________________
> mythtv-users mailing list
> mythtv-users@mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users


--

On Tuesday 12 October 2004 07:48, jack wrote:
> > -----Original Message-----
> > From: Jarod Wilson
> >
> > On Oct 11, 2004, at 18:13, jack wrote:
> > > I had pretty much all the problems you described but I knocked them
> > > off one
> > > by one on an AMD64 3400. The one I can't get rid of is signal
> > > strength... I
> > > can only get into the high 80's on one channel at a time with a highly
> > > directional antenna (the silver sensor).
> >
> > You don't need a high 80s signal to get a good recording though. My
> > *strongest* signals (I live about 20 miles outside Seattle) are in the
> > high 60s. All the high 60s recordings are perfect. A few of my stations
> > come in with signals in the low 50s, and while I get the occasional
> > failed recording due to lack of signal lock, when they do record, 99%
> > of the video is perfectly fine (every once in a blue moon, there's some
> > pixelization in the video stream where I presume the signal dropped a
> > bit).
>
> Really?! I thought the signal quality was what was holding me back. Gonna
> have to go back and investigate more, but I am almost positive if the
> signal strength isn't 85 or better mythtv just craps out early on in the
> stream.

Huh. I wish I could get 85s... But I'm ecstatic when my high 60s stations
occasionally come in over 70. The local NBC station is really pissing me off,
they're right on the border of recordability during prime-time (signal
fluctuates between 47 and 53 usually), so I keep missing shows when the
signal is a touch low at program start time (the recording never starts). Fox
also sits right on that threshold, which is making watching the MLB playoffs
a bit annoying, but after a few tries (in Live TV mode), I can usually get it
to lock on.

> I am almost 50 miles away from the tower, for some reason I don't
> think my high 85 equals one of your low 60's =p

Dunno. I should add that 20 miles outside Seattle also includes hills, very
large trees and spotty weather that impede my signal, so distance isn't the
only thing to factor in. I'd take 50 miles and clean line of sight over what
I've got. :-) I have a massive directional yagi antenna on my rooftop (w/a
10ft mast extension), about 100ft of RG6-QS and a decent signal amp, and
still rarely see any station bump over 70. I still have some excess cable to
cut out of the picture (I moved my TV, need to drill a new hole in the
house), and I'm now investigating a better quality signal amp to get me over
the 50 hump w/NBC and Fox...

Judging from the issues Kyle Rose was having getting HD to work on his dual
Opteron, maybe you have some other issues w/the Athlon64 there?... What is
processor usage like while playing back a stream?

--
Jarod C. Wilson, RHCE
jcw@wilsonet.com

Got a question? Read this first...
http://catb.org/~esr/faqs/smart-questions.html
MythTV, Fedora Core & ATrpms documentation:
http://wilsonet.com/mythtv/
MythTV Searchable Mailing List Archive
http://www.gossamer-threads.com/lists/mythtv/

> You don't need a high 80s signal to get a good recording though. My
> *strongest* signals (I live about 20 miles outside Seattle) are in the
> high 60s. All the high 60s recordings are perfect. A few of my stations
> come in with signals in the low 50s, and while I get the occasional
> failed recording due to lack of signal lock, when they do record, 99%
> of the video is perfectly fine (every once in a blue moon, there's some
> pixelization in the video stream where I presume the signal dropped a
> bit).

I wrote an entry in the pchdtv forum on signal strength and how the
green and red lights on the back of the pcHDTV card relate.

http://pchdtv.com/forum/viewtopic.php?t=72&highlight=lights

I live in Rochester NY. As of a few weeks ago when Fox came online
all the local stations are broadcasting digitally. CBS is the only one
left broadcasting in 480p. Not all the content is HD yet, some of it
is upscaled, but it's getting better. The needed signal strength to
not have errors in the stream varies widely among the channels for me.
Fox "needs" the lowest signal only >50, non-coincidentally it's also
the lowest channel(frequency) at 28... next up is CBS requiring >65 or
so, at channel 45... ABC and NBC are 58 and 59.. I can't remember
which is which... They both require >85 to be decoded correctly....
So that driver is doing some crazyness... ( maybe just a simple
normalization by frequency is needed? )

The common indicator that tells me if I'm pulling in the channel no
matter what station is the lights. If I see any red at all, even a
blink here and there, that station is not going to come it. I believe
that the red light is linked to the error-correction of the ATSC chip,
if the error-correction fails, the red light gets a bit of juice. I
think there are plans to get the LED status out of the driver. For now
I might run some optical fiber to the coffee table so I have the ATSC
decode status close at hand!

Thanks for listening to me rank :) hope it helped.


--
Anthony Vito
anthony.vito@gmail.com

> Judging from the issues Kyle Rose was having getting HD to work on his dual
> Opteron, maybe you have some other issues w/the Athlon64 there?... What is
> processor usage like while playing back a stream?

FWIW, I need to examine this again: I was running a bad kernel when I
did my initial mythfrontend-on-AMD64 test. I am also now running all
packages from the gcc-3.4 repository, which might improve things.
I'll try to look at it more closely this evening.

Cheers,
Kyle

On Tuesday 12 October 2004 10:49, Brandon Beattie wrote:
> On Tue, Oct 12, 2004 at 10:45:10AM -0600, John Patrick Poet wrote:
> > On Tue, 12 Oct 2004, Brandon Beattie wrote:
> > > As for hard drive access causing the audio/video corruption I doubt it,
> > > because I've rewound and watched the segment again and it is still
> > > there.
> >
> > I have watched a show just a few minutes behind as it was recording. My
> > backend was doing lot's of other tasks and I was seeing pixelization. I
> > could rewind, and see the exact same pixelization.
> >
> > I shut down those other tasks, and the pixelization went away. I could
> > rewind back to the begining and see the pixelization, but once I caught
> > up to the point where I shut down the other processes, the corruption was
> > gone.
> >
> > I never see any errors in the mythbackend log indicating it could not
> > write to the disk fast enough, but it sure looks like that can happen.
> > Maybe it is not a problem with myth writing the file, but with myth
> > reading from the HD-2000 buffer fast enough? Maybe the HD-2000 driver
> > needs a larger buffer?
> >
> > John
>
> I've wondered about this for some time, but have not had time to prove
> it. I also thought that the kernel should take care of holding the data
> in memory until it has the time to write it to disk? Am I wrong with
> this thought? Adding a buffer may be helpful though.

This would appear to be one of the things the 1.4ulmo patch on top of the
pcHDTV 1.3 patch does. David George's words in the "HD-3000 and 2.6.9" thread
(forked off this one) about the 1.4ulmo patch:

"There appears to only be three types of changes (a larger buffer, different
timeouts, and true pre-eq signal strength)."

--
Jarod C. Wilson, RHCE
jcw@wilsonet.com

Got a question? Read this first...
http://catb.org/~esr/faqs/smart-questions.html
MythTV, Fedora Core & ATrpms documentation:
http://wilsonet.com/mythtv/
MythTV Searchable Mailing List Archive
http://www.gossamer-threads.com/lists/mythtv/

On Tuesday 12 October 2004 11:16, Anthony Vito wrote:
> > You don't need a high 80s signal to get a good recording though. My
> > *strongest* signals (I live about 20 miles outside Seattle) are in the
> > high 60s. All the high 60s recordings are perfect. A few of my stations
> > come in with signals in the low 50s, and while I get the occasional
> > failed recording due to lack of signal lock, when they do record, 99%
> > of the video is perfectly fine (every once in a blue moon, there's some
> > pixelization in the video stream where I presume the signal dropped a
> > bit).
>
> I wrote an entry in the pchdtv forum on signal strength and how the
> green and red lights on the back of the pcHDTV card relate.
>
> http://pchdtv.com/forum/viewtopic.php?t=72&highlight=lights

Good stuff, I'll have to peek at my card a bit. Unfortunately, I have a
rooftop antenna that I have to manually adjust, so its a bit hard for me to
correlate antenna position w/lights without a LOT of up and down, but I'll
have to see what I can see...

> I live in Rochester NY. As of a few weeks ago when Fox came online
> all the local stations are broadcasting digitally. CBS is the only one
> left broadcasting in 480p. Not all the content is HD yet, some of it
> is upscaled, but it's getting better. The needed signal strength to
> not have errors in the stream varies widely among the channels for me.
> Fox "needs" the lowest signal only >50, non-coincidentally it's also
> the lowest channel(frequency) at 28... next up is CBS requiring >65 or
> so, at channel 45... ABC and NBC are 58 and 59.. I can't remember
> which is which... They both require >85 to be decoded correctly....
> So that driver is doing some crazyness... ( maybe just a simple
> normalization by frequency is needed? )

Interesting. Fox is the lowest channel here also (18), and works fine in Myth
when it can get a lock (i.e., when the signal is over 50 -- might even work
at lower thresholds if I set the threshold even lower manually in the db,
since the slider only goes down to 50). However, NBC is the highest channel
here (48), and also works fine at 50. ABC, CBS, WB and PBS all come in around
60-70, no problems with any of them.

Are you running a straight-up pcHDTV 1.3 driver, or are you using the 1.4ulmo
patches also?

> The common indicator that tells me if I'm pulling in the channel no
> matter what station is the lights. If I see any red at all, even a
> blink here and there, that station is not going to come it. I believe
> that the red light is linked to the error-correction of the ATSC chip,
> if the error-correction fails, the red light gets a bit of juice.

I'm thinking maybe I can use this info to determine actual levels where my
problem channels (NBC and Fox) are actually non-viable... Maybe they're fine
even at 45, and I can safely mod my database for that minimum level...

> I think there are plans to get the LED status out of the driver.

Cool.

> For now
> I might run some optical fiber to the coffee table so I have the ATSC
> decode status close at hand!

:-p

> Thanks for listening to me rank :) hope it helped.

Most definitely.

--
Jarod C. Wilson, RHCE
jcw@wilsonet.com

Got a question? Read this first...
http://catb.org/~esr/faqs/smart-questions.html
MythTV, Fedora Core & ATrpms documentation:
http://wilsonet.com/mythtv/
MythTV Searchable Mailing List Archive
http://www.gossamer-threads.com/lists/mythtv/

Let me say first that all of my previous comments where based on using the
original 2.6.6 pchdtv patch on a 2.6.7 kernel and mythtv cvs as of a couple
months ago. I just stopped using it (hdtv in mythtv) because it was largely
worthless to me. Playback never needed much cpu (60-70) even with 1080i on
my 720p dlp but it crashed constantly and the audio was so flakey as to be
useless.


All of the comments on these threads made me want to go and try it again
though, plus I had no idea about version 1.3 of the pchdtv drivers. Grabbed
those, applied them to a fresh copy of 2.6.7 and hot damn I was in business.
I could switch between cbs, wb, nbc, abc, pbs and fox with out a problem
once I got the antenna to show at least 70 signal strength for all of them.
I told it to record a whale special on pbs which it did. I tried playing it
back and it still worked. Not only did it work, it worked beautifully. I
couldn't believe it. I couldn't even crash it by fast forwarding and
rewinding repeatedly as fast as I could. I need to see what happens when it
starts recording some other shows on different channels but I am incredibly
impressed so far on the progress made. I could never watch the WB before, no
problem so far, will see how it does tomorrow night with Smallville.

Wondering if it is worth it to apply the Ulmo1.4 patch, I don't care about
ntsc at all.

> -----Original Message-----
> From: mythtv-users-bounces@mythtv.org [mailto:mythtv-users-
> bounces@mythtv.org] On Behalf Of Jarod Wilson
> Sent: Tuesday, October 12, 2004 11:02 AM
> To: Discussion about mythtv
> Subject: Re: [mythtv-users] HDTV on Myth -- is it a "myth?"
>
> On Tuesday 12 October 2004 07:48, jack wrote:
> > > -----Original Message-----
> > > From: Jarod Wilson
> > >
> > > On Oct 11, 2004, at 18:13, jack wrote:
> > > > I had pretty much all the problems you described but I knocked them
> > > > off one
> > > > by one on an AMD64 3400. The one I can't get rid of is signal
> > > > strength... I
> > > > can only get into the high 80's on one channel at a time with a
> highly
> > > > directional antenna (the silver sensor).
> > >
> > > You don't need a high 80s signal to get a good recording though. My
> > > *strongest* signals (I live about 20 miles outside Seattle) are in the
> > > high 60s. All the high 60s recordings are perfect. A few of my
> stations
> > > come in with signals in the low 50s, and while I get the occasional
> > > failed recording due to lack of signal lock, when they do record, 99%
> > > of the video is perfectly fine (every once in a blue moon, there's
> some
> > > pixelization in the video stream where I presume the signal dropped a
> > > bit).
> >
> > Really?! I thought the signal quality was what was holding me back.
> Gonna
> > have to go back and investigate more, but I am almost positive if the
> > signal strength isn't 85 or better mythtv just craps out early on in the
> > stream.
>
> Huh. I wish I could get 85s... But I'm ecstatic when my high 60s stations
> occasionally come in over 70. The local NBC station is really pissing me
> off,
> they're right on the border of recordability during prime-time (signal
> fluctuates between 47 and 53 usually), so I keep missing shows when the
> signal is a touch low at program start time (the recording never starts).
> Fox
> also sits right on that threshold, which is making watching the MLB
> playoffs
> a bit annoying, but after a few tries (in Live TV mode), I can usually get
> it
> to lock on.
>
> > I am almost 50 miles away from the tower, for some reason I don't
> > think my high 85 equals one of your low 60's =p
>
> Dunno. I should add that 20 miles outside Seattle also includes hills,
> very
> large trees and spotty weather that impede my signal, so distance isn't
> the
> only thing to factor in. I'd take 50 miles and clean line of sight over
> what
> I've got. :-) I have a massive directional yagi antenna on my rooftop (w/a
> 10ft mast extension), about 100ft of RG6-QS and a decent signal amp, and
> still rarely see any station bump over 70. I still have some excess cable
> to
> cut out of the picture (I moved my TV, need to drill a new hole in the
> house), and I'm now investigating a better quality signal amp to get me
> over
> the 50 hump w/NBC and Fox...
>
> Judging from the issues Kyle Rose was having getting HD to work on his
> dual
> Opteron, maybe you have some other issues w/the Athlon64 there?... What is
> processor usage like while playing back a stream?
>
> --
> Jarod C. Wilson, RHCE
> jcw@wilsonet.com
>
> Got a question? Read this first...
> http://catb.org/~esr/faqs/smart-questions.html
> MythTV, Fedora Core & ATrpms documentation:
> http://wilsonet.com/mythtv/
> MythTV Searchable Mailing List Archive
> http://www.gossamer-threads.com/lists/mythtv/

Jarod Wrote:
> here (48), and also works fine at 50. ABC, CBS, WB and PBS all come in around
> 60-70, no problems with any of them.

No WB here :'( All I want to watch is gilmore girls! ( yes, my only
source of content is OTA digital, no cable, no NTSC. )

> Are you running a straight-up pcHDTV 1.3 driver, or are you using the 1.4ulmo
> patches also?

I have to give credit where credit is due. I use the 2.6.7 patch and
videodev.h found here.

http://www.nop.org/inkling/dtv/

This is where I read the LED status being in the driver. He patched
it to be feed out with the signal strength. Then his pchdtvr program
picks it up. Nice program BTW. He claims he doesn't use Myth, oh well.
I patched this against the 2.6.7 kernel and have had great success....
No sure it really differs much from the 2.6.6 patch on pchdtv.com
functionally, ( diff between them spits out a lot )

I have not looked at the 1.4Ulmo patches. I wasn't aware they existed
yet. I'll put it on my super long TODO list.


--
Anthony Vito
anthony.vito@gmail.com

On Tue, 12 Oct 2004 11:49:37 -0600, Brandon Beattie
<brandon+myth@linuxis.us> wrote:
>
>
> On Tue, Oct 12, 2004 at 10:45:10AM -0600, John Patrick Poet wrote:
> >
> > On Tue, 12 Oct 2004, Brandon Beattie wrote:
> >
> > > As for hard drive access causing the audio/video corruption I doubt it,
> > > because I've rewound and watched the segment again and it is still
> > > there.
> >
> >
> > I have watched a show just a few minutes behind as it was recording. My
> > backend was doing lot's of other tasks and I was seeing pixelization. I
> > could rewind, and see the exact same pixelization.
> >
> > I shut down those other tasks, and the pixelization went away. I could
> > rewind back to the begining and see the pixelization, but once I caught up
> > to the point where I shut down the other processes, the corruption was gone.
> >
> > I never see any errors in the mythbackend log indicating it could not write
> > to the disk fast enough, but it sure looks like that can happen. Maybe it
> > is not a problem with myth writing the file, but with myth reading from the
> > HD-2000 buffer fast enough? Maybe the HD-2000 driver needs a larger buffer?
> >
> > John
>
> I've wondered about this for some time, but have not had time to prove
> it. I also thought that the kernel should take care of holding the data
> in memory until it has the time to write it to disk? Am I wrong with
> this thought? Adding a buffer may be helpful though.

The data *is* buffered both by Myth and the filesystem (if you're
using a decent one). In fact the buffering in Myth was recently
optimized to reduce the disk io for HDTV folks.

On Tue, 12 Oct 2004, Donavan Stanley wrote:

> On Tue, 12 Oct 2004 11:49:37 -0600, Brandon Beattie
> <brandon+myth@linuxis.us> wrote:
> >
> >
> > On Tue, Oct 12, 2004 at 10:45:10AM -0600, John Patrick Poet wrote:
> > >
> > > On Tue, 12 Oct 2004, Brandon Beattie wrote:
> > >
> > > > As for hard drive access causing the audio/video corruption I doubt it,
> > > > because I've rewound and watched the segment again and it is still
> > > > there.
> > >
> > >
> > > I have watched a show just a few minutes behind as it was recording. My
> > > backend was doing lot's of other tasks and I was seeing pixelization. I
> > > could rewind, and see the exact same pixelization.
> > >
> > > I shut down those other tasks, and the pixelization went away. I could
> > > rewind back to the begining and see the pixelization, but once I caught up
> > > to the point where I shut down the other processes, the corruption was gone.
> > >
> > > I never see any errors in the mythbackend log indicating it could not write
> > > to the disk fast enough, but it sure looks like that can happen. Maybe it
> > > is not a problem with myth writing the file, but with myth reading from the
> > > HD-2000 buffer fast enough? Maybe the HD-2000 driver needs a larger buffer?
> > >
> > > John
> >
> > I've wondered about this for some time, but have not had time to prove
> > it. I also thought that the kernel should take care of holding the data
> > in memory until it has the time to write it to disk? Am I wrong with
> > this thought? Adding a buffer may be helpful though.
>
> The data *is* buffered both by Myth and the filesystem (if you're
> using a decent one). In fact the buffering in Myth was recently
> optimized to reduce the disk io for HDTV folks.


Yes, and the new optimizations are effective. Before I actually would
occasionally see messages in the backend log indicating a problem writing
data to the disk.

I have to really *load up* the machine before I have any problems. It would
just be nice if the system could still work flawlessly even with such a
load. If there is something that can be fixed, I am guessing it is in the
HD-2000 driver.

John

On Tuesday 12 October 2004 12:58, Anthony Vito wrote:
> Jarod Wrote:
> > here (48), and also works fine at 50. ABC, CBS, WB and PBS all come in
> > around 60-70, no problems with any of them.
>
> No WB here :'( All I want to watch is gilmore girls! ( yes, my only
> source of content is OTA digital, no cable, no NTSC. )

Heh. The only thing I don't get in HD now is UPN, but I think I have slight
interest in maybe one show on that network...

> > Are you running a straight-up pcHDTV 1.3 driver, or are you using the
> > 1.4ulmo patches also?
>
> I have to give credit where credit is due. I use the 2.6.7 patch and
> videodev.h found here.
>
> http://www.nop.org/inkling/dtv/

Huh, cool.

> This is where I read the LED status being in the driver. He patched
> it to be feed out with the signal strength. Then his pchdtvr program
> picks it up. Nice program BTW. He claims he doesn't use Myth, oh well.
> I patched this against the 2.6.7 kernel and have had great success....
> No sure it really differs much from the 2.6.6 patch on pchdtv.com
> functionally, ( diff between them spits out a lot )

The documentation on that site seems to indicate the LED status monitoring is
the only significant addition. Your mention of it got me thinking about
looking at the lights on my card while trying to tune NBC and FOX (both right
around 50). I took a look at the lights while running the signal program, and
with readings in the 45-52 range, the green light was locked in solid, so I
went ahead and manually edited my db to set the low-end threshold to 45
(since the slider only goes down to 50), and wouldn't you know it, even with
signal strength fluctuating between 45-47 (on FOX), I can watch them just
fine.

--
Jarod C. Wilson, RHCE
jcw@wilsonet.com

Got a question? Read this first...
http://catb.org/~esr/faqs/smart-questions.html
MythTV, Fedora Core & ATrpms documentation:
http://wilsonet.com/mythtv/
MythTV Searchable Mailing List Archive
http://www.gossamer-threads.com/lists/mythtv/