media_server can't find media_addon_server from its signature.

[gotaku]

When booting a Haiku image compiled on Linux an alert appears stating:

Launching media_addon_server failed. media_server will terminate

If I try to run media_server from the terminal it says:

### ERROR: couldn't find MediaServerPort ### ERROR: couldn't find MediaAddonsServerPort Launching media_addon_server (application/x-vnd.Be.addon-host) failed: Application could not be found

Using FileTypes I see that media_addon_server is indeed missing from the application types list. I then run media_addon_server from the terminal and while it does crash, since it actually ran its signature is now registered and appears in the application types list.

If I reboot, media_server will now be able to find media_addon_server and start normally.

[axeld]

Never seen this one, but I didn't build on Linux recently. Since this looks like a build problem, I'm passing off to Ingo :-)

[bonefish]

Tested under VMWare with a Linux-built hrev20387 image: Works for me. The media_server is started properly by the Bootscript and it starts the media_addon_server as expected. If I kill all of them and run the media_server from the terminal manually, it starts fine and also launches the media_addon_server.

When it hasn't been started before, it is normal, that an application's signature is not in the MIME DB yet. You can nevertheless start it by signature, since BRoster queries for it by signature. I've also tested: The "open" command properly starts the add-on server when invoked by signature, and a "query" for the signature turns up the right file.

Maybe your build environment is an invalid state (though not likely since my last respective changes, this can still happen). I would suggest to delete the "attributes" and "objects" directories in your "generated" directory and rebuild the image from the scratch. If that doesn't help, please give more information about the /system/servers/media_addon_server file. Particularly whether its "BEOS::APP_SIG" attribute is set correctly and whether query finds the file when searching for the signature.

[gotaku]

Building the image from scratch won't help as the same thing has happens even with a fresh svn checkout.I'm still a Haiku newbie so if you wouldn't mind can you tell me how I can check what the BEOS::APP_SIG of an application is and how I can make a query for the signature?

This seems very similar to ticket #324 from a year ago that looks erroneously labeled as a duplicate of #170.

[bonefish]

You can list the attributes a file has using the listattr command in the terminal (should be 6 for the media_addon_server). To print the value of a particular attribute use catattr. In this case:

catattr BEOS:APP_SIG /system/servers/media_addon_server

(note: only one ":"; was a typo in my previous comment)

The output should be:

/system/servers/media_addon_server: string : application/x-vnd.Be.addon-host

To query for applications with the signature of the media_addon_server:

query BEOS:APP_SIG=application/x-vnd.Be.addon-host

The output should be:

/boot/beos/system/servers/media_addon_server

Regarding #324 and #170. At that time there existed a bug in the build system (and Haiku itself), that caused the BEOS:APP_SIG attribute to be removed for most apps. It was fixed in hrev17354 and solved the problem of starting applications by signature.

[gotaku]

catattr returns the expected output but the query returns nothing.

[bonefish]

Does lsindex (no parameters) list BEOS:APP_SIG?

If not, is there an error message to the effect "mkindex: Failed to create index BEOS:APP_SIG"? Should be directly before "Populating image ...", i.e. one of the last lines printed.

If there is indeed such an error message, does it disappear, if you change line 60 in "build/scripts/build_haiku_image" containing "sleep 1" to a greater number (try 10 for good measure -- means 10s of waiting)?

[bonefish]

The second and third paragraph prefer to building the image. Sorry, might have been confusing.

[bonefish]

prefer -> refer

OMG

[bonefish]

Mmh, it seems a failed mkindex due to the bfs_shell not running doesn't produce an error message. Please try increasing the wait time anyway, and check whether that fixes the problem.

[gotaku]

lsindex does list BEOS:APP_SIG among other things and changing sleep in build_haiku_image doesn't seem to do anything.

[bonefish]

OK, so what we have is: The media_addon_server executable has the an BEOS:APP_SIG attribute with the correct value, the BEOS:APP_SIG index exists on the volume, but a query for the exact attribute value doesn't turn the file up.

This does at least not sound like a build system problem anymore. Maybe BFS or kernel. I bounce it back to Axel.

[gotaku]

If I run "rmindex BEOS:APP_SIG" I am no longer able to query by BEOS:APP_SIG (as expected). However, if I then run "mkindex BEOS:APP_SIG" I'm still not able to query by BEOS:APP_SIG even though lsindex now lists BEOS:APP_SIG again.

Is something else needed besides mkindex or could this be the source of the problem?

[bonefish]

Replying to gotaku:

If I run "rmindex BEOS:APP_SIG" I am no longer able to query by BEOS:APP_SIG (as expected).

What do you mean? I thought the query didn't work correctly anyway (returning nothing). What changes after removing the index? Does "query" return an error now (here it doesn't after removing the index)?

However, if I then run "mkindex BEOS:APP_SIG" I'm still not able to query by BEOS:APP_SIG even though lsindex now lists BEOS:APP_SIG again.

Is something else needed besides mkindex or could this be the source of the problem?

The BFS implementation of indices is ignorant when you create a new index. The index will be empty, even if the volume already contains files with the respective attribute. Only when the attribute is added to a file or changed will the file be added to the index. E.g. you could add a file to the newly created index by copying it and then replacing the original with the copy.

BTW, deleting the BEOS:APP_SIG index makes the system quite unusable. My idea that the problem could be that the index isn't correctly created in the first place was wrong, since the system wouldn't even have booted far enough for you to do anything. So, naturally changing the build_haiku_image would have any effect.

Anyway, please verify that the query for the media_addon_server's BEOS:APP_SIG value does indeed return nothing after booting a newly built image (I recommend doing a catattr on the file first and then copy and paste the strings, so that typos are ruled out). If it doesn't, we'll have to dig deeper into the query mechanism, otherwise there's a problem with the mechanism starting apps by signature.

[gotaku]

On a fresh image, query seems to work fine on everything but application/x-vnd.Be.addon-host so I was just just curious on what would happen if I removed and regenerated the index, but you are telling me it doesn't really work like that.

Here is the output of those two commands:

~>catattr BEOS:APP_SIG /system/servers/media_addon_server /system/servers/media_addon_server : string : application/x-vnd.Be.addon-host

~>query BEOS:APP_SIG=application/x-vnd.Be.addon-host ~>

Like I said, only application/x-vnd.Be.addon-host seems to cause problems for example:

~>query BEOS:APP_SIG=application/x-vnd.Be.media-server /boot/beos/system/servers/media_server

Why does it seem that only I am experiencing this bug? Could it be some subtle distro specific problem? I'm using Debian Etch.

[bonefish]

Replying to gotaku:

Here is the output of those two commands:

~>catattr BEOS:APP_SIG /system/servers/media_addon_server /system/servers/media_addon_server : string : application/x-vnd.Be.addon-host

~>query BEOS:APP_SIG=application/x-vnd.Be.addon-host

Thanks for your clarification.

Like I said, only application/x-vnd.Be.addon-host seems to cause problems for example:

~>query BEOS:APP_SIG=application/x-vnd.Be.media-server /boot/beos/system/servers/media_server

Yep, the index seems to be OK in principle, but it does either not contain the media_addon_server's attribute value (respectively an incorrect value) or the query mechanism is somehow broken. You could try:

query BEOS:APP_SIG=*

This should list all files that have the attribute and are in the index. For comparison, here 74 entries are listed (you can count them by piping the command through wc, i.e. append " | wc -l" to the above command line), the last ones being print add-ons (PCL5/6, PS, Preview). The media_addon_server is at position 13.

Why does it seem that only I am experiencing this bug? Could it be some subtle distro specific problem? I'm using Debian Etch.

I would consider this relatively unlikely. We're not using that many features of the host platform (basically a bit of standard POSIX API). I guess the most likely thing to happen when something like a header changes in a problematic way would be that the build breaks, the image becomes unbootable, or some feature breaks completely (like attributes). But I wouldn't rule out any possibility. :-)

[gotaku]

Well that's intresting I only got the following 60 results:

/boot/beos/bin/hey /boot/beos/apps/Mail /boot/beos/apps/People /boot/beos/preferences/Printers /boot/beos/system/servers/print_server /boot/beos/preferences/Screen /boot/beos/preferences/Time /boot/beos/system/Tracker /boot/beos/system/Deskbar /boot/beos/apps/Workspaces /boot/beos/system/servers/input_server /boot/beos/demos/Chart /boot/beos/system/servers/media_server /boot/beos/apps/Cortex /boot/beos/apps/AboutHaiku /boot/beos/preferences/Backgrounds /boot/beos/apps/CDPlayer /boot/beos/demos/Clock /boot/beos/apps/DeskCalc /boot/beos/apps/DiskProbe /boot/beos/apps/Expander /boot/beos/preferences/FileTypes /boot/beos/demos/FontDemo /boot/beos/preferences/Fonts /boot/beos/demos/GLTeapot /boot/beos/apps/Installer /boot/beos/system/kernel_x86 /boot/beos/preferences/Keyboard /boot/beos/preferences/Keymap /boot/beos/apps/Magnify /boot/beos/preferences/E-mail /boot/beos/preferences/Media /boot/beos/apps/MediaPlayer /boot/beos/preferences/Menu /boot/beos/apps/MidiPlayer /boot/beos/preferences/Mouse /boot/beos/apps/Pulse /boot/beos/system/servers/registrar /boot/beos/preferences/ScreenSaver /boot/beos/apps/ShowImage /boot/beos/preferences/Sounds /boot/beos/apps/StyledEdit /boot/beos/apps/Terminal /boot/beos/system/servers/app_server /boot/beos/bin/desklink /boot/beos/system/servers/midi_server /boot/beos/system/servers/net_server /boot/beos/bin/funzip /boot/beos/bin/unzip /boot/beos/bin/unzipsfx /boot/beos/bin/unrar /boot/beos/system/add-ons/kernel/busses/usb/ehci /boot/beos/system/add-ons/kernel/busses/usb/ohci /boot/beos/system/add-ons/kernel/busses/usb/uhci /boot/beos/system/add-ons/kernel/bus_managers/usb /boot/beos/bin/mimeset /boot/beos/system/add-ons/Tracker/ZipOMatic-Z /boot/beos/system/add-ons/Print/PDF\ Writer /boot/beos/system/add-ons/Print/PS\ Compatible /boot/beos/system/add-ons/Print/Preview

[gotaku]

If nobody else is experiencing this bug I think we can close it. After I switched Linux distributions I haven't had this problem since.