Well, you needn't have killall installed on the empeg necessarily. It just automates finding the PID of the process(es). Sending signal 2 (INT) to the process, which is the same thing a Ctrl-C does, will end it without respawn.

Oh yeah; I forgot that this was intended to be programatically called.

No, you don't need cut. Nor "ps". You can grep through /proc/nn/ looking for the player, and use the bash built-in string processing to "cut" out the pid if need be.

Cheers

Do you mean this FAQ entry?

The problem with my created database file is to do with 'extended' characters. E.g. the length of the following track title:-

Cú Chullain

is counted by the empeg player (and by perl on my Mac) as 11, but when I create the database file on my RedHat linux server, it counts the length as 12. So whenever one of this type of 'accented' characters appears it gets the length wrong. I have tried to not use anything except regular ASCII, but some names/titles really need them and it's not practical to strip them out and have to monitor every new track, just in case.

So I really need to find a solution and count the length consistently.

I know I could let the empeg create the database each time, but this is something I specifically want to avoid, so it's not a viable solution. I just want to make perl on the RedHat machine count the same number of chars.

Anyone any suggestions as to how to do this?

Hmmm... what version of perl and how are you getting the length? If you have multiple accented characters, do you get 2 for each character or just a +1 error for the entire string?

I get one extra count for each instance.

If I run this on the Mac (which counts the same as the empeg player)

perl -e '{print( "length = ", length "Cú Chullain","\n" );}'

it counts 11 chars, but the Intel RedHat machine counts 12.

If I modify that to start:-

perl -e '{use utf8; print....etc

Then RH perl counts 11 as I want, but the Mac gives an error:-

Malformed UTF-8 character (unexpected continuation byte 0x9c, with no preceding start byte)

Since I want this to be operable on both platforms, I still have a problem:-(

Feels like a version and/or latformspecific bug... i386 Debian with an ancient perl (5.005_03) returns 11 for the plain (non utf8) statement (don't have utf8 pm installed.)

Just toss another platform into the mix:
Activestate perl 5.8.7.build813 on XP returns 11 for the non-utf8 and 7!! for the use utf8 case (had to muck a bit with the quotes and parens to get it accepted, this is what I ran:
C:\Documents and Settings\tempsch.XP-TEMPSCH>perl -e "{print(length 'Cú Chullain');}"
11)
C:\Documents and Settings\tempsch.XP-TEMPSCH>perl -e "use utf8;{print(length 'Cú Chullain');}"
7

Inserting extra [normal] chars in various places in the string do get noticed:
C:\Documents and Settings\tempsch.XP-TEMPSCH>perl -e "use utf8;{print(length 'Cú1 1Chullain');}"
9
C:\Documents and Settings\tempsch.XP-TEMPSCH>perl -e "use utf8;{print(length 'C1ú1 1Chullain');}"
10

But putting in the ú in various places it sometimes acts correct and adds 1, elsewhere I get a net negative change...and sometimes an error message. Can't see a pattern as to when/why it happens Some samples:
C:\Documents and Settings\tempsch.XP-TEMPSCH>perl -e "use utf8;{print(length 'Cú Cúhullain');}"
8
C:\Documents and Settings\tempsch.XP-TEMPSCH>perl -e "use utf8;{print(length 'úCú Cúhullain');}"
5
C:\Documents and Settings\tempsch.XP-TEMPSCH>perl -e "use utf8;{print(length 'úCú Cúhuúllain');}"
6
C:\Documents and Settings\tempsch.XP-TEMPSCH>perl -e "use utf8;{print(length 'úCú Cúhuúllainú');}"
Malformed UTF-8 character (unexpected end of string) at -e line 1.
6
C:\Documents and Settings\tempsch.XP-TEMPSCH>perl -e "use utf8;{print(length 'úCú CúhuúllainúA');}"
Malformed UTF-8 character (unexpected end of string) at -e line 1.
6

Very funky...

I don't recall how to do it, but I think one can make perl check version and libraries version at compile time, but don't recall if you can do a conditional use or not... beeen a while...

My guess would be that the Mac uses one byte to hold the ú, but RedHat is using two. My point being that your source file has the characters encoded differently, with RedHat using UTF8 and the Mac using some 1-byte codepage.

To test, create a plain text file on both systems that both contain the ú. Then do an 'od -x' on both of them and see how the character is encoded. My guess, again, is that it'll be one byte on the Mac and two bytes on the RedHat machine.

If that's the case, then your solution is to programmatically figure out what encoding scheme is being used "natively" on each system the perl script is being run on. I don't know how to do that, though.

I'm sure you're right, it's a variation in the encoding schemes of each machine. What I orignally used to encode the info for the database file is:-

$tagsdb .= pack("U2A*",$tags{ $_ }, length $$hot{ $_ }, $$hot{ $_ } );

$tagsdb is then added to the database file - for each fid.

Now I preprocess the tag data like this:-

my $utag = $$hot{ $_ };
utf8::decode($utag);
$tagsdb .= pack("U2A*",$tags{ $_ }, length $utag, $$hot{ $_ } );

This seems to produce the correct length count on both the Mac and RedHat and most importantly when I rsync the resultant database file the empeg player no longer tries to rebuild. So that appears to be the solution to that problem.

I am still having trouble with rsync though. After the first bulk upload rsync crashed with an error I wasn't able to record and the recent update also produced a different error when trying to turn swapoff after the sync:-

swapoff: /dev/hdc6: Cannot allocate memory

but the sync did complete, although I'm sure it transferred far more then it ought.

The beauty of rsync of course is that you can simply try again and it catches up from where it left off so you just keep going till it shows no files were tranferred and then you know it finished. I just need to keep doing it to iron out these last probs, but I feel that with memory so short it may be impossible to entirely eliminate all issues.

So, it now seems to count ok, but any advice on running rsync in low memory situations (or with no terminal) would be welcome:-)

Does it really actually try the open()/write() calls in this case, Roger?

If so, then perhaps I should have a Hijack GUI entry to permit it to succeed.. or perhaps have it pop-up a yes/no prompt.

??

Yes, that's the idea.. remount r/w during the call to "open()", and then remount r/o again on "close()".

Cheers