Touch Power code regression?

[Shai-Hulud]

I've noticed an infrequent but persistent problem affecting battery life on the Kobo touch.

I run the device in Airplane mode with an auto-sleep timeout of 15 minutes and a power-off timeout of 30 minutes. Every so often when either manually flicking the power switch to sleep mode or letting the machine timeout to enter sleep mode, it subsequently fails to enter power-off mode. Furthermore when this occurs and I flick the power switch back on I notice a fair chunk of battery reserve has been eaten up. e.g. Enter sleep mode at 1 a.m. with 94% battery. Resume 7 hours later at 8 a.m. with 67% battery! It's almost as if the machine enters some kind of loop which chews through more power than if it was in true sleep or power off mode. Anyhow the net result is the same: I end up charging every few days if this happens.

Now the odd thing is this behaviour is not limited to one machine since we have 2 Touch's in my family purchased at the same time. This behaviour can occur on either device and has been observed on firmwares 1.9.17, 2.1.5 and 2.3.2. Having searched the mobileread forum, this is the closest issue I can find but it was posted three years ago.

Is it possible there has been a code regression inadvertently introduced? Has anyone else seen this behaviour?

[Gaffer]

Originally Posted by Shai-Hulud

Now the odd thing is this behaviour is not limited to one machine since we have 2 Touch's in my family purchased at the same time. This behaviour can occur on either device and has been observed on firmwares 1.9.17, 2.1.5 and 2.3.2. Having searched the mobileread forum, this is the closest issue I can find but it was posted three years ago.

Is it possible there has been a code regression inadvertently introduced? Has anyone else seen this behaviour?

I've been running 1.9.17 continuously since it was released nearly a year ago, and have never seen any such problem.

[Shai-Hulud]

Well it's quite possible that it's restricted to specific hardware revisions or even a batch fault - lack of further comment would certainly suggest it's not a common issue.

What's frustrating is it isn't predictable other than to say it will occur on average twice a month.

[VelvetElvis]

Originally Posted by Shai-Hulud

I've noticed an infrequent but persistent problem affecting battery life on the Kobo touch.

I run the device in Airplane mode with an auto-sleep timeout of 15 minutes and a power-off timeout of 30 minutes. Every so often when either manually flicking the power switch to sleep mode or letting the machine timeout to enter sleep mode, it subsequently fails to enter power-off mode. Furthermore when this occurs and I flick the power switch back on I notice a fair chunk of battery reserve has been eaten up. e.g. Enter sleep mode at 1 a.m. with 94% battery. Resume 7 hours later at 8 a.m. with 67% battery! It's almost as if the machine enters some kind of loop which chews through more power than if it was in true sleep or power off mode. Anyhow the net result is the same: I end up charging every few days if this happens.

Now the odd thing is this behaviour is not limited to one machine since we have 2 Touch's in my family purchased at the same time. This behaviour can occur on either device and has been observed on firmwares 1.9.17, 2.1.5 and 2.3.2. Having searched the mobileread forum, this is the closest issue I can find but it was posted three years ago.

Is it possible there has been a code regression inadvertently introduced? Has anyone else seen this behaviour?

I'm having the exact same issues with a Glo. I should note that this is a replacement Glo, with the same one exhibiting the same problem. Posting details in a separate thread.

[Shai-Hulud]

Originally Posted by VelvetElvis

I'm having the exact same issues with a Glo.

I now have a replacement Touch which runs the Glo firmware (2.1.5 ATM) and it's happening on this too. However odd this sounds, I'm beginning to suspect it's an issue triggered by the actual timing intervals selected.

My preferred intervals are 15 min sleep/30 min power-off which have thus far been giving me the problem. However I am currently testing with 10 min sleep/15 min power-off and *so far* the problem hasn't shown itself i.e. it doesn't get stuck in sleep mode, no excessive battery use in between and the transition to full power-off occurs as expected. I'd need a month or so to be sure of course.

Perhaps it would be useful if those contributing to this thread were to state their selected sleep/power-off settings (plus model) to explore if this has any validity?

[Mrs_Often]

Originally Posted by Shai-Hulud

I now have a replacement Touch which runs the Glo firmware (2.1.5 ATM) and it's happening on this too. However odd this sounds, I'm beginning to suspect it's an issue triggered by the actual timing intervals selected.

Interesting. I'm also having battery problems with my Glo (2.3.2). However, my sleep time is 15 mins and it's set to never switch off... My Touch is set up the same way and is not having problems.

[Shai-Hulud]

Originally Posted by Mrs_Often

Interesting. I'm also having battery problems with my Glo (2.3.2). However, my sleep time is 15 mins and it's set to never switch off... My Touch is set up the same way and is not having problems.

My father has an early Touch (on 2.1.5), and I now have a replacement Touch running the Glo software (also 2.1.5). And the fault is reproducible on both
* I should add "intermittently" - it isn't constantly reproducible which makes it harder to track down unfortunately *

Given you "sleep" both your Kobos, it tends to disprove that the fault occurs at the point of entering the power-off state at least.

[Mrs_Often]

Originally Posted by Shai-Hulud

Given you "sleep" both your Kobos, it tends to disprove that the fault occurs at the point of entering the power-off state at least.

Not necessarily. We might have two different problems. I must admit I didn't completely read your first post of this thread before I replied. I have now. What I understand is that you have a large battery drop every time your device stays in sleep mode.

- This could mean that sleep mode just buggers up battery life more than it should – this is comparable to the problem I am having. Have you tried not using (auto) off-mode? How's battery life in sleep without a planned off-moment?

- It could also mean what you suggest, that the device is constantly trying to trigger off-mode without proper response, draining battery faster due to its constant trying. Weird that 15/30 min gave problems but 10/15 doesn't seem to. What could the difference be?

When you say the problem is reproducible but not *always*, what does that mean? In what situations is it not reproducible?

[Shai-Hulud]

Originally Posted by Mrs_Often

What I understand is that you have a large battery drop every time your device stays in sleep mode.

No not quite the case. I'm saying I have intermittent occurences where the unit does not transition into full power-off mode, instead staying stuck in sleep mode. When that happens, that is when I also experience a large battery drain. However, I cannot predict WHEN this will happen as so far it's random. All I can say is on average it will occur roughly twice a month. (This is why the problem is frustrating as it's hard to diagnose a fault that's inconsistent!)

Originally Posted by Mrs_Often

Have you tried not using (auto) off-mode? How's battery life in sleep without a planned off-moment?

A fair point. It could be that when it fails to trigger a full power-off then I may end up experiencing what you and others are reporting (certainly this would be more consistent). I assumed that the failure to trigger a power-off and the heavy battery drain were aspects of the same fault. Perhaps this isn't the case and it could be two faults as you suggest. I'll try this for a few days to investigate. Perhaps you could try setting an explicit power-off to test the impact on battery life as well?

Originally Posted by Mrs_Often

Weird that 15/30 min gave problems but 10/15 doesn't seem to. What could the difference be?

Unsure - and it's not proven until I have a month under my belt at least, so it could prove to be a red herring. Let's see what the above shows us.

[Mrs_Often]

Originally Posted by Shai-Hulud

Perhaps you could try setting an explicit power-off to test the impact on battery life as well?

Good idea. I would, but I don't have my Glo any more. I'm waiting for a replacement from Kobo. And my Touch has no battery problems and is currently lasting a ridiculously long time in sleep mode, I'm in the middle of testing how long exactly (going on 22 days, estimated 43 days).

[Shai-Hulud]

As a by-the-by, does anyone know a way of determining the linux kernel version used? I can't seem to find anything in the firmware itself (short of reverse engineering) and all I can find in the user partition is a text file named "version" in .kobo containing "2.6.35.3" which is indicative though not definitive of course.

Now if 2.6.35 is the kernel version used, then this may help explain the high power consumption (though not the trigger for the problem itself) since there was a bad power regression of around 18% over previous kernel versions introduced in 2.6.35 and a further cumulative regression of 5% introduced with 2.6.38 according to Phoronix. Other sources will no doubt confirm this.

[Mrs_Often]

Originally Posted by Shai-Hulud

As a by-the-by, does anyone know a way of determining the linux kernel version used? I can't seem to find anything in the firmware itself (short of reverse engineering) and all I can find in the user partition is a text file named "version" in .kobo containing "2.6.35.3" which is indicative though not definitive of course.

Now if 2.6.35 is the kernel version used, then this may help explain the high power consumption (though not the trigger for the problem itself) since there was a bad power regression of around 18% over previous kernel versions introduced in 2.6.35 and a further cumulative regression of 5% introduced with 2.6.38 according to Phoronix. Other sources will no doubt confirm this.

Hah. That is quite interesting indeed. I can hardly imagine such an exact match of string of numbers being two different things so you might be on to something. I want to check my Touch's kernel version now but I don't want to plug it in and mess up the battery test... hmmm... I'll think about it a bit and maybe stop the test

On the other hand, you never know, maybe the numbers are a coincidence.

[Shai-Hulud]

If so then I suspect that the .3 in "2.6.35.3" would be a Kobo internal revision number. If 2.6.35 is employed then all we know is that it's a bad choice for power consumption generally. However what would be *really* nice to know is whether there has been a kernel revision change since the earlier Touch firmware was released (I genuinely don't know). Because this might point the finger at a regression being the cause of the current power problem (poor choice of base kernel aside).

[Mrs_Often]

I found a backup I had of my Touch from firmware 2.0.0, and I'm afraid the version file from that backup showed the exact same 2.6.35.3... and as I already stated my Touch has perfect battery life so I'm afraid your wonderful discovery is not the key to our problems.

I had two more backups from the Touch:
Firmware 1.9.17: 2.6.35.3
Firmware 1.9.11: 2.6.35.3

So nope, no change since at least more than a year ago.

[PeterT]

I had a whole slew of backups

02\08\2012\.kobo\version
KG3172104949A,2.6.35.3,2.0.3,2.6.35.3,2.6.35.3,00000000-0000-0000-0000-000000000310
05\08\2012\.kobo\version
KG3172104949A,2.6.35.3,2.0.3,2.6.35.3,2.6.35.3,00000000-0000-0000-0000-000000000310
28-12-2012\.kobo\version
KG3172104949A,2.6.35.3,2.3.2,2.6.35.3,2.6.35.3,00000000-0000-0000-0000-000000000310
31\07\2012\.kobo\version
KG3172104949A,2.6.35.3,2.0.3,2.6.35.3,2.6.35.3,00000000-0000-0000-0000-000000000310
Backup - Feb 3 - 2013\.kobo\version
KG3172104949A,2.6.35.3,2.4.0,2.6.35.3,2.6.35.3,00000000-0000-0000-0000-000000000310
July 17\.kobo\version
KG3172104949A,2.6.35.3,2.0.0,2.6.35.3,2.6.35.3,00000000-0000-0000-0000-000000000310
02\03\2012\.kobo\version
KG3172104949A,2.6.35.3,1.9.17,2.6.35.3,2.6.35.3,00000000-0000-0000-0000-000000000310
14\10\2012\.kobo\version
KG3172104949A,2.6.35.3,2.1.4,2.6.35.3,2.6.35.3,00000000-0000-0000-0000-000000000310
4-4-11\.kobo\version
00:08:54:E5:7E:EE,Mobile,1.9,Mobile,Mobile,00000000-0000-0000-0000-000000000210
Dec 13\.kobo\version
KG3172104949A,2.6.35.3,1.9.14,2.6.35.3,2.6.35.3,00000000-0000-0000-0000-000000000310
June 28 - 2012\.kobo\version
KG3172104949A,2.6.35.3,1.9.18,2.6.35.3,2.6.35.3,00000000-0000-0000-0000-000000000310
July-26\.kobo\version
00:08:54:E5:7E:EE,Mobile,1.9,Mobile,Mobile,00000000-0000-0000-0000-000000000210
Sep 9 - 2012\.kobo\version
KG3172104949A,2.6.35.3,2.1.2,2.6.35.3,2.6.35.3,00000000-0000-0000-0000-000000000310
Kobo-Sep-26\.kobo\version
KG3152502577A,2.6.35.3,1.9.10,2.6.35.3,2.6.35.3,00000000-0000-0000-0000-000000000310

So all of these show the 2.6.35.3 code. One of these Kobo's was bought the day they went on sale, the other a few months later.