Mailing List Archive

I sorta have it running... I have a master be with 2 pvr 250s and one
slave be with 1 pchdtv. The pchdtv is a little flaky (playing 720p)
with a 2.6 ghz p4. It's not bad, it actually looks good, but it does
crash a lot. I don't know yet while it crashes, but I'm working on
it... Should we have a dedicated HDTV with myth support group? :)

I haven't seen any new patches on the pchdtv since the inkling ones,
so I believe I'm running latest and greatest (no XVMC).

Art


On Sat, 9 Oct 2004 12:29:43 -0700 (PDT), Joe Barnhart
<joebarnhart@yahoo.com> wrote:
> I guess my expectations were too high. I've been
> watching HD on my combo satellite/terrestrial receiver
> a couple of years now, and I expected Myth to be able
> to record and play signals equivalent to what I see on
> "normal" HDTV (terrestrial) broadcasts. What I
> actually get on Myth is slow, jerky, stuttering
> playback that often hangs the frontend with something
> as simple as skipping forward or backward, or any
> activity that pops up the on-screen display.
>
> When I am able to get streams to play, the video is
> marred by scaling artifacts and weird interactions
> between interlaced and non-interlaced video streams.
> For instance, a 1080i source played on a 1080i output
> device shows horrible jaggies.
> (http://www.pbase.com/jbarnhart/image/34300421.jpg)
> The same stream played through the "bob" deinterlacer
> looks better (but still not up to the level of the
> receiver).
>
> I tried to build a system able to handle this task,
> with an Athlon 2800+ processor and a GeForce4 MX video
> card, but the system is unable to cope with my
> 1920x1080i output device. The Xv software player is
> unable to keep up with task of decoding MPEG at this
> rate, and XvMC simply doesn't work reliably enough to
> watch an entire show without hanging mythfrontend.
>
> Were my expectations too high? Is this a matter of
> "rough edges" soon to be smoothed out? Or is the
> current state of Myth unable to handle HDTV (at
> 1920x1080i) for anyone? Should I dump my system and
> buy new Intel Pentium hardware? Or just go back to
> the combo receiver and wait another year for the
> software to catch up?
>
> I would love to hear from anyone who is playing
> streams at 1920x1080i with no stutters or poor video
> quality. What kind of system are you using? Xv or
> XvMC? Intel or AMD? Video card?
>
>
> _______________________________
> Do you Yahoo!?
> Declare Yourself - Register online to vote today!
> http://vote.yahoo.com
>
>
> _______________________________________________
> mythtv-users mailing list
> mythtv-users@mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
>
>
>

I have a PCHDTV card in my master backend and record quite a bit of
off-air HDTV material. Playback is done on a P4 3.2E, Nvidia FX5500, all
on an Intel D865GLC mobo with 8X AGP, using XV. I'm using FC2, with a
vanilla 2.6.7 kernel, compiled for SMP and SMT (Hyperthreading). I never
see any artifacts or stuttering on this setup. Picture quality is excellent
and as well as sound quality.


-----Original Message-----
From: mythtv-users-bounces@mythtv.org
[mailto:mythtv-users-bounces@mythtv.org] On Behalf Of Joe Barnhart
Sent: Saturday, October 09, 2004 12:30 PM
To: mythtv-users@mythtv.org
Subject: [mythtv-users] HDTV on Myth -- is it a "myth?"

I guess my expectations were too high. I've been
watching HD on my combo satellite/terrestrial receiver
a couple of years now, and I expected Myth to be able
to record and play signals equivalent to what I see on
"normal" HDTV (terrestrial) broadcasts. What I
actually get on Myth is slow, jerky, stuttering
playback that often hangs the frontend with something
as simple as skipping forward or backward, or any
activity that pops up the on-screen display.

When I am able to get streams to play, the video is
marred by scaling artifacts and weird interactions
between interlaced and non-interlaced video streams.
For instance, a 1080i source played on a 1080i output
device shows horrible jaggies.
(http://www.pbase.com/jbarnhart/image/34300421.jpg)
The same stream played through the "bob" deinterlacer
looks better (but still not up to the level of the
receiver).

I tried to build a system able to handle this task,
with an Athlon 2800+ processor and a GeForce4 MX video
card, but the system is unable to cope with my
1920x1080i output device. The Xv software player is
unable to keep up with task of decoding MPEG at this
rate, and XvMC simply doesn't work reliably enough to
watch an entire show without hanging mythfrontend.

Were my expectations too high? Is this a matter of
"rough edges" soon to be smoothed out? Or is the
current state of Myth unable to handle HDTV (at
1920x1080i) for anyone? Should I dump my system and
buy new Intel Pentium hardware? Or just go back to
the combo receiver and wait another year for the
software to catch up?

I would love to hear from anyone who is playing
streams at 1920x1080i with no stutters or poor video
quality. What kind of system are you using? Xv or
XvMC? Intel or AMD? Video card?



_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com

Joe Barnhart wrote:
> I would love to hear from anyone who is playing
> streams at 1920x1080i with no stutters or poor video
> quality. What kind of system are you using? Xv or
> XvMC? Intel or AMD? Video card?

Works quite well for me. P4, 2.8 GHz, OSS emulation on ALSA, no XvMC,
nVidia FX5200.

I submit that the reason this and other similar configurations work well
is that I made it so, since that's what I have. There are in the
neighborhood of 5 of us who have spent the last year or so sequentially
debugging, fixing, and submitting patches for problems we've
encountered. We do not have your hardware. We have not seen your
symptoms. You are the only one capable of debugging and fixing your
problems.

-Doug

--- Doug Larrick <doug@ties.org> wrote:

> Works quite well for me. P4, 2.8 GHz, OSS emulation
> on ALSA, no XvMC,
> nVidia FX5200.

Doug -- Are you outputting to a 1920x1080i device?
The reason I ask is because Xv won't keep up with this
resolution using an Athlon 2800. I also see severe
problems with 720p input streams. They play at half
speed, with unlistenable sound stuttering, with both
Xv and XvMC on my system.

Given the potential advantage of hardware-assisted
MPEG decoding, I'm rather surprised that few people
(and no developers?) are using XvMC.



_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com

Joe Barnhart wrote:
> Doug -- Are you outputting to a 1920x1080i device?

Yes. I can use either a 1920x1080i mode with no deinterlacing, or
1920x540p with bob deinterlacing; they look basically identical until
you activate a zoom mode (at which point bob looks better since the
interlaced mode is no longer line-for-line).

> I also see severe
> problems with 720p input streams. They play at half
> speed, with unlistenable sound stuttering, with both
> Xv and XvMC on my system.

Have you read the recent ALSA discussions on the -dev list?

> Given the potential advantage of hardware-assisted
> MPEG decoding, I'm rather surprised that few people
> (and no developers?) are using XvMC.

XvMC is a PITA because of the way it barely fits into the Myth video
output architecture. You can't apply filters; you have to deal with the
fact that there are fewer in-flight video buffers (frames); seeking is
more difficult because the decoder has to have all the reference frames
for non-I frames, etc. Software decoder is just more flexible.

-Doug

--- Doug Larrick <doug@ties.org> wrote:

> I can use either a 1920x1080i mode with no
> deinterlacing, or
> 1920x540p with bob deinterlacing; they look
> basically identical until
> you activate a zoom mode (at which point bob looks
> better since the
> interlaced mode is no longer line-for-line).

Hmm.. Doesn't something seem fundamentally wrong about
this? Why should 1920x540 look the same as 1920x1080?
I presume you looked at the screen pic I posted of my
setup playing (XvMC) 1920x1080i w/o deinterlacing.
It's horrible.
(http://www.pbase.com/jbarnhart/image/34300421.jpg)

> Have you read the recent ALSA discussions on the
> -dev list?

Yes. I downleveled ALSA to 1.0.5 with no change in
symptoms. I'm outputting AC3 via optical out. Oddly
enough, if I "hide" my sound output device I can get
Xv to play the 720p stream at full speed with no
sound. XvMC still runs at half-speed, however, even
with no sound.

> XvMC is a PITA because of the way it barely fits
> into the Myth video
> output architecture.

I have not found any development docs which hint at
this architecture. I'm not afraid of C++, but it makes
it a little difficult to contribute to the project
when the only documentation I can find is the source
code. I just lack the time to invest to figure out
the architecture on my own.

> You can't apply filters; you
> have to deal with the
> fact that there are fewer in-flight video buffers
> (frames); seeking is
> more difficult because the decoder has to have all
> the reference frames
> for non-I frames, etc. Software decoder is just
> more flexible.

I think my needs are very simple. I have an output
device that is locked to 1080i. I want to play 1080i
streams unmodified to the output device. 720p streams
will have to be rescaled to 1080i on playback, and so
will 480i or 480p. I just want to view recorded TV
programs and DVDs. If the video processing does the
"right thing" there should be no need for filtering,
right?

I have noticed that my "myth" question has not
received a flood of messages like "I'm using it and it
works great." Jarod and I are running Athlon systems
with mucho trouble, and I've had responses from three
Pentium users (yourself included). Of the P4 users,
two are working fine and one is not. I guess just not
many people are using Myth with HDTV monitors yet.
>From the breathless MythTV promotion by EFF
(http://www.eff.org/broadcastflag) I would have
thought HDTV were a lot more debugged.



_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com

>>Have you read the recent ALSA discussions on the
>>-dev list?
>>
>>
>
>Yes. I downleveled ALSA to 1.0.5 with no change in
>symptoms. I'm outputting AC3 via optical out. Oddly
>enough, if I "hide" my sound output device I can get
>Xv to play the 720p stream at full speed with no
>sound. XvMC still runs at half-speed, however, even
>with no sound.
>
>
>
I have sound playback issues with hdtv content also. Audio stutters or
sounds like it is underwater. Mainly with abc. Mplayer plays the same
file with no problems at all so alsa is working, mythtv just has a
problem with keeping up with sending audio out to alsa. I even have a
problem playing some recordings I made using 720x480, 2200 bitrate.
Audio is constantly stuttering.

>>XvMC is a PITA because of the way it barely fits
>>into the Myth video
>>output architecture.
>>
>>
>
>I have not found any development docs which hint at
>this architecture. I'm not afraid of C++, but it makes
>it a little difficult to contribute to the project
>when the only documentation I can find is the source
>code. I just lack the time to invest to figure out
>the architecture on my own.
>
>
>
>> You can't apply filters; you
>>have to deal with the
>>fact that there are fewer in-flight video buffers
>>(frames); seeking is
>>more difficult because the decoder has to have all
>>the reference frames
>>for non-I frames, etc. Software decoder is just
>>more flexible.
>>
>>
>
>I think my needs are very simple. I have an output
>device that is locked to 1080i. I want to play 1080i
>streams unmodified to the output device. 720p streams
>will have to be rescaled to 1080i on playback, and so
>will 480i or 480p. I just want to view recorded TV
>programs and DVDs. If the video processing does the
>"right thing" there should be no need for filtering,
>right?
>
>I have noticed that my "myth" question has not
>received a flood of messages like "I'm using it and it
>works great." Jarod and I are running Athlon systems
>with mucho trouble, and I've had responses from three
>Pentium users (yourself included). Of the P4 users,
>two are working fine and one is not. I guess just not
>many people are using Myth with HDTV monitors yet.
>>From the breathless MythTV promotion by EFF
>(http://www.eff.org/broadcastflag) I would have
>thought HDTV were a lot more debugged.
>
>
>
>
I also have a wierd problem, fast forward works on hdtv content until I
get a blast of noise then I can only ff 1 second at a time but the
timeline jumps 10 seconds. I have not been able to finish watching the
last three recordings of Joan of Arcadia because about 30 minutes into
the playback, it starts playing from the beginning, I can never seem to
get to the end of the show. I am in the process of transcoding one of
the shows to see is I can watch the transcoded file. Besides that, 1080i
looks great.

- James

Joe Barnhart wrote:
> Hmm.. Doesn't something seem fundamentally wrong about
> this? Why should 1920x540 look the same as 1920x1080?

1080i at 30 Hz is identically the same as 540p at 60 Hz. Suggest you do
some reading.

-Doug

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.

> Jarod and I are running Athlon systems
> with mucho trouble,

Jarod *was* running with mucho trouble, (which I was actually able to
duplicate on a system almost identical to Doug's), but I managed to get
both my P4 and Athlon playing back everything just fine.

> and I've had responses from three
> Pentium users (yourself included). Of the P4 users,
> two are working fine and one is not. I guess just not
> many people are using Myth with HDTV monitors yet.

That, and even fewer folks actually have pcHDTV cards to go with HDTV
displays.

So did you rebuild Myth against the down-graded ALSA libs? I'm not
certain it made a difference here or not, but I made sure to do so on
both systems that had problems and now don't. Enabling extra audio
buffering was the other key for me.

--
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/

--- Doug Larrick <doug@ties.org> wrote:

> Joe Barnhart wrote:
> > Hmm.. Doesn't something seem fundamentally wrong
> about
> > this? Why should 1920x540 look the same as
> 1920x1080?
>
> 1080i at 30 Hz is identically the same as 540p at 60
> Hz. Suggest you do
> some reading.

What is the same, Doug? The horizontal scanning
frequency of 33.75kHz? I agree. How about the image?
With 1080i you get two different frames of
information, 30 times each second. With 540p you get
two identical frames 30 times each second. Shouldn't
they look different? I think they should.




_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com

--- Jarod Wilson <jcw@wilsonet.com> wrote:

> So did you rebuild Myth against the down-graded ALSA
> libs? I'm not
> certain it made a difference here or not, but I made
> sure to do so on
> both systems that had problems and now don't.
> Enabling extra audio
> buffering was the other key for me.

I first went with 1.0.5rc1 with no change, then 1.0.5,
also no change. I can get 720p playback to work,
sometimes, with Xv and "extra buffering" (and downhill
with a tailwind). XvMC never works at 720p, buffering
or not. The tables turn at 1080i, with Xv not able to
keep up without sound gaps and stutters and XvMC able
to play pretty well, except for the jaggies and
freezing when the OSD comes up.

As I recall you are using a modeline other than
1920x1080i, aren't you? Are you doing the 540p thing
like Doug? I wonder if I'm taxing my system just a
smidgen more, with hardware just a little less capable
(Athlon 2800+, nForce2, 1G dual-channel memory,
GF4MX).

I guess I could pile on more hardware to make Xv work
at 1080i without choking on the audio. Its so darned
wasteful, tho, having all this nice hardware assist
and leaving it turned off! I'd eventually like to
have a system with three or four capture cards, so I
want to use my cpu cycles sparingly.

Do you think it would help to recompile everything
(kernel, myth) for Athlon instead of 586 or 686? (I
doubt it, which is why I haven't done it yet.)

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. 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. As a
newcomer, I don't expect to be taken as seriously.

Joe Barnhart

P.S. Here's another observation. Setting chmod u+s on
mythfrontend, XvMC uses about 55% cpu playing 1080i
and has sound gaps every two seconds. When I chmod
u-s the cpu goes down to 37% and it plays without
gaps. Weird.

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

Joe Barnhart wrote:
> --- Doug Larrick <doug@ties.org> wrote:
>
>
>>Joe Barnhart wrote:
>>
>>>Hmm.. Doesn't something seem fundamentally wrong
>>
>>about
>>
>>>this? Why should 1920x540 look the same as
>>
>>1920x1080?
>>
>>1080i at 30 Hz is identically the same as 540p at 60
>>Hz. Suggest you do
>>some reading.
>
>
> What is the same, Doug? The horizontal scanning
> frequency of 33.75kHz? I agree. How about the image?
> With 1080i you get two different frames of
> information, 30 times each second. With 540p you get
> two identical frames 30 times each second. Shouldn't
> they look different? I think they should.

No.

1080i = 2 fields of 540 lines, at 30 Hz

540p = 1 frame of 540 lines, at 60 Hz.

Six of one, half a dozen of the other. Almost literally.

-Doug

>> What is the same, Doug? The horizontal scanning
>> frequency of 33.75kHz? I agree. How about the image?
>> With 1080i you get two different frames of
>> information, 30 times each second. With 540p you get
>> two identical frames 30 times each second. Shouldn't
>> they look different? I think they should.
>
> No.
>
> 1080i = 2 fields of 540 lines, at 30 Hz
>
> 540p = 1 frame of 540 lines, at 60 Hz.
>
> Six of one, half a dozen of the other. Almost literally.
>
> -Doug
>
Same frequencies for the TV, agreed. It's not exactly the same,
perceptually, however. An 1080i signal will resolve higher vertical
resolution (Kell factor notwithstanding) than a 540p signal, even though
the TV's H/V PLL's will by running at the same rate. The difference would
be most apparent on a still frame with horizontal lines on it.... annoying
30Hz flicker, granted, but higher resolution yes.

-Cory

Cory Papenfuss wrote:
>>> What is the same, Doug? The horizontal scanning
>>> frequency of 33.75kHz? I agree. How about the image?
>>> With 1080i you get two different frames of
>>> information, 30 times each second. With 540p you get
>>> two identical frames 30 times each second. Shouldn't
>>> they look different? I think they should.
>>
>>
>> No.
>>
>> 1080i = 2 fields of 540 lines, at 30 Hz
>>
>> 540p = 1 frame of 540 lines, at 60 Hz.
>>
>> Six of one, half a dozen of the other. Almost literally.
>>
>> -Doug
>>
> Same frequencies for the TV, agreed. It's not exactly the same,
> perceptually, however. An 1080i signal will resolve higher vertical
> resolution (Kell factor notwithstanding) than a 540p signal, even though
> the TV's H/V PLL's will by running at the same rate. The difference
> would be most apparent on a still frame with horizontal lines on it....
> annoying 30Hz flicker, granted, but higher resolution yes.

What I'm saying is that for 1080i, the TV electrically has *no way* of
telling the difference. The signals transmitted are identical, whether
the hardware sends each field, or if you run bob deinterlace in software
and send the exact same fields sequentially.

Note that this is untrue for NTSC and its 525 lines, where one frame has
one more line than the other.

-Doug

>> Same frequencies for the TV, agreed. It's not exactly the same,
>> perceptually, however. An 1080i signal will resolve higher vertical
>> resolution (Kell factor notwithstanding) than a 540p signal, even though
>> the TV's H/V PLL's will by running at the same rate. The difference would
>> be most apparent on a still frame with horizontal lines on it.... annoying
>> 30Hz flicker, granted, but higher resolution yes.
>
> What I'm saying is that for 1080i, the TV electrically has *no way* of
> telling the difference. The signals transmitted are identical, whether the
> hardware sends each field, or if you run bob deinterlace in software and send
> the exact same fields sequentially.
>
> Note that this is untrue for NTSC and its 525 lines, where one frame has one
> more line than the other.
>
> -Doug
>
That's what I thought I said. Frequencies are the same. What
about the 1-line offset though? I believe that even with the same number
of lines/field, the monitor still has to know that it's interlaced so it
can interleave the lines spatially. Otherwise, the two frames will draw
sequentially on top of each other. I think that an interlaced signal
often swaps between positive and negative VSYNC polarity on the redraw to
indicate interlaced.

That would be the ideal situation, but I know that some monitors
don't know the difference and draw one on top of the other (like you
suggest). Either way, it's not going to hurt the monitor since the
freqencies are the same.

-Cory

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? Are you using a stock kernel or customer
build?

Thanks,

Steve

An unrelated if not annoying issue with a mixed HDTV environment, is
that when going to a screen with a live preview, if it has HDTV
content, it takes a very long time to come show up (I've disabled the
previews to see if that fixes it, but I'm not sure if it has...)

IT is much closer to working than before... almost usable now :) (for
the wife that is :)

Art

fuck you remove me from your cocksucker list now.


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? Are you using a stock kernel or customer
>build?
>
>Thanks,
>
>Steve
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>mythtv-users mailing list
>mythtv-users@mythtv.org
>http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
>
>

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

fuck you remove me from your cocksucker list now.


Art Morales wrote:

>An unrelated if not annoying issue with a mixed HDTV environment, is
>that when going to a screen with a live preview, if it has HDTV
>content, it takes a very long time to come show up (I've disabled the
>previews to see if that fixes it, but I'm not sure if it has...)
>
>IT is much closer to working than before... almost usable now :) (for
>the wife that is :)
>
>Art
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>mythtv-users mailing list
>mythtv-users@mythtv.org
>http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
>
>

On Sat, 9 Oct 2004, Joe Barnhart wrote:

> I guess my expectations were too high. I've been
> watching HD on my combo satellite/terrestrial receiver
> a couple of years now, and I expected Myth to be able
> to record and play signals equivalent to what I see on
> "normal" HDTV (terrestrial) broadcasts. What I
> actually get on Myth is slow, jerky, stuttering
> playback that often hangs the frontend with something
> as simple as skipping forward or backward, or any
> activity that pops up the on-screen display.

<snip>

> Were my expectations too high? Is this a matter of
> "rough edges" soon to be smoothed out? Or is the
> current state of Myth unable to handle HDTV (at
> 1920x1080i) for anyone? Should I dump my system and
> buy new Intel Pentium hardware? Or just go back to
> the combo receiver and wait another year for the
> software to catch up?
>
> I would love to hear from anyone who is playing
> streams at 1920x1080i with no stutters or poor video
> quality. What kind of system are you using? Xv or
> XvMC? Intel or AMD? Video card?


I have been playing with Myth/HDTV since January. It not was until March
that I had something usable. My machine at the time:

2.6GHz HT P4 overclocked to ~2.8GHz
512MB DDR400 RAM
nVidia 440MX video card

Things I learned during this process:

1) NvAGP *must* be set right for your video card/motherboard.
In my case, I needed to comment out/remove
Option "NvAGP" "1"
from my xorg.conf file
2) Hyperthreading is a good thing.
I built a kernel with Hyperthreading/SMP disabled which resulted in
really bad stuttering.
3) Kernel 2.6.7 is a win. Much better than any 2.4 kernel, both for
recording and playback. pcHDTV's 2.6.6 kernel patch works perfectly with
the 2.6.7 kernel.
4) Building Myth/ffmpeg with optimizations for your processor is a win.
For example:
./configure
add/modify "-march=pentium4" in settings.pro and config.mak
qmake
make && make install
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.


This all resulted in a machine which would play both 720p and 1080i material
pretty well. It had consistent problems with close-up pans and scrolling
text, but it was watchable.

I decided that to fix the final issues, I must need to upgrade my CPU. So I
relegated my 2.6GHz system to be my Myth backend, and for my front end, I
splurged on:

3.2GHz HT P4
512MB DDR400 RAM
nVidia FX5700LE video card

The result was a setup with almost exactly the same characteristics I had
before. If there was any improvement, it was minor. Obviously, the
extra CPU power was not as necessary as I thought.

Then Doug came along with his latest improvements to Myth. He re-wrote the
audio/video synchronization code. This made a small but noticeable
improvement.

Version 2 of Doug's synchronization code was the final piece. Bruce got
involved and between them they fixed 99.99% of my stuttering problems.
Playback is now silky smooth. I still get rare, very short, "micropauses",
but they are few and far between.

When ALSA 1.0.6a came out, I grabbed it and compiled Myth against it. Major
problems. Quickly went back and recompiled Myth against ALSA 1.0.5.

Hope this helps.


John

Yo braindead,

Have you tried clicking on the links at the bottom of most of the
mails in this list. They will take you to a page that let's you put in
your email address to unsubscribe.

http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

Please watch your language


On Mon, 11 Oct 2004 11:34:57 -0400, Robert <lgilmore1@tampabay.rr.com> wrote:
> fuck you remove me from your cocksucker list now.
>
>
>
>
> Art Morales wrote:
>
> >An unrelated if not annoying issue with a mixed HDTV environment, is
> >that when going to a screen with a live preview, if it has HDTV
> >content, it takes a very long time to come show up (I've disabled the
> >previews to see if that fixes it, but I'm not sure if it has...)
> >
> >IT is much closer to working than before... almost usable now :) (for
> >the wife that is :)
> >
> >Art
> >
> >
> >------------------------------------------------------------------------
> >
> >_______________________________________________
> >mythtv-users mailing list
> >mythtv-users@mythtv.org
> >http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
> >
> >
>
>
> _______________________________________________
> mythtv-users mailing list
> mythtv-users@mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
>
>
>

Just a couple thoughts/comments. The ratio of HDTV to regular TV myth
users is much smaller, I'd say less than 3%. Most people on these lists
also only stick around while they are having problems. Also, once most
people get their HD setups working they drop off the list and go on with
life. I think there are only 30 or so people who use HDTV that are on
the list here, and many are read only people. Your problem is not
unique, it's just it takes time to track down the problem. HDTV takes a
lot of resources and every CPU, MB, and hard drive will effect things.
I run 3 HDTV tuner cards and record about 20 shows a day. My backend
hasn't crashed in 2 weeks (Before that cvs update it was every 1.5 weeks
or so). There was a several week period where even I had problems
getting playback working well. After a year of completely despising it,
it has since become my friend. I run an athlon 2600 and 333mhz FSB, and
an nvidia fx5200. I have to run XVMC to get 1080i de-interlaced. For
almost a year I went without de-interlacing but several people have
improved this and it works very well.

The only problems I currently have is when watching high-res and
seeking I get audio drop out when the OSD disapears. .. That's it. And
this is on a athlon 2600. I very much do NOT recommend this setup and
if I had to do it over again I would go with a P4 3.2Ghz. The reason is
I have several non-myth related issues that come up from time to time.
Doing backend and frontend on a single 2600 has some bandwidth problems.
When watching HD and recording 3 shows at once, and commercial detecting
is a lot for any system. P4's hyper threading helps quite nicely with
keeping audio sound dropouts down when seeking. My system locks at
times when stopping recording 3 shows and starting recording 3 new
shows, and when I'm watching a movie via mplayer, the movie stops for
2-8 seconds. I also see much more video stuttering with mplayer. The
fact is, HD is not a little thing. I've had problems with data
throughput even with a 5 disk stripped raid system that moves about
100MB a second because recording 3 shows, commercial detecting one, and
watching another is simply too much for my motherboard's FSB to take,
period. I also had more problems until I revamped which PCI/AGP cards
use which IRQ's.

My point I guess is, HD is right on the boarder of what current systems
can take, and in my personal experience it's not JUST cpu that matters,
it's your system bus. They are not all created the same, and every
person doing HD will have things slightly different which can cause odd
problems. My experience tells me that running an 800mhz FSB and a P4
3.2Ghz does a lot better for reducing chances of problems. But then if
you're willing to take the time like I did, you can get something
working as I did.

The ideal setup is a 1-2Ghz backend holding the HD cards doing the
recording and a frontent only carrying about display and streaming
things over the network. This setup would be very hard to have
bandwidth issues on either system.

I do believe HD in myth is ready, and has been. Things are tweaked and
broken. XVMC has more problems now with seeking than it used to, but
this is temporary. Also, if you're running an older version you may
want to grab CVS and if you have a question if it's in a good state or
not e-mail me and I'll let you know. Rarely am I more than a week past
CVS and I'll almost always find a bug if it's there.

Oh, and BTW, here is the compiler settings I use.

-O3 -march=athlon-xp -m3dnow -mmmx -msse -mfpmath=sse
-fomit-frame-pointer

And if you want about a 10% speedup, use gcc 3.4. I did for some time
but I went back to 3.3 because I was trying to find out of 3.4 was
causing seeking issues, it wasn't, and I've been to busy to change
symlinks to 3.4 (mostly forgotten to). 3.4 should be fine and in fact
next build I'll be back to 3.4.

Hope this gives some insight... Oh, I just remebered, last night seeking
did lock the frontend. And a quick tip is even though you don't see the
text, hit the save possition button and it will save it, restart the
frontend and go... I saw this problem once in 5 hours of watching 50
shows (my weekly tv review session). This is a known problem too, it's
just time to fix it, but it's so minor I overlook it. :)

--Brandon


On Sun, Oct 10, 2004 at 11:21:44PM -0700, Joe Barnhart wrote:
>
> --- Jarod Wilson <jcw@wilsonet.com> wrote:
>
> > So did you rebuild Myth against the down-graded ALSA
> > libs? I'm not
> > certain it made a difference here or not, but I made
> > sure to do so on
> > both systems that had problems and now don't.
> > Enabling extra audio
> > buffering was the other key for me.
>
> I first went with 1.0.5rc1 with no change, then 1.0.5,
> also no change. I can get 720p playback to work,
> sometimes, with Xv and "extra buffering" (and downhill
> with a tailwind). XvMC never works at 720p, buffering
> or not. The tables turn at 1080i, with Xv not able to
> keep up without sound gaps and stutters and XvMC able
> to play pretty well, except for the jaggies and
> freezing when the OSD comes up.
>
> As I recall you are using a modeline other than
> 1920x1080i, aren't you? Are you doing the 540p thing
> like Doug? I wonder if I'm taxing my system just a
> smidgen more, with hardware just a little less capable
> (Athlon 2800+, nForce2, 1G dual-channel memory,
> GF4MX).
>
> I guess I could pile on more hardware to make Xv work
> at 1080i without choking on the audio. Its so darned
> wasteful, tho, having all this nice hardware assist
> and leaving it turned off! I'd eventually like to
> have a system with three or four capture cards, so I
> want to use my cpu cycles sparingly.
>
> Do you think it would help to recompile everything
> (kernel, myth) for Athlon instead of 586 or 686? (I
> doubt it, which is why I haven't done it yet.)
>
> 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. 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. As a
> newcomer, I don't expect to be taken as seriously.
>
> Joe Barnhart
>
> P.S. Here's another observation. Setting chmod u+s on
> mythfrontend, XvMC uses about 55% cpu playing 1080i
> and has sound gaps every two seconds. When I chmod
> u-s the cpu goes down to 37% and it plays without
> gaps. Weird.
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com

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


--

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.

--Brandon

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


*************************************************************************
* Cory Papenfuss *
* Electrical Engineering candidate Ph.D. graduate student *
* Virginia Polytechnic Institute and State University *
*************************************************************************

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/

> > 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 )
>
> 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.

Well I'm glad this discussion ended up to be so helpful :)

Looking to the future.. What should happen here is the reed-solomon
failures ( red LED blinks ) should become in someway part of the
actual pcHDTV drivers. MythTV should then use this information to
detect whether or not to allow a channel to be brought up. Signal
strength could still be used, it would just have to be made more
consistant with the reed-solomon decoding. Consistant enough that the
signal strength being above a number, say 50, means that there are no
reed-solomon failures. Again, I believe there is a normalization
equation using frequency that can be used here.


--
Anthony Vito
anthony.vito@gmail.com

I think the v4l2 signal interface in the 2.6.x drivers changed the
thresholds range a bit. I don't mind patching the low end threshold to
40% if it is working for people.

-- Daniel

On Sun, 17 Oct 2004, Jarod Wilson wrote:

]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.
]
]

On Monday 18 October 2004 05:58, Daniel Thor Kristjansson wrote:
> I think the v4l2 signal interface in the 2.6.x drivers changed the
> thresholds range a bit. I don't mind patching the low end threshold to
> 40% if it is working for people.

I'm not certain how low I can go before it goes completely haywire, but
definitely still good in the 45-50 range. The weather was pretty bad here
yesterday, so my signal kept plummeting down a ways below, and video got
pretty bad during the baseball games at times, but I think it was driving the
signal strength down by double-digits at times. So I would say 45 is
definitely a safe number for me, but with the warning already present, I
don't think 40 is unreasonably low.

--
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 Sun, 10 Oct 2004 08:32:04 -0400, Doug Larrick <doug@ties.org> wrote:
> Joe Barnhart wrote:
> > I would love to hear from anyone who is playing
> > streams at 1920x1080i with no stutters or poor video
> > quality. What kind of system are you using? Xv or
> > XvMC? Intel or AMD? Video card?
>
> Works quite well for me. P4, 2.8 GHz, OSS emulation on ALSA, no XvMC,
> nVidia FX5200.

Does your processor have hyperthreading? What's the bus speed?

Thanks,
Lane

Lane Schwartz wrote:
> On Sun, 10 Oct 2004 08:32:04 -0400, Doug Larrick <doug@ties.org> wrote:
>
>>Joe Barnhart wrote:
>>
>>>I would love to hear from anyone who is playing
>>>streams at 1920x1080i with no stutters or poor video
>>>quality. What kind of system are you using? Xv or
>>>XvMC? Intel or AMD? Video card?
>>
>>Works quite well for me. P4, 2.8 GHz, OSS emulation on ALSA, no XvMC,
>>nVidia FX5200.
>
>
> Does your processor have hyperthreading? What's the bus speed?

Yes, HT. 2.6 kernel to take advantage of it. 800 MHz FSB.

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

On Mon, 18 Oct 2004 08:58:31 -0400 (EDT), Daniel Thor Kristjansson
<danielk@mrl.nyu.edu> wrote:
>
> I think the v4l2 signal interface in the 2.6.x drivers changed the
> thresholds range a bit. I don't mind patching the low end threshold to
> 40% if it is working for people.
>
> -- Daniel
>

Bringing down the threshold for now is probably a good idea. Thanks
for the offer :) . Without being able to normalize the signal
strength across all channels, the best solution I see for the
intermediate term is to offer a threshold on a per-channel basis. ( is
that already a feature?? if it is, someone slap me upside the head. )

--
Anthony Vito
anthony.vito@gmail.com