Try this - Re: [greenstone-devel] Problem with GLI, plugin and non-ascii met adata

From Anupama of Greenstone Team
DateTue Mar 23 15:56:56 2010
Subject Try this - Re: [greenstone-devel] Problem with GLI, plugin and non-ascii met adata
In-Reply-To (63CB844B15B0D142BF448D6925EFE4AB08EE9A15-mermoz-st-etienne-archi-fr)
Hi Arnaud,

My supervisor came and investigated further today and the solution that
worked for us here is quite simple:

1. Go to the machine running the server and stop the Greenstone server.

2. Now open the file <greenstone
folder>/apache-linux/linux/conf/httpd.conf.in

3. Look for the line specifying "PassEnv"

4. Change the line to:
PassEnv **LIBRARY_PATH_VAR** LANG

5. The above passes your server's LANG environmnent variable onto your
Apache web server, so that the web server should now behave the same way
as your terminal when it comes to the language encoding.

6. Start up the server again by running ./gs2-server.sh
(Make a note of what port it's running on)

7. Go back to the client machine and run GLI-client, connect to the
server and try to rebuild your collection of OGV files and Preview to
see whether the metadata looks fine now.

Does the above work?


In your MediainfoOGVPlugin.pm file, can you replace the line
# my $video_metadata = `$command`;

with all of:
>>
# my $video_metadata = `$command`; # backticks operator way
# Another way to execute the command: better experience with this than
with backticks operator above:
# use open() to read the output of executing the command (which is
piped through to a handle using the | operator)
my $video_metadata;
if (open(VMIN,"$command|")) {
my $line;

# we read a line of output at a time
while (defined ($line=<VMIN>)) {
#print STDERR "***** line = $line ";

$video_metadata .= $line;
}

close(VMIN);
}
<<

The loop above is better behaved than the backtick operator in our
experience. At some point we had problems with the backticks version, so
this way may be better in the long run.

Regards,
Anupama


arnaud yvan wrote:
> Hi Anupama,
>
> I've just tested your modified version and it works perfectly !
> As you noticed I'm not (yet?) a Perl expert. So I'm glad to learn and it's
> much better this way because it can work on other systems too(ie. Windows).
> Thank you.
>
> As for my offer to inspect the GLI code, I think I can do that. I'm also
> interested in a way to link the remote GLI and a LDAP directory for
> authentication but don't expect too much very soon as I dont know too much
> about Java programming !
>
> Thanks again and have a very good week end at the other end of the world.
>
> Best regards,
> Yvan
>
> -----Message d'origine-----
> De : Anupama of Greenstone Team
> [mailto:greenstone_team@cs.waikato.ac.nz]
> Envoy□ : vendredi 19 mars 2010 11:06
> □ : arnaud yvan
> Objet : One more thing - Re: [greenstone-devel] Problem with GLI, plugin
> and non-ascii met adata
>
>
> Hi,
>
> I just sent another e-mail. Please read that too.
>
> In this message, I'm attaching an updated version of your plugin once
> again. This time:
>
> 1. it uses the Perl splits function to split the results of executing
> the mediainfo command over the '|' field. (When I tried the same
> yesterday I forgot to escape the | so it didn't work then, and I had to
> resort to an ugly Regular Expression instead.) The split operation
> returns an array of all the tokenized strings. The code then stores the
> string elements of the array returned, in a list of individually-named
> and ordered variables like artist, duration. These are once again the
> variables you already invented.
>
> 2. I've also made the code use Perl to do the substitions for artist and
> title metadata, instead of launching sed.
>
> The above two changes are only to show you how Perl can be used to
> produce the same results as awk (point 1 above) and sed (point 2). This
> is because Perl is a scripting language too: so it works a lot like bash
> scripting.
>
> Could you try this version of your MediainfoOGVPlugin on your data set,
> and tell me if it fails at any point? I don't want any minor changes I
> made to ruin the functioning of your plugin which you had already tested.
>
> Thanks again for your excellent efforts at writing a plugin. And thanks
> for bringing this remote GLI issue to our notice.
>
> Kind regards,
> Anu
>