What kind of hub are you using?

Should really try to stick with one that is confirmed compatible

http://elinux.org/RPi_Powered_USB_Hubs

Pi ports don't have enough power to supply one I don't think

They aren't powered per se

Seeing how my first test of the issue was from miner.php, which showed the difference in the output as well, I don't think that was the issue. I do believe that something may be up with the read/write. After about 5 restarts of CGMiner today I got it to show correct stats, I noticed the avg rate was in kH/s which was odd, along with the shares being off (also odd), a couple restarts and now it's fine again. The SD card is about 2 days old (class 10, spec'd from eLinux.org wiki as completely compatible with rPi), also I have 5 other SD cards (all class 10, random sizes), so it would be easy to test that theory just by cloning the card.

I'm going to monitor this a bit more, I have another rPi that will be here tomorrow, I'll play with it some there on the new rPi as well.

For someone to say they know anything about programming and not know references (or differences) between an INT or BOOL is beyond me, very basic stuff right there..

I've clearly stated it could be a combination of things (CGMiner,I/O w/ SD Card). I've already proved it was at the application level, by restarting CGMiner several times before finally getting the correct data returned through API calls. Which seems semi-isolated and almost random (for me) however other people have reported incorrect readings between the output screen and what MinePeon's WebUI is showing, which is coming from the UI. So far I personally have seen incorrect speeds, invalid share totals and a few other minor things, all of which eventually get flushed out after restarting CGMiner (usually about 4-5 times after a reboot of the Pi).

Please stop saying you wrote miner.php, you've said it enough times, I don't care because I'm not using it for anything other than to compare data results from the API call (also, it doesn't look like the latest release of MinePeon is calling/including miner.php anywhere now). I'm not pointing a finger at you, but you seem to somehow think I am? So you're continually trying to defend yourself it seems.

I'm glad you know how to send text over sockets, wonderful. I used it (miner.php) along with cgminer.inc.php and my own code to try and see if I was getting the same results as OTHER PEOPLE were reporting and I did...

Also, nice touch trying to "dick measure" with the '10's of thousands of lines of PHP' (yet you still use globals? (in miner.php, everywhere) finding that hard to believe...).

I know the exact difference, however, I've no idea why someone would send the wrong one in the php code they wrote.
As I said "So I don't get what the true/1 issue is."
... since miner.php doesn't have this issue anywhere as far as I know ...

No - you've said you wrote your own php using parameters that were incorrect, data types that were incorrect, and got unexpected results.
But you won't say exactly what you did in php so I can work out what's going on.
Fine I give up - have fun with it.

Oh and hint ... java API ...

The drop in long-term average hash rate to near zero is specific to the Pi, and probably to MinePeon. At boot time, the Pi's date starts at Jan 1, 1970. After a few minutes, a background task updates it to the right time.  But in the interim, cgminer has started. So to get the average,  it calculates your total hashes divided by run time. Since the apparent run time is over 43 years, the average is near zero.

I'm using the same just with another branding. It works well with 5 USB Miners. For over a Month now. have You tried different USB Cables? Sometimes it helps to cut the red cable of the Connection, but I didn't.

Whenever I reboot my RPi, I need to restart ntpd and then cgminer to get reasonable results.