I have one of these video cameras ‘Samsung VP-D381 Mini DV’. The camera itself is probably no problem but when capturing through Kino, KDenlive etc, the firewire connection slips from time to time. I use the raw1394 module and things seems fine except for the disconnections which eventually will occur, sometimes 10 minutes sometimes seconds. To reconnect it I just have to switch the camera off and on again, or unplug and replug the cable again. The module is a hotplug I believe, it isn’t present in /dev before I plug in the camera, so perhaps if I forced it to load at boot time it would work better? Does anyone know how I should proceed to do this correctly in OpenSuSE (11.2)? Or is my presumption far fetched?
I wonder if this might be cable problem - Check that your cable plugs mate properly, and that the pins are not bent.
It is unlikely that it is a cable issue, I have tested with two different cables and the second one was new. However, it could of course be the camera port, but it looks alright to me.
782.599919] ohci1394: fw-host0: AT dma reset ctx=0, aborting transmission
Searching around I found this thread describing a similar problem with the 1394 bus being frequently reset. (It seems to be a bug that only affects some firewire controllers). If you’ve got money to spare, it might be a good investment to buy an external unit (like the Belkin type suggested in the thread).
The old ieee1394 driver stack — i.e. ieee1394, ohci1394, pcilynx, sbp2, eth1394, raw1394, video1394, dv1394 — is now scheduled for removal in Linux 2.6.37.
Even for 2.6.33 (for example), it mentions
Distributors who still ship the old stack (ieee1394, ohci1394, raw1394, sbp2, eth1394 and more) should now switch to the new one (firewire-core, firewire-ohci, firewire-sbp2, firewire-net). In the first iteration, those distributors might want to ship the old stack also (but blacklisted) as a fallback for their users if unforeseen problems with the newer replacement drivers are encountered.
The older FireWire stack contains several known problems which are not going to be fixed; instead, those issues are addressed by the new stack. An incomplete list of these issues is kept in bugzilla. We have a guide on migration from the older to the newer stack.
I know little about the new firewire stack, but it looks like progress has been made in newer kernels, so I’ll leave it to you to research it further.
olav@localhost:~> dvgrab
Found AV/C device with GUID 0x0000f000ffffffff
Warning: Cannot set RR-scheduler
Capture Started
"dvgrab-001.dv": buffer underrun near: timecode 00:14:48.15 date 2008.01.01 00:00:00
This error means that the frames could not be written fast enough.
"dvgrab-001.dv": buffer underrun near: timecode 00:14:48.15 date 2008.01.01 00:00:00
This error means that the frames could not be written fast enough.
"dvgrab-001.dv": buffer underrun near: timecode 00:14:48.15 date 2008.01.01 00:00:00
This error means that the frames could not be written fast enough.
"dvgrab-001.dv": buffer underrun near: timecode 00:14:48.15 date 2008.01.01 00:00:00
This error means that the frames could not be written fast enough.
"dvgrab-001.dv": buffer underrun near: timecode 00:14:48.15 date 2008.01.01 00:00:00
This error means that the frames could not be written fast enough.
"dvgrab-001.dv": buffer underrun near: timecode 00:14:48.15 date 2008.01.01 00:00:00
This error means that the frames could not be written fast enough.
"dvgrab-001.dv": buffer underrun near: timecode 00:14:48.15 date 2008.01.01 00:00:00
This error means that the frames could not be written fast enough.
I really think this may come down to your firewire controller. Is is an old card? Have a read of this lengthy RH bug report, some of which mentions buffer under-runs. Other than this, I’m out of ideas. Does it capture the video ok (despite the warnings)?
I really think this may come down to your firewire controller
The firewire ports are on a firewire/usb pci expansion card and it used to work quite fine under OS 11.0 running the same camera captured through firewire into Kino.
Does it capture the video ok
The video is being captured just fine for a while (apart from the buffer under-runs), but eventually it will disconnect. The same as with Kino/KDenlive.
There are several threads and bug reports on this topic, both concerning firewire modules and dvgrab. The workarounds, however, does not seem to work for me, so far. There is one tip, though, I’m a bit uncertain about. In a Ubuntu forum someone suggested to add user to the group ‘disk’ and add this line (the red one) in the 50-raw-firewire.rules file:
I’ve already added the raw module to the ‘audio’ group (could have been added to the ‘video’ group) to have user access to it. But I don’t know what the ‘disk’ group is and I haven’t tried this suggestion.
I would be wary of adding a user to the disk group, as it means that a rogue application can potentially write directly to hard disk device nodes for example. (Its regarded as being nearly as bad as having root permissions). AFAIU, the suggestion you mention involves acquiring direct access to the raw firewire device /dev/raw1394 by being a member of the disk group. However, I completely understand why some users would choose it if it solves a problem for them.
I’ll leave the disk group as it is. I guess I have to look towards the new firewire stack and see if that could be a solution, or perhaps buy a video card and try importing video that way.