11.1 dvgrab 3.2 No Camera

[KaptRoger]

Hi,

Its possible that this problem is not hardware, but it strikes me as being the right place to start.

I wish to pull AV off my camcorder (JVC GR-DVL157E) and store it on my PC (Os 11.1/Gnome 2.24). Google seems to suggest that DVGrab would be my answer.

I have an IEEE1394 card:

lspci |grep 1394
02:0b.0 FireWire (IEEE 1394): Texas Instruments TSB12LV23 IEEE-1394 Controller

lsmod shows this (I have manually added raw/dv/video):

lsmod |grep 1394
video1394 13988 0
dv1394 15648 0
raw1394 21212 0
ohci1394 27664 2 video1394,dv1394
ieee1394 83756 4 video1394,dv1394,raw1394,ohci1394

But dvgrab complains that there is no camera.


testlibraw reports (with camera detached) :

testlibraw
successfully got handle
current generation number: 1
1 card(s) found
nodes on bus: 1, card name: ohci1394
using first card found: 1 nodes on bus, local ID is 0, IRM is 0

doing transactions with custom tag handler
trying to send read request to node 0... completed with value 0x1ebb1946

using standard tag handler and synchronous calls
trying to read from node 0... completed with value 0xe7e31946

testing FCP monitoring on local node
got fcp command from node 0 of 8 bytes: 01 23 45 67 89 ab cd ef
got fcp response from node 0 of 8 bytes: 01 23 45 67 89 ab cd ef
testing config rom stuff
get_config_rom returned 0, romsize 64, rom_version 4
here are the first 10 quadlets:
0. quadlet: 0xa5ad0404
1. quadlet: 0x34393331
2. quadlet: 0x32a264e0
3. quadlet: 0xe1425000
4. quadlet: 0x7ab74002
5. quadlet: 0xc95c0300
6. quadlet: 0x42500003
7. quadlet: 0x02000081
8. quadlet: 0xc083000c
9. quadlet: 0x2a2c0600
update_config_rom returned 0

polling for leftover messages

With camera attached:

testlibraw
successfully got handle
current generation number: 1
1 card(s) found
nodes on bus: 0, card name: ohci1394
using first card found: 0 nodes on bus, local ID is 0, IRM is 63

doing transactions with custom tag handler

using standard tag handler and synchronous calls

testing FCP monitoring on local node
testing config rom stuff
get_config_rom returned 0, romsize 64, rom_version 5
here are the first 10 quadlets:
0. quadlet: 0xa5ad0404
1. quadlet: 0x34393331
2. quadlet: 0x32a264e0
3. quadlet: 0xe1425000
4. quadlet: 0x7ab74002
5. quadlet: 0xc95c0300
6. quadlet: 0x42500003
7. quadlet: 0x02000081
8. quadlet: 0xc083000c
9. quadlet: 0x2a2c0600
update_config_rom returned 0

polling for leftover messages


It is odd that the number of nodes goes down when the camera is plugged in and turned on.

Can any one advise a way forward for me please?

Thanks in advance.

[KaptRoger]

Well after a lot more digging I went into "playing" mode.

I had these 1394 modules loaded:

lsmod|grep 1394
video1394 13988 0
raw1394 21212 0
ohci1394 27664 1 video1394
ieee1394 83756 3 video1394,raw1394,ohci1394

testlibraw appeared to be behaving oddly. So I unloaded the modules and started reloading them one by one (modprobe -r video1394 etc, modprobe ieee1394)

After loading each one I ran testlibraw and observed the same behaviour, i.e. the camera not being detected.

I then realised that testlibraw was testing libraw. So I unloaded the modules again, and this time only loaded raw1394, tested with testlibraw and got this:

testlibraw
successfully got handle
current generation number: 0
0 card(s) found

Which is odd because I do have a card, so I then loaded ohci1394 (pure guess - well partly it is the card driver after all), and then tested again.

testlibraw
successfully got handle
current generation number: 1
1 card(s) found
nodes on bus: 2, card name: ohci1394
using first card found: 2 nodes on bus, local ID is 1, IRM is 1

doing transactions with custom tag handler
trying to send read request to node 0... completed with value 0x82ea88c4
trying to send read request to node 1... completed with value 0xd6ba89c4

using standard tag handler and synchronous calls
trying to read from node 0... completed with value 0xdbc689c4
trying to read from node 1... completed with value 0xbce08ac4

testing FCP monitoring on local node
got fcp command from node 1 of 8 bytes: 01 23 45 67 89 ab cd ef
got fcp response from node 1 of 8 bytes: 01 23 45 67 89 ab cd ef
testing config rom stuff
get_config_rom returned 0, romsize 64, rom_version 3
here are the first 10 quadlets:
0. quadlet: 0xa5ad0404
1. quadlet: 0x34393331
2. quadlet: 0x32a264e0
3. quadlet: 0xe1425000
4. quadlet: 0x7ab74002
5. quadlet: 0xc95c0300
6. quadlet: 0x42500003
7. quadlet: 0x02000081
8. quadlet: 0xc083000c
9. quadlet: 0x2a2c0600
update_config_rom returned 0

polling for leftover messages

Apparent success! Something extra was detected on the Firewire bus.

So taking a leap of faith, I ran dvgrab, and got this:

dvgrab
Found AV/C device with GUID 0x0080880100a65687
Capture Started
"dvgrab-001.dv": 999.89 MiB 7281 frames timecode 00:04:54.19 date 2007.05.13 21:58:36
"dvgrab-002.dv": 999.89 MiB 7281 frames timecode 00:09:46.00 date 2007.05.14 00:11:4

It works.

I suppose I am left now with the questions - how do I ensure that a) these modules are loaded (I could script it), and b) they are loaded in the correct order?

Thanks in advance

[pdc_2]

phew;

we have had a firewire card on each of our two computers; both were auto-configured on suse; ranging from 9.3 to 11.0 and both have enabled us to download video, fine each time; the saving grace is you seem very proficient at diagnosing and investigating your problems; one wonders if any permutation of linux can be solved

[KaptRoger]

Thanks but actually I have a propensity for leaping in with both feet.

I have subsequently discovered that my "solution" was entirely coincidental with events. :-(

It appears (I'm being cautious here because I don't wish to offend any one), that at least with my firewire card that you have to randomly unload and reload the firewire drivers to be able to see my DV camera. It appears to be completely random. Rebooting also doesn't fix the issue necessarily, repeated reboots will (sigh) eventually.

So I ended up writing a naff script to be run as root to unload and reload the modules until the camera (turned on and ready to use) was recognised. The script is dedicated to finding the one and only node on my firewire bus (excluding the card itself), any bus with extra nodes would require the script to be edited. I enclose it below for others who might need this sort of resolution.

#!/bin/bash

while true
do
    modprobe -r dv1394 -r raw1394 -r ohci1394
    modprobe ohci1394
    modprobe raw1394
    sleep 5
    if [ `testlibraw|grep -c "got fcp response from node 1"` -eq 0 ]
    then
	echo "No result"
	sleep 5
    else
	echo "Success found node 1"
	exit
    fi
done

Oh and in my opinion Kino beats dvgrab hands down. :-)

[ahimhaim]

There is one single simple step which solved this problem for me: switch back to dvgrab version 3.0-18. Suddenly everything works. This worked for me on opensuse 11.1 with the latest raw drivers.

This also solved the issue where dvgrab stops capturing and issues "This error means that the frames could not be written fast enough."

Therefore, there is a bug with dvgrab 3.2 on opensuse 11.1. It also seems that later versions are buggy on opensuse 11.1.