[opensuse] howto get details of 1394 (firewire) device creation on camera plug-in (need BASH test)
Guys, Working with dvgrab and a firewire link to download digital video, I have run into a problem on camera plug-in to the computer. Sometimes the firewire device is created properly and video downloads fine. Other times, the device is created and is able to control the camera, but cannot download video. Unplugging and replugging the cable in usually cures it. The kernel message for the bad plug-in is: Sep 24 21:21:18 archangel kernel: [2111415.165895] firewire_core: phy config: card 0, new root=ffc1, gap_count=5 Sep 24 21:21:18 archangel kernel: [2111415.800050] firewire_core: created device fw1: GUID 08004601017ede99, S100 For the successful plug-in, you get: Sep 24 21:33:54 archangel kernel: [2112171.169381] firewire_core: phy config: card 0, new root=ffc1, gap_count=5 Sep 24 21:33:57 archangel kernel: [2112174.926294] firewire_core: created device fw1: GUID 08004601017ede99, S100, 1 config ROM retries Note the "1 config ROM retries" appended to the 'fw1' device creation when the plug-in goes correctly. I don't understand what this is or what it means, but I do need to devise a way to test for a successful plug-in from within a BASH script. Now, granted, it is simple enough to grep the message log and look for "1 config ROM retries" within a reasonable time after the plug in, but I know that is a hack... When the device is created, where does it go in the /proc tree? How best to test and what to test for the correct creation of the ROM entries before beginning the dvgrab? Anybody run into this before? -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On 9/24/2011 8:18 PM, David C. Rankin wrote:
Guys,
Working with dvgrab and a firewire link to download digital video, I have run into a problem on camera plug-in to the computer. Sometimes the firewire device is created properly and video downloads fine. Other times, the device is created and is able to control the camera, but cannot download video. Unplugging and replugging the cable in usually cures it. The kernel message for the bad plug-in is:
Sep 24 21:21:18 archangel kernel: [2111415.165895] firewire_core: phy config: card 0, new root=ffc1, gap_count=5 Sep 24 21:21:18 archangel kernel: [2111415.800050] firewire_core: created device fw1: GUID 08004601017ede99, S100
For the successful plug-in, you get:
Sep 24 21:33:54 archangel kernel: [2112171.169381] firewire_core: phy config: card 0, new root=ffc1, gap_count=5 Sep 24 21:33:57 archangel kernel: [2112174.926294] firewire_core: created device fw1: GUID 08004601017ede99, S100, 1 config ROM retries
Note the "1 config ROM retries" appended to the 'fw1' device creation when the plug-in goes correctly.
I don't understand what this is or what it means, but I do need to devise a way to test for a successful plug-in from within a BASH script. Now, granted, it is simple enough to grep the message log and look for "1 config ROM retries" within a reasonable time after the plug in, but I know that is a hack...
When the device is created, where does it go in the /proc tree? How best to test and what to test for the correct creation of the ROM entries before beginning the dvgrab? Anybody run into this before?
I don't have a firewire camera, but all my other firewire disks just show up in some subdirectory of /media. I use these for backup. So I create a sub directory of that sub-directory where the firewire drive appears and I put a file in there. If I can read the file, the drive is not mounted. If Its not found, its because the drive mounted over the subdirectory. -- _____________________________________ ---This space for rent--- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On 09/24/2011 10:36 PM, John Andersen wrote:
For the successful plug-in, you get:
Sep 24 21:33:54 archangel kernel: [2112171.169381] firewire_core: phy config: card 0, new root=ffc1, gap_count=5 Sep 24 21:33:57 archangel kernel: [2112174.926294] firewire_core: created device fw1: GUID 08004601017ede99, S100, 1 config ROM retries
Note the "1 config ROM retries" appended to the 'fw1' device creation when the plug-in goes correctly.
I don't understand what this is or what it means, but I do need to devise a way to test for a successful plug-in from within a BASH script. Now, granted, it is simple enough to grep the message log and look for "1 config ROM retries" within a reasonable time after the plug in, but I know that is a hack...
When the device is created, where does it go in the /proc tree? How best to test and what to test for the correct creation of the ROM entries before beginning the dvgrab? Anybody run into this before?
I don't have a firewire camera, but all my other firewire disks just show up in some subdirectory of /media. I use these for backup. So I create a sub directory of that sub-directory where the firewire drive appears and I put a file in there. If I can read the file, the drive is not mounted. If Its not found, its because the drive mounted over the subdirectory.
John, All, Thanks. It seems with this firewire device, it is either hit or miss. Looking further at the error, I was misinterpreting the "1 config ROM retries" as being some additional indication that something got created somewhere that allowed for the successful download of video. (smacks self...) Wrong-O. It means just what it says: "1 config ROM retries". Meaning it just re-tried the creation of the 1st config ROM... Basically it's just saying "Hey stupid, I just retried doing what I just did to create the fw1 device." For whatever reason it may or may not work on the first creation attempt. It usually always works after an unplug/re-plug. I have also had it work just fine after the 1st connect attempt. So basically, this is one of those annoying "may/may not" work things that I don't know enough about, but I do need to be able to figure out if I have a good connection before I try and call dvgrab from the script. If I don't have a good connection and I start dvgrab, then the tape will start playing and no video will be downloaded. Not a big deal, unless you need to start the capture at a specific point, then it is a giant PITA (rewind, reset, restart capture...). I'll keep messing with it. 'dvgrab' is an amazing tool for 1394 or usb video capture. I have been really impressed with its flexibility. Anybody have any other thoughts on how to test for a good fw1 device creation or connection before calling dvgrab, I would appreciate your thoughts. -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Sun, 2011-09-25 at 13:36 -0500, David C. Rankin wrote: I use firewire cameras, not video. They plug in just fine. They do not have any local storage, so access is really just grabbing a new image. I have a udev rule that ensures proper permissions. I think this is different for video cameras. But the general idea may be the same: KERNEL=="raw1394*", NAME="%k", GROUP="video", MODE="666", OPTIONS="last_rule" KERNEL=="dv1394*", NAME="%k", SYMLINK+="dv1394/%n", GROUP="video", MODE="666", OPTIONS="last_rule" KERNEL=="video1394*", NAME="%k", SYMLINK+="video1394/%n", GROUP="video", MODE="666", OPTIONS="last_rule" The only thing I have found is that if the cameras are unplugged/plugged too quickly, the 1349 drivers sometimes complain about which devices is a master. (Or some such similar text - it never happened enough to become an issue that I remember in detail.) Does dvgrab list all the interesting info about the found cameras when it starts? If so, perhaps that shows a difference. Yours sincerely, Roger Oberholtzer OPQ Systems / Ramböll RST Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On 09/26/2011 01:34 AM, Roger Oberholtzer wrote:
On Sun, 2011-09-25 at 13:36 -0500, David C. Rankin wrote:
I use firewire cameras, not video. They plug in just fine. They do not have any local storage, so access is really just grabbing a new image. I have a udev rule that ensures proper permissions. I think this is different for video cameras. But the general idea may be the same:
KERNEL=="raw1394*", NAME="%k", GROUP="video", MODE="666", OPTIONS="last_rule" KERNEL=="dv1394*", NAME="%k", SYMLINK+="dv1394/%n", GROUP="video", MODE="666", OPTIONS="last_rule" KERNEL=="video1394*", NAME="%k", SYMLINK+="video1394/%n", GROUP="video", MODE="666", OPTIONS="last_rule"
The only thing I have found is that if the cameras are unplugged/plugged too quickly, the 1349 drivers sometimes complain about which devices is a master. (Or some such similar text - it never happened enough to become an issue that I remember in detail.)
Does dvgrab list all the interesting info about the found cameras when it starts? If so, perhaps that shows a difference.
Roger, Thanks. dvgrab doesn't give you a whole lot of information when it starts other than telling you it: Found AV/C device with GUID 0x08004601017ede99 It gives you that information regardless. (as long as it can find a device). If there is no camera found it just exits with the "No Camera Found" message. In my case, the camera is always found and dvgrab can ALWAYS control it (rewind, play, etc..) The problem I'm dealing with is when it starts 'play' to begin the capture - sometimes there is no capture, nothing recorded to disk, even though dvgrab has started the 'play' mode on the camera just fine. The indication I get on whether there is a successful download started is that dvgrab issues the "Capture Started" message when download begins. For the times when the camera is put in play mode and nothing is downloaded, dvgrab just sits there with the "Waiting for DV..." message (even though dvgrab has rewound the tape and started the camera playing). In either case, dvgrab will play though the entire tape before exiting... (roughly an hour +- 5 minutes) I am using the following command line to start dvgrab. I just echo the date so I have a reference for when I started the download so I know to check back in an hour to switch tapes and start it again. (the first "Capture Started" message is mine from the CLI [poor choice of words]) The second "Capture Started" message is the one issued by dvgrab. I run dvgrab in a subshell so that any error messages from the dvgrab stderr stream are logged in the correct order and don't get intertwined with any messages from the tee stderr stream (not that I've ever had any from tee). The download/no download issue occurs regardless of whether you run dvgrab in a subshell. 10:37 archangel:/dat_e/dv/new> (echo -e "\nCapture Started: $(date '+%b %e %T')\n"; dvgrab -rewind -timestamp -autosplit=3600 -format raw dcrv- 2>&1) | tee -a /dat_e/dv/capture.log Capture Started: Sep 26 10:37:52 Found AV/C device with GUID 0x08004601017ede99 Waiting for DV... Capture Started <== this is the dvgrab message "dcrv-1999.12.24_17-11-33.dv": 999.98 MiB 8738 frames timecode 00:04:51.18 date 1999.12.24 17:24:26 "dcrv-1999.12.24_17-24-26.dv": 656.78 MiB 5739 frames timecode 00:08:03.05 date 1999.12.24 18:14:28 <snip> On thing I could do is to wait for 3-4 minutes after starting dvgrab and then check for the "Capture Started" message -- but frankly, I'm unclear how I would do that from within a script since processing in the script is waiting for dvgrab to finish?? Any ideas on how to do this would be welcomed. I don't know, maybe start a timer in the script before the dvgrab call that waits 5 minutes, checks for the "Capture Started" and if not found, kills the dvgrab PID and issues an error?? I'll have to dig more into BASH to figure that one out. dnh, bkw -- you listening :) -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On 09/26/2011 11:01 AM, David C. Rankin wrote:
The indication I get on whether there is a successful download started is that dvgrab issues the "Capture Started" message when download begins. For the times when the camera is put in play mode and nothing is downloaded, dvgrab just sits there with the "Waiting for DV..." message (even though dvgrab has rewound the tape and started the camera playing).
FYI, I've also posted this to the kino list and will pass along any further information I get... -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Mon, 2011-09-26 at 11:32 -0500, David C. Rankin wrote:
On 09/26/2011 11:01 AM, David C. Rankin wrote:
The indication I get on whether there is a successful download started is that dvgrab issues the "Capture Started" message when download begins. For the times when the camera is put in play mode and nothing is downloaded, dvgrab just sits there with the "Waiting for DV..." message (even though dvgrab has rewound the tape and started the camera playing).
FYI, I've also posted this to the kino list and will pass along any further information I get...
Anything in /var/log/messages when it does and does not work? Yours sincerely, Roger Oberholtzer OPQ Systems / Ramböll RST Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
It turns out we may be adding video to our system if we get a contract in New Zealand. So perhaps I should take this chance to ask what kind of camera you are using. We would be needing rather high-resolution (still undefined). What formats do the cameras provide? In the case of 1394 still image cameras, the cameras follow a standard and provide images encoded as, say, YUV 4:4:2. Not JPEG or anything. We do that after we capture the image. I am guessing you do not do any sort of time encoding in the image. That usually requires additional hardware. I have not even checked what 1394 video possibilities there are. Yours sincerely, Roger Oberholtzer OPQ Systems / Ramböll RST Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Hello, On Mon, 26 Sep 2011, David C. Rankin wrote:
10:37 archangel:/dat_e/dv/new> (echo -e "\nCapture Started: $(date '+%b %e %T')\n"; dvgrab -rewind -timestamp -autosplit=3600 -format raw dcrv- 2>&1) | tee -a /dat_e/dv/capture.log
Capture Started: Sep 26 10:37:52
Found AV/C device with GUID 0x08004601017ede99 Waiting for DV... Capture Started <== this is the dvgrab message [..] On thing I could do is to wait for 3-4 minutes after starting dvgrab and then check for the "Capture Started" message -- but frankly, I'm unclear how I would do that from within a script since processing in the script is waiting for dvgrab to finish?? Any ideas on how to do this would be welcomed. I don't know, maybe start a timer in the script before the dvgrab call that waits 5 minutes, checks for the "Capture Started" and if not found, kills the dvgrab PID and issues an error?? I'll have to dig more into BASH to figure that one out. dnh, bkw -- you listening :)
A bit tricky. Basic idea: ==== #!/bin/bash DVLOG=/dat_e/dv/capture.log do_dvgrab() { exec 3>$DVLOG dvgrab ... >&3 2>&3 & DVPID="$!" sleep 300 if ! grep -q "Capture Started" $DVLOG; then kill -TERM $DVPID ret=127 ### dvgrab only uses 0 and 1 as exit codes else wait $DVPID ret=$? fi exec 3>&- return $ret } i=0 while ! do_dvgrab; do dv_ret=$? test $dv_ret -ne 127 && exit $dv_ret i=$((i+1)) ### abort after 5 tries if test $i -ge 5; then break; fi done ==== HTH, -dnh -- "Now, what was I doing before I so rudely interrupted myself?" -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
participants (4)
-
David C. Rankin -
David Haller -
John Andersen -
Roger Oberholtzer