Re: Anyone using dvgrab successfully in opensuse 11.0/11.1?

Carl Karsten wrote:
> On Sat, May 16, 2009 at 7:03 PM, Woojin Lee <[email protected]> wrote:
>> when I connected two PCs together
>> with the same cable, this is what I got on both PCs.
>>
>> /sys/bus/ieee1394/devices/fw-host0/node_count:2
>> /sys/bus/ieee1394/devices/fw-host0/nodes_active:2
>> /sys/bus/ieee1394/devices/fw-host0/selfid_count:2
>>
>> which I presume means success.  So, am I safe to assume the cards and the
>> cable are good then?  It's hard to believe that both DV camcoders are damaged
>> though...  They both are relative new.  Is there anything else that could be
>> the issue?  I'll see if I can find another DV camera.
>>
> 
> I had some problems too.  No clue if it was the same problem, or
> exactly what my problem was.  but I remember thinking " It's hard to
> believe that both DV camcoders" till someone pointed out there are
> probably some common chipsets / implementations.  I also concluded
> that 99% of the people coming across the problem were able to roll
> with it, like the driver/app was able to just drop some frames and
> continue.
> 
> my only point is "yes, it could be both DV camcoders are damaged." but
> it isn't a very strong case.

OTOH it could still be an issue between our kernel drivers and the PC's 
controller chips.  Is it the Texas Instruments PCI4451 in both PCs?

Texas Instruments controllers like the TSB43ABxx family and TSB82AA2 
work very well under Linux.  These are all OHCI 1.1 implementations 
though, while PCI4451 is shown in your logs as an OHCI 1.0 part.  Maybe 
they used the older TSB12LV26 design there.  By far fewer people have 
these compared to the aforementioned TI controller series, hence there 
might be issues between our drivers and these chips which we weren't 
aware of yet.

Ah, by the way:
>>>> ieee1394: Host added: ID:BUS[0-00:1023]  GUID[434fc000248c8821]
This GUID is not a proper one.  434fc0 is not a registered 
Organizationally Unique ID.  I.e. the serial EEPROM which feeds 
initialization values to the controller has some bogus contents. 
However, the OUI of the other card, 001106, is a registered one. 
(Siemens NV, Belgium - can this be correct?)

The next thing is that this could be a problem between the camcorders 
and the PHY chips --- these are interface chips which sit between the 
PCI4451 and the FireWire socket.  I suspect that some or many camcorders 
send stream data right from the moment on when they are powered on, and 
that some PHY chips are disturbed by this and unable to finish the bus 
reset/ self identification phases.

Owners of Sony camcorders sometimes seem to experience something which 
might be explainable by the latter, but other camcorder types might be 
involved too.  Whether the fault lies with the camcorders or the PC's 
PHY or somewhere else is unclear.  Deviation from the IEEE 1394 physical 
layer specification on one or the other or both sides seems the most 
plausible explanation to me though.
-- 
Stefan Richter
-=====-=-=== -=-= -==-=
http://arcgraph.de/sr/

------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables 
unlimited royalty-free distribution of the report engine 
for externally facing server and web deployment. 
http://p.sf.net/sfu/businessobjects