Mailing List Archive: MythTV: Dev

what does "DVBRec(1): PID 0x840 discontinuity detected" mean?

Index | Next | Previous | View Threaded

adeffs.mythtv at gmail

Sep 29, 2006, 11:59 AM

Post #1 of 21 (8135 views)
Permalink

what does "DVBRec(1): PID 0x840 discontinuity detected" mean?

Starting about 3 weeks ago I've been getting these errors with lots of
glitches on my ATSC tuners.

I had the cable guy come out today and he cleaned up some of the noise
being experienced on the line and said that the signal out of the wall
is as good as it gets.

So what I'm wondering is what else could be causing errors like these:
2006-09-29 14:47:56.303 DVBRec(1): PID 0x840 discontinuity detected
2006-09-29 14:47:56.304 DVBRec(1): PID 0x840 discontinuity detected
2006-09-29 14:48:01.727 DVBRec(2): PID 0x800 discontinuity detected
2006-09-29 14:48:04.726 DVBRec(1): PID 0x840 discontinuity detected
2006-09-29 14:48:04.739 DVBRec(1): PID 0x840 discontinuity detected
2006-09-29 14:48:09.229 DVBRec(1): PID 0x840 discontinuity detected
2006-09-29 14:48:09.233 DVBRec(1): PID 0x840 discontinuity detected
2006-09-29 14:48:21.002 DVBRec(0): PID 0x800 discontinuity detected
2006-09-29 14:48:21.039 DVBRec(0): PID 0x800 discontinuity detected
2006-09-29 14:48:21.041 DVBRec(0): PID 0x801 discontinuity detected
2006-09-29 14:48:21.042 DVBRec(0): PID 0x802 discontinuity detected
2006-09-29 14:48:26.348 DVBRec(2): PID 0x800 discontinuity detected
2006-09-29 14:48:26.349 DVBRec(1): PID 0x841 discontinuity detected
2006-09-29 14:48:26.350 DVBRec(2): PID 0x800 discontinuity detected
2006-09-29 14:48:26.350 DVBRec(1): PID 0x840 discontinuity detected
2006-09-29 14:48:26.354 DVBRec(1): PID 0x841 discontinuity detected
2006-09-29 14:48:29.753 DVBRec(2): PID 0x800 discontinuity detected
2006-09-29 14:48:29.754 DVBRec(2): PID 0x800 discontinuity detected

could heat or anything internal to my backend be the cause? latency?

--
Steve
Before you ask, read the FAQ!
http://www.mythtv.org/wiki/index.php/Frequently_Asked_Questions
then search the Wiki, and this list,
http://www.gossamer-threads.com/lists/mythtv/
Mailinglist etiquette -
http://www.mythtv.org/wiki/index.php/Mailing_List_etiquette
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

stuarta at squashedfrog

Sep 29, 2006, 12:42 PM

Post #2 of 21 (8093 views)
Permalink

Re: what does "DVBRec(1): PID 0x840 discontinuity detected" mean? [In reply to]

On Fri, Sep 29, 2006 at 02:59:03PM -0400, Steven Adeff wrote:
> Starting about 3 weeks ago I've been getting these errors with lots of
> glitches on my ATSC tuners.
>
> I had the cable guy come out today and he cleaned up some of the noise
> being experienced on the line and said that the signal out of the wall
> is as good as it gets.

okay so the wall signal is pretty good.

>
> So what I'm wondering is what else could be causing errors like these:
> 2006-09-29 14:47:56.303 DVBRec(1): PID 0x840 discontinuity detected
> 2006-09-29 14:47:56.304 DVBRec(1): PID 0x840 discontinuity detected

[...]

These are caused by the next packet being recieved on that pid,
not being the one that is expected.

The main cause is bad signal, but you've had that sorted.
It can also caused by things like power spikes, or other
intermittant interferance.

However, looking at this i've noticed something interesting.
We don't throw away the packet if we detect a discontinuity.
This would be okay if the new packet CC = last seen CC, as this
would possibly be a duplicate packet. But if the new packet CC
is > last seen CC + 1 (modulo 0xf) then the full TS packet is
broken and should be thrown away....

I'll whip up a quick patch for that...

Stuart

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

adeffs.mythtv at gmail

Sep 29, 2006, 4:19 PM

Post #3 of 21 (8036 views)
Permalink

Re: what does "DVBRec(1): PID 0x840 discontinuity detected" mean? [In reply to]

On 9/29/06, Stuart Auchterlonie <stuarta [at] squashedfrog> wrote:
> On Fri, Sep 29, 2006 at 02:59:03PM -0400, Steven Adeff wrote:
> > Starting about 3 weeks ago I've been getting these errors with lots of
> > glitches on my ATSC tuners.
> >
> > I had the cable guy come out today and he cleaned up some of the noise
> > being experienced on the line and said that the signal out of the wall
> > is as good as it gets.
>
> okay so the wall signal is pretty good.
>
> >
> > So what I'm wondering is what else could be causing errors like these:
> > 2006-09-29 14:47:56.303 DVBRec(1): PID 0x840 discontinuity detected
> > 2006-09-29 14:47:56.304 DVBRec(1): PID 0x840 discontinuity detected
>
> [...]
>
> These are caused by the next packet being recieved on that pid,
> not being the one that is expected.
>
> The main cause is bad signal, but you've had that sorted.
> It can also caused by things like power spikes, or other
> intermittant interferance.
>
> However, looking at this i've noticed something interesting.
> We don't throw away the packet if we detect a discontinuity.
> This would be okay if the new packet CC = last seen CC, as this
> would possibly be a duplicate packet. But if the new packet CC
> is > last seen CC + 1 (modulo 0xf) then the full TS packet is
> broken and should be thrown away....
>
> I'll whip up a quick patch for that...

thanks, let me know if I can provide any more information. I do know
that my HD3000 is more prone to this error than either of my Aver
A180's (which 95% of the time show the problem at the same time).

--
Steve
Before you ask, read the FAQ!
http://www.mythtv.org/wiki/index.php/Frequently_Asked_Questions
then search the Wiki, and this list,
http://www.gossamer-threads.com/lists/mythtv/
Mailinglist etiquette -
http://www.mythtv.org/wiki/index.php/Mailing_List_etiquette
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

stuarta at squashedfrog

Sep 30, 2006, 1:59 AM

Post #4 of 21 (8006 views)
Permalink

Re: what does "DVBRec(1): PID 0x840 discontinuity detected" mean? [In reply to]

On Fri, Sep 29, 2006 at 07:19:02PM -0400, Steven Adeff wrote:
> On 9/29/06, Stuart Auchterlonie <stuarta [at] squashedfrog> wrote:
> >
> > These are caused by the next packet being recieved on that pid,
> > not being the one that is expected.
> >
> > The main cause is bad signal, but you've had that sorted.
> > It can also caused by things like power spikes, or other
> > intermittant interferance.
> >
> > However, looking at this i've noticed something interesting.
> > We don't throw away the packet if we detect a discontinuity.
> > This would be okay if the new packet CC = last seen CC, as this
> > would possibly be a duplicate packet. But if the new packet CC
> > is > last seen CC + 1 (modulo 0xf) then the full TS packet is
> > broken and should be thrown away....
> >
> > I'll whip up a quick patch for that...
>
> thanks, let me know if I can provide any more information. I do know
> that my HD3000 is more prone to this error than either of my Aver
> A180's (which 95% of the time show the problem at the same time).
>

That is to be expected, since some form of electrical interference
would hit the input and all cards equally. It looks like the HD3000
is more sensitive to this noise..

The patch has gone in in changeset 11334.

Stuart

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

adeffs.mythtv at gmail

Sep 30, 2006, 8:20 AM

Post #5 of 21 (8016 views)
Permalink

Re: what does "DVBRec(1): PID 0x840 discontinuity detected" mean? [In reply to]

On 9/30/06, Stuart Auchterlonie <stuarta [at] squashedfrog> wrote:
> On Fri, Sep 29, 2006 at 07:19:02PM -0400, Steven Adeff wrote:
> > On 9/29/06, Stuart Auchterlonie <stuarta [at] squashedfrog> wrote:
> > >
> > > These are caused by the next packet being recieved on that pid,
> > > not being the one that is expected.
> > >
> > > The main cause is bad signal, but you've had that sorted.
> > > It can also caused by things like power spikes, or other
> > > intermittant interferance.
> > >
> > > However, looking at this i've noticed something interesting.
> > > We don't throw away the packet if we detect a discontinuity.
> > > This would be okay if the new packet CC = last seen CC, as this
> > > would possibly be a duplicate packet. But if the new packet CC
> > > is > last seen CC + 1 (modulo 0xf) then the full TS packet is
> > > broken and should be thrown away....
> > >
> > > I'll whip up a quick patch for that...
> >
> > thanks, let me know if I can provide any more information. I do know
> > that my HD3000 is more prone to this error than either of my Aver
> > A180's (which 95% of the time show the problem at the same time).
> >
>
> That is to be expected, since some form of electrical interference
> would hit the input and all cards equally. It looks like the HD3000
> is more sensitive to this noise..
>
> The patch has gone in in changeset 11334.

Is it safe to apply the diff for 11334 to 0-20-fixes or will it need
other patches to work?

--
Steve
Before you ask, read the FAQ!
http://www.mythtv.org/wiki/index.php/Frequently_Asked_Questions
then search the Wiki, and this list,
http://www.gossamer-threads.com/lists/mythtv/
Mailinglist etiquette -
http://www.mythtv.org/wiki/index.php/Mailing_List_etiquette
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

adeffs.mythtv at gmail

Sep 30, 2006, 12:05 PM

Post #6 of 21 (8005 views)
Permalink

Re: what does "DVBRec(1): PID 0x840 discontinuity detected" mean? [In reply to]

On 9/30/06, Steven Adeff <adeffs.mythtv [at] gmail> wrote:
> On 9/30/06, Stuart Auchterlonie <stuarta [at] squashedfrog> wrote:
> > On Fri, Sep 29, 2006 at 07:19:02PM -0400, Steven Adeff wrote:
> > > On 9/29/06, Stuart Auchterlonie <stuarta [at] squashedfrog> wrote:
> > > >
> > > > These are caused by the next packet being recieved on that pid,
> > > > not being the one that is expected.
> > > >
> > > > The main cause is bad signal, but you've had that sorted.
> > > > It can also caused by things like power spikes, or other
> > > > intermittant interferance.
> > > >
> > > > However, looking at this i've noticed something interesting.
> > > > We don't throw away the packet if we detect a discontinuity.
> > > > This would be okay if the new packet CC = last seen CC, as this
> > > > would possibly be a duplicate packet. But if the new packet CC
> > > > is > last seen CC + 1 (modulo 0xf) then the full TS packet is
> > > > broken and should be thrown away....
> > > >
> > > > I'll whip up a quick patch for that...
> > >
> > > thanks, let me know if I can provide any more information. I do know
> > > that my HD3000 is more prone to this error than either of my Aver
> > > A180's (which 95% of the time show the problem at the same time).
> > >
> >
> > That is to be expected, since some form of electrical interference
> > would hit the input and all cards equally. It looks like the HD3000
> > is more sensitive to this noise..
> >
> > The patch has gone in in changeset 11334.
>
> Is it safe to apply the diff for 11334 to 0-20-fixes or will it need
> other patches to work?

well, I did that anyway, and it seems as though only my HD3000 card
has issues (perhaps moving it to another pci slot?), as the A180's
recorded together fine, and only showed any problems once the HD3000
started recording.

any way, let me know about how exactly I should test the patch (I'll
guess I did it wrong) and I'll try that...

--
Steve
Before you ask, read the FAQ!
http://www.mythtv.org/wiki/index.php/Frequently_Asked_Questions
then search the Wiki, and this list,
http://www.gossamer-threads.com/lists/mythtv/
Mailinglist etiquette -
http://www.mythtv.org/wiki/index.php/Mailing_List_etiquette
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

adeffs.mythtv at gmail

Oct 2, 2006, 6:43 PM

Post #7 of 21 (7992 views)
Permalink

Re: what does "DVBRec(1): PID 0x840 discontinuity detected" mean? [In reply to]

On 9/30/06, Steven Adeff <adeffs.mythtv [at] gmail> wrote:
> On 9/30/06, Steven Adeff <adeffs.mythtv [at] gmail> wrote:
> > On 9/30/06, Stuart Auchterlonie <stuarta [at] squashedfrog> wrote:
> > > On Fri, Sep 29, 2006 at 07:19:02PM -0400, Steven Adeff wrote:
> > > > On 9/29/06, Stuart Auchterlonie <stuarta [at] squashedfrog> wrote:
> > > > >
> > > > > These are caused by the next packet being recieved on that pid,
> > > > > not being the one that is expected.
> > > > >
> > > > > The main cause is bad signal, but you've had that sorted.
> > > > > It can also caused by things like power spikes, or other
> > > > > intermittant interferance.
> > > > >
> > > > > However, looking at this i've noticed something interesting.
> > > > > We don't throw away the packet if we detect a discontinuity.
> > > > > This would be okay if the new packet CC = last seen CC, as this
> > > > > would possibly be a duplicate packet. But if the new packet CC
> > > > > is > last seen CC + 1 (modulo 0xf) then the full TS packet is
> > > > > broken and should be thrown away....
> > > > >
> > > > > I'll whip up a quick patch for that...
> > > >
> > > > thanks, let me know if I can provide any more information. I do know
> > > > that my HD3000 is more prone to this error than either of my Aver
> > > > A180's (which 95% of the time show the problem at the same time).
> > > >
> > >
> > > That is to be expected, since some form of electrical interference
> > > would hit the input and all cards equally. It looks like the HD3000
> > > is more sensitive to this noise..
> > >
> > > The patch has gone in in changeset 11334.
> >
> > Is it safe to apply the diff for 11334 to 0-20-fixes or will it need
> > other patches to work?
>
> well, I did that anyway, and it seems as though only my HD3000 card
> has issues (perhaps moving it to another pci slot?), as the A180's
> recorded together fine, and only showed any problems once the HD3000
> started recording.
>
> any way, let me know about how exactly I should test the patch (I'll
> guess I did it wrong) and I'll try that...

errors still show up but now they don't cause me to miss whole blocks
of seconds, just minor blips. which i guess is an improvement. I'd
still love to know why this started happening. I even replaced the
HD3000 with a new card and get the problem....

--
Steve
Before you ask, read the FAQ!
http://www.mythtv.org/wiki/index.php/Frequently_Asked_Questions
then search the Wiki, and this list,
http://www.gossamer-threads.com/lists/mythtv/
Mailinglist etiquette -
http://www.mythtv.org/wiki/index.php/Mailing_List_etiquette
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

stuarta at squashedfrog

Oct 3, 2006, 1:03 AM

Post #8 of 21 (7976 views)
Permalink

Re: what does "DVBRec(1): PID 0x840 discontinuity detected" mean? [In reply to]

On Mon, Oct 02, 2006 at 09:43:43PM -0400, Steven Adeff wrote:
> > >
> > > Is it safe to apply the diff for 11334 to 0-20-fixes or will it need
> > > other patches to work?
> >
> > well, I did that anyway, and it seems as though only my HD3000 card
> > has issues (perhaps moving it to another pci slot?), as the A180's
> > recorded together fine, and only showed any problems once the HD3000
> > started recording.
> >
> > any way, let me know about how exactly I should test the patch (I'll
> > guess I did it wrong) and I'll try that...
>
> errors still show up but now they don't cause me to miss whole blocks
> of seconds, just minor blips. which i guess is an improvement. I'd
> still love to know why this started happening. I even replaced the
> HD3000 with a new card and get the problem....
>

That's what I would expect it to do. Previously it was keeping
the partial packet when it suffered a discontinuity. Now it throws
away that partial packet and waits for the start of a new one.

The net effect as you have noticed is that only the small error
is seen, rather than the larger one.

Stuart

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

paulrwheeler at gmail

Oct 3, 2006, 4:04 AM

Post #9 of 21 (7968 views)
Permalink

Re: what does "DVBRec(1): PID 0x840 discontinuity detected" mean? [In reply to]

On 10/3/06, Stuart Auchterlonie <stuarta [at] squashedfrog> wrote:
> On Mon, Oct 02, 2006 at 09:43:43PM -0400, Steven Adeff wrote:
> > > >
> > > > Is it safe to apply the diff for 11334 to 0-20-fixes or will it need
> > > > other patches to work?
> > >
> > > well, I did that anyway, and it seems as though only my HD3000 card
> > > has issues (perhaps moving it to another pci slot?), as the A180's
> > > recorded together fine, and only showed any problems once the HD3000
> > > started recording.
> > >
> > > any way, let me know about how exactly I should test the patch (I'll
> > > guess I did it wrong) and I'll try that...
> >
> > errors still show up but now they don't cause me to miss whole blocks
> > of seconds, just minor blips. which i guess is an improvement. I'd
> > still love to know why this started happening. I even replaced the
> > HD3000 with a new card and get the problem....
> >
>
> That's what I would expect it to do. Previously it was keeping
> the partial packet when it suffered a discontinuity. Now it throws
> away that partial packet and waits for the start of a new one.
>
> The net effect as you have noticed is that only the small error
> is seen, rather than the larger one.
>
Is it possible to apply this to fixes as well as trunk? Does it count
enough as a bug?

Thanks

Paul

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

stuarta at squashedfrog

Oct 3, 2006, 4:11 AM

Post #10 of 21 (7979 views)
Permalink

Re: what does "DVBRec(1): PID 0x840 discontinuity detected" mean? [In reply to]

On Tue, Oct 03, 2006 at 12:04:35PM +0100, Paul Wheeler wrote:
> > >
> >
> > That's what I would expect it to do. Previously it was keeping
> > the partial packet when it suffered a discontinuity. Now it throws
> > away that partial packet and waits for the start of a new one.
> >
> > The net effect as you have noticed is that only the small error
> > is seen, rather than the larger one.
> >
> Is it possible to apply this to fixes as well as trunk? Does it count
> enough as a bug?
>

It's in quite a fundamental area of the packet processing,
so i'm going to await further reports for a while before
considering it for inclusion.

Stuart

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

adeffs.mythtv at gmail

Oct 3, 2006, 5:06 AM

Post #11 of 21 (7982 views)
Permalink

Re: what does "DVBRec(1): PID 0x840 discontinuity detected" mean? [In reply to]

On 10/3/06, Stuart Auchterlonie <stuarta [at] squashedfrog> wrote:
> On Tue, Oct 03, 2006 at 12:04:35PM +0100, Paul Wheeler wrote:
> > > That's what I would expect it to do. Previously it was keeping
> > > the partial packet when it suffered a discontinuity. Now it throws
> > > away that partial packet and waits for the start of a new one.
> > >
> > > The net effect as you have noticed is that only the small error
> > > is seen, rather than the larger one.
> > >
> > Is it possible to apply this to fixes as well as trunk? Does it count
> > enough as a bug?
> >
>
> It's in quite a fundamental area of the packet processing,
> so i'm going to await further reports for a while before
> considering it for inclusion.

is there a way to tell if the issue is with the signal the card is
receiving or something internal to the computer? I'm just having a
hard time understanding why this would randomly start happening and
the cable line looks to be clean?

It also seems to occur more during heavy i/o load, though this is more
a casual observance. When all three of my HD recorders are going it
seems to be more of an issue than when just one is.

--
Steve
Before you ask, read the FAQ!
http://www.mythtv.org/wiki/index.php/Frequently_Asked_Questions
then search the Wiki, and this list,
http://www.gossamer-threads.com/lists/mythtv/
Mailinglist etiquette -
http://www.mythtv.org/wiki/index.php/Mailing_List_etiquette
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

stuarta at squashedfrog

Oct 3, 2006, 5:53 AM

Post #12 of 21 (7986 views)
Permalink

Re: what does "DVBRec(1): PID 0x840 discontinuity detected" mean? [In reply to]

On Tue, Oct 03, 2006 at 08:06:21AM -0400, Steven Adeff wrote:
> >
> > It's in quite a fundamental area of the packet processing,
> > so i'm going to await further reports for a while before
> > considering it for inclusion.
>
> is there a way to tell if the issue is with the signal the card is
> receiving or something internal to the computer? I'm just having a
> hard time understanding why this would randomly start happening and
> the cable line looks to be clean?
>
> It also seems to occur more during heavy i/o load, though this is more
> a casual observance. When all three of my HD recorders are going it
> seems to be more of an issue than when just one is.
>

Sounds like you may be running into limitations with
1) PCI bus maximum throughput
2) I/O throughput to your storage

also check your dmesg and see if any errors are being thrown
by the driver. verify also that each card has it's own interrupt.

Stuart

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

danielk at cuymedia

Oct 3, 2006, 6:00 AM

Post #13 of 21 (7984 views)
Permalink

Re: what does "DVBRec(1): PID 0x840 discontinuity detected" mean? [In reply to]

On Tue, 2006-10-03 at 12:11 +0100, Stuart Auchterlonie wrote:
> On Tue, Oct 03, 2006 at 12:04:35PM +0100, Paul Wheeler wrote:
> > Is it possible to apply this to fixes as well as trunk? Does it count
> > enough as a bug?
> It's in quite a fundamental area of the packet processing,
> so i'm going to await further reports for a while before
> considering it for inclusion.

Yeah, let it sit in SVN for a couple weeks.

BTW this was a known problem when I first committed the code,
but I thought these events would be very rare so I figured it
wasn't a big deal that you lost two packets instead of one..
There is probably something wrong with the PCI latencies or
some hardware malfunction if this is limited to some ATSC cards.

-- Daniel

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

adeffs.mythtv at gmail

Oct 3, 2006, 6:07 AM

Post #14 of 21 (7971 views)
Permalink

Re: what does "DVBRec(1): PID 0x840 discontinuity detected" mean? [In reply to]

On 10/3/06, Stuart Auchterlonie <stuarta [at] squashedfrog> wrote:
> On Tue, Oct 03, 2006 at 08:06:21AM -0400, Steven Adeff wrote:
> > >
> > > It's in quite a fundamental area of the packet processing,
> > > so i'm going to await further reports for a while before
> > > considering it for inclusion.
> >
> > is there a way to tell if the issue is with the signal the card is
> > receiving or something internal to the computer? I'm just having a
> > hard time understanding why this would randomly start happening and
> > the cable line looks to be clean?
> >
> > It also seems to occur more during heavy i/o load, though this is more
> > a casual observance. When all three of my HD recorders are going it
> > seems to be more of an issue than when just one is.
> >
>
> Sounds like you may be running into limitations with
> 1) PCI bus maximum throughput
> 2) I/O throughput to your storage
>
> also check your dmesg and see if any errors are being thrown
> by the driver. verify also that each card has it's own interrupt.

Stuart, thanks for helping me with this. Some "answers" to your questions...

I/O: I've been using the same RAID10 setup with no changes for months
now. I wonder if perhaps fragmentation on my recordings drive is
slowing it down now to the point of being an issue? I run XFS, I don't
know if its something that can be an issue with XFS? I discovered
xfs_fsr well into having a full recording drive, so I don't use it.
perhaps I should erase all watched recordings that I can to empty the
drive out and then begin doing a defrag process?

IRQ:
Subsystem: Hauppauge computer works Inc. WinTV PVR 150
Flags: bus master, medium devsel, latency 64, IRQ 225
Memory at e8000000 (32-bit, prefetchable) [size=64M]
Capabilities: [44] Power Management version 2

Subsystem: pcHDTV pcHDTV HD3000 HDTV
Flags: bus master, medium devsel, latency 32, IRQ 10
Memory at f9000000 (32-bit, non-prefetchable) [size=16M]
Capabilities: [44] Vital Product Data
Capabilities: [4c] Power Management version 2

Subsystem: pcHDTV pcHDTV HD3000 HDTV
Flags: bus master, medium devsel, latency 32, IRQ 217
Memory at fa000000 (32-bit, non-prefetchable) [size=16M]
Capabilities: [4c] Power Management version 2

Subsystem: Avermedia Technologies Inc AVerTVHD MCE A180
Flags: bus master, medium devsel, latency 32, IRQ 233
Memory at fbffe000 (32-bit, non-prefetchable) [size=2K]
Capabilities: [40] Power Management version 2

Subsystem: Avermedia Technologies Inc AVerTVHD MCE A180
Flags: bus master, medium devsel, latency 32, IRQ 225
Memory at fbfff000 (32-bit, non-prefetchable) [size=2K]
Capabilities: [40] Power Management version 2

it looks like one of my A180's and my PVR150 are on the same IRQ.

In my kern.log I seem to be getting a lot of
Oct 2 21:29:32 mythbox kernel: cx88[0]/2: queue is empty - first active
Oct 2 21:29:32 mythbox kernel: cx88[0]/2: cx8802_start_dma w: 0, h: 0, f: 2
Oct 2 21:29:32 mythbox kernel: cx88[0]/2: setting the interrupt mask
Oct 2 21:29:32 mythbox kernel: cx88[0]/2: [ffff81003a356200/0]
cx8802_buf_queue - first active
Oct 2 21:29:32 mythbox kernel: cx88[0]/2: cx8802_restart_queue
Oct 2 21:29:32 mythbox kernel: cx88[0]/2: cx8802_restart_queue: queue is empty
Oct 2 21:29:32 mythbox kernel: cx88[0]/2: queue is empty - first active
Oct 2 21:29:32 mythbox kernel: cx88[0]/2: cx8802_start_dma w: 0, h: 0, f: 2
Oct 2 21:29:32 mythbox kernel: cx88[0]/2: setting the interrupt mask
Oct 2 21:29:32 mythbox kernel: cx88[0]/2: [ffff810012f8aa00/0]
cx8802_buf_queue - first active
Oct 2 21:29:33 mythbox kernel: cx88[0]/2: cx8802_restart_queue
Oct 2 21:29:33 mythbox kernel: cx88[0]/2: cx8802_restart_queue: queue is empty
Oct 2 21:29:33 mythbox kernel: cx88[0]/2: queue is empty - first active
Oct 2 21:29:33 mythbox kernel: cx88[0]/2: cx8802_start_dma w: 0, h: 0, f: 2
Oct 2 21:29:33 mythbox kernel: cx88[0]/2: setting the interrupt mask
Oct 2 21:29:33 mythbox kernel: cx88[0]/2: [ffff810015f3be00/0]
cx8802_buf_queue - first active
Oct 2 22:01:30 mythbox kernel: cx88[0]/2: cx8802_restart_queue
Oct 2 22:01:30 mythbox kernel: cx88[0]/2: cx8802_restart_queue: queue is empty

let me know if you see anything that jumps out at you that I should
look into/etc.

--
Steve
Before you ask, read the FAQ!
http://www.mythtv.org/wiki/index.php/Frequently_Asked_Questions
then search the Wiki, and this list,
http://www.gossamer-threads.com/lists/mythtv/
Mailinglist etiquette -
http://www.mythtv.org/wiki/index.php/Mailing_List_etiquette
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

adeffs.mythtv at gmail

Oct 3, 2006, 6:13 AM

Post #15 of 21 (7974 views)
Permalink

Re: what does "DVBRec(1): PID 0x840 discontinuity detected" mean? [In reply to]

On 10/3/06, Daniel Kristjansson <danielk [at] cuymedia> wrote:
> On Tue, 2006-10-03 at 12:11 +0100, Stuart Auchterlonie wrote:
> > On Tue, Oct 03, 2006 at 12:04:35PM +0100, Paul Wheeler wrote:
> > > Is it possible to apply this to fixes as well as trunk? Does it count
> > > enough as a bug?
> > It's in quite a fundamental area of the packet processing,
> > so i'm going to await further reports for a while before
> > considering it for inclusion.
>
> Yeah, let it sit in SVN for a couple weeks.
>
> BTW this was a known problem when I first committed the code,
> but I thought these events would be very rare so I figured it
> wasn't a big deal that you lost two packets instead of one..
> There is probably something wrong with the PCI latencies or
> some hardware malfunction if this is limited to some ATSC cards.

It's not limited to, but it does occur *more often* on my HD3000. Come
to think of it. This all started "around the time" I installed 0.20SVN
after the feature freeze. I need to keep better track of dates/times I
make changes (especially to SVN!).

At first I thought it was just the cable line since we were seeing
dropped frames through our cable box that we have directly connected
to the TV(for the HD channels Myth can't record). The cable guy came
and he said there were some issues, which he fixed. The cable box
connected directly to the TV was fine and his meter was showing no
issues on the line in the closet where my backend is. So now I seek
the advice of the sage's here =)

--
Steve
Before you ask, read the FAQ!
http://www.mythtv.org/wiki/index.php/Frequently_Asked_Questions
then search the Wiki, and this list,
http://www.gossamer-threads.com/lists/mythtv/
Mailinglist etiquette -
http://www.mythtv.org/wiki/index.php/Mailing_List_etiquette
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

adeffs.mythtv at gmail

Oct 3, 2006, 2:49 PM

Post #16 of 21 (7961 views)
Permalink

Re: what does "DVBRec(1): PID 0x840 discontinuity detected" mean? [In reply to]

On 10/3/06, Steven Adeff <adeffs.mythtv [at] gmail> wrote:
> On 10/3/06, Stuart Auchterlonie <stuarta [at] squashedfrog> wrote:
> > On Tue, Oct 03, 2006 at 08:06:21AM -0400, Steven Adeff wrote:
> > > >
> > > > It's in quite a fundamental area of the packet processing,
> > > > so i'm going to await further reports for a while before
> > > > considering it for inclusion.
> > >
> > > is there a way to tell if the issue is with the signal the card is
> > > receiving or something internal to the computer? I'm just having a
> > > hard time understanding why this would randomly start happening and
> > > the cable line looks to be clean?
> > >
> > > It also seems to occur more during heavy i/o load, though this is more
> > > a casual observance. When all three of my HD recorders are going it
> > > seems to be more of an issue than when just one is.
> > >
> >
> > Sounds like you may be running into limitations with
> > 1) PCI bus maximum throughput
> > 2) I/O throughput to your storage
> >
> > also check your dmesg and see if any errors are being thrown
> > by the driver. verify also that each card has it's own interrupt.
>
> Stuart, thanks for helping me with this. Some "answers" to your questions...
>
> I/O: I've been using the same RAID10 setup with no changes for months
> now. I wonder if perhaps fragmentation on my recordings drive is
> slowing it down now to the point of being an issue? I run XFS, I don't
> know if its something that can be an issue with XFS? I discovered
> xfs_fsr well into having a full recording drive, so I don't use it.
> perhaps I should erase all watched recordings that I can to empty the
> drive out and then begin doing a defrag process?
>
> IRQ:
> Subsystem: Hauppauge computer works Inc. WinTV PVR 150
> Flags: bus master, medium devsel, latency 64, IRQ 225
> Memory at e8000000 (32-bit, prefetchable) [size=64M]
> Capabilities: [44] Power Management version 2
>
> Subsystem: pcHDTV pcHDTV HD3000 HDTV
> Flags: bus master, medium devsel, latency 32, IRQ 10
> Memory at f9000000 (32-bit, non-prefetchable) [size=16M]
> Capabilities: [44] Vital Product Data
> Capabilities: [4c] Power Management version 2
>
> Subsystem: pcHDTV pcHDTV HD3000 HDTV
> Flags: bus master, medium devsel, latency 32, IRQ 217
> Memory at fa000000 (32-bit, non-prefetchable) [size=16M]
> Capabilities: [4c] Power Management version 2
>
> Subsystem: Avermedia Technologies Inc AVerTVHD MCE A180
> Flags: bus master, medium devsel, latency 32, IRQ 233
> Memory at fbffe000 (32-bit, non-prefetchable) [size=2K]
> Capabilities: [40] Power Management version 2
>
> Subsystem: Avermedia Technologies Inc AVerTVHD MCE A180
> Flags: bus master, medium devsel, latency 32, IRQ 225
> Memory at fbfff000 (32-bit, non-prefetchable) [size=2K]
> Capabilities: [40] Power Management version 2
>
> it looks like one of my A180's and my PVR150 are on the same IRQ.
>
> In my kern.log I seem to be getting a lot of
> Oct 2 21:29:32 mythbox kernel: cx88[0]/2: queue is empty - first active
> Oct 2 21:29:32 mythbox kernel: cx88[0]/2: cx8802_start_dma w: 0, h: 0, f: 2
> Oct 2 21:29:32 mythbox kernel: cx88[0]/2: setting the interrupt mask
> Oct 2 21:29:32 mythbox kernel: cx88[0]/2: [ffff81003a356200/0]
> cx8802_buf_queue - first active
> Oct 2 21:29:32 mythbox kernel: cx88[0]/2: cx8802_restart_queue
> Oct 2 21:29:32 mythbox kernel: cx88[0]/2: cx8802_restart_queue: queue is empty
> Oct 2 21:29:32 mythbox kernel: cx88[0]/2: queue is empty - first active
> Oct 2 21:29:32 mythbox kernel: cx88[0]/2: cx8802_start_dma w: 0, h: 0, f: 2
> Oct 2 21:29:32 mythbox kernel: cx88[0]/2: setting the interrupt mask
> Oct 2 21:29:32 mythbox kernel: cx88[0]/2: [ffff810012f8aa00/0]
> cx8802_buf_queue - first active
> Oct 2 21:29:33 mythbox kernel: cx88[0]/2: cx8802_restart_queue
> Oct 2 21:29:33 mythbox kernel: cx88[0]/2: cx8802_restart_queue: queue is empty
> Oct 2 21:29:33 mythbox kernel: cx88[0]/2: queue is empty - first active
> Oct 2 21:29:33 mythbox kernel: cx88[0]/2: cx8802_start_dma w: 0, h: 0, f: 2
> Oct 2 21:29:33 mythbox kernel: cx88[0]/2: setting the interrupt mask
> Oct 2 21:29:33 mythbox kernel: cx88[0]/2: [ffff810015f3be00/0]
> cx8802_buf_queue - first active
> Oct 2 22:01:30 mythbox kernel: cx88[0]/2: cx8802_restart_queue
> Oct 2 22:01:30 mythbox kernel: cx88[0]/2: cx8802_restart_queue: queue is empty
>
> let me know if you see anything that jumps out at you that I should
> look into/etc.

did a quick google that lead me to discover my two PATA drives in my
RAID were running
IO_support = 0 (default 16-bit)
instead of
IO_support = 1 (32-bit)

and unmaskirq was also off...
so I made those right. time to see what happens...

--
Steve
Before you ask, read the FAQ!
http://www.mythtv.org/wiki/index.php/Frequently_Asked_Questions
then search the Wiki, and this list,
http://www.gossamer-threads.com/lists/mythtv/
Mailinglist etiquette -
http://www.mythtv.org/wiki/index.php/Mailing_List_etiquette
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

adeffs.mythtv at gmail

Oct 4, 2006, 8:47 AM

Post #17 of 21 (7959 views)
Permalink

Re: what does "DVBRec(1): PID 0x840 discontinuity detected" mean? [In reply to]

On 10/3/06, Steven Adeff <adeffs.mythtv [at] gmail> wrote:
> On 10/3/06, Steven Adeff <adeffs.mythtv [at] gmail> wrote:
> > On 10/3/06, Stuart Auchterlonie <stuarta [at] squashedfrog> wrote:
> > > On Tue, Oct 03, 2006 at 08:06:21AM -0400, Steven Adeff wrote:
> > > > >
> > > > > It's in quite a fundamental area of the packet processing,
> > > > > so i'm going to await further reports for a while before
> > > > > considering it for inclusion.
> > > >
> > > > is there a way to tell if the issue is with the signal the card is
> > > > receiving or something internal to the computer? I'm just having a
> > > > hard time understanding why this would randomly start happening and
> > > > the cable line looks to be clean?
> > > >
> > > > It also seems to occur more during heavy i/o load, though this is more
> > > > a casual observance. When all three of my HD recorders are going it
> > > > seems to be more of an issue than when just one is.
> > > >
> > >
> > > Sounds like you may be running into limitations with
> > > 1) PCI bus maximum throughput
> > > 2) I/O throughput to your storage
> > >
> > > also check your dmesg and see if any errors are being thrown
> > > by the driver. verify also that each card has it's own interrupt.
> >
> > Stuart, thanks for helping me with this. Some "answers" to your questions...
> >
> > I/O: I've been using the same RAID10 setup with no changes for months
> > now. I wonder if perhaps fragmentation on my recordings drive is
> > slowing it down now to the point of being an issue? I run XFS, I don't
> > know if its something that can be an issue with XFS? I discovered
> > xfs_fsr well into having a full recording drive, so I don't use it.
> > perhaps I should erase all watched recordings that I can to empty the
> > drive out and then begin doing a defrag process?
> >
> > IRQ:
> > Subsystem: Hauppauge computer works Inc. WinTV PVR 150
> > Flags: bus master, medium devsel, latency 64, IRQ 225
> > Memory at e8000000 (32-bit, prefetchable) [size=64M]
> > Capabilities: [44] Power Management version 2
> >
> > Subsystem: pcHDTV pcHDTV HD3000 HDTV
> > Flags: bus master, medium devsel, latency 32, IRQ 10
> > Memory at f9000000 (32-bit, non-prefetchable) [size=16M]
> > Capabilities: [44] Vital Product Data
> > Capabilities: [4c] Power Management version 2
> >
> > Subsystem: pcHDTV pcHDTV HD3000 HDTV
> > Flags: bus master, medium devsel, latency 32, IRQ 217
> > Memory at fa000000 (32-bit, non-prefetchable) [size=16M]
> > Capabilities: [4c] Power Management version 2
> >
> > Subsystem: Avermedia Technologies Inc AVerTVHD MCE A180
> > Flags: bus master, medium devsel, latency 32, IRQ 233
> > Memory at fbffe000 (32-bit, non-prefetchable) [size=2K]
> > Capabilities: [40] Power Management version 2
> >
> > Subsystem: Avermedia Technologies Inc AVerTVHD MCE A180
> > Flags: bus master, medium devsel, latency 32, IRQ 225
> > Memory at fbfff000 (32-bit, non-prefetchable) [size=2K]
> > Capabilities: [40] Power Management version 2
> >
> > it looks like one of my A180's and my PVR150 are on the same IRQ.
> >
> > In my kern.log I seem to be getting a lot of
> > Oct 2 21:29:32 mythbox kernel: cx88[0]/2: queue is empty - first active
> > Oct 2 21:29:32 mythbox kernel: cx88[0]/2: cx8802_start_dma w: 0, h: 0, f: 2
> > Oct 2 21:29:32 mythbox kernel: cx88[0]/2: setting the interrupt mask
> > Oct 2 21:29:32 mythbox kernel: cx88[0]/2: [ffff81003a356200/0]
> > cx8802_buf_queue - first active
> > Oct 2 21:29:32 mythbox kernel: cx88[0]/2: cx8802_restart_queue
> > Oct 2 21:29:32 mythbox kernel: cx88[0]/2: cx8802_restart_queue: queue is empty
> > Oct 2 21:29:32 mythbox kernel: cx88[0]/2: queue is empty - first active
> > Oct 2 21:29:32 mythbox kernel: cx88[0]/2: cx8802_start_dma w: 0, h: 0, f: 2
> > Oct 2 21:29:32 mythbox kernel: cx88[0]/2: setting the interrupt mask
> > Oct 2 21:29:32 mythbox kernel: cx88[0]/2: [ffff810012f8aa00/0]
> > cx8802_buf_queue - first active
> > Oct 2 21:29:33 mythbox kernel: cx88[0]/2: cx8802_restart_queue
> > Oct 2 21:29:33 mythbox kernel: cx88[0]/2: cx8802_restart_queue: queue is empty
> > Oct 2 21:29:33 mythbox kernel: cx88[0]/2: queue is empty - first active
> > Oct 2 21:29:33 mythbox kernel: cx88[0]/2: cx8802_start_dma w: 0, h: 0, f: 2
> > Oct 2 21:29:33 mythbox kernel: cx88[0]/2: setting the interrupt mask
> > Oct 2 21:29:33 mythbox kernel: cx88[0]/2: [ffff810015f3be00/0]
> > cx8802_buf_queue - first active
> > Oct 2 22:01:30 mythbox kernel: cx88[0]/2: cx8802_restart_queue
> > Oct 2 22:01:30 mythbox kernel: cx88[0]/2: cx8802_restart_queue: queue is empty
> >
> > let me know if you see anything that jumps out at you that I should
> > look into/etc.
>
> did a quick google that lead me to discover my two PATA drives in my
> RAID were running
> IO_support = 0 (default 16-bit)
> instead of
> IO_support = 1 (32-bit)
>
> and unmaskirq was also off...
> so I made those right. time to see what happens...

Doesn't seem to affect it.

I'm going to try moving the cards around inside the case (I moved them
early in trying to solve the problem) to see if where they used to sit
makes it go away. I do notice that the cx88 errors only seem to occur
at the beginning of a recording (at least now).

The patch has done well at preventing loss of large time chunks of
video so far. I just get a row of broken macroblocks now, which while
being "the suck", is at least watchable.

--
Steve
Before you ask, read the FAQ!
http://www.mythtv.org/wiki/index.php/Frequently_Asked_Questions
then search the Wiki, and this list,
http://www.gossamer-threads.com/lists/mythtv/
Mailinglist etiquette -
http://www.mythtv.org/wiki/index.php/Mailing_List_etiquette
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

adeffs.mythtv at gmail

Oct 4, 2006, 11:47 AM

Post #18 of 21 (8010 views)
Permalink

Re: what does "DVBRec(1): PID 0x840 discontinuity detected" mean? [In reply to]

On 10/4/06, Steven Adeff <adeffs.mythtv [at] gmail> wrote:
> On 10/3/06, Steven Adeff <adeffs.mythtv [at] gmail> wrote:
> > On 10/3/06, Steven Adeff <adeffs.mythtv [at] gmail> wrote:
> > > On 10/3/06, Stuart Auchterlonie <stuarta [at] squashedfrog> wrote:
> > > > On Tue, Oct 03, 2006 at 08:06:21AM -0400, Steven Adeff wrote:
> > > > > >
> > > > > > It's in quite a fundamental area of the packet processing,
> > > > > > so i'm going to await further reports for a while before
> > > > > > considering it for inclusion.
> > > > >
> > > > > is there a way to tell if the issue is with the signal the card is
> > > > > receiving or something internal to the computer? I'm just having a
> > > > > hard time understanding why this would randomly start happening and
> > > > > the cable line looks to be clean?
> > > > >
> > > > > It also seems to occur more during heavy i/o load, though this is more
> > > > > a casual observance. When all three of my HD recorders are going it
> > > > > seems to be more of an issue than when just one is.
> > > > >
> > > >
> > > > Sounds like you may be running into limitations with
> > > > 1) PCI bus maximum throughput
> > > > 2) I/O throughput to your storage
> > > >
> > > > also check your dmesg and see if any errors are being thrown
> > > > by the driver. verify also that each card has it's own interrupt.
> > >
> > > Stuart, thanks for helping me with this. Some "answers" to your questions...
> > >
> > > I/O: I've been using the same RAID10 setup with no changes for months
> > > now. I wonder if perhaps fragmentation on my recordings drive is
> > > slowing it down now to the point of being an issue? I run XFS, I don't
> > > know if its something that can be an issue with XFS? I discovered
> > > xfs_fsr well into having a full recording drive, so I don't use it.
> > > perhaps I should erase all watched recordings that I can to empty the
> > > drive out and then begin doing a defrag process?
> > >
> > > IRQ:
> > > Subsystem: Hauppauge computer works Inc. WinTV PVR 150
> > > Flags: bus master, medium devsel, latency 64, IRQ 225
> > > Memory at e8000000 (32-bit, prefetchable) [size=64M]
> > > Capabilities: [44] Power Management version 2
> > >
> > > Subsystem: pcHDTV pcHDTV HD3000 HDTV
> > > Flags: bus master, medium devsel, latency 32, IRQ 10
> > > Memory at f9000000 (32-bit, non-prefetchable) [size=16M]
> > > Capabilities: [44] Vital Product Data
> > > Capabilities: [4c] Power Management version 2
> > >
> > > Subsystem: pcHDTV pcHDTV HD3000 HDTV
> > > Flags: bus master, medium devsel, latency 32, IRQ 217
> > > Memory at fa000000 (32-bit, non-prefetchable) [size=16M]
> > > Capabilities: [4c] Power Management version 2
> > >
> > > Subsystem: Avermedia Technologies Inc AVerTVHD MCE A180
> > > Flags: bus master, medium devsel, latency 32, IRQ 233
> > > Memory at fbffe000 (32-bit, non-prefetchable) [size=2K]
> > > Capabilities: [40] Power Management version 2
> > >
> > > Subsystem: Avermedia Technologies Inc AVerTVHD MCE A180
> > > Flags: bus master, medium devsel, latency 32, IRQ 225
> > > Memory at fbfff000 (32-bit, non-prefetchable) [size=2K]
> > > Capabilities: [40] Power Management version 2
> > >
> > > it looks like one of my A180's and my PVR150 are on the same IRQ.
> > >
> > > In my kern.log I seem to be getting a lot of
> > > Oct 2 21:29:32 mythbox kernel: cx88[0]/2: queue is empty - first active
> > > Oct 2 21:29:32 mythbox kernel: cx88[0]/2: cx8802_start_dma w: 0, h: 0, f: 2
> > > Oct 2 21:29:32 mythbox kernel: cx88[0]/2: setting the interrupt mask
> > > Oct 2 21:29:32 mythbox kernel: cx88[0]/2: [ffff81003a356200/0]
> > > cx8802_buf_queue - first active
> > > Oct 2 21:29:32 mythbox kernel: cx88[0]/2: cx8802_restart_queue
> > > Oct 2 21:29:32 mythbox kernel: cx88[0]/2: cx8802_restart_queue: queue is empty
> > > Oct 2 21:29:32 mythbox kernel: cx88[0]/2: queue is empty - first active
> > > Oct 2 21:29:32 mythbox kernel: cx88[0]/2: cx8802_start_dma w: 0, h: 0, f: 2
> > > Oct 2 21:29:32 mythbox kernel: cx88[0]/2: setting the interrupt mask
> > > Oct 2 21:29:32 mythbox kernel: cx88[0]/2: [ffff810012f8aa00/0]
> > > cx8802_buf_queue - first active
> > > Oct 2 21:29:33 mythbox kernel: cx88[0]/2: cx8802_restart_queue
> > > Oct 2 21:29:33 mythbox kernel: cx88[0]/2: cx8802_restart_queue: queue is empty
> > > Oct 2 21:29:33 mythbox kernel: cx88[0]/2: queue is empty - first active
> > > Oct 2 21:29:33 mythbox kernel: cx88[0]/2: cx8802_start_dma w: 0, h: 0, f: 2
> > > Oct 2 21:29:33 mythbox kernel: cx88[0]/2: setting the interrupt mask
> > > Oct 2 21:29:33 mythbox kernel: cx88[0]/2: [ffff810015f3be00/0]
> > > cx8802_buf_queue - first active
> > > Oct 2 22:01:30 mythbox kernel: cx88[0]/2: cx8802_restart_queue
> > > Oct 2 22:01:30 mythbox kernel: cx88[0]/2: cx8802_restart_queue: queue is empty
> > >
> > > let me know if you see anything that jumps out at you that I should
> > > look into/etc.
> >
> > did a quick google that lead me to discover my two PATA drives in my
> > RAID were running
> > IO_support = 0 (default 16-bit)
> > instead of
> > IO_support = 1 (32-bit)
> >
> > and unmaskirq was also off...
> > so I made those right. time to see what happens...
>
> Doesn't seem to affect it.
>
> I'm going to try moving the cards around inside the case (I moved them
> early in trying to solve the problem) to see if where they used to sit
> makes it go away. I do notice that the cx88 errors only seem to occur
> at the beginning of a recording (at least now).
>
> The patch has done well at preventing loss of large time chunks of
> video so far. I just get a row of broken macroblocks now, which while
> being "the suck", is at least watchable.

more,
noticing some, what I think are, odd PID's in the discontinuity errors
for the HD3000 card:
2006-10-04 14:41:15.546 DVBRec(0): PID 0x940 discontinuity detected
2006-10-04 14:41:15.956 DVBRec(0): PID 0x940 discontinuity detected
2006-10-04 14:41:15.957 DVBRec(0): PID 0x941 discontinuity detected
2006-10-04 14:41:15.965 DVBRec(0): PID 0x0 discontinuity detected
2006-10-04 14:41:15.968 DVBRec(0): PID 0x31 discontinuity detected
2006-10-04 14:41:15.969 DVBRec(0): PID 0x32 discontinuity detected
2006-10-04 14:41:15.970 DVBRec(0): PID 0x33 discontinuity detected
2006-10-04 14:41:15.971 DVBRec(0): PID 0x34 discontinuity detected
2006-10-04 14:41:15.983 DVBRec(0): PID 0x30 discontinuity detected
2006-10-04 14:41:15.984 DVBRec(0): PID 0x35 discontinuity detected
2006-10-04 14:41:16.135 DVBRec(0): PID 0x940 discontinuity detected
2006-10-04 14:41:16.136 DVBRec(0): PID 0x941 discontinuity detected
2006-10-04 14:41:16.141 DVBRec(0): PID 0x33 discontinuity detected
2006-10-04 14:41:16.142 DVBRec(0): PID 0x31 discontinuity detected
2006-10-04 14:41:16.142 DVBRec(0): PID 0x30 discontinuity detected
2006-10-04 14:41:16.179 DVBRec(0): PID 0x35 discontinuity detected
2006-10-04 14:41:16.209 DVBRec(0): PID 0x32 discontinuity detected
2006-10-04 14:41:16.213 DVBRec(0): PID 0x34 discontinuity detected
2006-10-04 14:41:16.229 DVBRec(0): PID 0x0 discontinuity detected
2006-10-04 14:42:25.060 DVBRec(0): PID 0x940 discontinuity detected
2006-10-04 14:42:27.739 DVBRec(0): PID 0x940 discontinuity detected
2006-10-04 14:42:28.133 DVBRec(0): PID 0x941 discontinuity detected
2006-10-04 14:42:28.143 DVBRec(0): PID 0x34 discontinuity detected
2006-10-04 14:42:28.150 DVBRec(0): PID 0x33 discontinuity detected
2006-10-04 14:43:40.276 DVBRec(0): PID 0x940 discontinuity detected
2006-10-04 14:43:40.280 DVBRec(0): PID 0x941 discontinuity detected

where are 0x0, 0x34 and 0x33 coming from?

--
Steve
Before you ask, read the FAQ!
http://www.mythtv.org/wiki/index.php/Frequently_Asked_Questions
then search the Wiki, and this list,
http://www.gossamer-threads.com/lists/mythtv/
Mailinglist etiquette -
http://www.mythtv.org/wiki/index.php/Mailing_List_etiquette
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

adeffs.mythtv at gmail

Oct 5, 2006, 6:11 AM

Post #19 of 21 (7956 views)
Permalink

Re: what does "DVBRec(1): PID 0x840 discontinuity detected" mean? [In reply to]

On 10/4/06, Steven Adeff <adeffs.mythtv [at] gmail> wrote:
> On 10/4/06, Steven Adeff <adeffs.mythtv [at] gmail> wrote:
> > On 10/3/06, Steven Adeff <adeffs.mythtv [at] gmail> wrote:
> > > On 10/3/06, Steven Adeff <adeffs.mythtv [at] gmail> wrote:
> > > > On 10/3/06, Stuart Auchterlonie <stuarta [at] squashedfrog> wrote:
> > > > > On Tue, Oct 03, 2006 at 08:06:21AM -0400, Steven Adeff wrote:
> > > > > > >
> > > > > > > It's in quite a fundamental area of the packet processing,
> > > > > > > so i'm going to await further reports for a while before
> > > > > > > considering it for inclusion.
> > > > > >
> > > > > > is there a way to tell if the issue is with the signal the card is
> > > > > > receiving or something internal to the computer? I'm just having a
> > > > > > hard time understanding why this would randomly start happening and
> > > > > > the cable line looks to be clean?
> > > > > >
> > > > > > It also seems to occur more during heavy i/o load, though this is more
> > > > > > a casual observance. When all three of my HD recorders are going it
> > > > > > seems to be more of an issue than when just one is.
> > > > > >
> > > > >
> > > > > Sounds like you may be running into limitations with
> > > > > 1) PCI bus maximum throughput
> > > > > 2) I/O throughput to your storage
> > > > >
> > > > > also check your dmesg and see if any errors are being thrown
> > > > > by the driver. verify also that each card has it's own interrupt.
> > > >
> > > > Stuart, thanks for helping me with this. Some "answers" to your questions...
> > > >
> > > > I/O: I've been using the same RAID10 setup with no changes for months
> > > > now. I wonder if perhaps fragmentation on my recordings drive is
> > > > slowing it down now to the point of being an issue? I run XFS, I don't
> > > > know if its something that can be an issue with XFS? I discovered
> > > > xfs_fsr well into having a full recording drive, so I don't use it.
> > > > perhaps I should erase all watched recordings that I can to empty the
> > > > drive out and then begin doing a defrag process?
> > > >
> > > > IRQ:
> > > > Subsystem: Hauppauge computer works Inc. WinTV PVR 150
> > > > Flags: bus master, medium devsel, latency 64, IRQ 225
> > > > Memory at e8000000 (32-bit, prefetchable) [size=64M]
> > > > Capabilities: [44] Power Management version 2
> > > >
> > > > Subsystem: pcHDTV pcHDTV HD3000 HDTV
> > > > Flags: bus master, medium devsel, latency 32, IRQ 10
> > > > Memory at f9000000 (32-bit, non-prefetchable) [size=16M]
> > > > Capabilities: [44] Vital Product Data
> > > > Capabilities: [4c] Power Management version 2
> > > >
> > > > Subsystem: pcHDTV pcHDTV HD3000 HDTV
> > > > Flags: bus master, medium devsel, latency 32, IRQ 217
> > > > Memory at fa000000 (32-bit, non-prefetchable) [size=16M]
> > > > Capabilities: [4c] Power Management version 2
> > > >
> > > > Subsystem: Avermedia Technologies Inc AVerTVHD MCE A180
> > > > Flags: bus master, medium devsel, latency 32, IRQ 233
> > > > Memory at fbffe000 (32-bit, non-prefetchable) [size=2K]
> > > > Capabilities: [40] Power Management version 2
> > > >
> > > > Subsystem: Avermedia Technologies Inc AVerTVHD MCE A180
> > > > Flags: bus master, medium devsel, latency 32, IRQ 225
> > > > Memory at fbfff000 (32-bit, non-prefetchable) [size=2K]
> > > > Capabilities: [40] Power Management version 2
> > > >
> > > > it looks like one of my A180's and my PVR150 are on the same IRQ.
> > > >
> > > > In my kern.log I seem to be getting a lot of
> > > > Oct 2 21:29:32 mythbox kernel: cx88[0]/2: queue is empty - first active
> > > > Oct 2 21:29:32 mythbox kernel: cx88[0]/2: cx8802_start_dma w: 0, h: 0, f: 2
> > > > Oct 2 21:29:32 mythbox kernel: cx88[0]/2: setting the interrupt mask
> > > > Oct 2 21:29:32 mythbox kernel: cx88[0]/2: [ffff81003a356200/0]
> > > > cx8802_buf_queue - first active
> > > > Oct 2 21:29:32 mythbox kernel: cx88[0]/2: cx8802_restart_queue
> > > > Oct 2 21:29:32 mythbox kernel: cx88[0]/2: cx8802_restart_queue: queue is empty
> > > > Oct 2 21:29:32 mythbox kernel: cx88[0]/2: queue is empty - first active
> > > > Oct 2 21:29:32 mythbox kernel: cx88[0]/2: cx8802_start_dma w: 0, h: 0, f: 2
> > > > Oct 2 21:29:32 mythbox kernel: cx88[0]/2: setting the interrupt mask
> > > > Oct 2 21:29:32 mythbox kernel: cx88[0]/2: [ffff810012f8aa00/0]
> > > > cx8802_buf_queue - first active
> > > > Oct 2 21:29:33 mythbox kernel: cx88[0]/2: cx8802_restart_queue
> > > > Oct 2 21:29:33 mythbox kernel: cx88[0]/2: cx8802_restart_queue: queue is empty
> > > > Oct 2 21:29:33 mythbox kernel: cx88[0]/2: queue is empty - first active
> > > > Oct 2 21:29:33 mythbox kernel: cx88[0]/2: cx8802_start_dma w: 0, h: 0, f: 2
> > > > Oct 2 21:29:33 mythbox kernel: cx88[0]/2: setting the interrupt mask
> > > > Oct 2 21:29:33 mythbox kernel: cx88[0]/2: [ffff810015f3be00/0]
> > > > cx8802_buf_queue - first active
> > > > Oct 2 22:01:30 mythbox kernel: cx88[0]/2: cx8802_restart_queue
> > > > Oct 2 22:01:30 mythbox kernel: cx88[0]/2: cx8802_restart_queue: queue is empty
> > > >
> > > > let me know if you see anything that jumps out at you that I should
> > > > look into/etc.
> > >
> > > did a quick google that lead me to discover my two PATA drives in my
> > > RAID were running
> > > IO_support = 0 (default 16-bit)
> > > instead of
> > > IO_support = 1 (32-bit)
> > >
> > > and unmaskirq was also off...
> > > so I made those right. time to see what happens...
> >
> > Doesn't seem to affect it.
> >
> > I'm going to try moving the cards around inside the case (I moved them
> > early in trying to solve the problem) to see if where they used to sit
> > makes it go away. I do notice that the cx88 errors only seem to occur
> > at the beginning of a recording (at least now).
> >
> > The patch has done well at preventing loss of large time chunks of
> > video so far. I just get a row of broken macroblocks now, which while
> > being "the suck", is at least watchable.
>
> more,
> noticing some, what I think are, odd PID's in the discontinuity errors
> for the HD3000 card:
> 2006-10-04 14:41:15.546 DVBRec(0): PID 0x940 discontinuity detected
> 2006-10-04 14:41:15.956 DVBRec(0): PID 0x940 discontinuity detected
> 2006-10-04 14:41:15.957 DVBRec(0): PID 0x941 discontinuity detected
> 2006-10-04 14:41:15.965 DVBRec(0): PID 0x0 discontinuity detected
> 2006-10-04 14:41:15.968 DVBRec(0): PID 0x31 discontinuity detected
> 2006-10-04 14:41:15.969 DVBRec(0): PID 0x32 discontinuity detected
> 2006-10-04 14:41:15.970 DVBRec(0): PID 0x33 discontinuity detected
> 2006-10-04 14:41:15.971 DVBRec(0): PID 0x34 discontinuity detected
> 2006-10-04 14:41:15.983 DVBRec(0): PID 0x30 discontinuity detected
> 2006-10-04 14:41:15.984 DVBRec(0): PID 0x35 discontinuity detected
> 2006-10-04 14:41:16.135 DVBRec(0): PID 0x940 discontinuity detected
> 2006-10-04 14:41:16.136 DVBRec(0): PID 0x941 discontinuity detected
> 2006-10-04 14:41:16.141 DVBRec(0): PID 0x33 discontinuity detected
> 2006-10-04 14:41:16.142 DVBRec(0): PID 0x31 discontinuity detected
> 2006-10-04 14:41:16.142 DVBRec(0): PID 0x30 discontinuity detected
> 2006-10-04 14:41:16.179 DVBRec(0): PID 0x35 discontinuity detected
> 2006-10-04 14:41:16.209 DVBRec(0): PID 0x32 discontinuity detected
> 2006-10-04 14:41:16.213 DVBRec(0): PID 0x34 discontinuity detected
> 2006-10-04 14:41:16.229 DVBRec(0): PID 0x0 discontinuity detected
> 2006-10-04 14:42:25.060 DVBRec(0): PID 0x940 discontinuity detected
> 2006-10-04 14:42:27.739 DVBRec(0): PID 0x940 discontinuity detected
> 2006-10-04 14:42:28.133 DVBRec(0): PID 0x941 discontinuity detected
> 2006-10-04 14:42:28.143 DVBRec(0): PID 0x34 discontinuity detected
> 2006-10-04 14:42:28.150 DVBRec(0): PID 0x33 discontinuity detected
> 2006-10-04 14:43:40.276 DVBRec(0): PID 0x940 discontinuity detected
> 2006-10-04 14:43:40.280 DVBRec(0): PID 0x941 discontinuity detected
>
> where are 0x0, 0x34 and 0x33 coming from?

Well, this will be my last email in this ongoing saga of mine, unless
someone has an idea for me.

Last night I moved the cards back to their original PCI slots (I had
moved them previously to see if something was to be found from doing
so). I also noticed my CPU wasn't running at its full speed for some
reason, so I went into the BIOS and changed that.

Still no love. I did find that the hdparm changes were actually
detrimental to my RAID performance, so I reverted back to the
defaults. I also notice that using the PVR-150 (via my cablebox)
increases the discontinuity errors no matter how many ATSC tuners I
use. the HD3000 produces more errors than my A180's. So short of
moving all the cards to another computer (which is a possibility, my
bedroom desktop has enough PCI slots, though is only an XP1600+) to
see if its somehow the motherboard I don't know what occured that
causes these dropped packets to occur.

--
Steve
Before you ask, read the FAQ!
http://www.mythtv.org/wiki/index.php/Frequently_Asked_Questions
then search the Wiki, and this list,
http://www.gossamer-threads.com/lists/mythtv/
Mailinglist etiquette -
http://www.mythtv.org/wiki/index.php/Mailing_List_etiquette
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

mark.kendall at gmail

Oct 5, 2006, 8:01 AM

Post #20 of 21 (7964 views)
Permalink

Re: what does "DVBRec(1): PID 0x840 discontinuity detected" mean? [In reply to]

