Bug 220638 - dvgrab doesn't discover DV devices automatically anymore
dvgrab doesn't discover DV devices automatically anymore
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: libavc1394 (Show other bugs)
9
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jarod Wilson
bzcl34nup
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-12-22 12:53 EST by Bastien Montagne
Modified: 2008-07-08 10:40 EDT (History)
2 users (show)

See Also:
Fixed In Version: 3.1-3.fc9
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-07-08 10:40:12 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Bastien Montagne 2006-12-22 12:53:04 EST
Description of problem:
dvgrab doesn't discover dv camera automatically at start-up.

Version-Release number of selected component (if applicable):
original rpm in FC6 DVD (dvgrab-2.0-1.2.2.i386.rpm)

How reproducible:
Plug in a dv camera and start dvgrab with something like :
    $ dvgrab -i capt-

Steps to Reproduce:
1.
2.
3.
  
Actual results:
dvgrab halts saying that it didn't found any dv device.

Expected results:
dvgrab should detect the camera and enter in interactive mode.

Additional info:
I am working on an another dv capture tool (sourceforge.net/projects/dvgrabgui)
and I discovered the bug with this app, before reproducing it with dvgrab.
I think the problem is in fact in libavc1394, with the 
    avc1394_check_subunit_type
function, witch seems to never return a true value when searching dv camera devices.

dvgrab still works well, if you provide him the guid of the scope.
Comment 1 Jarod Wilson 2007-01-19 16:27:08 EST
Changing component to libavc1394... Good thing I've got a dv camera at home,
probably will need to bring that into the office to actually be able to make any
progress on this one...
Comment 2 Jarod Wilson 2007-01-19 16:27:57 EST
Also, you say "anymore" in the summary... Do you happen to recall when it was
last working?
Comment 3 Bastien Montagne 2007-01-21 08:37:12 EST
It worked with the original rpm of the FC5 DVD(i.e.
libavc1394-0.5.1-2.2.i386.rpm, and dvgrab-2.0-1.2.1.i386.rpm).
Comment 4 Jarod Wilson 2007-01-23 13:03:52 EST
Blah. It looks like the current dvgrab was built against libavc1394 0.5.1, which
was subsequently upgraded to 0.5.3, without a rebuild of dvgrab. There are some
changes in 0.5.3, particularly wrt the need to call
avc1394_transaction_block_close that I'm guessing dvgrab isn't properly dealing
with.

There's a dvgrab 2.1 release of about a month ago, so I'm actually going to bump
up to that, along with the rebuild against libavc1394 0.5.3. I'll push builds to
both rawhide and updates-testing for FC6. If you'd be so kind, please give them
a spin once they show up and see if that doesn't resolve the problem.
Comment 5 Bastien Montagne 2007-02-18 09:49:59 EST
I've tested the dvgrab-2.1-2.fc6.i386.rpm, it doesn't seem to resolve the
problem,  and I didn't found any newer version at this time. Let me know when
there will be news... Thanks for working on it!
Comment 6 Jarod Wilson 2007-02-22 01:03:09 EST
Unfortunately, the only news I have is that everything works perfectly with my Canon ZR-45 DV camera, so 
I don't really know how to go about fixing this one. :\ You'd probably get the best results if you could 
engage upstream directly.
Comment 7 Jarod Wilson 2007-10-26 09:44:28 EDT
I was just reminded this bug was still open... Bastien, are you still running
FC6 and still seeing this problem? FC6 is unlikely to get anymore attention,
since its almost end-of-life and for the most part, all of my attention has been
on F7 and F8 dv support of late, where we use a different firewire stack. Would
be very interested to hear if things are better or the same with F7 + all the
latest updates or with F8 (due to be released shortly).
Comment 8 Bastien Montagne 2007-11-18 15:20:14 EST
Hi, Jarod.
Sory I'm not very reactive, but I'm mainly working under Debian these days...
Anyway, I installed Fedora 7 (from scratch, not an update), and found that
dvgrab wasn't on the F7 DVD I used! So I tried with the version of FC6...
As a simple user, I have still the same problem, but as root, the camera is well
discovered ... and dvgrab crash causing kernel oops (probably because it can't
run with the dirvers/librairy of F7?)
It would probably be a good idea to try to launch dvgrab as root under FC6, but
I won't reinstall it just for that!

So I think I will wait for Fedora 8 (a month or two: I use press DVDs...) and
see if it work (I've seen in that it will be dvgrab 3.0). I'll post a new
message at this time.

PS: under Debian, I have the same problem, with a message "failed to get raw1394
handler: permission denied", witch force me to try to launch dvgrab as root...
and there is no more problems...
Comment 9 Bastien Montagne 2008-01-30 09:50:46 EST
Hi, I've tested dvgrab in the new Fedora 8.
First, this bug seems to be corrected (i.e. dvgrab seems
to discover automaticaly my camera...)!

Hoever, I have same problems as reported in bug #271801
(https://bugzilla.redhat.com/show_bug.cgi?id=271801), So I can't be really sure
everything is OK...

Here is a log when trying to launch dvgrab:

[root@fedora fedora]# dvgrab -i
Found AV/C device with GUID 0x00008500008cec1e
ioctl call failed, retval = -1
ieee1394io.cc:460: In function "virtual bool iec61883Reader::StartReceive()":
"iec61883_dv_fb_start( m_iec61883.dv, channel )" evaluated to -1
"Loading Medium" ff:ff:ff:ff ""          sec      

...and dvgrab can't capture anything nor quit (I have to close the console...),
It even freezes all the system when I unplug the camera (I have to do a RESET!).


I also tested with GStreamer (after a reset):

[root@fedora fedora]# gst-launch dv1394src ! decodebin name=d ! queue !
audioconvert ! audioresample ! alsasink d. ! ffmpegcolorspace ! xvimagesink
Setting pipeline to PAUSED ...
ioctl call failed, retval = -1
ERROR: Pipeline doesn't want to pause.
ERROR: from element /pipeline0/dv1394src0: Could not read from resource.
Additional debug info:
gstdv1394src.c(866): gst_dv1394src_start (): /pipeline0/dv1394src0:
can't start 1394 iso receive
Setting pipeline to NULL ...
FREEING pipeline ...

...no exit problems here...

Comment 10 Jarod Wilson 2008-01-30 10:13:29 EST
The 'ioctl call failed, retval = -1' message leads me to believe you've got an
OHCI 1.0 controller. We didn't add proper dv support for 1.0 controllers until a
post-release F8 kernel. That part should be resolved if you just upgrade to the
latest kernel available via yum. Not sure about the complete system lockup though...
Comment 11 Bug Zapper 2008-04-04 01:21:15 EDT
Fedora apologizes that these issues have not been resolved yet. We're
sorry it's taken so long for your bug to be properly triaged and acted
on. We appreciate the time you took to report this issue and want to
make sure no important bugs slip through the cracks.

If you're currently running a version of Fedora Core between 1 and 6,
please note that Fedora no longer maintains these releases. We strongly
encourage you to upgrade to a current Fedora release. In order to
refocus our efforts as a project we are flagging all of the open bugs
for releases which are no longer maintained and closing them.
http://fedoraproject.org/wiki/LifeCycle/EOL

If this bug is still open against Fedora Core 1 through 6, thirty days
from now, it will be closed 'WONTFIX'. If you can reporduce this bug in
the latest Fedora version, please change to the respective version. If
you are unable to do this, please add a comment to this bug requesting
the change.

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we are following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.

And if you'd like to join the bug triage team to help make things
better, check out http://fedoraproject.org/wiki/BugZappers
Comment 12 Bug Zapper 2008-05-06 13:14:10 EDT
This bug is open for a Fedora version that is no longer maintained and
will not be fixed by Fedora. Therefore we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen thus bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.
Comment 13 Jarod Wilson 2008-05-06 13:53:52 EDT
Pardon the triage bot... Would be good to know if this still impacts Fedora 8
and/or 9 though.
Comment 14 Bug Zapper 2008-05-06 21:03:35 EDT
This bug has been in NEEDINFO for more than 30 days since feedback was
first requested. As a result we are closing it.

If you can reproduce this bug in the future against a maintained Fedora
version please feel free to reopen it against that version.

The process we're following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp
Comment 15 Jarod Wilson 2008-05-06 22:30:21 EDT
Nggggh. Bot, stop it...
Comment 16 Bug Zapper 2008-05-13 22:31:22 EDT
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 17 Bastien Montagne 2008-07-08 10:26:06 EDT
I, Jarod
I think we should close this bug: with Fedora 9, there is no more problem about
discovering dv devices.

In fact, the only real problem that stay is the needing of beeing root to use
it... but there are other threads about it, I saw (445100, 441073).

Thanks for working on it!

Bastien
Comment 18 Jarod Wilson 2008-07-08 10:40:12 EDT
Excellent, we're slowly getting closer and closer... :) Just bear with us a
little bit longer, and we should get the permissions thing sorted out. I may
need to go poke some of the hal folks in person...

Anyhow, I'll go ahead and close this bug out. Thanks much!

Note You need to log in before you can comment on or make changes to this bug.