Re: Can't get kino or dvgrab to work

Gary Lawrence Murphy wrote:
> This is a little OT, but maybe tangentially relevant: I have a dvgrab
> problem that has plagued me since acquiring this Dell (Inspiron 1521)
> laptop. I get nothing at all from the firewire port using Ubuntu linux
> (8.04) and dvgrab.

First of all, make sure that this is not just a file access permissions
problem.  With the user account which you use to run dvgrab, run
    ls -l /dev/raw1394
    id
If unsure about the result or how to fix it if it isn't correct, post
the result here.  (In moderately new distributions, /dev/raw1394 does
not exist from the outset but is created when a device was plugged in
and recognized for which this device file is suitable, e.g. a camcorder.
If it doesn't exist, the next checks will be more important than file
permissions.)

> is there any way to test the port to see if it is working?

The latest Ubuntu contains new firewire kernel drivers, in addition to
the "classic" ieee1394 Linux kernel drivers.  The latter are loaded by
default but can be replaced by the newer ones.  The new drivers allow
more comfortable diagnostics of issues like this one.

*However*, you can also get something out of the classic ieee1394
drivers in Ubuntu 8.04.  First of all, take a filebrowser and look into
/sys/bus/ieee1394/devices.  As long as nothing is connected to the
FireWire port, you get two subdirectories there.  (Actually symlinks,
not directories.)  When you plug in/ switch on the camcorder, watch
whether another subdirectory is being added.  If not, that'd be bad.
Then look at the contents of fw-host0/in_bus_reset, fw-host0/node_count,
and fw-host0/nodes_active and compare their values from before and after
you connected the camcorder.

A 2nd test:  Issue the command "dmesg" shortly after you connected the
camcorder and see if there are any messages in there from the 1394
drivers.  (dmesg prints the kernel log, which is usually also saved
somewhere in a log file in /var/log, e.g. in the general log
/var/log/messages.  But this differs from distribution to distribution
while dmesg does the same everywhere.)

A 3rd test:  You can watch whether the FireWire controller emits any
interrupts (it should).  Start a loop like this:
    while sleep 1; do grep 1394 /proc/interrupts; done
Then plug in/ switch on the camcorder and see whether the interrupt
count increases.  (2nd number on single core PCs, 2nd or 3rd number on
dual core PCs.)  You can quit the loop with [Ctrl][c] when done.

And a 4th test:  If you have two PCs with FireWire, you can plug them
together and check whether they see each other by the three
aforementioned methods.

> lspci lists the hardware as
> 
>  03:01.0 FireWire (IEEE 1394): Ricoh Co Ltd R5C832 IEEE 1394 Controller (rev
> 05)
> 
> and everything seems right, there's just no evidence of any actual
> connection; this camera worked perfectly using Mandriva 2007 with
> 
> 01:0a.0 FireWire (IEEE 1394): Agere Systems FW323 (rev 04)
> 
> but it also does not work with a Toshiba DVD-recorder bought at wal-mart; a
> friend said it might be because my Sony TRV-230 might have an 'older'
> standard of FireWire that is invisible to modern hardware.

I don't think so.  IEEE 1394 is IEEE 1394, regardless whether 1394 or
FireWire or iLink is stamped on it.  There have been revisions to the
standard over time, but not that drastic that devices wouldn't recognize
each other anymore.

Older FireWire hardware was more susceptible to damage to the ports due
to hotplugging though.  I.e. older devices with blown-out ports are not
unheard of.

> is there any way I can test this at a low level?  is there any (free)
> standalone windows app that I might use to see if this is a faulty firewire
> port
[...]

I suppose the Windows device manager shows the camcorder or at least an
unknown device if your FireWire port and camcorder work under Windows.
-- 
Stefan Richter
-=====-==--= =-=- =-=-=
http://arcgraph.de/sr/

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference