Aura One Firmware 4.2.8432

[DNSB]

Originally Posted by akorx

Hi,

Do you know if nightmode is ok with a kobo no HD with FW 4.2.8432 ?

If you try the version of nightmode from this link https://github.com/gtalusan/kobo-nig...r/KoboRoot.tgz, it should work on your Glo with 4.2.8432. I've tested it on a KA1, H2O, Aura HD and Aura. The KA1 is the only one that was a pain since the only way I found to enable/disable nightmode is to edit the .ini file.

[JSWolf]

Originally Posted by GeoffR

I'm having some trouble connecting my Glo via USB to my laptop running Debian Linux with firmware 4.2.8432.

If I reboot the Glo then I can connect once without any problems, but if I try to connect a second time withoot a reboot inbetween then it won't connect.

I'm not finding any problem with my laptop and Windows 10 (not yet at the anniversary edition) connecting my H2O via USB. Before I install the anniversary edition, I need to do a backup. I'll do the backup sometime next week.

[Ksquared]

I have not been following the forum the past few weeks, so I was surprised when my Aura 6" updated during a sync last night.
I notice 2 changes:
- I have always had a bad ghost of the book cover image when the device wakes up from the sleep cover, but not if it was put to sleep by the switch. The ghost is gone since the update.
- After waking up or turning on, the first time I would do a 2 finger swipe to adjust the light, there was always a delay. Now it works well the first time out.

One other thing that might have always been there - it seems like when the device wakes up the light comes on in small, rapid steps, until it is at the designated brightness. I never noticed that before.

The ShowPageHeader=False does not work, as with the previous couple of FW. Oh well...

So far, it looks like things are working well.

[ElWorm]

*Deleted*

[GeoffR]

I've been having quite a few problems since my Glo updated from 3.19.5761 to 4.2.8432, but they all have something in common which makes me think the underlying issue is that the new firmware requires more memory and the Glo doesn't have quite enough.

Problems:

* I can only connect once via USB to my laptop, and have to reboot the Glo to connect again.

* I can only successfuly complete one wi-fi sync, and have to reboot the Glo to sync again.

* After connecting via USB and sideloading an ePub, opening the ePub causes the Glo to freeze for a while and then close the book. If I reboot the Glo between sideloading the ePub and opening it then there is no problem.

* After reading a synced KePub, if I open a sideloaded ePub and try to change fonts the device is very slow, freezes for a while, then closes the book. If I reboot the device between finishing the KePub and opening the ePub then there is no problem. (This problem occured in 3.19.5761 only with the extremely large CJK fonts such as Kobo Tsukushi Mincho, but with firmware 4.2.8432 it seems to happen with all fonts.)

I have about 1000 books on my Glo: 375 synced KePubs and the rest sideloaded ePubs. My KoboReader.sqlite database is about 90Mb.

One related issue is that my synced KePubs no longer have full-size (N3_FULL) cover images downloaded from the server, I guess the device must be using the meduim-sized covers and upscaling them to fill the sleep screen. This might be an attempt to reduce memory use, but it means that the sleep screen covers on synced KePubs are a bit fuzzy. Sideloaded ePubs still generate full-sized cover images.

The problems are managable if I remember to reboot the Glo at the appropriate times, but I suspect things will only get worse as I add more books and my database grows.

Edit: I've removed some fonts and replaced some KePub books with ePub versions, and things have improved a bit. I think memory was probably getting tight before and the firmware update had just tipped my availalable memory from just-enough to not-quite-enough. Maybe I will do a factory reset and start afresh, it has been three years since my last one.

[Katsunami]

I'm always flabbergasted why manufacturers include so little hardware in anything from e-readers to digital piano's.

In the latter, manufacturers are still designing and maintaining their own CPU's, chips and operating systems. It would be much faster to just put an Intel NUC-like board in there, run Linux on top of it (adapted how and where needed), and write the piano software for that, using the piano itself as a hardware controller.

Compared to what is available in a current-day digital piano (or any hardware instrument), CPU, memory and storage capacity could be considered unlimited.

As flash memory and RAM is close to free nowadays, I've always wondered why an e-reader doesn't have 16GB storage and 2GB RAM; and why a phone doesn't have 4 or 8GB RAM.

[GeoffR]

Originally Posted by Katsunami

IAs flash memory and RAM is close to free nowadays, I've always wondered why an e-reader doesn't have 16GB storage and 2GB RAM; and why a phone doesn't have 4 or 8GB RAM.

More RAM = higher energy consumption. This is much more noticable in e-ink devices because the screen uses so little energy.

[eenk]

Originally Posted by Katsunami

I'm always flabbergasted why manufacturers include so little hardware in anything from e-readers to digital piano's.

I have a background in one of the many embedded systems industry. The systems you are probably referring to are generic volume systems, which are too expensive. That's because you need quite some software beyond a standard operating system. And that costs a lot of money to develop. So, the hardware needs to be cheap. Also, system energy consumption needs is an important part here, and most generic mass platforms are not suitabe. Yes, I can build a 7" rbook reader from a Raspberry Pi and the official 7" touch display. But it won't be a usable product, and its hardware costs are insane when compared to what I suspect the Kobo HW prices to be.

In short, don't apply what you see for mobiles, tablets, PCs, Raspberrys, etc. Don't even apply car electronic control unit economics, all are a different scale.

Also, these are SoC systems, so you don't get your flash and RAM for nothing. Au contraire. The full picture is much more complex than what you describe.

[GeoffR]

One thing that seems to be much faster in 4.2.8432 is processing sideloaded books. I loaded 5 ePubs at once from Calibre to my Glo and they only took about 2 seconds total to process. In 3.19.5761 it would have been more like 15 seconds.

The glitch in 3.19.5761 where the cover image flashed on the screen when changing font settings in the ePub reader seems to have been fixed.