Created attachment 27879 [details]
gst-register run with debug level 5

Created attachment 27880 [details]
trace output of gst-register

Here you can see that it find the plugins but after this something seems to
goes wrong.

Please file such bugs on Gentoo's forum.

You've probably compiled GStreamer for a different prefix than where it is
installed.

Closing as INVALID.

Some additional note:

It seems to be not! gentoo specific. It works if I copy the plugins to an
ext2-partition and give gst-register the new path. It seems to be a problem with
the combination of gstreamer and reiser4.

Again, please discuss this on the Gentoo fora. There's expert people on those
that will be able to help you and explain you what's going on here. This is
*not* reiser-related and it's *not* a GStreamer bug. It's related to your
prefix, as I already noted earlier.

The main problem with this bug is that it takes up expensive developer time that
could better be spent on fixing actual and real bugs. ;). I'm sure you, as a
Gentoo user, can understand that. If it were an actual bug, the Gentoo experts
(on the Gentoo fora) would be able to help you get all the relevant information
related to this bug reports, and then to provide us with a very accurate,
confirmed and detailed bug report and report it upstream (here) for you; with
those detailed bug reports, we are also able to fix the bugs very efficiently.

This system assures that Gentoo bugs stay in the Gentoo camp and that GStreamer
bugs discovered by Gentoo people still get reported upstream in a very efficient
way. We all win by doing this.

I can assure you that this is an actual bug.

# gst-register-0.8
rebuilding global_registry (/var/lib/cache/gstreamer-0.8/registry.xml)
rebuilding user_registry (/root/.gstreamer-0.8/registry.xml)
loaded 0 plugins with 0 features
# cd /usr/lib/
# cp -a gstreamer-0.8/ /dev/shm/
# mount --bind /dev/shm/gstreamer-0.8/ gstreamer-0.8
# gst-register-0.8
rebuilding global_registry (/var/lib/cache/gstreamer-0.8/registry.xml)
added plugin ac3parse with 1 feature(s)
added plugin alaw with 2 feature(s)
added plugin alsa with 3 feature(s)
added plugin gstaudio with 0 feature(s)
...

This quite clearly demonstrates that the problem is caused by the filesystem the
plugins are located on: the two invocations of gst-register-0.8 are executed in
otherwise identical situations.

It is unrelated to my prefix, as the very same plugin files (i.e. binary
identical) work when located on any filesystem other than reiser 4.

I have tried to setup a loop device formatted with ext2 and bind it to
/usr/lib/gstreamer-0.8. Then I reinstalled gstreamer and all plugins. This also
doesn't seem to work. It doesn't not seems to depend only on the used filesystem.

I also have the same problem.  I am running Slackware-current with reiser4. 
gst-register finds the directory of the plugins, but does not register any of
them.  I ran gst-register on another system and copied the registry over and
gstreamer worked.  It just couldn't register the plugins by itself.

I'll try to explain again.

I understand that you guys are having difficulties. I do not know what the
problem is (obviously - else I'd have fixed it already). However, it is not
absolutely sure that the problem is related to GStreamer. I *know* and *see*
that gst-register fails for you guys, but that's merely a *symptom*. I don't
know the *cause* yet.

Now, in order to find the cause, there will have to be some debugging,
trying-out-things, etc. It seems that this is reiser4-related, but it's also
reproduceable on loopback-ext2 devices (looped back to what base file system,
btw?). I see reports here from various distributions that have a variety of
packages/kernel versions installed, none of which is in any way reproduceable by
me, and *that* is why I am not directly able to provide any direct help here. In
order to fix it, I need to be able to reproduce it first.

Now, how can you guys help in fixing this. It requires some programming
knowledge. I want to ask you to add various g_print()s in places in
gstreamer/tools/gst-register.c to see what code is exactly being executed. A
"gst-register --gst-debug-level=5 &> log" would also help. Add g_print()s to the
dir_list for()-loop in main() and to the spawn_in_dir() function. If you don't
know what any of this means, then ask it on the Gentoo fora or on the Slackware
fora.

It would also help if you can reproduce this on a variety of kernel versions
(2.6.x, 2.4.x) or even base systems (preferrably something standard, like Suse
or Fedora). That helps in pinning down the problem and we might be able to help
in solving the problem then.

Hope this helps.

OK, I've worked it out.

Remember that Reiser4 lets one open files as directories (this is in order to be
able to implement arbitrary extended attributes, ACLs, and alternate data streams).

gst/registries/gstxmlregistry.c @@ 1313:
static GList *
gst_xml_registry_rebuild_recurse (GstXMLRegistry * registry,
    const gchar * directory)
{
  GDir *dir;
  GList *ret = NULL;
  gint dr_len, sf_len;

  dir = g_dir_open (directory, 0, NULL);

  if (dir) {

The g_dir_open call always succeeds, so gst_xml_registry_rebuild_recurse tries
to recurse into the file-as-directory contents of the plugins.so instead of
loading them as plugins.

Created attachment 28035 [details] [review]
gstreamer-0.8.1-reiser4.patch

Adds a call to g_file_test (directory, G_FILE_TEST_IS_DIR) - this will return
the expected result on all file systems. Moves call to g_dir_open (directory,
0, NULL) to inside if (g_file_test(directory, G_FILE_TEST_IS_DIR)) {.

This has been tested on a reiser4 filesystem, on reiser3 and on Linux 2.6
ramfs. In all cases plugins are loaded correctly.

At first glance there is not any nearby code that needs similar treatment.

Created attachment 28060 [details] [review]
gstreamer-0.8.1-reiser4.patch

Previous patch would pass NULL to g_dir_read_name if the g_dir_open call
failed. This patch adds in an if (dir) to avoid that.
If applied, the indenting will need to be cleaned up to add another level of
indenting.

applied