Re: Can't get kino or dvgrab to work

thanks for the very detailed reply.  Unfortunately it fails the first test,
there is no file created in /sys/bus/ieee1394/devices and no change in the
/proc/interrupts when the camera is turned to vcr mode or off or camera
mode.  I've also tried multiple cables.

I'll try that two machine test later; I didn't know I could do that, but I
think what I'm seeing here is that the firewire port on the camera may no
longer be working.

thanks again for these instructions.  very useful.

On Wed, Oct 21, 2009 at 2:08 PM, Stefan Richter
<[email protected]>wrote:

> 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

_______________________________________________
Kino-dev mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/kino-dev