>
> Hi, James.
>
> After searching for somebody posting some issues similar to mine, I think this
> one you posted to the mailing list can be related:
>
> https://www.mail-archive.com/linux-
> media%40vger.kernel.org/msg80078.html
>
> I'm having problems using both tuners in a dual tuner card (
I'm still not having any luck getting reliable operation of the second tuner on
my cx23885 based card.
Incidental to this, I'm getting a crash in cx23885_video_wakeup at the line:
buf->vb.v4l2_buf.sequence = q->count++;
(full log follows this email)
I'm not sure exactly why, but I do know that
>
> 041ad449683bb2d54a7f082d78ec15bbc958a175 introduced stats gathering
> into the dib7000p code which seems to generate a lot more i2c traffic which
> would exacerbate the problem, if one existed. The timing (May/June) very
> roughly matches what I remember too. When my recording stops, so do the
> >> Is that two tuners in the same device, or two tuners in different devices?
> >
> > DViCO FusionHDTV DVB-T Dual Express2
> >
> > 2 tuners on one card
>
> Any idea if there were changes or are issues with i2c access when there are
> two tuners in the same device?
>
> That's not really my expe
> >>>
> >>> Any hints on what I can do to figure out what layer it's stalling at?
> >>
> >> I have no idea. I would do a git bisect to try and narrow it down.
> >>
> >
> > Problem with the bisect is that I can't be sure what version it actually
> worked on. It certainly predates when my patch for m
>
> >
> > Any hints on what I can do to figure out what layer it's stalling at?
>
> I have no idea. I would do a git bisect to try and narrow it down.
>
Problem with the bisect is that I can't be sure what version it actually worked
on. It certainly predates when my patch for my card was commi
>
> I'll test out the downgrade to 73d8102298719863d54264f62521362487f84256
> just to be sure, then see if I can take it further back.
>
73d8102298719863d54264f62521362487f84256 still breaks for me, so it's
definitely not related to the conversion.
Any hints on what I can do to figure out what
> >
> > And important for me, because if it IS related to the vb2 conversion then I
> > need to know asap.
> >
>
> Might take a few days to be completely sure. I've wondered if it's something
> to do with the signal too (maybe some bug when signal error occurs?). So
> many variables :(
>
I can r
> > That sounds plausible wrt timeframe, but if cx23885 only started using vb2
> > after Sept 8 then it couldn't have affected me before then right?
>
> You are right about that. You are using DVB right? Not analog video? (Just to
> be 100% certain).
>
Yes. Australia mostly has no analog anymore
> > I was looking through the patches and saw a date of August 14 on the
> > cx23885 to vb2 patch and thought that could have been around when it
> > started breaking, but then the
> > 73d8102298719863d54264f62521362487f84256 is dated September 3 and I'm
> > pretty sure it had started playing up be
> > Oops I should have mentioned that. I'm using Debian "Jessie" with
> > 3.16 kernel and already using the latest v4l as per link you sent (my
> > DViCO FusionHDTV DVB-T Dual Express2 patch is in 3.17 I think, but
> > that's not in Debian yet).
>
> Ah, yes, that's rather important information :-)
>
> On 09/20/2014 05:32 AM, James Harper wrote:
> >
> > My cx23885 based DViCO FusionHDTV DVB-T Dual Express2 (I submitted a
> > patch for this a little while ago) has been working great but over
> > the last few months it has started playing up. Nothing has really
>
> The recent conversion of saa7134 to vb2 unconvered a poll() bug that
> broke the teletext applications alevt and mtt. These applications
> expect that calling poll() without having called VIDIOC_STREAMON will
> cause poll() to return POLLERR. That did not happen in vb2.
>
> This patch fixes t
I'm building v4l against Debian Jessie (3.14.15) and I am getting this:
"
In file included from
/usr/local/src/media_build/v4l/../linux/include/media/videobuf2-core.h:19:0,
from /usr/local/src/media_build/v4l/mcam-core.h:13,
from /usr/local/src/media_build/v4l/ca
DViCO FusionHDTV DVB-T Dual Express2 is cx23885 + dib7070
Signed-off-by: James Harper
---
drivers/media/pci/cx23885/cx23885-cards.c | 15 +++-
drivers/media/pci/cx23885/cx23885-dvb.c | 123 ++
drivers/media/pci/cx23885/cx23885.h | 1 +
3 files changed, 138
cates each page with dma_alloc_coherent() to guarantee that each
page is suitable for the device in question.
Signed-off-by: Konrad Rzeszutek Wilk
Signed-off-by: James Harper
---
drivers/media/v4l2-core/videobuf-dma-sg.c | 62 +--
include/media/videobuf-dma
cates each page with dma_alloc_coherent() to guarantee that each
page is suitable for the device in question.
Signed-off-by: Konrad Rzeszutek Wilk
Signed-off-by: James Harper
---
drivers/media/v4l2-core/videobuf-dma-sg.c | 62 +--
include/media/videobuf-dma
Fix regression in some dib0700 based devices.
Set size_of_priv, and don't call dvb_detach unnecessarily.
This resolves the oops(s) for my "Leadtek Winfast DTV Dongle (STK7700P based)"
Signed-off-by: James Harper
---
drivers/media/usb/dvb-usb/dib0700_devices.c | 2 +-
1 file chang
The following patch implements support for the cx23885 based DViCO FusionHDTV
DVB-T Dual Express2. It uses the dib7070 chipset, which was already supported
by an existing usb adapter. Working on my pc but not extensively tested yet.
There is obviously a bit of code duplication due to the cut and
Somewhere along the way there's been a regression in dib0700 for my "Leadtek
Winfast DTV Dongle (STK7700P based)"
One is the addition of dvb_detach(&state->dib7000p_ops);
The other is a missing .size_of_priv
The following is required to get it working again, although obviously
commenting out d
.kernel.org [mailto:linux-media-
> ow...@vger.kernel.org] On Behalf Of James Harper
> Sent: Sunday, 8 June 2014 8:36 PM
> To: René; linux-media@vger.kernel.org
> Subject: RE: fusion hdtv dual express 2 (working, kind of)
>
> One thing I just noticed, it's always the same pages in e
One thing I just noticed, it's always the same pages in each buffer that is
'lost' (in "find_next_packet"). If I printk some details, the 'lost' parts are
always some multiple of 4k in size (with allowance for 188 byte packet).
printk("find_next_packet() lost %p %d-%d (%d)\n", buf, start, pos, l
> Hi,
> I don't use mythtv myself so I can't help you troubleshooting using this
> program. But the symptoms you describe (high pitch sound, degraded video)
> make me think of missing packets in the received stream. May be you might
> use vlc in maximum verbosity mode to get information about the s
OK I have picture in mythtv now, but it's very glitchy (lines in video, bursts
of high pitched tone in audio). In fact it is behaving much like the dib0700
based adapter that I replaced with the express2 adapter because I thought it
had died. Could there been a regression somewhere? I'll check t
> Hi James,
>
> The first basic thing you should look at is if the dvb device has got all
> its pieces.
> A dvb adapter has, sort of, 4 sub-devices:
> [me@home ~]$ ll /dev/dvb/adapter2
> total 0
> crw-rw+ 1 root video 212, 12 Jun 5 12:31 demux0
> crw-rw+ 1 root video 212, 13 Jun 5 12:31
After confirming that it was supported I just bought a fusion hdtv dual express
PCI adapter, only to find that I'd bought the 'dual express 2' version, which
isn't supported (not the first time I've made such a mistake).
This page
http://www.linuxtv.org/wiki/index.php/DViCO_FusionHDTV_DVB-T_Dua
26 matches
Mail list logo
