Mailing List Archive: MythTV: Users

PVR250 + TVWonder = jerky

Index | Next | Previous | View Threaded

chadmcquinn at insightbb

Jun 2, 2003, 11:14 PM

Post #1 of 24 (3001 views)
Permalink

PVR250 + TVWonder = jerky

This is similar to the issue posted this evening with subject "PVR250 +
BT878", but different enough that I thought it deserved a new message rather
than a reply.

I have set up the following hardware over the last few days:

ASUS A7v8x-x
Athlon 2600xp+
512MB RAM
Dedicated video drive (7200RPM) with a dedicated controller
PVR-250
ATI TV-Wonder
SoundBlaster Live PCI 128 using OSS (not ALSA)
Nvidia GEForce4 MX 440 (8x AGP)

DMA is enabled on the hard drive, as is 32-bit mode. I am using Redhat 9 and
the NVidia closed-source drivers.

I am experiencing the following:

Using either JUST the PVR250 or the TV-Wonder, things seem fine (the
TV-Wonder maybe needs some tweaking, but the PVR250 works great). However,
if I try to use both tuners simultaneously, the video playback (not
recording) is extremely jumpy. This occurs whether I try to record one
program and watch live tv, or record two programs and watch one of them
(which amounts to the same thing).

The recording process itself is actually working fine; after the recording
is finished and no tuners are in use, I can watch the videos without a
problem. So, at this point you would guess that it is the hard drive not
being fast enough, but I don't think that is the case (see below). In fact I
think I can rule out any hardware or performance problems because the
following works perfectly:

* record two programs with MythTV
* play back a stream (either one being recorded now, or an old one) using
mplayer

The video coming from mplayer is extremely smooth in that case, so I don't
think this can be tied to processor, hard drive, or other hardware issues.

Here's even more evidence that it is something in myth that isn't working
correctly; if I do this:

*record two programs
*play back one of them with myth (this is jumpy)
*while that is playing, play another stream with mplayer (even one of the
currently recording streams)

then the mplayer stream is very smooth, while the stream that myth is
playing is jerky.

The relevant software settings are:

TV-Wonder set to MPEG4, 480x480, bitrate 4000, min quality 2, max 10.
Various combinations of the other flags, as well as the RTJPEG setting, have
been tried with no effect.

The PVR250 is set for 8Mb/s, dnr off.

I have tried all combinations of deinterlacing on/off and jitter reduction
on/off; while these look different, they don't have any effect on the
smoothness of the video playback.

I should also mention that the processor usage never tops 50% (in fact it is
usually much below 50%).

Any ideas?

-Chad

petecool at vl

Jun 3, 2003, 11:39 AM

Post #2 of 24 (2979 views)
Permalink

Re: PVR250 + TVWonder = jerky [In reply to]

Chad McQuinn wrote:
> ASUS A7v8x-x
> Athlon 2600xp+
> 512MB RAM
> Dedicated video drive (7200RPM) with a dedicated controller
> PVR-250
> ATI TV-Wonder
> SoundBlaster Live PCI 128 using OSS (not ALSA)
> Nvidia GEForce4 MX 440 (8x AGP)

Have you tried running the hard disk on the onboard IDE controller?
Maybe the PCI bus get filled (or latency gets bad) with the many
accesses caused by: raw video frames coming from the TV-Wonder, the
encoded frames being written to the hard disk, and the MPEG-2 stream
going from the PVR to the hard disk controller. Or, maybe your IDE
controller's driver is bad/slow in your distro's kernel. Those two
possible problems would be relieved by using the onboard IDE controller.

Pete

mythtv at codex

Jun 3, 2003, 12:01 PM

Post #3 of 24 (2983 views)
Permalink

Re: PVR250 + TVWonder = jerky [In reply to]

#if chadmcquinn /* Jun 03, 01:14 */
> This is similar to the issue posted this evening with subject "PVR250 +
> BT878", but different enough that I thought it deserved a new message rather
> than a reply.
>
> I have set up the following hardware over the last few days:
>
> ASUS A7v8x-x
> Athlon 2600xp+
> 512MB RAM
> Dedicated video drive (7200RPM) with a dedicated controller
> PVR-250
> ATI TV-Wonder
> SoundBlaster Live PCI 128 using OSS (not ALSA)
> Nvidia GEForce4 MX 440 (8x AGP)
>
> DMA is enabled on the hard drive, as is 32-bit mode. I am using Redhat 9 and
> the NVidia closed-source drivers.
>
#endif /* chadmcquinn [at] insightbb */

