if by 'work' you mean does it still use all the cpu, then yes. Also using 1.3.1.

I'm not talking about the "known problem" of the app appearing at the top of the task list and seeming to consume a lot of CPU. There's nothing I can do about that.

I'm talking about the original bug reported at the very top of this thread. The bug where it doesn't show the screen updates until after you open and close the configuration dialog box.

Does configuring the app so that the refresh is zero solve that particular problem?

Sorry.......Yep, as in the app works and NO, it does not change the refresh issue.
1.3.1 also is NOT affected by changing to "0"

In reply to:

---

I'm not talking about the "known problem" of the app appearing at the top of the task list and seeming to consume a lot of CPU. There's nothing I can do about that.

---

It's not 'appearing' to use cpu. It's actually using it. Although the 'system idle process' uses all free cpu, it at least doesn't cause laptop fans to start spinning and also when you look at the performance graph in taskmanager, the cpu is nailed at 100%.

A friend of mine had a similiar problem with one of his VB programs. It seems that VB doesn't really like looping around calls to releasing the cpu. As all that does, is use the cpu. I think but can't check until next week, that he had to use small sleeps instead.

As for the original problem, I'm not suffering from that, but then again running empegface takes cpus cycles away from looking for little green men so I've stopped running it.

I'm going to say this one last time, and then there will be no further discussion on the topic because it's going in the readme file:

If you don't like it using all the CPU, then instead of complaining, please do the following: Locate a piece of Visual Basic code which will download a file from a web site, directly into memory, without using the hard disk, and without using blocking calls. Oh, and without requring me to license and distribute a third party DLL.

The hard disk and blocking call thing comes because I'm using the IE "URLDownloadToFile" API to retreive the screen shot. As soon as I don't have to use that, then I don't have to sit in a loop waiting for the file to finish downloading, and the whole issue will go away.

I can't find code examples to do what I need, the only code examples I've seen use URLDownloadToFile.

I don't use VB but how complicated is network code in VB? If it's not too bad then you only need to do a few steps after setting up the connection.

1. Connect to port 80
2. Send "GET /proc/empeg_screen.png HTTP/1.0\r\n\r\n"
3. What you get back is the HTTP headers with the PNG file following it.

but how complicated is network code in VB?

There is no network code in VB itself. Unless I call the IE DLL, there's no functions for talking on the network. And I don't see a way to do what you're describing using the IE DLL. They don't expose it to me a that low a level. The lowest function I've got AFAIK is URLDownloadToFile.

If anyone has ACTUAL EXAMPLE CODE which shows how to do otherwise (as opposed to "how hard could it be" armchair theories), I'm all ears.

Isn't there a WinSock control? I know that the IE DLL only gives you a very basic interface.

Isn't there some EXAMPLE CODE showing exactly how to use it in VB?

here and download mailex.zip It's a POP3/SMTP client but it shows how to use winsock.

Thanks for the explaination. Now I'm on a mission.

Wow!
it doesnt take much to spark a fire with you guys
Just for your efforts, I promise to put out (4) new skins for the beloved Empegface on Monday!!!

Looking at it now. Looks really straightforward. Changing the method for getting the image might just kill a few birds with one stone and solve both problems in the process. Thank you for the link!

2. Send "GET /proc/empeg_screen.png HTTP/1.0\r\n\r\n"

I'm having trouble getting anything from the player this way.

If I go to a remote site, such as bluesnews, and send:
GET
Then I get the whole proper page back.

If I send a specifica page, like GET /index.html I get that page back just fine. Or a nicely formatted error screen if it's not a valid page.

If I send anything with the HTTP/1.0 string appended like you show, I get nothing back at all.

And no matter what, if I send anything at all to the empeg (even when I know the IP address is right) I get nothing back, including the kinds of stuff that works for remote sites.

Any ideas how I'm supposed to format the GET string so that KHTTPD sends me back the file I'm looking for?

It should work... You do know that \r\n\r\n means two CRLFs tho?

Do this from the command prompt

telnet your_empeg_ip 80 <PRESS ENTER>
GET /proc/uptime HTTP/1.0<PRESS ENTER>
<PRESS ENTER>

You probably won't be able to see yourself typing GET /proc/uptime etc... but just do it blindly.

It should display some numbers and then close the connection.

If you end with "HTTP/1.0", you have to hit return twice.

Tony, I've got a small vb program I knocked up that tries to do 1/100th of empegface. It grabs the file, saves it to disc, reads it back and displays it. I'll email it to you when I power up my other pc.

He's already got part sorted in empegface. We're trying to avoid writing it to disk which is why we're messing around with doing the HTTP transfer manually

If you end with "HTTP/1.0", you have to hit return twice.

Aha found it.

Actually, my problem was that I was sending LF+CR's instead of CR+LF's. Picky web servers, hmph.

Thanks for the help everyone. On to the rest of the work.

Okay, so what's the syntax for the GET request if I only want it to send the file back and not the headers? Found some examples on Google but they don't seem to be working for me...

You can't with the HTTP server in Hijack. It's been hardcoded to always send headers.

Okay, then I'll just parse out everything that appeas after (what seems to be) "Content-Type: text/plain" followed by two CRLF pairs.

Does that sound right?

A better way would be to just junk everything before and including the first line with just a CRLF on it. That's what delimits the header from the data.

Or, in other words, junk everything up to and including the first pair of CRLFs.

Yeah Not quite sure why I was thinking in such a convoluted way.

Thanks guys. I've got it working with the Winsock code now.

I'm not ready to release it just yet because it needs the Winsck.OCX and I have to check to find out how that needs to get distributed, if at all. Maybe I'm lucky and that gets included with IE5 or something? I can hope...

Does that sound right?

Or you could RTFM, which explicitly says that each value in the header is terminated with CRLF and that the header itself is terminated by a blank line. So, just look for CR/LF/CR/LF to find the end of the headers.

Yeah, something funny is that, between those two CRLFs and the actual empeg_screen.raw file, there are two additional bytes that are coming through (I think they're nulls) that I have to account for. Dunno why. But it only works if I filter out those two CRLF and the two following bytes. Oh well.