tried to see what codes DS was sending and no luck i am afraid

That's not what I meant. I mean that if I poll at random (or regular) intervals, the chances are fairly high that it'll always be grabbing the middle of a song title, if it's scrolling. I can't think of any way right now to assure that it will send out a screen grab where the title is at the beginning of its scroll.

HTTP servers send Content-Type headers. Hopefully, Hijack's HTTP server will send the appropriate Content-Type (audio/mp3?) for mp3 files. I can't think of a way for ftp servers to do this. Which may be a reason to keep HTTP there. But it may also be a reason to move it into userland.

Nope. If you grab the screen buffer from within the kernel, from the point where display_blat() is called, it will never have mangled text.

Either you still don't understand me, or the kernel is doing an assload more than I think it is. If a long songname is being displayed on the empeg, let's say "The Girl Who Lives on Heaven Hill", the screen will sometimes be displaying "The Girl Who Lives on Heaven H", and sometimes it will be displaying "e Girl Who Lives on Heaven Hill". If I select the wrong times to update the VNC client, then I run the risk of never sending the beginning of the title, or other pertinent sections. I'll figure out the best way to deal with this, I'm sure, but I doubt the kernel can take care of it for me automatically. Or am I wrong?

Frank didn't put up source for 2.0. As far as I remember, it was only ever a beta version before he disappeared off the face of the planet. Where are you when we need you, Frank? We miss you, please come back..

You are right.

But I don't see any reason for concern, so long as your refresh rate is more than once a second it will be fine.

I thought you were more concerned with sampling during a partial font rewrite, which would produce garbage if it were possible to do.

-ml