ecc2GUI v0.6 [by Jeff Gilchrist] available (Fixes Nasty Bug)

[Digital Parasite]

A new version of ecc2GUI has been released (v0.6). This new version has fixes a nasty bug in v0.5 and everyone should upgrade.

You can get it in the regular location:
http://gilchrist.ca/jeff/ecc2GUI/

v0.6 (Jan 11, 2003)
- Fixed major bug that could spawn multiple copies of the ECC2 client simultaneously. This bug happened if the "Restart Inactive Client after" was checked in v0.5. It should now be fixed. Everyone should upgrade to v0.6!

- Added "Save Config" button so that you can now save your config to the .ini file right away instead of waiting to close ecc2GUI. The GUI still saves your Config data on close as well.

MD5 Sum:
408611a1b74eed072e1182c266ee8b85 ecc2GUIv06.zip

If you have any problems please let me know.

Jeff.

Screen Shots:
http://gilchrist.ca/jeff/ecc2GUI/ecc2GUIv06noconfig.jpg

http://gilchrist.ca/jeff/ecc2GUI/ecc2GUIv06.jpg

[alpha]

Hey DP, I've been using your GUI since v0.1, so first things first, good work :thumbs:

Are there any known quirks with the 'Time Since Last DP Found' counter? In v0.5 and 0.6 I've noticed that it somehow resets itself before a DP is found. I have proof of this in the form of a screenshot (http://www.btinternet.com/~matt_mills/ecc2-GUI.jpg) :)

Obviously an XP1700 can't do 1177m iterations in 2 minutes. I assure you the GUI had been running the same time as the 'Benchmark Running Time' reads, I didn't reset it or anything. I had not fiddled with the GUI in any way, just fired it up and let it work its magic, checking on it every now and then.

The only configuration options I use are 'AutoStart ECC2 Client', 'AutoStop on Close' and make the client hidden. Oh, and the refresh rate is 15s.

[Digital Parasite]

Originally posted by alpha
Are there any known quirks with the 'Time Since Last DP Found' counter? In v0.5 and 0.6 I've noticed that it somehow resets itself before a DP is found. I have proof of this in the form of a screenshot (http://www.btinternet.com/~matt_mills/ecc2-GUI.jpg) :)

There is obviously something strange going on there. I will have to check the code but one possibility is that if the .spd file doesn't update within 10 seconds the GUI thinks the client has stopped so it resets some of the benchmarks. But your benchmark running time was 58+ minutes so obviously the benchmark didn't get reset. I'm not sure what is up with that but thanks for pointing it out I will have to check to code to see if I can find anything wrong in there.

Jeff.

[alpha]

Seeing the release of 0.7, I'm assuming you never found anything wrong with what I mentioned?

[Digital Parasite]

Originally posted by alpha
Seeing the release of 0.7, I'm assuming you never found anything wrong with what I mentioned?

I observe that once in a while the "Time since DP Found" resets early for some reason. It doesn't happen very often and I'm not sure why. I couldn't see any reason when looking at the code. I may be able to figure something out with the new logging feature.

Jeff.

[alpha]

I don't mean to be a pain in the :moon: about this, but I just thought I would give it another mention with another screenshot (http://www.btinternet.com/~matt_mills/ecc2-GUI2.jpg).

This time, it was the same machine, but Windows XP, as opposed to 98SE. I had been out for the morning, when I came back I noticed that the time since last DP was well over 2 hours (due to 7908m iterations). After using the computer for a bit, and checking the GUI now and again, I noticed the counter reset before a DP was found.

I know, it REALLY isn't a big deal, but I just thought this additional information could be the next step to solving it.

Tell me to shut up if you've heard enough about this ;)

[Digital Parasite]

Alpha: I believe you that this is a problem and I have seen it happen once myself. Woh, talk about extremes in your screen shot, the previous DP only took 86m iterations and the current one is already over 7908, how unlucky...

I'm not sure why this is happening so I can't in turn fix it. The way the GUI knows that you found a new DP and then adds it to the New DPs list is by looking at the current # of DPs your machine has finished each refresh. It keeps track of that number from the last refresh and if the numbers are not the same, you have obviously found another DP. When this happens the time since last DP is reset also.

So for some reason the # DPs for your machine was different in one refresh to another. I could see this happening if the GUI tried to read the .spd file at exactly the same time the client was writing out a new one so the the GUI read a number that wasn't completely written by the client and so it didn't match the previous refresh and reset the counter. I don't think there is much I can do about that case. Any suggestions?

Jeff.

[Darkness Productions]

Maybe check the size of the file? Shouldn't the size of the file (the dplist) always grow, unless they've been uploaded? If the size of the file is smaller, then do some magic...

[alpha]

Originally posted by Darkness Productions
Maybe check the size of the file? Shouldn't the size of the file (the dplist) always grow, unless they've been uploaded? If the size of the file is smaller, then do some magic...

No. The dplist should ALWAYS grow. It should never reduce in size, unless the file is moved or edited by hand.

[alpha]

Originally posted by Digital Parasite
Alpha: I believe you that this is a problem and I have seen it happen once myself. Woh, talk about extremes in your screen shot, the previous DP only took 86m iterations and the current one is already over 7908, how unlucky...

Indeed, a DP was found after 9561m :) I guess that's nature balancing out the extremes.


Any suggestions?

Now that you've explained how everything works I'll give it some thought. Seriously though, I don't want to bug you about this too much, nobody else has even mentioned it, so I assume it is rare (not to mention trivial).

[Digital Parasite]

Instead of looking at the dplist file since a number of people move/deleted/modify the dplist depending on if they are offline, doing other stuff, etc... I may be able to look at the # of DPs on the machine and if it doesn't match the previous # to make sure the current one is larger than the previous, not just if they are not equal.

I will have to check first if that will break any of the other code but that may solve the problem. If you guys have any other ideas in the mean time please post them.

Jeff.

[alpha]

Originally posted by Digital Parasite
Instead of looking at the dplist file since a number of people move/deleted/modify the dplist depending on if they are offline, doing other stuff, etc... I may be able to look at the # of DPs on the machine and if it doesn't match the previous # to make sure the current one is larger than the previous, not just if they are not equal.


Are you referring to the ecc2-109.cnt file? That would be a good idea, since there isn't really any reason for someone to edit or delete that file (and I assume its regenerated each time a DP is found, or something anyway?). You could use that as a double-check along side your current method.

Edit: Reading your previous posts, isn't this what you're already doing?

[Digital Parasite]

What I am doing right now is a != (not equal) check but what I proposed was a > (greater than). So if your machine had found as 1000 DPs and it records 1000 after the refresh. The next time the refresh happens it will check the value. If the value is still 1000 it knows you haven't found a new DP. If there was an error reading the .spd file and it came out as say 100 instead of 1000 with a != it would be considerd a new DP found and reset the DP timer. If it was set to > the 100 is less than 1000 so it would ignore it and not reset the DP counter.

This is all using the .spd file. I think there was a reason I set it to != in the first place (as other checks are done at the same time) so I have to double check that it won't screw anything else up.

Jeff.

[Jammy]

Jeff . . .to tell ya the truth, I like version 0.6 better than version 0.7!

Jammy :haddock:

[alpha]

Originally posted by Digital Parasite
This is all using the .spd file. I think there was a reason I set it to != in the first place (as other checks are done at the same time) so I have to double check that it won't screw anything else up.

Any reason why you're doing it all with the .spd? The .cnt seems ideal for this situation.

Jammy: I preferred the roll up/down config too! :cry:

[Digital Parasite]

Originally posted by alpha
Any reason why you're doing it all with the .spd? The .cnt seems ideal for this situation.

Jammy: I preferred the roll up/down config too! :cry:

I was using .spd because it gave me everything I needed. The less files I had to read/keep track of the better. But you are right the .cnt file is only updated when a new DP is found so there is less chance of reading it the same time as the .spd so that is probably a better choice.

I liked the roll config better too but you can blame all the non-conformist :swear: who decided to use larger/smaller fonts than the standard. ;) I probably would have had to switch to the current method anyways because many people still use 640x480 and 800x600 so when the config was unrolled it would have been off the screen and they would have complained about that.

Jeff.