I have a similiar setup, with the same problem.

my setup:
Asus a7v8x
XP2100+
256Mb PC2700
dedicated 180Gb WD
Haupauge bt869 wintv theatre
geforce 440 mx
running on debian/testing

since checking out a new cvs tree about a week ago, i've noticed very
choppy video playback using mythfrontend. my recording settings are:
480x480 rtjpeg/255 and the CPU utilization ticks over at 30% backend,
and 10% frontend.

this system has been working perfectly fine up until very recently.
about a week ago i checked out the latest CVS tree, and thats when
mythfrontend started dropping frames on playback. it doesnt look to me
like a problem with the backend, the video stream is being recorded OK.
but when i pause livetv after experiencing choppy playback, the stream
has fallen behind. over a 30 minute period it drops behind by almost a
minute.

to mirror what you are seeing, anything i playback with mplayer works
fine.

sorry i cant offer any advice as to how to fix your problem, but you
are not alone.

on the whole, mythtv has been pretty reliable for me, up until the last
week.

-v

--
keys: http://codex.net/pgp/gpg.asc http://codex.net/pgp/pgp.asc

perl -le '$_="6110>374086;2064208213:90<307;55";tr[0->][ LEOR!AUBGNSTY];print'

ijr at po

Jun 3, 2003, 1:50 PM

Post #4 of 24 (2999 views)
Permalink

Re: PVR250 + TVWonder = jerky [In reply to]

On Tuesday 03 June 2003 03:01 pm, Vincent AE Scott wrote:
> on the whole, mythtv has been pretty reliable for me, up until the last
> week.

Mind trying current CVS and seeing if it's better? I've made the output code
that Bruce and I have been messing around with optional, with a new
'Experimental AV Sync' option in the playback section to enable it. Not
having this checked should use the older (ie, previous to last week) code.

Isaac

mythtv at codex

Jun 3, 2003, 2:59 PM

Post #5 of 24 (2967 views)
Permalink

Re: PVR250 + TVWonder = jerky [In reply to]

#if ijr /* Jun 03, 04:50 */
> On Tuesday 03 June 2003 03:01 pm, Vincent AE Scott wrote:
> > on the whole, mythtv has been pretty reliable for me, up until the last
> > week.
>
> Mind trying current CVS and seeing if it's better? I've made the output code
> that Bruce and I have been messing around with optional, with a new
> 'Experimental AV Sync' option in the playback section to enable it. Not
> having this checked should use the older (ie, previous to last week) code.
>
#endif /* ijr [at] po */

Thanks for the quick response ;-)
I've tried it with the rtjpg codec and it didnt make the slightest bit
of difference. :( enabled and disabled, and it was still jittery.

so then i tried switching over to mpeg4, and the jittery playback
suddenly ceased. that was with the new option both enabled and
disabled. so it looks more likey that the problem is with the rtjpg
codec.

Thanks for all the great work ;-)

-v

--
keys: http://codex.net/pgp/gpg.asc http://codex.net/pgp/pgp.asc

I can see clearly now, the brain is gone...

chadmcquinn at insightbb

Jun 3, 2003, 3:09 PM

Post #6 of 24 (2989 views)
Permalink

Re: PVR250 + TVWonder = jerky FIXED [In reply to]

On 6/3/03 3:50 PM, "Isaac Richards" <ijr [at] po> wrote:

> On Tuesday 03 June 2003 03:01 pm, Vincent AE Scott wrote:
>> on the whole, mythtv has been pretty reliable for me, up until the last
>> week.
>
> Mind trying current CVS and seeing if it's better? I've made the output code
> that Bruce and I have been messing around with optional, with a new
> 'Experimental AV Sync' option in the playback section to enable it. Not
> having this checked should use the older (ie, previous to last week) code.

I will give it a shot as well and let you know what happens. I seem to have
solved my problem, for the time being at least.

I wanted to try the ALSA drivers instead of the OSS drivers; the soundcard
(SB PCI 128) is supposed to be ASLA-supported, but I never got it to work.
So, I am still using the OSS drivers. However, in the process I downloaded
the 2.4.20 kernel source (kernel.org) and the preempt and low-latency
patches as described in one of the ALSA howtos. Booting with this kernel, I
no longer experience the video playback issues, even with both tuners going.

I don't know whether it was the low latency patches that fixed things, or
maybe it was the RH threading model that was causing problems. I know
Vincent said he was using Debian, but recompiling the kernel is worth a
shot.

-Chad

bjm at lvcm

Jun 3, 2003, 9:18 PM

Post #7 of 24 (2969 views)
Permalink

Re: PVR250 + TVWonder = jerky [In reply to]

Vincent AE Scott wrote:
...
> so then i tried switching over to mpeg4, and the jittery playback
> suddenly ceased. that was with the new option both enabled and
> disabled. so it looks more likey that the problem is with the rtjpg
> codec.

Confirmed. One potential problem that I'd seen, and Mark
Chou pointed, is that prebuffering and rebuffering may be
contributing to choppiness for Live TV. RTjpeg writes
larger files so more data to move through the buffers.
If I use RTjpeg at low res for local live TV, I see 90%+
idle CPU but it's constantly pausing to prebuffer. I
hadn't been testing with RTjpeg so thanks for pointing
this out.

-- bjm

ijr at po

Jun 3, 2003, 10:15 PM

Post #8 of 24 (2989 views)
Permalink

Re: PVR250 + TVWonder = jerky [In reply to]

On Wednesday 04 June 2003 12:18 am, Bruce Markey wrote:
> Vincent AE Scott wrote:
> ...
>
> > so then i tried switching over to mpeg4, and the jittery playback
> > suddenly ceased. that was with the new option both enabled and
> > disabled. so it looks more likey that the problem is with the rtjpg
> > codec.
>
> Confirmed. One potential problem that I'd seen, and Mark
> Chou pointed, is that prebuffering and rebuffering may be
> contributing to choppiness for Live TV. RTjpeg writes
> larger files so more data to move through the buffers.
> If I use RTjpeg at low res for local live TV, I see 90%+
> idle CPU but it's constantly pausing to prebuffer. I
> hadn't been testing with RTjpeg so thanks for pointing
> this out.

Hm. Does changing line 363 of nuppeldecoder.cpp to:

ringBuffer->CalcReadAheadThresh(12000);

help any? Not that that's an actual fix, but I'd like to see..

Isaac

bjm at lvcm

Jun 4, 2003, 12:20 AM

Post #9 of 24 (2995 views)
Permalink

Re: PVR250 + TVWonder = jerky [In reply to]

Isaac Richards wrote:
> On Wednesday 04 June 2003 12:18 am, Bruce Markey wrote:
>
>>Vincent AE Scott wrote:
>>...
>>
>>
>>>so then i tried switching over to mpeg4, and the jittery playback
>>>suddenly ceased. that was with the new option both enabled and
>>>disabled. so it looks more likey that the problem is with the rtjpg
>>>codec.
>>
>>Confirmed. One potential problem that I'd seen, and Mark
>>Chou pointed, is that prebuffering and rebuffering may be
>>contributing to choppiness for Live TV. RTjpeg writes
>>larger files so more data to move through the buffers.
>>If I use RTjpeg at low res for local live TV, I see 90%+
>>idle CPU but it's constantly pausing to prebuffer. I
>>hadn't been testing with RTjpeg so thanks for pointing
>>this out.

Of course, I meant 10%+ idle.

> Hm. Does changing line 363 of nuppeldecoder.cpp to:
>
> ringBuffer->CalcReadAheadThresh(12000);
>
> help any? Not that that's an actual fix, but I'd like to see..

Inconclusive. This wrote more "rebuffering (125268 128000)"
messages but the "prebuffering..." messages are triggered
by high motion. It's hard to tell if they are more common
one way or the other.

I neglected to ask you if you could uncomment the prebuffer
message for when you see the 10ms std dev.

-- bjm

ijr at po

Jun 4, 2003, 9:29 AM

Post #10 of 24 (2993 views)
Permalink

Re: PVR250 + TVWonder = jerky [In reply to]

