@Ruskie_it: Beg to differ, you really *should* unmount && eject properly, the USB stack is notably crappy on those devices (well, it's much, much better on the PW2 to be fair), and FAT32 is terrible.
But that's a sidebar, and mostly irrelevant here, although volumd is known to have weird interactions with the boot process that do affect the hack, but it's mostly limited to the "don't boot while plugged in" thing
.
To get back to the issue at hand, even your 'extremely rarely' should be have been a never. The symptoms you describe happen when the framework is fed a broken file; which should *never* happen in cover mode, since we're generating them ourselves; and the final 'activation' copy should be atomic, and in a ramfs.
Unfortunately, when that happens, the framework gives up completely until it's restarted, so that sucks.
You could try to pinpoint if it happens with a specific book? When you mention switching books, that shouldn't matter much, except if those are new (queue of images to crunch, hogging the CPU), but even then, at worst you should see the *previous* cover, not a broken one. (Keep in mind that for the 'very briefly' to have an impact here, that's a real very briefly, i.e., something between the 5~15s range).
That, or there might have been subtle changes in how the framework reacts when its only image in the pool is silently modified (which works in a completley different and slightly broken way on legacy FW, for instance, so, who knows). Not running FW 5.6.1 here, but I've never heard of this happening in cover mode, and have never seen it happen myself on previous FW :/.