Well, I don't see the bug, where ever it is hiding. But I did write a simple little program, basically a stripped down version of yours, to test with:
Code:
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>
#include <errno.h>

static void sendButton (int fd, const char *st)
{
        int ret = write(fd, st, strlen(st));
        if (ret != strlen(st)) {
                fprintf(stderr, "write() returned %d instead of %d\n", ret, strlen(st));
                exit(-1);
        }
}

int main(int argc, char *argv[])
{
        char st[64];
        int fd;

        if (argc != 2) {
                fprintf(stderr, "Error: expected button name/value as only parameter\n");
                exit(-1);
        }

        fd = open("/proc/empeg_notify",O_RDWR);
        if (fd < 0) {
                perror("Failed to open /proc/empeg_notify for RDWR\n");
                exit(1);
        }
        sprintf(st, "BUTTONRAW=%s", argv[1]);
        sendButton(fd, st);
        usleep(250000);
        strcat(st, ".R");
        sendButton(fd, st);
        return 0;
}


I just compiled that, renamed it to junk and put it in / on the empeg.
Once in place, I ran it many times like this:

/junk NextTrack

Each time, it skipped forward exactly one track -- I used the "Now&Next" track info display to monitor it.

So.. something's not quite right at your end. Maybe the real-time priority is preventing the keys from being processed at the desired time spacing?