On Wednesday 04 June 2003 03:20 am, Bruce Markey wrote:
> Inconclusive. This wrote more "rebuffering (125268 128000)"
> messages but the "prebuffering..." messages are triggered
> by high motion. It's hard to tell if they are more common
> one way or the other.
>
> I neglected to ask you if you could uncomment the prebuffer
> message for when you see the 10ms std dev.

Ok, does the attached patch help any?

Isaac

Attachments:

highbitrate.diff (2.08 KB)

michael at optusnet

Jun 4, 2003, 4:21 PM

Post #11 of 24 (2984 views)
Permalink

Re: PVR250 + TVWonder = jerky [In reply to]

Isaac Richards <ijr [at] po> writes:
> On Wednesday 04 June 2003 03:20 am, Bruce Markey wrote:
> > Inconclusive. This wrote more "rebuffering (125268 128000)"
> > messages but the "prebuffering..." messages are triggered
> > by high motion. It's hard to tell if they are more common
> > one way or the other.
> >
> > I neglected to ask you if you could uncomment the prebuffer
> > message for when you see the 10ms std dev.
>
> Ok, does the attached patch help any?

It may paper over the problem, but the underlying cause will
still exist.

The basic problem is long standing. That is, RingBuffer::safe_read
doesn't handle the request windowing correctly.

The logic you've currently got there is

if there's less than one requests worth of data buffered then
send off a 'random' number of requests for more blocks.
munch data and return it.

If the supplier is normally fast (i.e. it's normally reading from
disk, but every now and then runs slow because there's a sync() or
similar) then you'll get infrequent random rebuffering.

The real solution (as I think was mentioned some time ago) is to
count the number of requests outstanding, and ensure that that
number doesn't drop below a given threshold. (i.e. no less
than 5 requests outstanding or some such).

(And no, the the read ahead code doesn't fix this. It just hides the
problem a bit more).

Michael.

ijr at po

Jun 4, 2003, 5:37 PM

Post #12 of 24 (2961 views)
Permalink

Re: PVR250 + TVWonder = jerky [In reply to]

On Wednesday 04 June 2003 07:21 pm, michael [at] optusnet wrote:
> It may paper over the problem, but the underlying cause will
> still exist.
>
> The basic problem is long standing. That is, RingBuffer::safe_read
> doesn't handle the request windowing correctly.
>
> The logic you've currently got there is
>
> if there's less than one requests worth of data buffered then
> send off a 'random' number of requests for more blocks.
> munch data and return it.
>
> If the supplier is normally fast (i.e. it's normally reading from
> disk, but every now and then runs slow because there's a sync() or
> similar) then you'll get infrequent random rebuffering.
>
> The real solution (as I think was mentioned some time ago) is to
> count the number of requests outstanding, and ensure that that
> number doesn't drop below a given threshold. (i.e. no less
> than 5 requests outstanding or some such).
>
> (And no, the the read ahead code doesn't fix this. It just hides the
> problem a bit more).

Nope. The issue is that due to the scheduler and the way all backend requests
are synced and due to them using the Qt event loop and everything, there's a
limited number of requests you can make of the backend in any given time
period. Simply requesting blocks more often doesn't help -- it's still bound
by that limit. Requesting _more_, however, does.

Just for fun, I tried out your previous patch and it had absolutely no effect
on very high bitrate ( > 14000 kbps) streams.

Isaac

bjm at lvcm

Jun 4, 2003, 5:56 PM

Post #13 of 24 (2991 views)
Permalink

Re: PVR250 + TVWonder = jerky [In reply to]

Isaac Richards wrote:
> On Wednesday 04 June 2003 03:20 am, Bruce Markey wrote:
>
>>Inconclusive. This wrote more "rebuffering (125268 128000)"
>>messages but the "prebuffering..." messages are triggered
>>by high motion. It's hard to tell if they are more common
>>one way or the other.
>>
>>I neglected to ask you if you could uncomment the prebuffer
>>message for when you see the 10ms std dev.
>
>
> Ok, does the attached patch help any?

It seem to help a little for local live but it absolutely
kills remote playback over a 10Mb network. The problem is
that the frontend makes several block requests while it is
waiting for data to arrive. If there is a seek, all the
blocks requested need to complete their transfer before
the frontend can request new data from the new position.

In the attached example, there are six quarter MB requests
when the player checks the first 2048 bytes to see if this
is a nupple or mpeg file. This takes 2 to 3 seconds. 2 or 3
seconds to go back and read the file header. 2 or 3 sec
to look for the seek table. By the time it's ready to play,
drained old data, fills buffers and syncs, it's been over
15sec. Every rew/ff, comm skip, etc. causes a pause for three
to four seconds.

There probably needs to be a way for the backend to ignore
impatient request and make sure there are never more than
one or two pending block requests.

-- bjm

Attachments:

256000 (10.0 KB)

ijr at po

Jun 4, 2003, 6:23 PM

Post #14 of 24 (2979 views)
Permalink

Re: PVR250 + TVWonder = jerky [In reply to]

On Wednesday 04 June 2003 08:56 pm, Bruce Markey wrote:
> It seem to help a little for local live but it absolutely
> kills remote playback over a 10Mb network. The problem is
> that the frontend makes several block requests while it is
> waiting for data to arrive. If there is a seek, all the
> blocks requested need to complete their transfer before
> the frontend can request new data from the new position.

Yeah -- I wasn't intending that to go into CVS as it was, just to see if it
helped the high bitrate rtjpeg stuff. The only way I could reproduce any
jerkiness was to use rtjpeg at 640x480 @ quality 255, luma/chroma cutoffs at
0, and that patch fixed things up pretty much perfectly for that case.

A final version of the change would involve estimating the bitrate of the
rtjpeg stream and only double the blocksize like that if necessary.

> There probably needs to be a way for the backend to ignore
> impatient request and make sure there are never more than
> one or two pending block requests.

That should pretty easily taken care of..

Isaac

bjm at lvcm

Jun 4, 2003, 6:43 PM

Post #15 of 24 (2988 views)
Permalink

Re: PVR250 + TVWonder = jerky [In reply to]

Isaac Richards wrote:
> ... The issue is that due to the scheduler and the way all backend requests
> are synced and due to them using the Qt event loop and everything, there's a
> limited number of requests you can make of the backend in any given time
> period. Simply requesting blocks more often doesn't help -- it's still bound
> by that limit. Requesting _more_, however, does.

Yeah, it's not that there aren't pending requests. The
prebuffering pauses happen when the data hasn't actually
been stuffed into vbuffers yet. Too much unnecessary data
queued on the network is what I've been struggling with
for remote seeks.

I reverted from the patch and it's back to requesting two
or three 128000 block per seek. Remote playback startup is
under five seconds and individual seeks are about one sec.

-- bjm

bjm at lvcm

Jun 4, 2003, 6:49 PM

Post #16 of 24 (2980 views)
Permalink

Re: PVR250 + TVWonder = jerky [In reply to]

Isaac Richards wrote:
> On Wednesday 04 June 2003 08:56 pm, Bruce Markey wrote:
>
>>It seem to help a little for local live but it absolutely
>>kills remote playback over a 10Mb network. The problem is
>>that the frontend makes several block requests while it is
>>waiting for data to arrive. If there is a seek, all the
>>blocks requested need to complete their transfer before
>>the frontend can request new data from the new position.
>
>
> Yeah -- I wasn't intending that to go into CVS as it was, just to see if it
> helped the high bitrate rtjpeg stuff. The only way I could reproduce any
> jerkiness was to use rtjpeg at 640x480 @ quality 255, luma/chroma cutoffs at
> 0, and that patch fixed things up pretty much perfectly for that case.

In that case, yes, it shows fewer buffering problems for a
boarderline resolution with rtjpeg.

-- bjm

michael at optusnet

Jun 4, 2003, 7:05 PM

Post #17 of 24 (2988 views)
Permalink

Re: PVR250 + TVWonder = jerky [In reply to]

Isaac Richards <ijr [at] po> writes:
> On Wednesday 04 June 2003 07:21 pm, michael [at] optusnet wrote:
[...]
> > The real solution (as I think was mentioned some time ago) is to
> > count the number of requests outstanding, and ensure that that
> > number doesn't drop below a given threshold. (i.e. no less
> > than 5 requests outstanding or some such).
> >
> > (And no, the the read ahead code doesn't fix this. It just hides the
> > problem a bit more).
>
> Nope. The issue is that due to the scheduler and the way all backend requests
> are synced and due to them using the Qt event loop and everything, there's a
> limited number of requests you can make of the backend in any given time
> period.

I didn't find this problem in my testing. I could stream 20
megabytes/sec out of the backend with a hacked up requestor. Why do
you think this is a problem? (This is easy to test: Write a few lines
of perl to do a connect to the backend, and stuff request blocks
down as fast as you can, just counting and dumping the data the comes
back).

> Simply requesting blocks more often doesn't help -- it's still bound
> by that limit. Requesting _more_, however, does.

It's nothing to do with requesting more often. It's about compensating for
the latency between the front and backend.

To try and make it really really clear. Pretend that there's a 60
second network delay between the front and back. I.e. whenever you
make a request, it takes 60 seconds to get a response. ( In real life,
the backend latency varies wildly, driven by both network and disk,
and it's not constant, but it does frequently range up to 5 - 10
seconds when watching livetv)

If you RequestBlock, wait for reply, request, wait for reply, you'll never
get more than 1 block per minute. Read-ahead makes no difference.

If you do as the current code does, it will request (say) 20 blocks
before the first reply arrives. Then the frontend will never request
another block until it's used all the replies. At which point it starts
making more requests but must wait a full minute for the reply. Boom!

If you make the requests bigger, it doesn't make much difference. It
just takes a little longer for the problem to appear.

Again: The problem is that the current code frequently arrives in
the situation where it has nothing in the buffer, needs more data,
and must send a request block and then wait for the reply to
_that_ request block before proceeding.

> Just for fun, I tried out your previous patch and it had absolutely no effect
> on very high bitrate ( > 14000 kbps) streams.

Using my mjpeg card on a 5 megabyte/sec stream is utterly unusable on
CVS mythtv (audio and video chops every 2 seconds). Streaming the
backend requests makes it silky smooth. (The current patch I'm
using fixes a few bugs in the original one).

PS: I know the mjpeg card has a ridiculous data rate.

Michael, now giving up.

ijr at po

Jun 4, 2003, 7:26 PM

Post #18 of 24 (2996 views)
Permalink

Re: PVR250 + TVWonder = jerky [In reply to]

On Wednesday 04 June 2003 10:05 pm, michael [at] optusnet wrote:
> I didn't find this problem in my testing. I could stream 20
> megabytes/sec out of the backend with a hacked up requestor. Why do
> you think this is a problem? (This is easy to test: Write a few lines
> of perl to do a connect to the backend, and stuff request blocks
> down as fast as you can, just counting and dumping the data the comes
> back).

That's not really a realistic test, since the perl client isn't using the
QSocket stuff.

> Using my mjpeg card on a 5 megabyte/sec stream is utterly unusable on
> CVS mythtv (audio and video chops every 2 seconds). Streaming the
> backend requests makes it silky smooth. (The current patch I'm
> using fixes a few bugs in the original one).

Send in a diff without all the extraneous changes you had in the original one,
then, and I'll see about getting it committed.

Isaac

michael at optusnet

Jun 5, 2003, 1:13 AM

Post #19 of 24 (2975 views)
Permalink

Re: PVR250 + TVWonder = jerky [In reply to]

Isaac Richards <ijr [at] po> writes:
> On Wednesday 04 June 2003 10:05 pm, michael [at] optusnet wrote:
> > I didn't find this problem in my testing. I could stream 20
> > megabytes/sec out of the backend with a hacked up requestor. Why do
> > you think this is a problem? (This is easy to test: Write a few lines
> > of perl to do a connect to the backend, and stuff request blocks
> > down as fast as you can, just counting and dumping the data the comes
> > back).
>
> That's not really a realistic test, since the perl client isn't using the
> QSocket stuff.

Quote: "Nope. The issue is that due to the scheduler and the way all
backend requests are synced and due to them using the Qt event loop
and everything, there's a limited number of requests you can make of
the backend in any given time period."

What does the perl client not using QSocket stuff have to do with
the backend performance??

I do know it's not a realistic test. All it was designed to do was
demonstrate that the problem was in the frontend, not the backend.

> > Using my mjpeg card on a 5 megabyte/sec stream is utterly unusable on
> > CVS mythtv (audio and video chops every 2 seconds). Streaming the
> > backend requests makes it silky smooth. (The current patch I'm
> > using fixes a few bugs in the original one).
>
> Send in a diff without all the extraneous changes you had in the original one,
> then, and I'll see about getting it committed.

The 'extraneous changes' shrank the code size by nearly 200 lines as I
very vaguely recall.

Am I being stupid, and missing some reason that you're keen on having
code duplicated in so many places?

Michael, ever curious.

ijr at po

Jun 5, 2003, 7:50 AM

Post #20 of 24 (2987 views)
Permalink

Re: PVR250 + TVWonder = jerky [In reply to]

On Thursday 05 June 2003 04:13 am, michael [at] optusnet wrote:
> Isaac Richards <ijr [at] po> writes:
> > On Wednesday 04 June 2003 10:05 pm, michael [at] optusnet wrote:
> > > I didn't find this problem in my testing. I could stream 20
> > > megabytes/sec out of the backend with a hacked up requestor. Why do
> > > you think this is a problem? (This is easy to test: Write a few lines
> > > of perl to do a connect to the backend, and stuff request blocks
> > > down as fast as you can, just counting and dumping the data the comes
> > > back).
> >
> > That's not really a realistic test, since the perl client isn't using the
> > QSocket stuff.
>
> Quote: "Nope. The issue is that due to the scheduler and the way all
> backend requests are synced and due to them using the Qt event loop
> and everything, there's a limited number of requests you can make of
> the backend in any given time period."
>
> What does the perl client not using QSocket stuff have to do with
> the backend performance??

Who said the issue was with the backend? If the issue is in the way
communications work between the two, not duplicating one end of the
conversation doesn't demonstrate it, of course.

The 'slow seeking' issue you had thought was the ringbuffer was exactly this
issue -- it was doing a fairly large number of backend queries in a tight
loop, and that was taking a set amount of time. Changing the protocol so
that it could make the same number of requests in a single query fixed
things.

> > Send in a diff without all the extraneous changes you had in the original
> > one, then, and I'll see about getting it committed.
>
> The 'extraneous changes' shrank the code size by nearly 200 lines as I
> very vaguely recall.
>
> Am I being stupid, and missing some reason that you're keen on having
> code duplicated in so many places?

Both Matt and I told you last time that making it completely non-obvious which
mode the RingBuffer class was in (ringbuffer or normal file) was not a good
thing. Splitting the functionality into a pair of classes would most likely
be acceptible, though.

Also, adding in comments like:

+// We're creating a new circular buffer file, as used by LiveTV and
+// similar things. There's a long of assumed behaviour here.
+//
+// In particular, it seems that this means we're ALWAYS writable,
+// and that the file size can't get more than 'size'.
+// I don't know what 'smudge' is for.

Well, for one, I really don't like applying patches that I have to edit while
applying them, and two, you probably shouldn't be submitting 'cleanup'
patches without understanding what the original code does. Finally, I really
prefer that cosmetic improvements be submitted for consideration separately
from functional improvements.

Isaac

chadmcquinn at insightbb

Jun 5, 2003, 2:36 PM

Post #21 of 24 (2977 views)
Permalink

Re: PVR250 + TVWonder = jerky FIXED [In reply to]

Just a note for the archives, really, that what seemed to be the problem
with jerky playback was the redhat kernel. Recompiling with stock source
from kernel.org (without the low-latency/preempt patches) also solved the
problem. I am having a different one now, but I'll post that in a separate
thread.

-Chad

On 6/3/03 5:09 PM, "Chad McQuinn" <chadmcquinn [at] insightbb> wrote:

> On 6/3/03 3:50 PM, "Isaac Richards" <ijr [at] po> wrote:
>
>> On Tuesday 03 June 2003 03:01 pm, Vincent AE Scott wrote:
>>> on the whole, mythtv has been pretty reliable for me, up until the last
>>> week.
>>
>> Mind trying current CVS and seeing if it's better? I've made the output code
>> that Bruce and I have been messing around with optional, with a new
>> 'Experimental AV Sync' option in the playback section to enable it. Not
>> having this checked should use the older (ie, previous to last week) code.
>
> I will give it a shot as well and let you know what happens. I seem to have
> solved my problem, for the time being at least.
>
> I wanted to try the ALSA drivers instead of the OSS drivers; the soundcard
> (SB PCI 128) is supposed to be ASLA-supported, but I never got it to work.
> So, I am still using the OSS drivers. However, in the process I downloaded
> the 2.4.20 kernel source (kernel.org) and the preempt and low-latency
> patches as described in one of the ALSA howtos. Booting with this kernel, I
> no longer experience the video playback issues, even with both tuners going.
>
> I don't know whether it was the low latency patches that fixed things, or
> maybe it was the RH threading model that was causing problems. I know
> Vincent said he was using Debian, but recompiling the kernel is worth a
> shot.
>
> -Chad
>
> _______________________________________________
> mythtv-users mailing list
> mythtv-users [at] snowman
> http://lists.snowman.net/cgi-bin/mailman/listinfo/mythtv-users

