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

Steven Adeff adeffs.mythtv at gmail.com
Wed Oct 4 15:47:08 UTC 2006


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.



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


More information about the mythtv-dev mailing list