I downloaded the .zip file, extracted it, placed the directory on my desktop, hooked up via ethernet and plugged in the player IP in the box in the configure menu and the app still does not work. I am running HiJack 344. All it does is show the remote and a blank face. It does not work to control my player. Question, I just type in the IP I assigned to the player that comes up in the player's About screen right? Be aware that I have a seperate ethernet card in my PC that I use only to connect to the Player. Am I missing something. I don't need FTP on my player for this app. do I? Also this is what I am entering into the IP box in configure: 10.0.0.2, which is my players address.

What's the IP# of the extra card in the computer? The net mask?
Can you otherwise see the empeg from the computer?

/Michael

Have you tried accessing it through IE using the IP address?

Stu

Yes, what Stu said is correct:

Open up Microsoft Internet Explorer and type into the URL box:

http://10.0.0.2

If you get something, then EmpegFace should work. If not, then you need to solve your ethernet problems before trying to get EmpegFace working.

Also: You said you extracted it to your desktop. Did you extract all of the files to the same foldeR?

Yeah, I extracted them all into one folder like you instruct on the download page. I am at work right now so I will check the IP with IE when I get home. Thanks

Tony great program by the way. I used it to reset the volume level on a player with a nonfunctional display board. Any way to reduce usage of CPU cycles? I have a P4 2.4 GHz CPU and Empegface uses all of it.

Stu

Please read the readme. It says what you can do to reduce that.

And It's not really using all the CPU cycles, it's just using all the idle time when it's available. As soon as any other program starts using any CPU cycles, it goes down in the list.

Do you complain to Microsoft because something called "System Idle Process" is using all the CPU cycles?

Don't put so much trust in what Task Manager tells you.

Do you complain to Microsoft because something called "System Idle Process" is using all the CPU cycles?

Yes, but System Idle Process dosen't cause my laptop fan to come on

As far as I know, the procedure outlined in the readme should prevent your fan from coming on as well.

Perhaps a poor choice of words, but the behavior of the PC does seem to indicate it's being a bit taxed. Anyway, still a very useful program even if it does give the very convincing illusion of monopolizing the PC.

I read the read me, and followed the suggestions to no effect. Yeah, the fan runs pretty steadily in mine too.

Stu

Odd, on my system, if I minimize it or only show the remote, there is no CPU usage on the task manager nor disk spinning. Nor is the system seeming to run slow at all. Only when the face itself is displayed do things appear to be actually happening (and in that case there are things happening, a graphic file is being downloaded to the hard disk and being processed over and over again).

I don't have a laptop to test the fan. But I can't imagine why a piece of software would make the fan run. I though the fans in laptops were thermally controlled.

Wait, your laptop probably has a CPU which changes speed depending on whether a piece of software is using up CPU cycles. If that's the case, I've got no idea how I could tell the CPU to skip the processor speedup just for my app. I don't know what the API is for that. If anyone knows, I'd be happy to code it in. Clearly the "System Idle Process" is doing this, so there's gotta be a way.

Let me clarify a bit. If I have the display showing on Empegface, then it runs the fan. I suppose not if I minimized it, but this is called Empegface afterall. I don't have anything setup to test that though. This is on a Dell desktop by the way; it has some kind of system controlled fan.

Stu

Only when the face itself is displayed do things appear to be actually happening (and in that case there are things happening, a graphic file is being downloaded to the hard disk and being processed over and over again).

Hmmm, I suspect I might be pointing out the obvious when I say that there's no reason to write the screen image to disk before displaying it? I havn't played with empegface yet, but I assume you aren't doing that.

As someone who's enjoying my operating systems class at the moment, I can tell you that any program that takes all available CPU time to accomplish a set task is doing something wrong. I have no idea how you've implemented everything (and I've never done any windows programming, so perhaps this problem lies in windows) but it would really seem like the program should do some sort of sleeping in between requesting a screen dump and getting it back. Perhaps you could also test and see how many identical copies of the screen you're getting back and only query the empeg at the interval that yields a new screen most of the time?

Matthew

Clearly the "System Idle Process" is doing this, so there's gotta be a way.

IIRC, the "System Idle Process" isn't a real process, or at least, not a real Win32 process. I think that any API it uses is probably only exposed to Native applications.

If you want to stop hogging the CPU, you'll have to stop busy-waiting on stuff -- blocking on message queues or semaphores or file handles or whatever will cause your process to yield, and the CPU usage to accurately represent what you're doing.

And what you say about laptops and speed control is half right -- this is a problem. It could also be a problem on (say) my new Athlon -- if the CPU is running all the time, it gets hot, and I've got a temperature controlled fan, too.

I don't know for sure, because I don't run EmpegFace -- my empeg's in a dock right next to the PC, so I don't really need to. I keep meaning to have a play with it at some point, though.

Hmmm, I suspect I might be pointing out the obvious when I say that there's no reason to write the screen image to disk before displaying it?

Only if I want to implement a complete FTP and/or HTTP client in raw software.

The only way I was able to get the app written (i.e., the only way I could do it in a reasonable amount of time without re-inventing a whole shitload of wheels) was to call out to the Internet Explorer DLL and ask it to grab the file for me. And IE won't load the file into a memory string for me, it will only download the file to the hard disk. If there were an easy way that I could load it directly into memory instead of to disk, I would have done it that way for sure. If anyone can link to some pre-written VB code that can grab a file via HTTP directly into memory without touching the disk, then please do.

If you want to stop hogging the CPU, you'll have to stop busy-waiting on stuff -- blocking on message queues or semaphores or file handles or whatever will cause your process to yield

Which is an exceptionally large PITA in visual basic 6. The Internet Explorer DLL that I'm using is the one doing the blocking that I must wait upon. The only way around it would be to create another thread, and coding threads in VB6 is just downright arcane. Again, something I would have done if only it were easy and quick to do. But projects like EmpegFace don't get that kind of quality time outta me.

I suppose not if I minimized it, but this is called Empegface afterall.

True. But I made it a system tray app so that it could spend most of its life minimized and only display the face when you needed to see it for remote control.