I tried the script you linked to hk... it's not much help. I did modify my script to have a bit of error handling, but it only helps the problem so much. It seems that ie sometimes (not often but maybe once every 20 secs) is able to open an image file as it's being written. There are, of course other alternatives.
It would require somene else to do the webpage end, because I suck at javascript, but a more bandwith saving technique might simply be to re-create the display file in html with the individual images in tact and incorporate a bit of javascript to constantly read a file that tells the status of each output. It's easy in javascript to rapidly display/hide an image... that's how mouse-over events work. I'm guessing it could take a while to load more complex displays, but once they are loaded everything should be in real time.
Of course this is all for animated display files. Static displays like a marquee, instruction card, command.dat, ect.... that'd be child's play. You wouldn't even have to constantly refresh the image. (Mind you, you could.) Instead the best bet would be to have a generic webpage with REALLY simple navigation. The javascript, instead of constantly re-loading the image, would re-load the html files body, which would update the links. It doesn't take any time to reload text and since you aren't refreshing the actual images, they wouldn't get constantly reloaded unless their address changed.
I intend on adding generic file operations support to mamehooker tonight. What you'd do is designate a folder where your webpage will be stored. You'd then keep all the non-generic stuff in a seperate sub-folder Upon mame startup, you'd delete everything in that folder, copy the artwork from all your folders (marquee, flyer, cards, ect) into the folder and re-edit the html to the new link names. So long as the link's have different names, the page should re-load them.
Anyway, I FINALLY got my digit creator working just the way I want it, so a release is immenant. Should be out by this weekend.