firewire dead, but only for some software

[Almost-retired]

Greetings;

Currently booted to 2.6.38.2-pae  but I just had synaptics install 2.6.38.4-pae if that makes any diff.

kino-1.3.4 works with my Sony Hi-8 camera, a model DCR-TRV460.  This despite this in the logs when I plug the camera into a firewire port:
 Apr 27 12:45:55 coyote klogd: firewire_core: skipped bus generations, destroying all nodes
Apr 27 12:45:56 coyote klogd: firewire_core: rediscovered device fw0
Apr 27 12:45:56 coyote klogd: firewire_core: phy config: card 0, new root=ffc1, gap_count=5
Apr 27 12:45:56 coyote klogd: firewire_core: skipped bus generations, destroying all nodes
Apr 27 12:45:56 coyote klogd: firewire_core: giving up on config rom for node id ffc0
Apr 27 12:45:56 coyote klogd: firewire_core: rediscovered device fw0
Apr 27 12:46:27 coyote klogd: firewire_core: giving up on config rom for node id ffc0

Which is repeated evertyime I plug the cable into the powered up camera.

But Dan Dennedy has abandoned kino development and has been working on kdenlive for the last 3 or 4 years.

kdenlive cannot find the firewire port, so even after all this time, it is still worthless to me.

Toss in that this command line:
[root@coyote ~]# updatedb;locate 1394 |grep '/lib/modules'
/lib/modules/2.6.33.7-pclos6.bfs/modules.ieee1394map
/lib/modules/2.6.33.7-pclos6.bfs/kernel/drivers/ieee1394
/lib/modules/2.6.33.7-pclos6.bfs/kernel/drivers/ieee1394/dv1394.ko.gz
/lib/modules/2.6.33.7-pclos6.bfs/kernel/drivers/ieee1394/eth1394.ko.gz
/lib/modules/2.6.33.7-pclos6.bfs/kernel/drivers/ieee1394/ieee1394.ko.gz
/lib/modules/2.6.33.7-pclos6.bfs/kernel/drivers/ieee1394/ohci1394.ko.gz
/lib/modules/2.6.33.7-pclos6.bfs/kernel/drivers/ieee1394/pcilynx.ko.gz
/lib/modules/2.6.33.7-pclos6.bfs/kernel/drivers/ieee1394/raw1394.ko.gz
/lib/modules/2.6.33.7-pclos6.bfs/kernel/drivers/ieee1394/sbp2.ko.gz
/lib/modules/2.6.33.7-pclos6.bfs/kernel/drivers/ieee1394/video1394.ko.gz
/lib/modules/2.6.38.2-pclos1.pae.bfs/modules.ieee1394map
/lib/modules/2.6.38.4-pclos1.pae/modules.ieee1394map

Does not return near enough stuff related to firewire to have a reasonable expectation of its working.  I am now going to reboot to 38.4-pae but I am not holding my breath.

Does anyone have a better idea?

Cheers & Thanks, Gene

[menotu]

kdenlive cannot find the firewire port, so even after all this time, it is still worthless to me.

Don't know whether it'll help ya Almost-retired but there is a new release of Kdenlive 0.8 (repo version is 0.7. so I don't know whether you want to do a Package Request

 

[Almost-retired]

That notice on freshmeat was the trigger to go try the version we had, since the ChangeLog says it can control cameras for the last several releases, starting back in 2006.  So according to that, it /should/ work now, but it can't even find the firewire device to see the video coming up the cable.  Shut kdenlive down and fire up kino-1.3.4 and it all Just Works(TM).  I can click on buttons to completely control the camera, basically doing anything I want to it as long as I give it enough time to complete the last requested operation.

Frankly I have no clue why Dan Dennedy abandoned kino & started promoting kdenlive.  It may be a hell of an editor for all I know, but until it can actually import the data stream from the camera, it has nothing to work with as I have never been able to make it load or play the raw files from this camera that were captured by kino.  It can see the files, but there is no response when clicked on and opened.  Consequently I have yet, in probably 4 years of screwing with kdenlive, to actually see it play a video of any kind.

This reminds me of a Commercial product like autocad, uses a proprietary format for the files, and will likely sue if anyone even thinks of reverse engineering a convertor that would allow other programs to import its data.  Its leaving that sort of a taste in my mouth.

In the meantime, I have joined that mailing list an hour ago, so maybe there could be some help there.

Thanks menotu, & Cheers, Gene

[Almost-retired]

Saga continued.  But I quickly get into dependency hell trying to build a dvgrab-3.5 from the tarball, finally get enough devel stuff installed so it builds, but half of kde-4.6.2 and all of vlc is dependent on a libavc1394 that is linked to a libraw1394.so.8, and this version expects the 4 or 5 year old /dev/raw1394 structure & has no clue what to do with /dev/fw0 and when the camera is turned on, /dev/fw1.

I am between a rock and a hard place here.  I get the impression that kdenlive, even version 0.8 is going to remain broken for pclos until all of this firewire library infrastructure has been brought up to date, and from what I see here, that will be a total rebuild of kde and vlc in addition to all the libraries.

And yet kino-1.3.4, continues to Just Work(TM), but I also recall the hell I went through with it before I had managed to create a handful of dvd's that would play in everybody elses BBLB machines.

So rather than wait for the snowball fights in hell to start, I guess I'll waste a 50 pack spindle of dvd's trying.  :-(
 
Is there ANY other video editing software that works for firewire cameras available in the repo's?

[Almost-retired]

Saga, continued again.

I have managed to import the video/audio with kino, then export it to a tree of data that avidemux-qt4 can load, search through and play.

dvdauthor, after I moved the exported data from /usr/lib/wedding back to /root/Videos/wedding and pass it Videos/wedding-final with the -o option, and the -x name-of-dvdauthor.xml file built by kino in the export process, goes through a whole list of processing this and processing that, and generates a few files in ~/Videos/wedding-final that appear to function with avidemux-qt4.

So, progress of sorts.  Now what I think I need, and can probably do it with avidemux-qt4, is save some snapshots that I can call into gimp and superimpose some text titles, and then re-insert them into the video stream at say 60 frames worth here and there.  Once the gfx is created, I assume avidemux-qt4 can insert one of them at the currently parked spot in the data stream.  Or would this actually be easier if I loaded it back into kino, which can also save & insert snapshots.  That would require re-exporting it, but that would also be best done in a burn ready iso, which I assume would be a pipe into k3b?

But I see no such facility's to coordinate this on an 'on the fly' basis.  devede might be able to do this but I have not convinced devede that these are .devede files and it won't open any other formats.  Bummer.

Side comment here, 1. why the hell do I have to do all this as root?  Dangerous as all hell, I had no clue that when I told kino to export it, that it was going to export the whole 10+ Gb MaryAnn into /usr/lib!  WTH??

2nd side comment, since the last update, no programs that need to be run as root, will bring up a password requester, they just silently time out, so I am now forced to open a root shell just to run synaptic.  That is doable but a minor PIMA.

Or, is that an artifact of booting to level 3 and doing a separate startx as me the user?  I have done that the last couple of boots looking for boot msgs from some of my stuff in rc.local that are hidden by the early x startup.

One such msg indicates it cannot find heyu, but that's about the first thing I install.  And it works from a cli after the boot is completed. $PATH problems when rc.local runs I have to assume.

As always, looking for hints to 'do it right'.

Thanks & Cheers, Gene

[Almost-retired]

Further info from some of the firewire folks:  Pasted from an email I just replied to...
On Friday, April 29, 2011 05:38:21 PM Stefan Richter did opine:

> On Apr 29 Gene Heskett wrote:
> > Similar problem:
> > root@coyote lib]# /usr/local/bin/dvgrab -i
> > /usr/local/bin/dvgrab: error while loading shared libraries:
> > libraw1394.so.8: cannot open shared object file: No such file or
> > directory
> >
> > It wants the older version.
> >
> > And I cannot even remake dvgrab, libavc1394 is linked against the old
> > libraw1394.so.8 I removed, and this is going to lead to dependency
> > hell.
>
> libavc1394 only depends on libraw1394 and libc at runtime.  I'm not sure
> about buildtime requirements but it cannot be much more than make, gcc,
> and libraw1394-devel.
>
> Besides libavc1394, dvgrab also depends on:
>   - librom1394 which is juts a part of the libavc1394 package,
>   - libiec61883 which like libavc1394 depends (only) on libraw1394,
>   - libdv which is only involved in data decoding, not in 1394 I/O,
>     hence you don't need to rebuild libdv.
>
> AFAIK kdenlive calls dvgrab for all FireWire I/O.  Hence it functionally
> depends on dvgrab.
>
> You can always check what is linked to which by
> $ ldd $(which dvgrab)
> $ ldd /usr/lib/libavc1394.so
> etc.
>
Either copy of dvgrab returns this:
[root@coyote Videos]# ldd /usr/local/bin/dvgrab
        linux-gate.so.1 =>  (0xffffe000)
        libraw1394.so.8 => /usr/lib/libraw1394.so.8 (0xb784f000)
        libavc1394.so.0 => /usr/lib/libavc1394.so.0 (0x45241000)
        librom1394.so.0 => /usr/lib/librom1394.so.0 (0x45258000)
        libiec61883.so.0 => /usr/lib/libiec61883.so.0 (0xb7841000)
        libdv.so.4 => /usr/lib/libdv.so.4 (0x453e4000)
        libquicktime.so.0 => /usr/lib/libquicktime.so.0 (0x45061000)
        libpthread.so.0 => /lib/i686/libpthread.so.0 (0x46025000)
        libm.so.6 => /lib/i686/libm.so.6 (0x45ff7000)
        libz.so.1 => /usr/lib/libz.so.1 (0x4604b000)
        libdl.so.2 => /lib/libdl.so.2 (0x4601f000)
        libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x47bea000)
        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x464dd000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x464bf000)
        libc.so.6 => /lib/i686/libc.so.6 (0x45e8f000)
        /lib/ld-linux.so.2 (0x45031000)
