PS3 Console Total Powered On Time (WebMAN Mod 1.47.25.3+ feature)

[excaliburn92]

I recently bought a messed up CECHB00 with a controller and a semi-dead laser (have to eject and insert disc multiple times before it reads). I'm really suspicious of the total power on time... can it be reset or fabricated? I'd like to know.

Edit: I'm reading through this thread to find more info and found this app (thanks @3141card) and this is what I got:

 

[DoublesAdvocate]

I recently bought a messed up CECHB00 with a controller and a semi-dead laser (have to eject and insert disc multiple times before it reads). I'm really suspicious of the total power on time... can it be reset or fabricated? I'd like to know.

Edit: I'm reading through this thread to find more info and found this app (thanks @3141card) and this is what I got:

Technically it can be fabricated but only by Sony.

 

[LuckyIhsremover]

I bought this cechA01 off eBay cheap. The seller said the USB ports were broken. I got the console and plugged a controller in and nothing. Plugged the controller in the wall and then back into the console and it synced normally. There are full accounts and messages on those accounts starting in December of 2008 and stop in late 2015! Sooo many game saves.. also whole photo albums of a family. This ps3 is like a time capsule. Still has the warranty sticker in place also. here is the web man time logs. bonus picture of the temps after an hour of heavy gta modding. I will not be breaking the warranty seal either.

 

[DeViL303]

I recently bought a messed up CECHB00 with a controller and a semi-dead laser (have to eject and insert disc multiple times before it reads). I'm really suspicious of the total power on time... can it be reset or fabricated? I'd like to know.

Edit: I'm reading through this thread to find more info and found this app (thanks @3141card) and this is what I got:

Wow that is crazy.

It like the user almost always turned it off at the back. No idea how they got 3660 boots in just 13 days of up time. That means they only ran it for an average of less than 6 minutes per boot, crazy.

 

[sandungas]

Technically it can be fabricated but only by Sony.

And i dont think sony was doing it that way
I mean... there could be good reasons why they could decide to "reset" that values, but incase of resetting them they would reset all them (time counter, poweron counter, and poweroff counter)

In the screenshot it looks like if the time counter was resetted... but the others for poweron poweroff was not resetted... and that doesnt makes sense
I mean... i dont see any reason why they could do that. The correct way to do it would be by reseting all them

---------
So... i think there are only 2 posible reasons for it

1) We are doing some mistake when reading the value, dunno, it could be related with the data types or lenghts, or the way how is stored if the value exceeds a predefined amount
I was brainstorming about it some moths ago when i was saying that i would like to see a screenshot of a PS3 with more than 1000 days of use (and as far i remember i could not see any yet)
You know... maybe the "13 days" we see in the screenshot are really "1013 days" , lol (so is like if the counter does a loop every 1000 days and we are missing 1 loop)
Also, as curiosity sake... we are talking about a CECHB that is a good candidate to have a huge time counter. The screenshot tells only 13 days but the owner have said the laser seems weared, so it doesnt looks like it was used only 13 days, it seems the previous owner made some ab/use of the laser

2) The PS3 was used in a cluster with the official otherOS installed, and was configured to autoboot by network... but it had some problems that was causing a firmware crash and was rebooting in a infinite loop... for 13 days
At day 13 someone realized about it, facepalmed, and retired the PS3 from the cluster... and sent to repair
Sony refurbished it and dissassembled it in parts... eventually the motherboard was used to repair the PS3 from other client

 

[excaliburn92]

And i dont think sony was doing it that way
I mean... there could be good reasons why they could decide to "reset" that values, but incase of resetting them they would reset all them (time counter, poweron counter, and poweroff counter)

In the screenshot it looks like if the time counter was resetted... but the others for poweron poweroff was not resetted... and that doesnt makes sense
I mean... i dont see any reason why they could do that. The correct way to do it would be by reseting all them

---------
So... i think there are only 2 posible reasons for it

1) We are doing some mistake when reading the value, dunno, it could be related with the data types or lenghts, or the way how is stored if the value exceeds a predefined amount
I was brainstorming about it some moths ago when i was saying that i would like to see a screenshot of a PS3 with more than 1000 days of use (and as far i remember i could not see any yet)
You know... maybe the "13 days" we see in the screenshot are really "1013 days" , lol (so is like if the counter does a loop every 1000 days and we are missing 1 loop)
Also, as curiosity sake... we are talking about a CECHB that is a good candidate to have a huge time counter. The screenshot tells only 13 days but the owner have said the laser seems weared, so it doesnt looks like it was used only 13 days, it seems the previous owner made some ab/use of the laser

2) The PS3 was used in a cluster with the official otherOS installed, and was configured to autoboot by network... but it had some problems that was causing a firmware crash and was rebooting in a infinite loop... for 13 days
At day 13 someone realized about it, facepalmed, and retired the PS3 from the cluster... and sent to repair
Sony refurbished it and dissassembled it in parts... eventually the motherboard was used to repair the PS3 from other client

Thank you for the reply. I'd like to clarify that the laser now works 100% since the day I made that post. I just had to thoroughly open and clean the system. I had to ask the previous owner of the system and I was told that it was used by kids and was just "collecting dust" as the initial usage and they probably didn't take good care of it. It just surprised the hell out of me, as I was expecting to see atleast 200 days for something of that condition. Either way, I feel like the value being reset at 1000 might be true, however that would mean that the system should've had a YLOD based on how careless the previous owners were. Idk, strangest system I've encountered so far, but it works perfectly so there's that.

 

[sandungas]

Thank you for the reply. I'd like to clarify that the laser now works 100% since the day I made that post. I just had to thoroughly open and clean the system. I had to ask the previous owner of the system and I was told that it was used by kids and was just "collecting dust" as the initial usage and they probably didn't take good care of it. It just surprised the hell out of me, as I was expecting to see atleast 200 days for something of that condition. Either way, I feel like the value being reset at 1000 might be true, however that would mean that the system should've had a YLOD based on how careless the previous owners were. Idk, strangest system I've encountered so far, but it works perfectly so there's that.

Ok, your PS3 is very interesting because you confirmed it doesnt looks like used for 13 days only, and the previous owner said it was used by kids (not only 1 but several kids), and kids plays a lot
So... yeah, your PS3 looks like a nice candidate to have exceeded the 1000 days of usage

As far i remember there was another user some weeks (or months?) ago reporting this same problem, and it was another CECHB or CECHA (another good candidate to exceed the 1000 days), so you are not alone

------------
I dont really know how to fix this problem, or even if it can be fixed
Right now im thinking maybe the time is stored using an specific byte to count the loops, 1 loop represents 1000 days... and we are missing that byte

------------
My guess is the kids had the PS3 turned on for long play sessions, thats not so bad
Just as example... is better to keep the PS3 turned on 1 session of 8 hours... than 8 sessions of 1 hour each
Also, i guess they had the PS3 in a area good ventilated, and they was seated far away from the console (so they was not touching it much)
Anyway is a bit awesome to see a PS3 with so many hours of usage, i guess at some point it had some manteinance service (a laser replacement, thermal paste, or PSU)

 

[Fin9ersMcGee]

Ok, your PS3 is very interesting because you confirmed it doesnt looks like used for 13 days only, and the previous owner said it was used by kids (not only 1 but several kids), and kids plays a lot
So... yeah, your PS3 looks like a nice candidate to have exceeded the 1000 days of usage

As far i remember there was another user some weeks (or months?) ago reporting this same problem, and it was another CECHB or CECHA (another good candidate to exceed the 1000 days), so you are not alone

------------
I dont really know how to fix this problem, or even if it can be fixed
Right now im thinking maybe the time is stored using an specific byte to count the loops, 1 loop represents 1000 days... and we are missing that byte

------------
My guess is the kids had the PS3 turned on for long play sessions, thats not so bad
Just as example... is better to keep the PS3 turned on 1 session of 8 hours... than 8 sessions of 1 hour each
Also, i guess they had the PS3 in a area good ventilated, and they was seated far away from the console (so they was not touching it much)
Anyway is a bit awesome to see a PS3 with so many hours of usage, i guess at some point it had some manteinance service (a laser replacement, thermal paste, or PSU)

Another scenario...
Kids barely played, sibling rivalry, games console.... I can see arguments and evil actions such as pushing power button/flipping the switch during gameplay to annoy said sibling.
Me and my brother did it as kids all the time on Sega/Nintendo. Also, I was quite the addict when I was very young, so my parents pulling the console power mid-play was a regular occurrence.

I wonder if there were any saves on the console... This could show a particular games play time... Add them all up. Might coincide with the total powered on time. Some games are short (especially indies) and I can't imagine young kids playing epics like GTA 5 and the like... I guess age will dictate that. I know of some very very young children that have their own console but don't even know how to play games.... Its more of a colour and sound interactions than figuring out the actual game.

Or maybe these young children haven't been taught how to exit from a game and are just power cycling the console with a few power button presses to return to the XMB. And if your even younger than that, hitting the power button when you die ingame, get bored or just switch focus to something else.

There are whole tangents of theories I can think of.

 

[sandungas]

Another scenario...
Kids barely played, sibling rivalry, games console.... I can see arguments and evil actions such as pushing power button/flipping the switch during gameplay to annoy said sibling.
Me and my brother did it as kids all the time on Sega/Nintendo. Also, I was quite the addict when I was very young, so my parents pulling the console power mid-play was a regular occurrence.

I wonder if there were any saves on the console... This could show a particular games play time... Add them all up. Might coincide with the total powered on time. Some games are short (especially indies) and I can't imagine young kids playing epics like GTA 5 and the like... I guess age will dictate that. I know of some very very young children that have their own console but don't even know how to play games.... Its more of a colour and sound interactions than figuring out the actual game.

Or maybe these young children haven't been taught how to exit from a game and are just power cycling the console with a few power button presses to return to the XMB. And if your even younger than that, hitting the power button when you die ingame, get bored or just switch focus to something else.

There are whole tangents of theories I can think of.

Lol, at the parents hard-powering the console because the kid was playing too much, i remember that panic moments, bad times

Yeah, the counter with more than 3000 incorrect power-offs looks like an indication that the previous owners was doing something weird

But the thing that doesnt makes sense here is the total time of 13 days of usage only, in some way all the counters needs to be interpreted considering the others
I mean... 3000 incorrect poweroffs could be real if we consider the console was used for 1013 days
But in 13 days is completly weird, devil303 made a rought calculation, thats around 1 reboot every 5 minutes and repeated for 13 consecutive days
My theory about that PS3 being in a cluster and configured with some kind fo auto-reboot could explain that... but to be honest is not much probable

You gave me an idea with the times recorded in saves... there is also a time counter inside the hdd, you should try to take a look at it @excaliburn92 incase you still have the hdd that came with the console when you bought it
Use crystaldisk or any other tool able to read the SMART settings of the hdd

 

[Fin9ersMcGee]

Lol, at the parents hard-powering the console because the kid was playing too much, i remember that panic moments, bad times

Yeah, the counter with more than 3000 incorrect power-offs looks like an indication that the previous owners was doing something weird

But the thing that doesnt makes sense here is the total time of 13 days of usage only, in some way all the counters needs to be interpreted considering the others
I mean... 3000 incorrect poweroffs could be real if we consider the console was used for 1013 days
But in 13 days is completly weird, devil303 made a rought calculation, thats around 1 reboot every 5 minutes and repeated for 13 consecutive days
My theory about that PS3 being in a cluster and configured with some kind fo auto-reboot could explain that... but to be honest is not much probable

You gave me an idea with the times recorded in saves... there is also a time counter inside the hdd, you should try to take a look at it @excaliburn92 incase you still have the hdd that came with the console when you bought it
Use crystaldisk or any other tool able to read the SMART settings of the hdd

HDD S.M.A.R.T data is a great shout. Very good suggestion. And something outside of the ps3 specific hardware.

I understand the idea of 1000 days being an integer (is that the correct term?) and webman is not interpreting it as it was never meant to read anything past 1000 days. Kinda sinilar to the Y2K problem. At least, this is my understanding.

 

[aldostools]

HDD S.M.A.R.T data is a great shout. Very good suggestion. And something outside of the ps3 specific hardware.

I understand the idea of 1000 days being an integer (is that the correct term?) and webman is not interpreting it as it was never meant to read anything past 1000 days. Kinda sinilar to the Y2K problem. At least, this is my understanding.

The function that obtains the runtime information, gets the total time in seconds.

// get runtime data by @3141card
int32_t arg_1, total_time_in_sec, power_on_ctr, power_off_ctr;
sys_sm_request_be_count(&arg_1, &total_time_in_sec, &power_on_ctr, &power_off_ctr);

webMAN MOD displays the total number of seconds in dd:hh:mm:ss for better reading.
ss = (u32)total_time_in_sec;
dd = (u32)(ss / 86400); ss %= 86400; hh = (u32)(ss / 3600); ss %= 3600; mm = (u32)(ss / 60); ss %= 60;

// 86400 = 24 hours * 60 minutes * 60 seconds, 3600 = 60 minutes * 60 seconds

For an overflow in a 32bit integer the total runtime must exceed 136 years of usage

 

[Fin9ersMcGee]

The function that obtains the runtime information, gets the total time in seconds.

// get runtime data by @3141card
int32_t arg_1, total_time_in_sec, power_on_ctr, power_off_ctr;
sys_sm_request_be_count(&arg_1, &total_time_in_sec, &power_on_ctr, &power_off_ctr);

webMAN MOD displays the total number of seconds in dd:hh:mm:ss for better reading.
ss = (u32)total_time_in_sec;
dd = (u32)(ss / 86400); ss %= 86400; hh = (u32)(ss / 3600); ss %= 3600; mm = (u32)(ss / 60); ss %= 60;

So, the console in questions DOES have a 13 day runtime with 3000 power cycles?

 

[aldostools]

So, the console in questions DOES have a 13 day runtime with 3000 power cycles?

The function sys_sm_request_be_count returned the following values:
total_time_in_sec = 1197292
power_on_ctr = 3660
power_off_ctr = 315

IIRC these statistics are stored in SYSCON and are believed to be true, except if the counters were modified or not recording properly.

The average usage time is 5 minutes 27 seconds. But looking at the other 2 variables, my theory is that was used in average 1 hour, then it presented a fail that caused it to shutdown few seconds after it was powered on. Although 3000+ tries to power on is a bit weird.

Another theory is that the "total time" could be recorded only on proper shutdown. If this is true, then the total runtime could be much more than 13 days.

 

[Fin9ersMcGee]

The function sys_sm_request_be_count returned the following values:
total_time_in_sec = 1197292
power_on_ctr = 3660
power_off_ctr = 315

IIRC these statistics are stored in SYSCON and are believed to be true, except if the counters were modified or not recording properly.

The average usage time is 5 minutes 27 seconds. But looking at the other 2 variables, my theory is that was used in average 1 hour, then it presented a fail that caused it to shutdown few seconds after it was powered on. Although 3000+ tries to power on is a bit weird.

Another theory is that the "total time" could be recorded only on proper shutdown. If this is true, then the total runtime could be much more than 13 days.

Not so definitive after all. A sure mystery for now. 3000 cycles is a large number indeed.

 

[DoublesAdvocate]

The function sys_sm_request_be_count returned the following values:
total_time_in_sec = 1197292
power_on_ctr = 3660
power_off_ctr = 315

IIRC these statistics are stored in SYSCON and are believed to be true, except if the counters were modified or not recording properly.

The average usage time is 5 minutes 27 seconds. But looking at the other 2 variables, my theory is that was used in average 1 hour, then it presented a fail that caused it to shutdown few seconds after it was powered on. Although 3000+ tries to power on is a bit weird.

Another theory is that the "total time" could be recorded only on proper shutdown. If this is true, then the total runtime could be much more than 13 days.

Given how many of these consoles I've seen with this bizarre pattern I think you're probably correct about it not logging the power on time with incorrect shutdowns.

 

[DeViL303]

Another theory is that the "total time" could be recorded only on proper shutdown. If this is true, then the total runtime could be much more than 13 days.

That makes sense, otherwise it would need to be constantly writing the uptime every second. That wouldn't be practical. Much more likely it just writes the current boots uptime when it shuts down.

 

[Fin9ersMcGee]

That makes sense, otherwise it would need to be constantly writing the uptime every second. That wouldn't be practical. Much more likely it just writes the current boots uptime when it shuts down.

Haha, my theory of sibling rivalry/brash parents isn't so farfetched. That console seems more abuse victim than barely touched gem... Lol

 

[sandungas]

The function that obtains the runtime information, gets the total time in seconds.

// get runtime data by @3141card
int32_t arg_1, total_time_in_sec, power_on_ctr, power_off_ctr;
sys_sm_request_be_count(&arg_1, &total_time_in_sec, &power_on_ctr, &power_off_ctr);

I was thinking mostly about reading the other int32_t located inmediatly before or after the ones we are actually reading
But now im thinking the function sys_sm_request_be_count cant be configured to read from a different offset ?

The idea was that syscon was storing the loops in a different register (an int_8 would be enought), and 1 loop represented 1000 days

...but i guess what you said is right, the time is only recorded if the power off sequence is completed successfully
Unplugging the power cord doesnt allows to complete the poweroff sequence, so there is no time recorded

 

[aldostools]

I was thinking mostly about reading the other int32_t located inmediatly before or after the ones we are actually reading
But now im thinking the function sys_sm_request_be_count cant be configured to read from a different offset ?

The idea was that syscon was storing the loops in a different register (an int_8 would be enought), and 1 loop represented 1000 days

...but i guess what you said is right, the time is only recorded if the power off sequence is completed successfully
Unplugging the power cord doesnt allows to complete the poweroff sequence, so there is no time recorded

sys_sm_request_be_count is the syscall 0x187:

static s32 sys_sm_request_be_count(s32 *arg_1, s32 *total_time_in_sec, s32 *power_on_ctr, s32 *power_off_ctr)
{
system_call_4(0x187, (u32)arg_1, (u32)total_time_in_sec, (u32)power_on_ctr, (u32)power_off_ctr);
return_to_user_prog(s32);
}

If the average session was 3801 seconds (1197292 / 315 correct OFFs). Then we could assume that the usage time not registered is 3,531.76 hours ((3660 - 315) * 3801 = 12,714,345 seconds).

The "real" runtime of that console should be approximately 13,911,637 seconds (1,197,292 + 12,714,345) = 161 days + lot of abuse

 

[sandungas]

What is the "arg_1" in the syscall ?

sys_sm_request_be_count(&arg_1, &total_time_in_sec, &power_on_ctr, &power_off_ctr);