I haven't tried, but does it work with download.c?

Jemplode probably just uses ftp to upload the image to /proc/empeg_kernel, so it is not even going through the empeg's builtin flash programmer.

I looked at the download.c source and it looks like the programming actually should be ok, the player must have even ok'd the last 28 byte block.

Is the logoedit code identical to download.c compiled for windows?

It fails to relock the first page it tries to lock, but that the data sent for that operation is identical whether you're flashing v300 or v299. Maybe the timeout is too short and it normaly doesn't trigger? Or did that last 28 byte block write fail after all. Perhaps it is a combination of the two. As the last write is only for 28 bytes, perhaps the flash programmer is 'initializing' the rest of the relatively large flash page and that delays it long enough to miss the timeout, or it starts writing stuff too late so that flushrx didn't get a chance to actually get rid of the '?' (prompt that is sent by the bootloader).

Add a sleep(1); to the beginning of lockpage, or try to pad the image to a larger size, so that the last bytes aren't as close to the flash-page boundary anymore.