Re: Conexant PCI-8604PW 4 channel BNC Video capture card (bttv)

2014-02-05 Thread Robert Longbottom 


On 28 Jan 2014, at 02:02 AM, Daniel Glöckner  wrote:

> On Mon, Jan 27, 2014 at 08:55:00PM +0000, Robert Longbottom wrote:
>>> As for the CPLD, there is not much we can do. I count 23 GPIOs going
>>> to that chip. And we don't know if some of these are outputs of the
>>> CPLD, making it a bit risky to just randomly drive values on those
>>> pins.
>> 
>> Is that because it might do some damage to the card, or to the host
>> computer, or both?
> 
> If there is damage, it will most likely be restricted to the card.
> 
>> Or is it just too hard to make random guesses at
>> what it should be doing?
> 
> When we cycle through all combinations in one minute, there are about
> a hundred PCI cycles per combination left for the chip to be granted
> access to the bus. I expect most of the pins to provide a priority
> or weighting value for each BT878A, so there should be many combinations
> that do something.

How difficult is it for me to do this?  And is it obvious when it works? I have 
an old pc that I can put the card in that doesn't matter. And given I can't get 
the card to work in windows or Linux its not much use to me as it is, so if it 
breaks then so be it. 

I've not done any Linux driver development, but I'm happy enough compiling 
stuff for the most part. 

> Maybe the seller is nice person and provides the contents of the CD for
> free.

I tried contacting the seller via eBay, but no response so far, so I'm guessing 
he's not interested, which is a shame. 

Cheers,
Rob. 

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Conexant PCI-8604PW 4 channel BNC Video capture card (bttv)

2014-01-27 Thread Robert Longbottom 

On 27/01/14 03:20, Daniel Glöckner wrote:

On Sun, Jan 26, 2014 at 04:23:06PM +, Robert Longbottom wrote:

000 00D7 DSTATUS
114 32734000 RISC_STRT_ADD
120 32734000 RISC_COUNT


Video is present and locked but the RISC counter is stuck at the start
address. My best guess is that the CPLD is not forwarding the REQ signal
to the PCI bridge, so the BT878A can't fetch the RISC instructions.
But then there is also this persistent ADC overflow...

As for the CPLD, there is not much we can do. I count 23 GPIOs going
to that chip. And we don't know if some of these are outputs of the
CPLD, making it a bit risky to just randomly drive values on those
pins.


Is that because it might do some damage to the card, or to the host 
computer, or both?  Or is it just too hard to make random guesses at 
what it should be doing?



If we had the original software, we could analyze what it is doing.
There is someone on ebay.com selling two of those cards and a cd
labled "Rescue Disk Version 1.14 for Linux DVR".


Ah yes, I've just found that, it seems a little pricey!  There is also a 
listing for an "Avermedia 4 Eyes Pro Capture Card PCI 8604" which looks 
pretty much the same, but it doesn't have any software with it and 
searching around for any more information on that hasn't got me anywhere.


I've just been trying to make my card work under Windows, but no luck 
there either.  I didn't get a driver CD with it, Windows 7 doesn't 
autodetect anything for the video chips and when I tried to frig some 
drivers I found earlier today for a similar looking card they did 
install, but then didn't work - the not very helpful "device failed to 
start" error you get in Windows.  Which I guess means it's just not the 
right driver.


Shame, but I think I'll just have to chalk it up to experience - it 
wouldn't be my first duff purchase in the video-capture-device-for-linux 
area :-)


Thanks for all your efforts.
Cheers,
Rob.

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Conexant PCI-8604PW 4 channel BNC Video capture card (bttv)

2014-01-26 Thread Robert Longbottom 

On 26/01/14 12:55, Daniel Glöckner wrote:

On Sun, Jan 26, 2014 at 11:21:31AM +, Robert Longbottom wrote:

0F0 00F9 PLL_F_LO
0F4 00DC PLL_F_HI
0F8 008E PLL_XCI


The PLL is enabled and configured for a 28.63636MHz input clock.
With the default board config these registers are not touched
at all, so this must be a remnant of testing with another board
number. Please repeat with pll=35,35,35,35 .


Ah, yes, sorry about that, it will be the result of me messing around 
trying different things in the hope I can stumble across something that 
works.


robert@quad ~ $ sudo rmmod bttv
robert@quad ~ $ sudo modprobe bttv pll=35,35,35,35
robert@quad ~ $ xawtv -c /dev/video0

robert@quad ~/dev/8604PW $ sudo ./dumpbt8xx /dev/video0 > dumpbt8xx.data

produces:

000 00D7 DSTATUS
004 0053 IFORM
008  TDEC
00C 00D2 E_CROP
010 00FE E_VDELAY_LO
014 00E0 E_VACTIVE_LO
018 0078 E_HDELAY_LO
01C 0080 E_HACTIVE_LO
020 0002 E_HSCALE_HI
024 00AC E_HSCALE_LO
028  BRIGHT
02C 0022 E_CONTROL
030 00D8 CONTRAST_LO
034  SAT_U_LO
038 00B5 SAT_V_LO
03C  HUE
040  E_SCLOOP
044 00CF WC_UP
048 0006 OFORM
04C 0020 E_VSCALE_HI
050  E_VSCALE_LO
054 0001 TEST
058  ARESET
060 007F ADELAY
064 0072 BDELAY
068 0081 ADC
06C  E_VTC
078 007F WC_DOWN
080 007F TGLB
084  TGCTRL
08C 00D2 O_CROP
090 00FE O_VDELAY_LO
094 00E0 O_VACTIVE_LO
098 0078 O_HDELAY_LO
09C 0080 O_HACTIVE_LO
0A0 0002 O_HSCALE_HI
0A4 00AC O_HSCALE_LO
0AC 0022 O_CONTROL
0B0  VTOTAL_LO
0B4  VTOTAL_HI
0C0  O_SCLOOP
0CC 0020 O_VSCALE_HI
0D0  O_VSCALE_LO
0D4  COLOR_FMT
0D8 0010 COLOR_CTL
0DC 0003 CAP_CTL
0E0 00FF VBI_PACK_SIZE
0E4 0001 VBI_PACK_DEL
0E8 0082 FCAP
0EC  O_VTC
0F0  PLL_F_LO
0F4  PLL_F_HI
0F8  PLL_XCI
0FC  DVSIF
100 0A0C INT_STAT
104 000C0B13 INT_MASK
10C C0AF GPIO_DMA_CTL
110 0003 I2C
114 32734000 RISC_STRT_ADD
118  GPIO_OUT_EN
11C  GPIO_REG_INP
120 32734000 RISC_COUNT
200 000F GPIO_DATA

and /var/log/messages still fills up with timeouts

Jan 26 16:13:59 quad sudo:   robert : TTY=pts/1 ; PWD=/home/robert ; 
USER=root ; COMMAND=/sbin/modprobe bttv pll=35,35,35,35
Jan 26 16:13:59 quad sudo: pam_unix(sudo:session): session opened for 
user root by robert(uid=0)
Jan 26 16:13:59 quad kernel: [13524.035909] bttv: driver version 0.9.19 
loaded
Jan 26 16:13:59 quad kernel: [13524.035918] bttv: using 8 buffers with 
2080k (520 pages) each for capture

Jan 26 16:13:59 quad kernel: [13524.036015] bttv: Bt8xx card found (0)
Jan 26 16:13:59 quad kernel: [13524.036050] bttv: 0: Bt878 (rev 17) at 
:02:0c.0, irq: 16, latency: 32, mmio: 0xd500
Jan 26 16:13:59 quad kernel: [13524.036639] bttv: 0: using:  *** 
UNKNOWN/GENERIC ***  [card=0,autodetected]

Jan 26 16:13:59 quad kernel: [13524.082056] bttv: 0: tuner type unset
Jan 26 16:13:59 quad kernel: [13524.082366] bttv: 0: registered device 
video0

Jan 26 16:13:59 quad kernel: [13524.082418] bttv: 0: registered device vbi0
Jan 26 16:13:59 quad kernel: [13524.082447] bttv: 0: PLL can sleep, 
using XTAL (35468950)

Jan 26 16:13:59 quad kernel: [13524.086752] bttv: Bt8xx card found (1)
Jan 26 16:13:59 quad kernel: [13524.086804] bttv: 1: Bt878 (rev 17) at 
:02:0d.0, irq: 17, latency: 32, mmio: 0xd5002000
Jan 26 16:13:59 quad kernel: [13524.086933] bttv: 1: using:  *** 
UNKNOWN/GENERIC ***  [card=0,autodetected]
Jan 26 16:13:59 quad kernel: [13524.088195] tveeprom 5-0050: Huh, no 
eeprom present (err=-6)?

Jan 26 16:13:59 quad kernel: [13524.088206] bttv: 1: tuner type unset
Jan 26 16:13:59 quad kernel: [13524.088317] bttv: 1: registered device 
video1

Jan 26 16:13:59 quad kernel: [13524.088350] bttv: 1: registered device vbi1
Jan 26 16:13:59 quad kernel: [13524.088373] bttv: 1: PLL can sleep, 
using XTAL (35468950)

Jan 26 16:13:59 quad kernel: [13524.092691] bttv: Bt8xx card found (2)
Jan 26 16:13:59 quad kernel: [13524.092729] bttv: 2: Bt878 (rev 17) at 
:02:0e.0, irq: 18, latency: 32, mmio: 0xd5004000
Jan 26 16:13:59 quad kernel: [13524.092802] bttv: 2: using:  *** 
UNKNOWN/GENERIC ***  [card=0,autodetected]
Jan 26 16:13:59 quad kernel: [13524.093704] tveeprom 6-0050: Huh, no 
eeprom present (err=-6)?

Jan 26 16:13:59 quad kernel: [13524.093711] bttv: 2: tuner type unset
Jan 26 16:13:59 quad kernel: [13524.093854] bttv: 2: registered device 
video2

Jan 26 16:13:59 quad kernel: [13524.093904] bttv: 2: registered device vbi2
Jan 26 16:13:59 quad kernel: [13524.093932] bttv: 2: PLL can sleep, 
using XTAL (35468950)

Jan 26 16:13:59 quad kernel: [13524.102337] bttv: Bt8xx card found (3)
Jan 26 16:13:59 quad kernel: [13524.102364] bttv: 3: Bt878 (rev 17) at 
:02:0f.0, irq: 19, latency: 32, mmio: 0xd5006000
Jan 26 16:13:59 quad kernel: [13524.102405] bttv: 3: using:  *** 
UNKNOWN/GENE

Re: Conexant PCI-8604PW 4 channel BNC Video capture card (bttv)

2014-01-26 Thread Robert Longbottom 

On 25/01/14 15:23, Daniel Glöckner wrote:

On Thu, Jan 23, 2014 at 02:29:19PM +, Robert Longbottom wrote:

Jan 23 14:24:48 quad kernel: [154562.493224] bits: FMTCHG* VSYNC
HSYNC OFLOW FBUS   NUML => 625
Jan 23 14:24:49 quad kernel: [154562.994015] bttv: 0: timeout:
drop=0 irq=1868/1868, risc=146da000, bits: VSYNC HSYNC OFLOW
Jan 23 14:24:49 quad kernel: [154563.496010] bttv: 0: timeout:
drop=0 irq=1868/1868, risc=146da000, bits: VSYNC HSYNC OFLOW
Jan 23 14:24:50 quad kernel: [154563.997020] bttv: 0: timeout:
drop=0 irq=1868/1868, risc=146da000, bits: VSYNC HSYNC OFLOW
Jan 23 14:24:50 quad kernel: [154564.498018] bttv: 0: timeout:
drop=0 irq=1868/1868, risc=146da000, bits: VSYNC HSYNC OFLOW
Jan 23 14:24:51 quad kernel: [154564.999023] bttv: 0: timeout:
drop=0 irq=1868/1868, risc=146da000, bits: VSYNC HSYNC OFLOW
Jan 23 14:24:51 quad kernel: [154565.500024] bttv: 0: timeout:
drop=0 irq=1868/1868, risc=146da000, bits: VSYNC HSYNC OFLOW
Jan 23 14:24:52 quad kernel: [154566.001014] bttv: 0: timeout:
drop=0 irq=1868/1868, risc=146da000, bits: VSYNC HSYNC OFLOW
Jan 23 14:24:52 quad kernel: [154566.502016] bttv: 0: timeout:
drop=0 irq=1868/1868, risc=146da000, bits: VSYNC HSYNC OFLOW


The chip didn't lock to the input signal.
What kind of input are you feeding into the card?


Ah, for most of the testing I've done during the week I haven't had 
anything plugged in.  Though (obviously) I have tried with some cameras 
plugged in.  I have 3 "bullet" cams and one mini security camera.  All 
just standard wired video outputs, PAL, colour.  They work fine on the 
IVC capture card I have.


I've rerun the test with irq_debug=1 and the /var/log/messages output is 
here: http://pastebin.com/AJSLBhtY  I don't think it looks any better 
(/different).



Can you run the attached program while xawtv is running?
It will dump most of the registers of the bt8xx video function.


Sure, output below.  It didn't print out anything until I ran it as root 
(failed on fd = open(path, O_RDWR|O_SYNC);).  The output remains pretty 
much the same over multiple runs except these two values:


0E8 FCAP flips between a few values
100 INT_STAT changes from 0A0C to 0B0C and back.

Full output with xawtv running, bttv module loaded with no params.

sudo ./dumpbt8xx /dev/video0

000 0092 DSTATUS
004 0053 IFORM
008  TDEC
00C 00D2 E_CROP
010 00FE E_VDELAY_LO
014 00E0 E_VACTIVE_LO
018 0078 E_HDELAY_LO
01C 0080 E_HACTIVE_LO
020 0002 E_HSCALE_HI
024 00AC E_HSCALE_LO
028  BRIGHT
02C 0022 E_CONTROL
030 00D8 CONTRAST_LO
034  SAT_U_LO
038 00B5 SAT_V_LO
03C  HUE
040  E_SCLOOP
044 00CF WC_UP
048 0006 OFORM
04C 0020 E_VSCALE_HI
050  E_VSCALE_LO
054 0001 TEST
058  ARESET
060 007F ADELAY
064 0072 BDELAY
068 0081 ADC
06C  E_VTC
078 007F WC_DOWN
080 007F TGLB
084 0008 TGCTRL
08C 00D2 O_CROP
090 00FE O_VDELAY_LO
094 00E0 O_VACTIVE_LO
098 0078 O_HDELAY_LO
09C 0080 O_HACTIVE_LO
0A0 0002 O_HSCALE_HI
0A4 00AC O_HSCALE_LO
0AC 0022 O_CONTROL
0B0  VTOTAL_LO
0B4  VTOTAL_HI
0C0  O_SCLOOP
0CC 0020 O_VSCALE_HI
0D0  O_VSCALE_LO
0D4  COLOR_FMT
0D8 0010 COLOR_CTL
0DC 0003 CAP_CTL
0E0 00FF VBI_PACK_SIZE
0E4 0001 VBI_PACK_DEL
0E8 0011 FCAP
0EC  O_VTC
0F0 00F9 PLL_F_LO
0F4 00DC PLL_F_HI
0F8 008E PLL_XCI
0FC  DVSIF
100 0A0C INT_STAT
104 000C0B13 INT_MASK
10C C0AF GPIO_DMA_CTL
110 0003 I2C
114 30B35000 RISC_STRT_ADD
118  GPIO_OUT_EN
11C  GPIO_REG_INP
120 30B35000 RISC_COUNT
200 000F GPIO_DATA

Thanks,
Rob.

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Conexant PCI-8604PW 4 channel BNC Video capture card (bttv)

2014-01-22 Thread Robert Longbottom 

On 22/01/14 11:53, Daniel Glöckner wrote:

On Tue, Jan 21, 2014 at 08:59:55PM +, Robert Longbottom wrote:

On 21/01/2014 19:49, Robert Longbottom wrote:

Here are some high-res pictures of both sides of the card.  Scanned at
600dpi (300dpi the tracks were very close).  Good idea to scan it by the
way, I like that, much better result than with a digital camera.

http://www.flickr.com/photos/astrofraggle/12073752546/sizes/l/
http://www.flickr.com/photos/astrofraggle/12073651306/sizes/l/



ok:
  - The Atmel chip is an AT24C02 EEPROM. Does one of the 878As have a PCI
subsystem ID?


No, I don't see any PCI id's for the of the 878A's (relevant bit of 
lspci -vnn below)



  - The 74HCT04 is used to drive the clock from the oscillator to the
878As.

  - The 74HCT245 is a bus driver for four pins of the connector CN3.

  - The unlabled chip is probably a CPLD/FGPA. It filters the PCI REQ#
lines from the 878As and has access to the GNT# and INT# lines,
as well as to the GPIOs you mentioned. The bypass caps have a layout
that fits to the Lattice ispMACH 4A.


Ah, ok, so this is something to do with interfacing to the PCI bus?


  - There is no mux or gate between the BNC connectors and the 878As.
The BNCs are on MUX0. MUX1 is connected to the two unpopulated 2x5
Headers.

So the UNKNOWN/GENERIC card entry should have the BNC connectors on its
first V4L input.

Have you tried passing pll=35,35,35,35 as module parameter?


I've just had a go at this, modprobe bttv pll=35,35,35,35, and using the 
composite0 input in xawtv (first in the list) and still no joy.  I just 
get the same timeout errors repeating in dmesg:


[63204.009013] bttv: 3: timeout: drop=0 irq=46/26548, risc=3085d000, 
bits: HSYNC OFLOW
[63204.513013] bttv: 3: timeout: drop=0 irq=84/26618, risc=3085d000, 
bits: HSYNC OFLOW
[63205.016045] bttv: 3: timeout: drop=0 irq=121/26689, risc=3085d000, 
bits: HSYNC OFLOW
[63205.519013] bttv: 3: timeout: drop=0 irq=158/26759, risc=3085d000, 
bits: HSYNC OFLOW
[63206.021022] bttv: 3: timeout: drop=0 irq=196/26829, risc=3085d000, 
bits: HSYNC OFLOW


I went through and tried each of the /dev/video[0-4] inputs in turn in 
the hope that one of them had been initialized, but just got the 
timeouts on them all.


I also went back and had another go with  modprobe bttv 
card=133,132,133,133, trying the "132" in each position and testing each 
of the video devices (/dev/video[0-4]) as well in the hope that one 
input got initialized, but no luck there either.


Any more ideas?

I can probably try the card in a Windows machine at the weekend if that 
will provide any helpful information, however I don't have a driver CD 
for it, so it may depend on me finding some drivers


Thanks,
Rob.


$ lspci -vnn

02:0c.0 Multimedia video controller [0400]: Brooktree Corporation Bt878 
Video Capture [109e:036e] (rev 11)

Flags: bus master, medium devsel, latency 32, IRQ 16
Memory at d500 (32-bit, prefetchable) [size=4K]
Capabilities: [44] Vital Product Data
Capabilities: [4c] Power Management version 2
Kernel driver in use: bttv
Kernel modules: bttv

02:0c.1 Multimedia controller [0480]: Brooktree Corporation Bt878 Audio 
Capture [109e:0878] (rev 11)

Flags: bus master, medium devsel, latency 32, IRQ 5
Memory at d5001000 (32-bit, prefetchable) [size=4K]
Capabilities: [44] Vital Product Data
Capabilities: [4c] Power Management version 2

02:0d.0 Multimedia video controller [0400]: Brooktree Corporation Bt878 
Video Capture [109e:036e] (rev 11)

Flags: bus master, medium devsel, latency 32, IRQ 17
Memory at d5002000 (32-bit, prefetchable) [size=4K]
Capabilities: [44] Vital Product Data
Capabilities: [4c] Power Management version 2
Kernel driver in use: bttv
Kernel modules: bttv

02:0d.1 Multimedia controller [0480]: Brooktree Corporation Bt878 Audio 
Capture [109e:0878] (rev 11)

Flags: bus master, medium devsel, latency 32, IRQ 10
Memory at d5003000 (32-bit, prefetchable) [size=4K]
Capabilities: [44] Vital Product Data
Capabilities: [4c] Power Management version 2

02:0e.0 Multimedia video controller [0400]: Brooktree Corporation Bt878 
Video Capture [109e:036e] (rev 11)

Flags: bus master, medium devsel, latency 32, IRQ 18
Memory at d5004000 (32-bit, prefetchable) [size=4K]
Capabilities: [44] Vital Product Data
Capabilities: [4c] Power Management version 2
Kernel driver in use: bttv
Kernel modules: bttv

02:0e.1 Multimedia controller [0480]: Brooktree Corporation Bt878 Audio 
Capture [109e:0878] (rev 11)

Flags: bus master, medium devsel, latency 32, IRQ 10
Memory at d5005000 (32-bit, prefetchable) [size=4K]
Capabilities: [44] Vital Product Data
Capabilities: [4c] Power Management version 2

02:0f.0 Multimedia video contr

Re: Conexant PCI-8604PW 4 channel BNC Video capture card (bttv)

2014-01-21 Thread Robert Longbottom 

On 21/01/2014 19:49, Robert Longbottom wrote:

On 21/01/2014 10:19, Daniel Glöckner wrote:

On Tue, Jan 21, 2014 at 09:27:38AM +, Robert Longbottom wrote:

On 20 Jan 2014, at 10:55 PM, Andy Walls  wrote:

Robert Longbottom  wrote:

Chips on card:

 >

Can you upload high resolution pictures of both sides of the card
somewhere? Something where we can follow the tracks to these chips.
Scanning the card with 300dpi should be enough.


Here are some high-res pictures of both sides of the card.  Scanned at
600dpi (300dpi the tracks were very close).  Good idea to scan it by the
way, I like that, much better result than with a digital camera.

http://www.flickr.com/photos/astrofraggle/12073752546/sizes/l/
http://www.flickr.com/photos/astrofraggle/12073651306/sizes/l/

(click original size at the top right for full res)



1x 35.46895M Crystal


Few cards use an 8x PAL Fsc crystal. Most have an NTSC crystal
(28.6363 MHz) and rely on the PLL for PAL. Maybe this helps to rule
out some card numbers.


I did have a look down the cardlist for ones with PLL_35 (?), but it
didn't help me.  I dont think there are any with 4 inputs.  Assuming
thats the right thing to do.


Hmm, quick followup, I've just been looking at the images more closely 
and the top two (on the image) 878A chips appear to have tracks coming 
out of the GPIO pins.


Top chip has a "few" from pins 56 to 61 (GPIO23-18) that look to go via 
the 74HCT245 to the connector on the end of the card (not sure what 
thats for though...)


2nd from top chip appears to have a "lot" of it's GPIO pins connected 
up, pins 56-61 and pins 67 to 82 so GPIO 4 - GPIO 23.  Which possibly 
come up and connect to the unmarked chip...


Doesn't get me any further in making the card work, but hopefully it 
helps you guys a bit :-)


I've tried Kodicom driver again 
(http://linuxtv.org/wiki/index.php/Kodicom_4400R) with the "master card" 
id=132 in all possible positions - 1st, 2nd, 3rd, 4th, but no success. 
I still just get the bttv: 0: timeout: drop=0 irq=643/644, 
risc=0647, bits: VSYNC HSYNC errors in dmesg.


Rob.


--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Conexant PCI-8604PW 4 channel BNC Video capture card (bttv)

2014-01-21 Thread Robert Longbottom 

On 21/01/2014 10:19, Daniel Glöckner wrote:

On Tue, Jan 21, 2014 at 09:27:38AM +, Robert Longbottom wrote:

On 20 Jan 2014, at 10:55 PM, Andy Walls  wrote:

Robert Longbottom  wrote:

Chips on card:

>

Can you upload high resolution pictures of both sides of the card
somewhere? Something where we can follow the tracks to these chips.
Scanning the card with 300dpi should be enough.


Here are some high-res pictures of both sides of the card.  Scanned at 
600dpi (300dpi the tracks were very close).  Good idea to scan it by the 
way, I like that, much better result than with a digital camera.


http://www.flickr.com/photos/astrofraggle/12073752546/sizes/l/
http://www.flickr.com/photos/astrofraggle/12073651306/sizes/l/

(click original size at the top right for full res)



1x 35.46895M Crystal


Few cards use an 8x PAL Fsc crystal. Most have an NTSC crystal
(28.6363 MHz) and rely on the PLL for PAL. Maybe this helps to rule
out some card numbers.


I did have a look down the cardlist for ones with PLL_35 (?), but it 
didn't help me.  I dont think there are any with 4 inputs.  Assuming 
thats the right thing to do.


Thanks,
Rob.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Conexant PCI-8604PW 4 channel BNC Video capture card (bttv)

2014-01-21 Thread Robert Longbottom 


On 20 Jan 2014, at 10:55 PM, Andy Walls  wrote:

> Robert Longbottom  wrote:
>> 
>> Hi,
>> 
>> I've just bought one of these cards which is based on the Conexant
>> Fusion 878A chip thinking it would just work under Linux being
>> bttv-based.  Unfortunately (for me) it's not and it is just picked up
>> as
>> a generic unknown card by the bttv driver.
>> 
>> Does anyone have one of these that is working, or have any pointers to
>> what I can try to make it work?  I've had a go manually specifying
>> card=
>> as a module option for a couple of the existing cards that also use the
>> Conexant Fusion chip but neither work (BTTV_BOARD_PICOLO_TETRA_CHIP and
>> BTTV_BOARD_GEOVISION_GV800S).
>> 
>> When I start up xawtv and switch to framegrabber mode I just get lots
>> of
>> errors in /var/log/messages saying:
>> 
>> Jan 20 21:09:13 quad kernel: [ 2732.616016] bttv: 0: timeout: drop=0
>> irq=2998/35891, risc=339d5000, bits: HSYNC
>> Jan 20 21:09:13 quad kernel: [ 2733.122014] bttv: 0: timeout: drop=0
>> irq=3028/35952, risc=339d5000, bits: HSYNC
>> Jan 20 21:09:14 quad kernel: [ 2733.625018] bttv: 0: timeout: drop=0
>> irq=3058/36015, risc=339d5000, bits: HSYNC
>> Jan 20 21:09:14 quad kernel: [ 2734.127014] bttv: 0: timeout: drop=0
>> irq=3088/36077, risc=339d5000, bits: HSYNC
>> Jan 20 21:09:15 quad kernel: [ 2734.628014] bttv: 0: timeout: drop=0
>> irq=3118/36140, risc=339d5000, bits: HSYNC
>> 
>> Any help appreciated.  More info about the card below.
>> Thanks,
>> Rob.
>> 
>> Chips on card:
>> 
>> 4x Conexant Fusion 878A
>> 1x PCI6140-AA33PC
>> 1x SMD IC with no markings at all
>> Couple of 74HCTnnn chips
>> 1x Atmel 520
>> 1x 35.46895M Crystal
>> 
>> Result of modprobe bttv:
>> 
>> Jan 20 20:07:07 quad kernel: [ 8490.076924] bttv: driver version 0.9.19
>> loaded
>> Jan 20 20:07:07 quad kernel: [ 8490.076930] bttv: using 8 buffers with
>> 2080k (520 pages) each for capture
>> Jan 20 20:07:07 quad kernel: [ 8490.076983] bttv: Bt8xx card found (0)
>> Jan 20 20:07:07 quad kernel: [ 8490.077001] bttv: 0: Bt878 (rev 17) at
>> :02:0c.0, irq: 16, latency: 32, mmio: 0xd500
>> Jan 20 20:07:07 quad kernel: [ 8490.077033] bttv: 0: using:  ***
>> UNKNOWN/GENERIC ***  [card=0,autodetected]
>> Jan 20 20:07:07 quad kernel: [ 8490.109816] bttv: 0: tuner type unset
>> Jan 20 20:07:07 quad kernel: [ 8490.110099] bttv: 0: registered device
>> video0
>> Jan 20 20:07:07 quad kernel: [ 8490.110485] bttv: 0: registered device
>> vbi0
>> Jan 20 20:07:07 quad kernel: [ 8490.114206] bttv: Bt8xx card found (1)
>> Jan 20 20:07:07 quad kernel: [ 8490.114228] bttv: 1: Bt878 (rev 17) at
>> :02:0d.0, irq: 17, latency: 32, mmio: 0xd5002000
>> Jan 20 20:07:07 quad kernel: [ 8490.114279] bttv: 1: using:  ***
>> UNKNOWN/GENERIC ***  [card=0,autodetected]
>> Jan 20 20:07:07 quad kernel: [ 8490.116288] tveeprom 5-0050: Huh, no
>> eeprom present (err=-6)?
>> Jan 20 20:07:07 quad kernel: [ 8490.116296] bttv: 1: tuner type unset
>> Jan 20 20:07:07 quad kernel: [ 8490.116393] bttv: 1: registered device
>> video1
>> Jan 20 20:07:07 quad kernel: [ 8490.116589] bttv: 1: registered device
>> vbi1
>> Jan 20 20:07:07 quad kernel: [ 8490.120104] bttv: Bt8xx card found (2)
>> Jan 20 20:07:07 quad kernel: [ 8490.120135] bttv: 2: Bt878 (rev 17) at
>> :02:0e.0, irq: 18, latency: 32, mmio: 0xd5004000
>> Jan 20 20:07:07 quad kernel: [ 8490.120165] bttv: 2: using:  ***
>> UNKNOWN/GENERIC ***  [card=0,autodetected]
>> Jan 20 20:07:07 quad kernel: [ 8490.121031] tveeprom 6-0050: Huh, no
>> eeprom present (err=-6)?
>> Jan 20 20:07:07 quad kernel: [ 8490.121035] bttv: 2: tuner type unset
>> Jan 20 20:07:07 quad kernel: [ 8490.121090] bttv: 2: registered device
>> video2
>> Jan 20 20:07:07 quad kernel: [ 8490.121226] bttv: 2: registered device
>> vbi2
>> Jan 20 20:07:07 quad kernel: [ 8490.124682] bttv: Bt8xx card found (3)
>> Jan 20 20:07:07 quad kernel: [ 8490.124714] bttv: 3: Bt878 (rev 17) at
>> :02:0f.0, irq: 19, latency: 32, mmio: 0xd5006000
>> Jan 20 20:07:07 quad kernel: [ 8490.124744] bttv: 3: using:  ***
>> UNKNOWN/GENERIC ***  [card=0,autodetected]
>> Jan 20 20:07:07 quad kernel: [ 8490.125739] tveeprom 7-0050: Huh, no
>> eeprom present (err=-6)?
>> Jan 20 20:07:07 quad kernel: [ 8490.125745] bttv: 3: tuner type unset
>> Jan 20 20:07:07 quad kernel: [ 8490.125842] bttv: 3: registered device
>> video3
>> Jan 20 20:07:07 quad kernel: [ 8490.126063] bttv: 3: r

Conexant PCI-8604PW 4 channel BNC Video capture card (bttv)

2014-01-20 Thread Robert Longbottom 


Hi,

I've just bought one of these cards which is based on the Conexant
Fusion 878A chip thinking it would just work under Linux being
bttv-based.  Unfortunately (for me) it's not and it is just picked up as
a generic unknown card by the bttv driver.

Does anyone have one of these that is working, or have any pointers to
what I can try to make it work?  I've had a go manually specifying card=
as a module option for a couple of the existing cards that also use the
Conexant Fusion chip but neither work (BTTV_BOARD_PICOLO_TETRA_CHIP and
BTTV_BOARD_GEOVISION_GV800S).

When I start up xawtv and switch to framegrabber mode I just get lots of
errors in /var/log/messages saying:

Jan 20 21:09:13 quad kernel: [ 2732.616016] bttv: 0: timeout: drop=0
irq=2998/35891, risc=339d5000, bits: HSYNC
Jan 20 21:09:13 quad kernel: [ 2733.122014] bttv: 0: timeout: drop=0
irq=3028/35952, risc=339d5000, bits: HSYNC
Jan 20 21:09:14 quad kernel: [ 2733.625018] bttv: 0: timeout: drop=0
irq=3058/36015, risc=339d5000, bits: HSYNC
Jan 20 21:09:14 quad kernel: [ 2734.127014] bttv: 0: timeout: drop=0
irq=3088/36077, risc=339d5000, bits: HSYNC
Jan 20 21:09:15 quad kernel: [ 2734.628014] bttv: 0: timeout: drop=0
irq=3118/36140, risc=339d5000, bits: HSYNC

Any help appreciated.  More info about the card below.
Thanks,
Rob.

Chips on card:

4x Conexant Fusion 878A
1x PCI6140-AA33PC
1x SMD IC with no markings at all
Couple of 74HCTnnn chips
1x Atmel 520
1x 35.46895M Crystal

Result of modprobe bttv:

Jan 20 20:07:07 quad kernel: [ 8490.076924] bttv: driver version 0.9.19
loaded
Jan 20 20:07:07 quad kernel: [ 8490.076930] bttv: using 8 buffers with
2080k (520 pages) each for capture
Jan 20 20:07:07 quad kernel: [ 8490.076983] bttv: Bt8xx card found (0)
Jan 20 20:07:07 quad kernel: [ 8490.077001] bttv: 0: Bt878 (rev 17) at
:02:0c.0, irq: 16, latency: 32, mmio: 0xd500
Jan 20 20:07:07 quad kernel: [ 8490.077033] bttv: 0: using:  ***
UNKNOWN/GENERIC ***  [card=0,autodetected]
Jan 20 20:07:07 quad kernel: [ 8490.109816] bttv: 0: tuner type unset
Jan 20 20:07:07 quad kernel: [ 8490.110099] bttv: 0: registered device
video0
Jan 20 20:07:07 quad kernel: [ 8490.110485] bttv: 0: registered device vbi0
Jan 20 20:07:07 quad kernel: [ 8490.114206] bttv: Bt8xx card found (1)
Jan 20 20:07:07 quad kernel: [ 8490.114228] bttv: 1: Bt878 (rev 17) at
:02:0d.0, irq: 17, latency: 32, mmio: 0xd5002000
Jan 20 20:07:07 quad kernel: [ 8490.114279] bttv: 1: using:  ***
UNKNOWN/GENERIC ***  [card=0,autodetected]
Jan 20 20:07:07 quad kernel: [ 8490.116288] tveeprom 5-0050: Huh, no
eeprom present (err=-6)?
Jan 20 20:07:07 quad kernel: [ 8490.116296] bttv: 1: tuner type unset
Jan 20 20:07:07 quad kernel: [ 8490.116393] bttv: 1: registered device
video1
Jan 20 20:07:07 quad kernel: [ 8490.116589] bttv: 1: registered device vbi1
Jan 20 20:07:07 quad kernel: [ 8490.120104] bttv: Bt8xx card found (2)
Jan 20 20:07:07 quad kernel: [ 8490.120135] bttv: 2: Bt878 (rev 17) at
:02:0e.0, irq: 18, latency: 32, mmio: 0xd5004000
Jan 20 20:07:07 quad kernel: [ 8490.120165] bttv: 2: using:  ***
UNKNOWN/GENERIC ***  [card=0,autodetected]
Jan 20 20:07:07 quad kernel: [ 8490.121031] tveeprom 6-0050: Huh, no
eeprom present (err=-6)?
Jan 20 20:07:07 quad kernel: [ 8490.121035] bttv: 2: tuner type unset
Jan 20 20:07:07 quad kernel: [ 8490.121090] bttv: 2: registered device
video2
Jan 20 20:07:07 quad kernel: [ 8490.121226] bttv: 2: registered device vbi2
Jan 20 20:07:07 quad kernel: [ 8490.124682] bttv: Bt8xx card found (3)
Jan 20 20:07:07 quad kernel: [ 8490.124714] bttv: 3: Bt878 (rev 17) at
:02:0f.0, irq: 19, latency: 32, mmio: 0xd5006000
Jan 20 20:07:07 quad kernel: [ 8490.124744] bttv: 3: using:  ***
UNKNOWN/GENERIC ***  [card=0,autodetected]
Jan 20 20:07:07 quad kernel: [ 8490.125739] tveeprom 7-0050: Huh, no
eeprom present (err=-6)?
Jan 20 20:07:07 quad kernel: [ 8490.125745] bttv: 3: tuner type unset
Jan 20 20:07:07 quad kernel: [ 8490.125842] bttv: 3: registered device
video3
Jan 20 20:07:07 quad kernel: [ 8490.126063] bttv: 3: registered device vbi3
Jan 20 20:07:07 quad kernel: [ 8490.130127] bttv: Bt8xx card found (4)
Jan 20 20:07:07 quad kernel: [ 8490.130151] bttv: 4: Bt878 (rev 17) at
:03:04.0, irq: 17, latency: 32, mmio: 0xd510
Jan 20 20:07:07 quad kernel: [ 8490.130182] bttv: 4: detected: IVC-200
[card=102], PCI subsystem ID is :a155
Jan 20 20:07:07 quad kernel: [ 8490.130186] bttv: 4: using: IVC-200
[card=102,autodetected]
Jan 20 20:07:07 quad kernel: [ 8490.130283] bttv: 4: tuner absent
Jan 20 20:07:07 quad kernel: [ 8490.130473] bttv: 4: registered device
video4
Jan 20 20:07:07 quad kernel: [ 8490.130512] bttv: 4: registered device vbi4
Jan 20 20:07:07 quad kernel: [ 8490.130534] bttv: 4: Setting PLL:
28636363 => 35468950 (needs up to 100ms)
Jan 20 20:07:07 quad kernel: [ 8490.136550] bttv: 4: Setting PLL:
28636363 => 35468950 (needs up to 100ms)
Jan 20 20:07:07 quad kernel: [ 8490.139121] bttv: 4: Setting PLL:
28636363 => 35468950 (needs up to

Re: OK szap is looking better, and I feel so close...

2011-04-30 Thread Robert Longbottom 

On 30/04/2011 12:06, Morgan Read wrote:

On 30/04/11 22:00, Robert Longbottom wrote:

On 30/04/2011 10:37, Morgan Read wrote:

OK, think I might be getting somewhere...





[user@vortexbox ~]$ szap -r TV2
reading channels from file '/home/user/.szap/channels.conf'


...


But, nothing happens at Playing /dev/dvb/adapter0/dvr0. ...  Where
should I see what's playing?


I usually do:

$ cat /dev/dvb/adapter0/dvr0>  recording.mpg

and then in another terminal

$ mplayer recording.mpg

Though it doesn't look like thats your problem, but at least you can see
if any data is being retrieved if the file grows in size.


Robert, thanks for your help!!!
Didn't get far with

$ cat /dev/dvb/adapter0/dvr0>  recording.mpg
$ mplayer recording.mpg
[vortexbox.lan ~]# cat /dev/dvb/adapter0/dvr0>  recording.mpg
^C
[vortexbox.lan ~]# ls -l
total 36
-rw-rw-r-- 1 user user  368 Apr 30 21:11 channels.conf
drwxr-xr-x 2 user user 4096 Apr 30 12:55 Desktop
drwxr-xr-x 2 user user 4096 Apr 29 22:22 Documents
drwxr-xr-x 2 user user 4096 Apr 29 22:34 Downloads
drwxr-xr-x 2 user user 4096 Apr 25 00:06 Music
drwxr-xr-x 2 user user 4096 Apr 25 00:06 Pictures
drwxr-xr-x 2 user user 4096 Apr 25 00:06 Public
-rw-rw-r-- 1 user user0 Apr 30 22:53 recording.mpg
drwxr-xr-x 2 user user 4096 Apr 25 00:06 Templates
drwxr-xr-x 2 user user 4096 Apr 25 00:06 Videos
[vortexbox.lan ~]#


Yes, I'm not that surpised that made no difference.  The problem it 
looks like you are having with the szap approach is that szap isn't 
locking onto a channel for some reason.  You aren't seeing those 
FE_HAS_LOCK messages in the szap output.  If you can sort that out, then 
szap + (cat +) mplayer should work.



BUT, that gave me an idea...

[vortexbox.lan ~]# dvbstream -f 1183 -s 22500 -p h -o 512 650>
recording.mpg
dvbstream v0.5 - (C) Dave Chapman 2001-2004
Released under the GPL.
Latest version available from http://www.linuxstb.org/
Using DVB card "Conexant CX24123/CX24109"
tuning DVB-S to L-Band:1, Pol:H Srate=2250, 22kHz=off
ERROR setting tone
: Invalid argument
polling
Getting frontend event
FE_STATUS:
polling
Getting frontend event
FE_STATUS: FE_HAS_SIGNAL
polling
Getting frontend event
FE_STATUS: FE_HAS_SIGNAL FE_HAS_LOCK FE_HAS_CARRIER FE_HAS_VITERBI
FE_HAS_SYNC
Event:  Frequency: 11783000
 SymbolRate: 2250
 FEC_inner:  3

Bit error rate: 0
Signal strength: 61952
SNR: 57635
FE_STATUS: FE_HAS_SIGNAL FE_HAS_LOCK FE_HAS_CARRIER FE_HAS_VITERBI
FE_HAS_SYNC
Setting filter for PID 512
Setting filter for PID 650
Output to stdout
Streaming 2 streams

Which produced this:

[user@vortexbox ~]$ mplayer recording.mpg
MPlayer SVN-r33254-snapshot-4.5.1 (C) 2000-2011 MPlayer Team
162 audio&  360 video codecs
Can't open joystick device /dev/input/js0: No such file or directory
Can't init input joystick
mplayer: could not connect to socket
mplayer: No such file or directory
Failed to open LIRC support. You will not be able to use your remote
control.

Playing recording.mpg.
TS file format detected.
VIDEO MPEG2(pid=512) AUDIO MPA(pid=650) NO SUBS (yet)!  PROGRAM N. 0
VIDEO:  MPEG2  720x576  (aspect 3)  25.000 fps  15000.0 kbps (1875.0
kbyte/s)
Load subtitles in ./
==
Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family
Selected video codec: [ffmpeg2] vfm: ffmpeg (FFmpeg MPEG-2)
==
==
Opening audio decoder: [mp3lib] MPEG layer-2, layer-3
AUDIO: 48000 Hz, 2 ch, s16le, 192.0 kbit/12.50% (ratio: 24000->192000)
Selected audio codec: [mp3] afm: mp3lib (mp3lib MPEG layer-2, layer-3)
==
AO: [pulse] 48000Hz 2ch s16le (2 bytes per sample)
Starting playback...
[VD_FFMPEG] Trying pixfmt=0.
Could not find matching colorspace - retrying with -vf scale...
Opening video filter: [scale]
The selected video_out device is incompatible with this codec.
Try appending the scale filter to your filter list,
e.g. -vf spp,scale instead of -vf spp.
[VD_FFMPEG] Trying pixfmt=1.
Could not find matching colorspace - retrying with -vf scale...
Opening video filter: [scale]
The selected video_out device is incompatible with this codec.
Try appending the scale filter to your filter list,
e.g. -vf spp,scale instead of -vf spp.
[VD_FFMPEG] Trying pixfmt=2.
Could not find matching colorspace - retrying with -vf scale...
Opening video filter: [scale]
The selected video_out device is incompatible with this codec.
Try appending the scale filter to your filter list,
e.g. -vf spp,scale instead of -vf spp.
Movie-Aspect is 1.78:1 - prescaling to correct movie aspect.
VO: [xv] 720x576 =>  1024x576 Planar YV12
A:90135.5 V:90135.5 A-V:  0.001 ct:  0.093 13786/13786  6%  0%  0.5% 0 0


MPlayer in

Re: OK szap is looking better, and I feel so close...

2011-04-30 Thread Robert Longbottom 

On 30/04/2011 10:37, Morgan Read wrote:

OK, think I might be getting somewhere...





[user@vortexbox ~]$ szap -r TV2
reading channels from file '/home/user/.szap/channels.conf'
zapping to 3 'TV2':
sat 0, frequency = 12483 MHz H, symbolrate 2250, vpid = 0x0204,
apid = 0x028e
using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
status 01 | signal fa00 | snr f772 | ber  | unc fffe |
status 01 | signal 0f00 | snr a344 | ber  | unc fffe |
status 01 | signal 0f00 | snr a423 | ber  | unc fffe |
... ... ...
^C


I'd expect to see (from memory) FE_HAS_LOCK on the end of those lines, 
so something more like this:


status 01 | signal fa00 | snr f772 | ber  | unc fffe | 
FE_HAS_LOCK


Looks like it hasn't locked on to the channel for some reason.  I think 
this is probably your problem, though I don't know what you should do to 
fix it...



[user@vortexbox ~]$

And, while szap -r TV2 is running, on another console I should be able
to run mplayer?  So:
[user@vortexbox ~]$ mplayer -vo x11 /dev/dvb/adapter0/dvr0
MPlayer SVN-r33254-snapshot-4.5.1 (C) 2000-2011 MPlayer Team
162 audio&  360 video codecs
Can't open joystick device /dev/input/js0: No such file or directory
Can't init input joystick
mplayer: could not connect to socket
mplayer: No such file or directory
Failed to open LIRC support. You will not be able to use your remote control.

Playing /dev/dvb/adapter0/dvr0.


MPlayer interrupted by signal 2 in module: demux_open


MPlayer interrupted by signal 2 in module: demux_open
[user@vortexbox ~]$

But, nothing happens at Playing /dev/dvb/adapter0/dvr0. ...  Where
should I see what's playing?


I usually do:

$ cat /dev/dvb/adapter0/dvr0 > recording.mpg

and then in another terminal

$ mplayer recording.mpg

Though it doesn't look like thats your problem, but at least you can see 
if any data is being retrieved if the file grows in size.


Robert.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ngene & Satix-S2 dual problems

2011-01-22 Thread Robert Longbottom 

On 11 Jan 2011, at 15:25, Andre wrote:


On 28 Dec 2010, at 17:25, Andre wrote:

/>  /
/>  I seems to work with the last patch commited by Oliver Endriss. Did you/
/>  try with a CI ?/
/  /
/  No I didn't, I don't have a CI./
/  /
/  I'll try Olivers latest commit in a few days, I'm a long way from my Myth 
system right now :-)/


 Finally got chance to try the latest commits, no extra nodes now and drivers 
work fine with several simultaneous HD recordings across both tuners.

 Satix S2 dual v2 on Ubuntu 10.0.4.1 kernel 2.6.32-25-generic

 Thanks

 Andre


Hi,
I've finally gotten round to trying the latest commits as well
and I can also report success.  No extra nodes, drivers appear to be working
ok after a very quick test.  I'll see how it goes over the next few days.

Satix S2 dual on Gentoo with kernel 2.6.35.4.

Cheers,
Robert.
 

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ngene & Satix-S2 dual problems

2010-11-27 Thread Robert Longbottom 

On 21/11/2010 19:48, Robert Longbottom wrote:

On 21/11/2010 19:23, Andre wrote:


On 21 Nov 2010, at 17:23, Robert Longbottom wrote:


Oh, I also get the three extra dvb adapters, in my case 1,2& 3. (I
already have two other dvb cards in this box that take 0 and 4) Thats
using these module parameters:


That's definitely odd, it's the ngene that's generating them not any
of the other cards I have. I just managed to get everything to fit in
the default 8 adaptors, I can't use one_adaptor=1 as dvbloopback
doesn't work with that.


Yes, it's definitely ngene thats creating them, because if I rmmod it,
then they dissapear. My other two cards use other drivers.


The extra nodes seem to be a harmless oddity and this driver is a
massive improvement, big thank you to Oliver.


Indeed, they don't seem to break anything or stop the Satix card from
working. And yes, this driver is a massive improvement in terms of being
able to use both tuners.


Report back in a few days, my system records ~ 10 hours of HD a day,
small percentage of which I actually watch so it should get a workout.


I've run a few tests this evening with MythTv recording up to 6
simultaneous programs across the two tuners on the Satix and it seems to
be holding up so far. A mixture of SD and HD. It did have a couple of
instances where it didn't immediately get a lock on a couple of channels
when I was surfing livetv, but I'm willing to put that down to just
bedding in for now.

I'm just debating whether to leave it as the active card and see how it
gets on. Assuming it manages this evenings recordings ok, I think I will
probably will.


Well, I did leave it as the active (and only) card in my MythTV box and 
it's been working fine for a week now doing my usual recording schedule 
across both inputs.  I've not seen any failed recordings, or any 
problems with the recordings it's made.


So it seems that it is working fine now.  I still have the problem with 
the additional dvb adapters, but they don't seem to be causing a problem 
so far as I can tell.


Thanks go to Oliver for these drivers - hopefully we can see these 
changes in the kernel sometime soon :-)


Robert.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ngene & Satix-S2 dual problems

2010-11-21 Thread Robert Longbottom 

On 21/11/2010 19:23, Andre wrote:


On 21 Nov 2010, at 17:23, Robert Longbottom wrote:


On 21/11/2010 13:15, Andre wrote:


On 21 Nov 2010, at 13:07, Robert Longbottom wrote:




On 21 Nov 2010, at 11:40 AM, Andre   wrote:



On 20 Nov 2010, at 19:22, Oliver Endriss wrote:


Hi,

On Saturday 20 November 2010 16:52:34 Robert Longbottom wrote:

Hi all,

I have a Satix-S2 Dual that I'm trying to get to work properly so that I
can use it under MythTv however I'm running into a few issues.  I
previously posted about the problems I'm having here to the mythtv
list[1], but didn't really get anywhere.  I've had chance to have a bit
more of a play and I now seem to have a definite repeatable problem.

The problem is when a recording stops on one of the inputs, after about
40s it causes the other input to loose it's signal lock and stop the
recording as well.


Steps to demonstrate the problem (My Satix card is adapters 5 and 6)

In 3 seperate terminals set up femon/szap/cat to make a recording from
one of the inputs:

1 - femon -a 6 -f 0 -H
2 - szap -a 6 -f 0 -d 0 -r -H -p -c scanResult07Oct2010_Satix -l
UNIVERSAL "BBC 1 London"
3 - cat /dev/dvb/adapter6/dvr0>   ad6.mpg

In 2 seperate terminals tune in the other input:

4 - femon -a 5 -f 0 -H
5 - szap -a 5 -f 0 -d 0 -r -H -p -c scanResult07Oct2010_Satix -l
UNIVERSAL "ITV1 London"

Both inputs are fine, signal is good, recording from adapter 6 works.

6 - Ctrl-C the szap process created in (5).

femon in (4) still reports status=SCVYL and decent signal strengh as if
the adapter is still tuned and FE_HAS_LOCK.  After approximately 40
seconds, either:

a) the signal drops significantly but the status remains at SCVYL and
FE_HAS_LOCK

or

b) the signal drops and the status goes blank with no lock.

It doesn't seem to matter which of these two happen, but at the same
time the recording on the other tuner looses it signal and stops
recording, despite the fact that szap is still running in (2).  femon in
(1) no longer reports FE_HAS_LOCK.

Strangely if I then try to restart the szap process created in terminal
2 (to try and retune it) it just waits after printing out "using
'/dev/dvb/".  However if I then restart the szap process in terminal
5, the one in terminal 2 suddenly kicks in and gets a lock.

Interestingly I found a link describing a 60s period the card is kept
open for [2], which seems to be similar to my ~40s delay.  So it looks
like when the second input on the card is closed the first input looses
it's lock.

This obviously makes it pretty useless for MythTv and as a result it's
not currently being used, which is a shame!

I'm using the ngene driver from the stock 2.6.35.4 kernel on Gentoo.

Does anyone else see this problem?  Is there anything I can do to try
and fix / debug it?  Are there any bug fixes in the latest kernel that
might help, or in the linux-dvb drivers that would help?

Any help or advice much appreciated.


Please try this driver:
http://linuxtv.org/hg/~endriss/ngene-test2


Well that's progress, trying Robert's procedure fails with my stock driver 
(Ubuntu 10.10's 2.6.35-22-generic) but recording continues with your 
ngene-test2 driver :-)

NB I needed to go grab ngene_18.fw before it would work and I have three unexpected 
extra frontends, adapter 0,1&2 as well as the configured 5&6, not sure what's 
going on there yet!

There's a ber bump on the other tuner when you retune but it carries on which 
is the main thing at this stage. Can see glitches at the corresponding spot in 
the recording but worth a try with Myth perhaps?

I've been running with only one of the tuners for months, perhaps best to 
switch off active eit collection though looking at that ber bump.

Great stuff Oliver.

Andre




That does sound like good news, I'll try and give it a go later today now that 
I have a process to test with. If it does appear to have fixed it then I'll 
switch myth over to using it later next week and see how it gets on.


I tried it with Myth 0.24 and just got six simultaneous HD recordings out of it 
:-)) total seven if you count the one I started to keep the HD-S2 card busy, 
can't try any more with that sat and my sub.

No glitches I can see, tried it a couple of times with different muxes, so far 
so good.


Will report back with the results later.


You can have your thread back now ;-)


Thanks ;-)  The more people that test this and iron out the bugs the better :-)


I've got an email monitor looking for any mention of the ngene in here, mythtv, 
hts&  vdr lists so I can see if there is any activity, looking for just this 
kind of email :-)


Ah, neat :-)



I've run through my procedure again using the ngene-test2 drivers from Oliver 
and I can report success as well.  I too see a glitch on the 2nd tuner when you 
retune the 1st, or after about 30s from killing an szap agains

Re: ngene & Satix-S2 dual problems

2010-11-21 Thread Robert Longbottom 

On 21/11/2010 13:15, Andre wrote:


On 21 Nov 2010, at 13:07, Robert Longbottom wrote:




On 21 Nov 2010, at 11:40 AM, Andre  wrote:



On 20 Nov 2010, at 19:22, Oliver Endriss wrote:


Hi,

On Saturday 20 November 2010 16:52:34 Robert Longbottom wrote:

Hi all,

I have a Satix-S2 Dual that I'm trying to get to work properly so that I
can use it under MythTv however I'm running into a few issues.  I
previously posted about the problems I'm having here to the mythtv
list[1], but didn't really get anywhere.  I've had chance to have a bit
more of a play and I now seem to have a definite repeatable problem.

The problem is when a recording stops on one of the inputs, after about
40s it causes the other input to loose it's signal lock and stop the
recording as well.


Steps to demonstrate the problem (My Satix card is adapters 5 and 6)

In 3 seperate terminals set up femon/szap/cat to make a recording from
one of the inputs:

1 - femon -a 6 -f 0 -H
2 - szap -a 6 -f 0 -d 0 -r -H -p -c scanResult07Oct2010_Satix -l
UNIVERSAL "BBC 1 London"
3 - cat /dev/dvb/adapter6/dvr0>  ad6.mpg

In 2 seperate terminals tune in the other input:

4 - femon -a 5 -f 0 -H
5 - szap -a 5 -f 0 -d 0 -r -H -p -c scanResult07Oct2010_Satix -l
UNIVERSAL "ITV1 London"

Both inputs are fine, signal is good, recording from adapter 6 works.

6 - Ctrl-C the szap process created in (5).

femon in (4) still reports status=SCVYL and decent signal strengh as if
the adapter is still tuned and FE_HAS_LOCK.  After approximately 40
seconds, either:

a) the signal drops significantly but the status remains at SCVYL and
FE_HAS_LOCK

or

b) the signal drops and the status goes blank with no lock.

It doesn't seem to matter which of these two happen, but at the same
time the recording on the other tuner looses it signal and stops
recording, despite the fact that szap is still running in (2).  femon in
(1) no longer reports FE_HAS_LOCK.

Strangely if I then try to restart the szap process created in terminal
2 (to try and retune it) it just waits after printing out "using
'/dev/dvb/".  However if I then restart the szap process in terminal
5, the one in terminal 2 suddenly kicks in and gets a lock.

Interestingly I found a link describing a 60s period the card is kept
open for [2], which seems to be similar to my ~40s delay.  So it looks
like when the second input on the card is closed the first input looses
it's lock.

This obviously makes it pretty useless for MythTv and as a result it's
not currently being used, which is a shame!

I'm using the ngene driver from the stock 2.6.35.4 kernel on Gentoo.

Does anyone else see this problem?  Is there anything I can do to try
and fix / debug it?  Are there any bug fixes in the latest kernel that
might help, or in the linux-dvb drivers that would help?

Any help or advice much appreciated.


Please try this driver:
http://linuxtv.org/hg/~endriss/ngene-test2


Well that's progress, trying Robert's procedure fails with my stock driver 
(Ubuntu 10.10's 2.6.35-22-generic) but recording continues with your 
ngene-test2 driver :-)

NB I needed to go grab ngene_18.fw before it would work and I have three unexpected 
extra frontends, adapter 0,1&2 as well as the configured 5&6, not sure what's 
going on there yet!

There's a ber bump on the other tuner when you retune but it carries on which 
is the main thing at this stage. Can see glitches at the corresponding spot in 
the recording but worth a try with Myth perhaps?

I've been running with only one of the tuners for months, perhaps best to 
switch off active eit collection though looking at that ber bump.

Great stuff Oliver.

Andre




That does sound like good news, I'll try and give it a go later today now that 
I have a process to test with. If it does appear to have fixed it then I'll 
switch myth over to using it later next week and see how it gets on.


I tried it with Myth 0.24 and just got six simultaneous HD recordings out of it 
:-)) total seven if you count the one I started to keep the HD-S2 card busy, 
can't try any more with that sat and my sub.

No glitches I can see, tried it a couple of times with different muxes, so far 
so good.


Will report back with the results later.


You can have your thread back now ;-)


Thanks ;-)  The more people that test this and iron out the bugs the 
better :-)


I've run through my procedure again using the ngene-test2 drivers from 
Oliver and I can report success as well.  I too see a glitch on the 2nd 
tuner when you retune the 1st, or after about 30s from killing an szap 
against the 1st, but the stream on the second tuner continues, so thats 
a massive improvement.  Good work.


I'll give it a quick go with MythTV as well tonight, and later next 
week.  Previously when I tried this tuner with MythTV it would record 
upto 6 streams with no problem, but of couse

Re: ngene & Satix-S2 dual problems

2010-11-21 Thread Robert Longbottom 


On 21 Nov 2010, at 11:40 AM, Andre  wrote:

> 
> On 20 Nov 2010, at 19:22, Oliver Endriss wrote:
> 
>> Hi,
>> 
>> On Saturday 20 November 2010 16:52:34 Robert Longbottom wrote:
>>> Hi all,
>>> 
>>> I have a Satix-S2 Dual that I'm trying to get to work properly so that I 
>>> can use it under MythTv however I'm running into a few issues.  I 
>>> previously posted about the problems I'm having here to the mythtv 
>>> list[1], but didn't really get anywhere.  I've had chance to have a bit 
>>> more of a play and I now seem to have a definite repeatable problem.
>>> 
>>> The problem is when a recording stops on one of the inputs, after about 
>>> 40s it causes the other input to loose it's signal lock and stop the 
>>> recording as well.
>>> 
>>> 
>>> Steps to demonstrate the problem (My Satix card is adapters 5 and 6)
>>> 
>>> In 3 seperate terminals set up femon/szap/cat to make a recording from 
>>> one of the inputs:
>>> 
>>> 1 - femon -a 6 -f 0 -H
>>> 2 - szap -a 6 -f 0 -d 0 -r -H -p -c scanResult07Oct2010_Satix -l 
>>> UNIVERSAL "BBC 1 London"
>>> 3 - cat /dev/dvb/adapter6/dvr0 > ad6.mpg
>>> 
>>> In 2 seperate terminals tune in the other input:
>>> 
>>> 4 - femon -a 5 -f 0 -H
>>> 5 - szap -a 5 -f 0 -d 0 -r -H -p -c scanResult07Oct2010_Satix -l 
>>> UNIVERSAL "ITV1 London"
>>> 
>>> Both inputs are fine, signal is good, recording from adapter 6 works.
>>> 
>>> 6 - Ctrl-C the szap process created in (5).
>>> 
>>> femon in (4) still reports status=SCVYL and decent signal strengh as if 
>>> the adapter is still tuned and FE_HAS_LOCK.  After approximately 40 
>>> seconds, either:
>>> 
>>> a) the signal drops significantly but the status remains at SCVYL and 
>>> FE_HAS_LOCK
>>> 
>>> or
>>> 
>>> b) the signal drops and the status goes blank with no lock.
>>> 
>>> It doesn't seem to matter which of these two happen, but at the same 
>>> time the recording on the other tuner looses it signal and stops 
>>> recording, despite the fact that szap is still running in (2).  femon in 
>>> (1) no longer reports FE_HAS_LOCK.
>>> 
>>> Strangely if I then try to restart the szap process created in terminal 
>>> 2 (to try and retune it) it just waits after printing out "using 
>>> '/dev/dvb/".  However if I then restart the szap process in terminal 
>>> 5, the one in terminal 2 suddenly kicks in and gets a lock.
>>> 
>>> Interestingly I found a link describing a 60s period the card is kept 
>>> open for [2], which seems to be similar to my ~40s delay.  So it looks 
>>> like when the second input on the card is closed the first input looses 
>>> it's lock.
>>> 
>>> This obviously makes it pretty useless for MythTv and as a result it's 
>>> not currently being used, which is a shame!
>>> 
>>> I'm using the ngene driver from the stock 2.6.35.4 kernel on Gentoo.
>>> 
>>> Does anyone else see this problem?  Is there anything I can do to try 
>>> and fix / debug it?  Are there any bug fixes in the latest kernel that 
>>> might help, or in the linux-dvb drivers that would help?
>>> 
>>> Any help or advice much appreciated.
>> 
>> Please try this driver:
>> http://linuxtv.org/hg/~endriss/ngene-test2
> 
> Well that's progress, trying Robert's procedure fails with my stock driver 
> (Ubuntu 10.10's 2.6.35-22-generic) but recording continues with your 
> ngene-test2 driver :-)
> 
> NB I needed to go grab ngene_18.fw before it would work and I have three 
> unexpected extra frontends, adapter 0,1&2 as well as the configured 5&6, not 
> sure what's going on there yet!
> 
> There's a ber bump on the other tuner when you retune but it carries on which 
> is the main thing at this stage. Can see glitches at the corresponding spot 
> in the recording but worth a try with Myth perhaps?
> 
> I've been running with only one of the tuners for months, perhaps best to 
> switch off active eit collection though looking at that ber bump.
> 
> Great stuff Oliver.
> 
> Andre
> 
> 

That does sound like good news, I'll try and give it a go later today now that 
I have a process to test with. If it does appear to have fixed it then I'll 
switch myth over to using it later next week and see how it gets on. 

Will report back with the results later. 

Robert. 

> 
>> 
>> CU
>> Oliver
>> 
>> -- 
>> 
>> VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/
>> 4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/
>> Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/
>> 
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-media" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> 
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

ngene & Satix-S2 dual problems

2010-11-20 Thread Robert Longbottom 

Hi all,

I have a Satix-S2 Dual that I'm trying to get to work properly so that I 
can use it under MythTv however I'm running into a few issues.  I 
previously posted about the problems I'm having here to the mythtv 
list[1], but didn't really get anywhere.  I've had chance to have a bit 
more of a play and I now seem to have a definite repeatable problem.


The problem is when a recording stops on one of the inputs, after about 
40s it causes the other input to loose it's signal lock and stop the 
recording as well.



Steps to demonstrate the problem (My Satix card is adapters 5 and 6)

In 3 seperate terminals set up femon/szap/cat to make a recording from 
one of the inputs:


1 - femon -a 6 -f 0 -H
2 - szap -a 6 -f 0 -d 0 -r -H -p -c scanResult07Oct2010_Satix -l 
UNIVERSAL "BBC 1 London"

3 - cat /dev/dvb/adapter6/dvr0 > ad6.mpg

In 2 seperate terminals tune in the other input:

4 - femon -a 5 -f 0 -H
5 - szap -a 5 -f 0 -d 0 -r -H -p -c scanResult07Oct2010_Satix -l 
UNIVERSAL "ITV1 London"


Both inputs are fine, signal is good, recording from adapter 6 works.

6 - Ctrl-C the szap process created in (5).

femon in (4) still reports status=SCVYL and decent signal strengh as if 
the adapter is still tuned and FE_HAS_LOCK.  After approximately 40 
seconds, either:


a) the signal drops significantly but the status remains at SCVYL and 
FE_HAS_LOCK


or

b) the signal drops and the status goes blank with no lock.

It doesn't seem to matter which of these two happen, but at the same 
time the recording on the other tuner looses it signal and stops 
recording, despite the fact that szap is still running in (2).  femon in 
(1) no longer reports FE_HAS_LOCK.


Strangely if I then try to restart the szap process created in terminal 
2 (to try and retune it) it just waits after printing out "using 
'/dev/dvb/".  However if I then restart the szap process in terminal 
5, the one in terminal 2 suddenly kicks in and gets a lock.


Interestingly I found a link describing a 60s period the card is kept 
open for [2], which seems to be similar to my ~40s delay.  So it looks 
like when the second input on the card is closed the first input looses 
it's lock.


This obviously makes it pretty useless for MythTv and as a result it's 
not currently being used, which is a shame!


I'm using the ngene driver from the stock 2.6.35.4 kernel on Gentoo.

Does anyone else see this problem?  Is there anything I can do to try 
and fix / debug it?  Are there any bug fixes in the latest kernel that 
might help, or in the linux-dvb drivers that would help?


Any help or advice much appreciated.

Thanks,
Robert.

[1] - 
http://www.mailinglistarchive.com/html/mythtv-us...@mythtv.org/2010-10/msg00725.html


[2] - https://patchwork.kernel.org/patch/87392/
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html