and
[root@coyote Videos]# ldd /usr/lib/libavc1394.so
        linux-gate.so.1 =>  (0xffffe000)
        libraw1394.so.8 => /usr/lib/libraw1394.so.8 (0xb7849000)
        libc.so.6 => /lib/i686/libc.so.6 (0x45e8f000)
        /lib/ld-linux.so.2 (0x45031000)

So its all built against the old stuffs.

> As far as the various FireWire related libraries are concerned, you can
> keep old libraries from your distributor in /usr/lib and install your
> own brand new stuff in /usr/local/lib as long as you make sure that
> compiler and linker search /usr/local/{include,lib} first.
>
> [...]
>
> > The thing I can't quite grok is that if I use synaptic to see if I can
> > remove the older versions, it takes about 50 pkgs out of the heart of
> > kde-4.6.2 with it, about 20 pkgs from vlc and the rest of the firewire
> > related libraries.
>
> Apparently there are some programs in your distro that are built with
> obscure old IEEE 1394 I/O backends which are linked against libraw1394
> 1.3. Perhaps some of this old stuff cannot be built against libraw1394
> 2.0 because of removal of ancient API elements.
>
> Note:
>
> libraw1394 1.3.0 (i.e. libraw1394.so. can only use /dev/raw1394 which
> is no longer available since kernel 2.6.37.  Or in other words, in
> order to keep using libraw1394 1.3.0, you need kernel 2.6.36.y or older
> and the kernel needs to be configured with CONFIG_IEEE1394,
> CONFIG_IEEE1394_OHCI1394, and CONFIG_IEEE1394_RAW1394.
>
> libraw1394 2.0.* on the other hand (i.e. libraw1394.s.11) automatically
> works with /dev/raw1394 or one or more /dev/fw* depending on what is
> exposed by the kernel.  The programs and libraries on top of libraw1394
> does not notice.  (Also, to expand on another point of the previous
> discussion, there never were any other programs than libraw1394 itself
> that accessed /dev/raw1394.  Back in the 2.3 kernel days, raw1394 was
> designed to be used through libraw1394 alone.)

Thanks & Cheers, Gene

[Texstar]

All of the old firewire code as been depreciated in the new kernels. I suspect software authors will have to update their source code to work with the new kernels devices which is outside the control of PCLinuxOS.

[Almost-retired]

Well, since this has been an 'underway' change since about 2006, I am disappointed that kde-4.6.2 for instance, or vlc, is still being built against the long deprecated versions of the firewire stuff.  Since I am on the kde list too, I'll go do some objecting to, as Jackie Gleason used to say, a revoltin development.  ;-)

Thanks for confirming what I suspected.  I would rather not go back to the older kernel just to make the likes of kdenlive work (particularly since kino still seems able to cope well), there have been some scheduler improvements that make the desktop experience much more pleasant since about 2.6.37-rc2 or thereabouts.

We'll muddle through I think, kino is in the process of exporting the wedding video in question to k3b in the background right now.  With a little luck, the first disk will play, in which case I'll make a 6 pack of them.  These will be far sharper than the VHS dub I left behind on the girls parents machine before putting us and our toy back on the auto-train to come home.  Now that we have hidef, I suppose I should see if an even better camera can be had, but this one kicked everything else out of the water at the time I bought it, doing a 720x480 digital that plays back to Never Twice Same Color tv's with a decent input.  VHS, even good VHS, simply does not compare.