Hacking AutoRCM CFW VS OFW Clean Switch; A Quick Battery Comparison

[kumikochan]

Wrong thread again...

It's NOT !!!!!!!!!!!!!! Again do I have to draw a simple kindergarten drawing for you to understand that this has to do with everything the OP said ??? I really wonder where you went to school if you fail to understand something so basic

 

[Kubas_inko]

It's NOT !!!!!!!!!!!!!! Again do I have to draw a simple kindergarten drawing for you to understand that this has to do with everything the OP said ???

OMG. This thread is not about AutoRCM and noticing how it boots to RCM after powering off and draining the battery. This thread is about testing Switches with AutoRCM vs Normal in (literally) a play time.
You are still thinking about this thread: https://gbatemp.net/threads/psa-man...es-not-turn-off-a-switch-with-autorcm.515402/
Otherwise, show me that OP of this thread ever stated anything about his Switch booting to RCM and draining battery.

 

[kumikochan]

OMG. This thread is not about AutoRCM and noticing how it boots to RCM after powering off and draining the battery. This thread is about testing Switches with AutoRCM vs Normal in literally a play time.
You are still thinking about this thread: https://gbatemp.net/threads/psa-man...es-not-turn-off-a-switch-with-autorcm.515402/

Ur fucking pissing me off that you can't seem to understand it has everything TO DO WITH WHAT I SAID !!!!!!!!! OP said his switch in AUTORCM drains faster while playing a game compared to his OFW switch holding a charge longer --- You still with me ????
I'm saying the reason why he can see that difference in charge is because the battery could have degraded of his AUTORCM switch being it always turned on compared to his OFW switch being always turned off and only on when playing a game ---- You still with me ?????
If you fail to understand that simple basic concept why it has everything to do with what he said then I advice you to go back to kindergarten and start all over after having to explain that concept to you over and over and over again and making it more simple to understand each time but you still fail to get that !!!

 

[Kubas_inko]

Ur fucking pissing me off that you can't seem to understand it has everything TO DO WITH WHAT I SAID !!!!!!!!! OP said his switch in AUTORCM drains faster while playing a game compared to his OFW switch holding a charge longer --- You still with me ????
I'm saying the reason why he can see that difference in charge is because the battery could have degraded of his AUTORCM switch being it always turned on compared to his OFW switch being always turned off and only on when playing a game ---- You still with me ?????
If you fail to understand that simple basic concept why it has everything to do with what he said then I advice you to go back to kindergarten and start all over !!!!!!!!!!!

OP never said this:

So stop freaking implying it.

 

[Phoenixrite]

The problem I had was powering it off completely in auto RCM the battery could drain from 86% to 25% in 6 hours turns out it doesn't power down completely and instead goes into RCM. Uninstalled auto RCM and powdered off completely battery level drained 1% after 1week not in use.

--------------------- MERGED ---------------------------

AutoRCM isnt doing anything to the battery.

Unless you're actually shutting down your console and not realizing you need Hekate for that. (Shutting down from the power menu sends your device back into RCM mode, still drawing power)

AutoRCM is simply changing a couple bytes in your boot table and boot is only called on power up.

So what's the solution to power down the machine with auto RCM or just stay in sleep mode?

 

[Loke]

Haha you guys...

If you want to test these kind of things, make a proper testing setup. Here is a wikihow to help you get started: https://www.wikihow.com/Test-a-Hypothesis

Do the test multiple times and switch the setup of the consoles, so you know it's not the console instead of the cfw or rcm.

And @kumikochan
When something is not properly tested in a controlled enviroment, it is not factual and can be considered a myth. Don't call people dumb with results like these, as they don't give any facts, except that one switch is draining faster than the other, which can be caused by a lot of things..

 

[kumikochan]

Haha you guys...

If you want to test these kind of things, make a proper testing setup. Here is a wikihow to help you get started: https://www.wikihow.com/Test-a-Hypothesis

Do the test multiple times and switch the setup of the consoles, so you know it's not the console instead of the cfw or rcm.

And @kumikochan
When something is not properly tested in a controlled enviroment, it is not factual and can be considered a myth. Don't call people dumb with results like these, as they don't give any facts, except that one switch is draining faster than the other, which can be caused by a lot of things..

I always said that it could be, I multiple times said that it could be and that it also could be something else. If you read my comments then you would have seen that. I was calling him dumb because he said multiple times my comment doesn't belong in this thread while it does

 

[Loke]

I always said that it could be, I multiple times said that it could be and that it also could be something else. If you read my comments then you would have seen that

I know. Maybe it's causing it, but while it is not proven to be the actual cause, it is considered a myth. You're getting pretty worked up over something that "might cause it".
Do actual proper testing or stop the insinuation that autoRCM is the cause. The used CFW is more likely to be the cause than autoRCM.

 

[Kubas_inko]

I know. Maybe it's causing it, but while it is not proven to be the actual cause, it is considered a myth. You're getting pretty worked up over something that "might cause it".
Do actual proper testing or stop the insinuation that autoRCM is the cause. The used CFW is more likely to be the cause than autoRCM.

There is no myth. If his Switch was really so many times in RCM, thus draining battery, it might have more cycles already, which can cause the difference. So there is no myth. But, kumikoxxxx is constantly saying it, as it is what this thread is about, which this thread isn't.

 

[kumikochan]

I know. Maybe it's causing it, but while it is not proven to be the actual cause, it is considered a myth. You're getting pretty worked up over something that "might cause it".
Do actual proper testing or stop the insinuation that autoRCM is the cause. The used CFW is more likely to be the cause than autoRCM.

that's also a myth so don't push that as a fact

 

[linuxares]

Okey stop bickering.

I've got to ask, and it's probably a question for the guys with more inside knowledge.

Since the Switch knows something is corrupt. Does it have some function that is running because of the corruption? Like a check or a process that emulates that broken part?

 

[tiliarou]

Okey stop bickering.

I've got to ask, and it's probably a question for the guys with more inside knowledge.

Since the Switch knows something is corrupt. Does it have some function that is running because of the corruption? Like a check or a process that emulates that broken part?

This is the only sensible post in this thread

On some OS, there is an integrity check at boot or after boot which could run something in the background to try to solve the issue on boot partition for example.
I believe that reswitched and atmo dev team knows sufficiently about the horizon boot process / background processes to answer this.
But they would have mentionned it in bricmee or autorcm threads and tutos, so I highly doubt such process is in horizon.

 

[Kubas_inko]

Okey stop bickering.

I've got to ask, and it's probably a question for the guys with more inside knowledge.

Since the Switch knows something is corrupt. Does it have some function that is running because of the corruption? Like a check or a process that emulates that broken part?

Probably something simple which reads boot0/1 on boot. If it can't (probably some hashes/idk differ), it boots to recovery.

 

[linuxares]

Probably something simple which reads boot0/1 on boot. If it can't, it boots to recovery.

I've know very well how AutoRCM works. But if Horizon itself got a check or not, haven't really been answered.
Also what might cause the extra battery usages is the CFWs themselves. Not necessarily but maybe.

 

[Kubas_inko]

I've know very well how AutoRCM works. But if Horizon itself got a check or not, haven't really been answered.
Also what might cause the extra battery usages is the CFWs themselves. Not necessarily but maybe.

Can Horzion know about brickmii/autorcm? Yes, it can. But does it? Probably not.
Can Horzion know about RCM? Yes, it can. But does it? Nope.
But I have no idea how any of that works so... (also I have no idea if this anyhow answered your question)

 

[linuxares]

Can Horzion know about brickmii/autorcm? Yes, it can. But does it? Probably not.
Can Horzion know about RCM? Yes, it can. But does it? Nope.
But I have no idea how any of that works so...

That's exactly why I rather ask the people with more knowledge. Because if the logs say it booted in RCM, it's a huge risk for bans also

 

[Kubas_inko]

That's exactly why I rather ask the people with more knowledge. Because if the logs say it booted in RCM, it's a huge risk for bans also

It has been proven by Atmo team (that it can be detected). But they also said that it Ninty is not detecting it yet. But try asking them how it works, and you get no answer

 

[linuxares]

It has been proven by Atmo team (that it can be detected). But they also said that it Ninty is not detecting it yet. But try asking them how it works, and you get no answer

Then Horizon might also therefore double check the corrupt partition, but who knows. I will ask the teams later.

 

[mastermx]

To clarify, my autorcm switch was purchased on release day last year. I only installed AutoRCM last week. And noticed a difference in battery. This is subjective, as I did not test this before installing autorcm. I installed firmware 5.1 from 3.0 through choidujours by rajkosto, therefore I am averse to undoing autorcm, as that would burn my e-fuses.

Before installing autoRCM, the release day switch got very little use outside of a run of botw. it was either asleep in the dock, or was shutdown collecting dust on the shelf. The battery may have degraded naturally due to the passage of time, and yet it was immiediete when I noticed the battery difference after hacking my switch. This could be due to using the tinfoil app to install nsps, or playing games mostly through the sd card.

Since the Switch knows something is corrupt. Does it have some function that is running because of the corruption? Like a check or a process that emulates that broken part?

This was a theory I had regarding why some people report different battery life after autoRCM. The switch doesn't have a process manager, you can't really monitor fanspeed, temps, or monitor what is using cpu/ram usage. So it's a very difficult to gauge the internal processes of the switch for those of us who aren't versed with the intricacies of horizon. It's not like we can play with clockspeeds like in the psp era.

I have a feeling that future CFWs for the switch may add improved optimizations, and decrease unnecessary usage of battery for otherwise erroneous tasks. Though it seems Nintendo has already optimized horizon quite well, I do wonder how all these implemented security measures in the system drain the system's resources.

 

[leonmagnus99]

the suggestions worked thanks guys, tested it out.
my switch was 70+% and i powered it off then while it was off i just held power again and that seemed to do the trick.

i just now after 5hours plugged it into my phone with the sx app on my phone and it directly launched tx os/cfw and the battery % had remained the same.

so all dandy and thanks again.