lan at falleagle

Jun 5, 2003, 4:35 PM

Post #22 of 24 (2986 views)
Permalink

Re: PVR250 + TVWonder = jerky FIXED [In reply to]

On Thu, Jun 05, 2003 at 04:36:25PM -0500, Chad McQuinn wrote:
> Just a note for the archives, really, that what seemed to be the problem
> with jerky playback was the redhat kernel. Recompiling with stock source
> from kernel.org (without the low-latency/preempt patches) also solved the
> problem. I am having a different one now, but I'll post that in a separate
> thread.
>
> -Chad
>

I posted a question earlier today asking, basically, which RH to upgrade
to, 8 or 9. If I read you correctly, neither is optimal.

Although perhaps RH could provide the skeleton of apps and services, and
then I could fix the kernel as you suggest ...

Confirm? Refute?

TIA,

--
Lan Barnes lan [at] falleagle
Linux Guy, SCM Specialist 858-354-0616

Therapy helps, but screaming obscenities is cheaper.
- Dave Looney

chadmcquinn at insightbb

Jun 5, 2003, 8:50 PM

Post #23 of 24 (2976 views)
Permalink

Re: PVR250 + TVWonder = jerky FIXED [In reply to]

On 6/5/03 6:35 PM, "Lan Barnes" <lan [at] falleagle> wrote:

> I posted a question earlier today asking, basically, which RH to upgrade
> to, 8 or 9. If I read you correctly, neither is optimal.

I don't know about 8. My only problem with 9 was the jerky video, which was
fixed by a kernel recompile (not with RH sources, but from kernel.org).

> Although perhaps RH could provide the skeleton of apps and services, and
> then I could fix the kernel as you suggest ...

It seems like that would work. RH does NOT come with alsa sound drivers, so
you will also need to do that yourself (if you don't want to use oss
drivers).

-Chad

lan at falleagle

Jun 6, 2003, 9:36 AM

Post #24 of 24 (2964 views)
Permalink

Re: PVR250 + TVWonder = jerky FIXED [In reply to]

On Thu, Jun 05, 2003 at 10:50:27PM -0500, Chad McQuinn wrote:
> On 6/5/03 6:35 PM, "Lan Barnes" <lan [at] falleagle> wrote:
>
> > I posted a question earlier today asking, basically, which RH to upgrade
> > to, 8 or 9. If I read you correctly, neither is optimal.
>
> I don't know about 8. My only problem with 9 was the jerky video, which was
> fixed by a kernel recompile (not with RH sources, but from kernel.org).
>

Thanks for the reply, and duly noted. I have engraved it into my brain:
"jerky video, try the kernel.org's latest." Everything, right now, is
for future reference ;-)

> > Although perhaps RH could provide the skeleton of apps and services, and
> > then I could fix the kernel as you suggest ...
>
> It seems like that would work. RH does NOT come with alsa sound drivers, so
> you will also need to do that yourself (if you don't want to use oss
> drivers).
>

And I will save this for the day when it will make more sense to me.

... talked to my wife about a mythTV HW budget last night. We decided
(i.e. I negotiated) to start with a used AMD 450 with maybe 3 G disk
just to get the SW working and to gain understanding. Then I could
transfer all the working guts (tuner card, sound card etc etc) to a more
appropriate platform for the useful model. That seems to be an approach
others on this list have profited from.

Comments welcome but not necessary.

--
Lan Barnes lan [at] falleagle
Linux Guy, SCM Specialist 858-354-0616

A man who is about to tell the truth should have one
foot in the stirrup.
- Traditional Mongol Proverb

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads