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

Mark Kendall mark.kendall at gmail.com
Thu Oct 5 15:01:23 UTC 2006


On 10/5/06, Steven Adeff <adeffs.mythtv at gmail.com> wrote:
> On 10/4/06, Steven Adeff <adeffs.mythtv at gmail.com> wrote:
> > On 10/4/06, Steven Adeff <adeffs.mythtv at gmail.com> wrote:
> > > On 10/3/06, Steven Adeff <adeffs.mythtv at gmail.com> wrote:
> > > > On 10/3/06, Steven Adeff <adeffs.mythtv at gmail.com> wrote:
> > > > > On 10/3/06, Stuart Auchterlonie <stuarta at squashedfrog.net> 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.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
>


More information about the mythtv-dev mailing list