On 10/5/06, Steven Adeff <adeffs.mythtv [at] gmail> wrote:
> On 10/4/06, Steven Adeff <adeffs.mythtv [at] gmail> wrote:
> > On 10/4/06, Steven Adeff <adeffs.mythtv [at] gmail> wrote:
> > > On 10/3/06, Steven Adeff <adeffs.mythtv [at] gmail> wrote:
> > > > On 10/3/06, Steven Adeff <adeffs.mythtv [at] gmail> wrote:
> > > > > On 10/3/06, Stuart Auchterlonie <stuarta [at] squashedfrog> wrote:
> > > > > > On Tue, Oct 03, 2006 at 08:06:21AM -0400, Steven Adeff wrote:
> > > > > > > >
> > > > > > > > It's in quite a fundamental area of the packet processing,
> > > > > > > > so i'm going to await further reports for a while before
> > > > > > > > considering it for inclusion.
> > > > > > >
> > > > > > > is there a way to tell if the issue is with the signal the card is
> > > > > > > receiving or something internal to the computer? I'm just having a
> > > > > > > hard time understanding why this would randomly start happening and
> > > > > > > the cable line looks to be clean?
> > > > > > >
> > > > > > > It also seems to occur more during heavy i/o load, though this is more
> > > > > > > a casual observance. When all three of my HD recorders are going it
> > > > > > > seems to be more of an issue than when just one is.
> > > > > > >
> > > > > >
> > > > > > Sounds like you may be running into limitations with
> > > > > > 1) PCI bus maximum throughput
> > > > > > 2) I/O throughput to your storage
> > > > > >
> > > > > > also check your dmesg and see if any errors are being thrown
> > > > > > by the driver. verify also that each card has it's own interrupt.
> > > > >
> > > > > Stuart, thanks for helping me with this. Some "answers" to your questions...
> > > > >
> > > > > I/O: I've been using the same RAID10 setup with no changes for months
> > > > > now. I wonder if perhaps fragmentation on my recordings drive is
> > > > > slowing it down now to the point of being an issue? I run XFS, I don't
> > > > > know if its something that can be an issue with XFS? I discovered
> > > > > xfs_fsr well into having a full recording drive, so I don't use it.
> > > > > perhaps I should erase all watched recordings that I can to empty the
> > > > > drive out and then begin doing a defrag process?
> > > > >
> > > > > IRQ:
> > > > > Subsystem: Hauppauge computer works Inc. WinTV PVR 150
> > > > > Flags: bus master, medium devsel, latency 64, IRQ 225
> > > > > Memory at e8000000 (32-bit, prefetchable) [size=64M]
> > > > > Capabilities: [44] Power Management version 2
> > > > >
> > > > > Subsystem: pcHDTV pcHDTV HD3000 HDTV
> > > > > Flags: bus master, medium devsel, latency 32, IRQ 10
> > > > > Memory at f9000000 (32-bit, non-prefetchable) [size=16M]
> > > > > Capabilities: [44] Vital Product Data
> > > > > Capabilities: [4c] Power Management version 2
> > > > >
> > > > > Subsystem: pcHDTV pcHDTV HD3000 HDTV
> > > > > Flags: bus master, medium devsel, latency 32, IRQ 217
> > > > > Memory at fa000000 (32-bit, non-prefetchable) [size=16M]
> > > > > Capabilities: [4c] Power Management version 2
> > > > >
> > > > > Subsystem: Avermedia Technologies Inc AVerTVHD MCE A180
> > > > > Flags: bus master, medium devsel, latency 32, IRQ 233
> > > > > Memory at fbffe000 (32-bit, non-prefetchable) [size=2K]
> > > > > Capabilities: [40] Power Management version 2
> > > > >
> > > > > Subsystem: Avermedia Technologies Inc AVerTVHD MCE A180
> > > > > Flags: bus master, medium devsel, latency 32, IRQ 225
> > > > > Memory at fbfff000 (32-bit, non-prefetchable) [size=2K]
> > > > > Capabilities: [40] Power Management version 2
> > > > >
> > > > > it looks like one of my A180's and my PVR150 are on the same IRQ.
> > > > >
> > > > > In my kern.log I seem to be getting a lot of
> > > > > Oct 2 21:29:32 mythbox kernel: cx88[0]/2: queue is empty - first active
> > > > > Oct 2 21:29:32 mythbox kernel: cx88[0]/2: cx8802_start_dma w: 0, h: 0, f: 2
> > > > > Oct 2 21:29:32 mythbox kernel: cx88[0]/2: setting the interrupt mask
> > > > > Oct 2 21:29:32 mythbox kernel: cx88[0]/2: [ffff81003a356200/0]
> > > > > cx8802_buf_queue - first active
> > > > > Oct 2 21:29:32 mythbox kernel: cx88[0]/2: cx8802_restart_queue
> > > > > Oct 2 21:29:32 mythbox kernel: cx88[0]/2: cx8802_restart_queue: queue is empty
> > > > > Oct 2 21:29:32 mythbox kernel: cx88[0]/2: queue is empty - first active
> > > > > Oct 2 21:29:32 mythbox kernel: cx88[0]/2: cx8802_start_dma w: 0, h: 0, f: 2
> > > > > Oct 2 21:29:32 mythbox kernel: cx88[0]/2: setting the interrupt mask
> > > > > Oct 2 21:29:32 mythbox kernel: cx88[0]/2: [ffff810012f8aa00/0]
> > > > > cx8802_buf_queue - first active
> > > > > Oct 2 21:29:33 mythbox kernel: cx88[0]/2: cx8802_restart_queue
> > > > > Oct 2 21:29:33 mythbox kernel: cx88[0]/2: cx8802_restart_queue: queue is empty
> > > > > Oct 2 21:29:33 mythbox kernel: cx88[0]/2: queue is empty - first active
> > > > > Oct 2 21:29:33 mythbox kernel: cx88[0]/2: cx8802_start_dma w: 0, h: 0, f: 2
> > > > > Oct 2 21:29:33 mythbox kernel: cx88[0]/2: setting the interrupt mask
> > > > > Oct 2 21:29:33 mythbox kernel: cx88[0]/2: [ffff810015f3be00/0]
> > > > > cx8802_buf_queue - first active
> > > > > Oct 2 22:01:30 mythbox kernel: cx88[0]/2: cx8802_restart_queue
> > > > > Oct 2 22:01:30 mythbox kernel: cx88[0]/2: cx8802_restart_queue: queue is empty
> > > > >
> > > > > let me know if you see anything that jumps out at you that I should
> > > > > look into/etc.
> > > >
> > > > did a quick google that lead me to discover my two PATA drives in my
> > > > RAID were running
> > > > IO_support = 0 (default 16-bit)
> > > > instead of
> > > > IO_support = 1 (32-bit)
> > > >
> > > > and unmaskirq was also off...
> > > > so I made those right. time to see what happens...
> > >
> > > Doesn't seem to affect it.
> > >
> > > I'm going to try moving the cards around inside the case (I moved them
> > > early in trying to solve the problem) to see if where they used to sit
> > > makes it go away. I do notice that the cx88 errors only seem to occur
> > > at the beginning of a recording (at least now).
> > >
> > > The patch has done well at preventing loss of large time chunks of
> > > video so far. I just get a row of broken macroblocks now, which while
> > > being "the suck", is at least watchable.
> >
> > more,
> > noticing some, what I think are, odd PID's in the discontinuity errors
> > for the HD3000 card:
> > 2006-10-04 14:41:15.546 DVBRec(0): PID 0x940 discontinuity detected
> > 2006-10-04 14:41:15.956 DVBRec(0): PID 0x940 discontinuity detected
> > 2006-10-04 14:41:15.957 DVBRec(0): PID 0x941 discontinuity detected
> > 2006-10-04 14:41:15.965 DVBRec(0): PID 0x0 discontinuity detected
> > 2006-10-04 14:41:15.968 DVBRec(0): PID 0x31 discontinuity detected
> > 2006-10-04 14:41:15.969 DVBRec(0): PID 0x32 discontinuity detected
> > 2006-10-04 14:41:15.970 DVBRec(0): PID 0x33 discontinuity detected
> > 2006-10-04 14:41:15.971 DVBRec(0): PID 0x34 discontinuity detected
> > 2006-10-04 14:41:15.983 DVBRec(0): PID 0x30 discontinuity detected
> > 2006-10-04 14:41:15.984 DVBRec(0): PID 0x35 discontinuity detected
> > 2006-10-04 14:41:16.135 DVBRec(0): PID 0x940 discontinuity detected
> > 2006-10-04 14:41:16.136 DVBRec(0): PID 0x941 discontinuity detected
> > 2006-10-04 14:41:16.141 DVBRec(0): PID 0x33 discontinuity detected
> > 2006-10-04 14:41:16.142 DVBRec(0): PID 0x31 discontinuity detected
> > 2006-10-04 14:41:16.142 DVBRec(0): PID 0x30 discontinuity detected
> > 2006-10-04 14:41:16.179 DVBRec(0): PID 0x35 discontinuity detected
> > 2006-10-04 14:41:16.209 DVBRec(0): PID 0x32 discontinuity detected
> > 2006-10-04 14:41:16.213 DVBRec(0): PID 0x34 discontinuity detected
> > 2006-10-04 14:41:16.229 DVBRec(0): PID 0x0 discontinuity detected
> > 2006-10-04 14:42:25.060 DVBRec(0): PID 0x940 discontinuity detected
> > 2006-10-04 14:42:27.739 DVBRec(0): PID 0x940 discontinuity detected
> > 2006-10-04 14:42:28.133 DVBRec(0): PID 0x941 discontinuity detected
> > 2006-10-04 14:42:28.143 DVBRec(0): PID 0x34 discontinuity detected
> > 2006-10-04 14:42:28.150 DVBRec(0): PID 0x33 discontinuity detected
> > 2006-10-04 14:43:40.276 DVBRec(0): PID 0x940 discontinuity detected
> > 2006-10-04 14:43:40.280 DVBRec(0): PID 0x941 discontinuity detected
> >
> > where are 0x0, 0x34 and 0x33 coming from?
>
> Well, this will be my last email in this ongoing saga of mine, unless
> someone has an idea for me.
>
> Last night I moved the cards back to their original PCI slots (I had
> moved them previously to see if something was to be found from doing
> so). I also noticed my CPU wasn't running at its full speed for some
> reason, so I went into the BIOS and changed that.
>
> Still no love. I did find that the hdparm changes were actually
> detrimental to my RAID performance, so I reverted back to the
> defaults. I also notice that using the PVR-150 (via my cablebox)
> increases the discontinuity errors no matter how many ATSC tuners I
> use. the HD3000 produces more errors than my A180's. So short of
> moving all the cards to another computer (which is a possibility, my
> bedroom desktop has enough PCI slots, though is only an XP1600+) to
> see if its somehow the motherboard I don't know what occured that
> causes these dropped packets to occur.
>
> --
> Steve
> Before you ask, read the FAQ!
> http://www.mythtv.org/wiki/index.php/Frequently_Asked_Questions
> then search the Wiki, and this list,
> http://www.gossamer-threads.com/lists/mythtv/
> Mailinglist etiquette -
> http://www.mythtv.org/wiki/index.php/Mailing_List_etiquette
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev [at] mythtv
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
>
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

adeffs.mythtv at gmail

Oct 16, 2006, 5:12 AM

Post #21 of 21 (7862 views)
Permalink

Re: what does "DVBRec(1): PID 0x840 discontinuity detected" mean? [In reply to]

On 9/30/06, Stuart Auchterlonie <stuarta [at] squashedfrog> wrote:
> On Fri, Sep 29, 2006 at 07:19:02PM -0400, Steven Adeff wrote:
> > On 9/29/06, Stuart Auchterlonie <stuarta [at] squashedfrog> wrote:
> > >
> > > These are caused by the next packet being recieved on that pid,
> > > not being the one that is expected.
> > >
> > > The main cause is bad signal, but you've had that sorted.
> > > It can also caused by things like power spikes, or other
> > > intermittant interferance.
> > >
> > > However, looking at this i've noticed something interesting.
> > > We don't throw away the packet if we detect a discontinuity.
> > > This would be okay if the new packet CC = last seen CC, as this
> > > would possibly be a duplicate packet. But if the new packet CC
> > > is > last seen CC + 1 (modulo 0xf) then the full TS packet is
> > > broken and should be thrown away....
> > >
> > > I'll whip up a quick patch for that...
> >
> > thanks, let me know if I can provide any more information. I do know
> > that my HD3000 is more prone to this error than either of my Aver
> > A180's (which 95% of the time show the problem at the same time).
> >
>
> That is to be expected, since some form of electrical interference
> would hit the input and all cards equally. It looks like the HD3000
> is more sensitive to this noise..
>
> The patch has gone in in changeset 11334.

any chance of this getting to the 0.20-fixes branch?

--
Steve
Before you ask, read the FAQ!
http://www.mythtv.org/wiki/index.php/Frequently_Asked_Questions
then search the Wiki, and this list,
http://www.gossamer-threads.com/lists/mythtv/
Mailinglist etiquette -
http://www.mythtv.org/wiki/index.php/Mailing_List_etiquette
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads