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.
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...
Also, you say "anymore" in the summary... Do you happen to recall when it was last working?
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).
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.
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!
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.
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).
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...
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...
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...
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
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.
Pardon the triage bot... Would be good to know if this still impacts Fedora 8 and/or 9 though.
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
Nggggh. Bot, stop it...
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
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
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!