I've had some fun getting some realplayer files opened a few weeks ago, and I've just now twigged that there's a difference between the codecs such as cook.so and cook.so.6.0.

The file sizes and dates are different, and I'm wondering if they're from different releases of realplayer ?
If so, what versions ? Google doesn't provide anything definitive.
And should sticking them all in one spot work ?

As an aside, how does the rvrend.so.6.0 (in the realplayer plugin folder) come into play - is it for the browsers use ?

OK, I don't know a lot about media players, but a .so is a shared object file - basically a shared lib something like a dll in Windows. Usually, when there are multiple versaions of a library, you get files like mysharedlib.so.x.y where x.y is the version number of the library. This is so programs can use a particular version if they need to.

Often, the main mysharedlib.so is symlinked to one of the mysharelib.so.x.y versions, but it doesn't have to be. If your files are different in size, they are probably two different versions. You may be able to run nm on the library to get clues about what version it is. And yes, plugins are often distributed as shared libs.

file.so is a symlink to the real file, along the lines of file.so.x.y.z where x y and z are versioning info. Each time you update the library it symlinks the .so file to the latest version .so.x.y.z file.

I decided to pull all the realplayer codecs off and install fresh (I'd been moving them around trying to get some stuff to work), so I could get an idea of where which files were being installed to.
They're definitely different files, not symlinks.

real-codecs-1.2-1plf contains
‎/usr/lib/real
‎/usr/lib/real/atrc.so.6.0
‎/usr/lib/real/cook.so.6.0
‎/usr/lib/real/ddnt.so.6.0
‎/usr/lib/real/dnet.so.6.0
‎/usr/lib/real/drv2.so.6.0
‎/usr/lib/real/drv3.so.6.0
‎/usr/lib/real/drv4.so.6.0
‎/usr/lib/real/dspr.so.6.0
‎/usr/lib/real/sipr.so.6.0
‎/usr/lib/real/tokf.so.6.0
‎/usr/lib/real/tokr.so.6.0

But /usr/lib/real isn't where the RealPlayer10GOLD installs to:
/usr/local/RealPlayer/codecs/amrn.so
‎/usr/local/RealPlayer/codecs/amrw.so
‎/usr/local/RealPlayer/codecs/atrc.so
‎/usr/local/RealPlayer/codecs/colorcvt.so
‎/usr/local/RealPlayer/codecs/cook.so
‎/usr/local/RealPlayer/codecs/cvt1.so
‎/usr/local/RealPlayer/codecs/drv1.so
‎/usr/local/RealPlayer/codecs/drv2.so
‎/usr/local/RealPlayer/codecs/drvc.so
‎/usr/local/RealPlayer/codecs/raac.so
‎/usr/local/RealPlayer/codecs/rv10.so
‎/usr/local/RealPlayer/codecs/rv20.so
‎/usr/local/RealPlayer/codecs/rv30.so
‎/usr/local/RealPlayer/codecs/rv40.so
‎/usr/local/RealPlayer/codecs/sipr.so

So using these packages there are two different locations for realplayer codecs.

Naturally kaffeine/gxine only look in one place, so I copied the ones from /usr/lib/real to the RealPlayer codecs directory at ‎/usr/local/RealPlayer/codec, ensured the realplayer codec preference was pointed at ‎/usr/local/RealPlayer/codec , and the errors about sipr.so.6.0 etc go away.

What's interesting is that a couple of rm files I have, realplay only plays sound, no video, but kaffeine plays it fine.

Is there a reason the plf rpms don't contain the newer realplayer codecs from the RealPlayer10GOLD rpm ? and that they're in a different location ?

Also, in searching for sipr.so.6.0 I found
http://itp.tugraz.at/Comp/RPM/sipr.so.6.0.html
which references mplayer-w32codec-1.0-1.i386

Is it better to install this in preference to the realplayer10 rpm, or is it just a matter of taste ?

IMNSHO mplayer.* is far better than anything real.* So if I had to choose a codec put out by the mplayer group over a codec put out from the real folks, mplayer would win 8 out of 7 days on my system.

BUT

That said, the real codecs should not be overlapping with the mplayer-win32 codecs. They can be happily installed side by side without overwriting one another, at least this has been my experience. Maybe it's a packaging issue that does this...

Cool