Firmware 4.31.19086

[ownedbycats]

I'd test with my old Aura HD (mark4), but unfortunately the failing SD card in it would muddy up the results.

[Sirtel]

Originally Posted by MGlitch

I will say occasionally the buttons don’t work but paging forward or backwards by touch resolves the issue and it happens very infrequently.

This seems to happen on many, if not most, Sages. It happens on mine, and my Sage is still on 4.30.

[agugu]

Originally Posted by MGlitch

I will say occasionally the buttons don’t work but paging forward or backwards by touch resolves the issue and it happens very infrequently.

Same...

[davidfor]

Originally Posted by Calenorn

I wonder if they care enough about side loading to bother. Barnes and Noble clearly didn't.

They definitely do. But, the issue is reproducing the problem. For example, the "always needs to scan" problem is not consistent for me. One night I had it twenty times in a row on my Clara HD and Libra H2O with epubs, but never with a kepub. Whereas someone here has reported it happens with every kepub they sideload. I went to repeat the tests the next day as I thought of something to get more information, and it didn't happen at all on Libra H2O. I did exactly the same thing and didn't have any problems.

While I am seeing some of the issues being reported, I am just not seeing them as often as others are. The scan prompt is happening more often than with previous firmware, but, it isn't happening every time. I have had the issue with the reading status not updating once. But, I suspect that was because it was one of the few times where I sideloaded a book and started reading it immediately. I have had a couple of corrupt databases on my Libra H2O, though the second one was probably me making a mistake when restoring the backup.

All that means is that the cause is not clear. And when trying to debug it, you have to catch it a problem to see what is happening. If the problem doesn't happen consistently, you have to be lucky to catch it. And this has problems debugging it as it is related to what happens when you connect to a PC and at that time, WiFi is shutdown and hence you can't use telnet to debug.

[icallaci]

I am seeing the problems with 4.31 on my Elipsa, if that helps.

[davidfor]

Originally Posted by ownedbycats

I'd be curious to see what devices the malfunctions are happening most on, as I'm wondering if it could be limited to certain firmware versions -- Libra H2O is mark7 and Libra 2 is mark9 if I'm remembering right.

Before you go off on this, do you know what the "Mark" means?

Almost nothing.

The marks are a just grouping of devices included in a firmware update package. Kobo has been trying to keep that update package at around 100MB. That means, the main reason they have started a new mark is because the update package was to big. Because this matches the sequence of the releases, there is some similarity in the hardware in the devices, but, it is largely just because of the timing. I was told this because I commented on the Aura Edition 2 Version 2 and Aura H2O Edition 2 Version 2 being in Mark7 but was told that they would have been Mark6, but the update package would have been to big.

The start of Mark8 and then Mark9 are probably the only ones explicitly keeping like devices together. But, they also fit with the update package size. And the difference is hardware between the Libra H2O and Libra 2 is tiny, it is basically enabling the Bluetooth parts of a chip and the screen. The Libra 2 could have been a Mark7.

[ownedbycats]

Originally Posted by davidfor

Before you go off on this, do you know what the "Mark" means?

Almost nothing.

The marks are a just grouping of devices included in a firmware update package. Kobo has been trying to keep that update package at around 100MB. That means, the main reason they have started a new mark is because the update package was to big. Because this matches the sequence of the releases, there is some similarity in the hardware in the devices, but, it is largely just because of the timing. I was told this because I commented on the Aura Edition 2 Version 2 and Aura H2O Edition 2 Version 2 being in Mark7 but was told that they would have been Mark6, but the update package would have been to big.

The start of Mark8 and then Mark9 are probably the only ones explicitly keeping like devices together. But, they also fit with the update package size. And the difference is hardware between the Libra H2O and Libra 2 is tiny, it is basically enabling the Bluetooth parts of a chip and the screen. The Libra 2 could have been a Mark7.

Ah. I assumed that there were differences between them.

[Poppaea]

Originally Posted by tschucha

I have not tried to run the numbers to see for sure but I do believe that the battery usage has been optimized somewhat on the sage. If I read before I go to sleep starting with a full charge i would be down to about 92-95 % under earlier firmware versions. With the 4.31 it is typically more like 94-96 %. This is certainly not scientific but I have been watching the percentages. I read with the light at 6% and WIFI/Bluetooth always off.

Hope this helps

Thank you! It does.

[Calenorn]

Originally Posted by davidfor

They definitely do. But, the issue is reproducing the problem. For example, the "always needs to scan" problem is not consistent for me. One night I had it twenty times in a row on my Clara HD and Libra H2O with epubs, but never with a kepub. Whereas someone here has reported it happens with every kepub they sideload. I went to repeat the tests the next day as I thought of something to get more information, and it didn't happen at all on Libra H2O. I did exactly the same thing and didn't have any problems.

While I am seeing some of the issues being reported, I am just not seeing them as often as others are. The scan prompt is happening more often than with previous firmware, but, it isn't happening every time. I have had the issue with the reading status not updating once. But, I suspect that was because it was one of the few times where I sideloaded a book and started reading it immediately. I have had a couple of corrupt databases on my Libra H2O, though the second one was probably me making a mistake when restoring the backup.

All that means is that the cause is not clear. And when trying to debug it, you have to catch it a problem to see what is happening. If the problem doesn't happen consistently, you have to be lucky to catch it. And this has problems debugging it as it is related to what happens when you connect to a PC and at that time, WiFi is shutdown and hence you can't use telnet to debug.

I am WAY out of my depth here, but is it possible that sometimes a process is still running when the device is ejected? If so, would it be logical to suspect that a newly occurring error it is related to the newly added (note-taking) firmware?

The reason I left NOOK for Kobo was that the Glowlight 3 seemed to recopy all sideloaded books anytime I added even one new book. This was a SLOW process, and had the annoying side effect of removing the sideloaded books from any user created shelves on the device. My Windows 8 machine would display "safe to remove" message when that clearly was NOT true for the Glowlight3.

The point is, a note-taking device would have to update the notes on EVERY book, wouldn't it? The larger the library, the longer this would take. Might be interesting to see if the problems occur more often on bulkier libraries.

I found this article interesting:

https://www.hellotech.com/blog/reall...ect-usb-drives

Particularly this bit:

"However, even if the USB is not in active use, there is still a danger of corrupting the files. Most operating systems use a caching process. This means that the data is not written immediately onto the USB drive. Some of this information could still be stored on your computer’s RAM.

When you perform a copy command, the computer (depending on the operating system) might perform a series of requests. This can lengthen the process of transferring data from the computer to the USB. This is especially true when you are handling a large amount of data or files."

Suggests that the problem might depend on the operating system, no?

Well, this is just me being a layperson trying to learn about the topic. Am I barking up the right tree?

[compurandom]

Originally Posted by Calenorn

Well, this is just me being a layperson trying to learn about the topic. Am I barking up the right tree?

Probably not. You are implying an operating system bug that is not kobo related. While this is possible, it is not likely, and the discussion here is leaning towards this being a bug in the kobo not the PC operating system.

[davidfor]

Originally Posted by Calenorn

I am WAY out of my depth here, but is it possible that sometimes a process is still running when the device is ejected? If so, would it be logical to suspect that a newly occurring error it is related to the newly added (note-taking) firmware?

This is probably what is happening. But, it will be a process left running when the device is connected to the PC. That will probably keep the filesystem open, and Windows will detect this as dirty. And if the database is open, then it could result in a corrupt database.

A problem like this was actually fixed in firmware 4.30. There was an apparently long-standing issue with the comic reader on the device. This did not close properly and resulted in issues if you connected to the PC and something (calibre, the Kobo desktop, etc) the database. If you didn't read comics, you never saw it. This was fixed as soon as it was reported.

Something similar seems to be happening here. Especially as restarting the device seems to prevent the issues. That will close all processes and that should result in a clean file system. It seems to be something in the import process, but, proving that is difficult.

The reason I left NOOK for Kobo was that the Glowlight 3 seemed to recopy all sideloaded books anytime I added even one new book. This was a SLOW process, and had the annoying side effect of removing the sideloaded books from any user created shelves on the device. My Windows 8 machine would display "safe to remove" message when that clearly was NOT true for the Glowlight3.

The point is, a note-taking device would have to update the notes on EVERY book, wouldn't it? The larger the library, the longer this would take. Might be interesting to see if the problems occur more often on bulkier libraries.

The annotations on Kobo devices are handled in two ways. For annotations in PDFs made using the stylus, they are written to the file. And they are written when the books is closed. Other annotations are stored in the database. As far as I can tell, these are written to the database as they are made.

I found this article interesting:

https://www.hellotech.com/blog/reall...ect-usb-drives

Particularly this bit:

"However, even if the USB is not in active use, there is still a danger of corrupting the files. Most operating systems use a caching process. This means that the data is not written immediately onto the USB drive. Some of this information could still be stored on your computer’s RAM.

When you perform a copy command, the computer (depending on the operating system) might perform a series of requests. This can lengthen the process of transferring data from the computer to the USB. This is especially true when you are handling a large amount of data or files."

Suggests that the problem might depend on the operating system, no?

That is correct. If you unplug the device at the wrong time it can cause issues. But, the device is the one in control when plugging in to the PC. Seeing what is left open at that time is hard. It has to be done from the device, and that is a pain.

[Calenorn]

Originally Posted by compurandom

Probably not. You are implying an operating system bug that is not kobo related. While this is possible, it is not likely, and the discussion here is leaning towards this being a bug in the kobo not the PC operating system.

Or a Kobo bug that interacts differently with different operating systems?

[davidfor]

Originally Posted by Calenorn

Or a Kobo bug that interacts differently with different operating systems?

I don't think so. The reports of the scan prompt come from Windows users, but, that is because that is what Windows does. Linux is much less likely to report the filesystem as dirty. I don't know if Linux is less aggressive with this, or it does other checks, or not.

If the issue is causing a corrupt database, that will be detected on an OS when the database is accessed. Calibre will do that, or you can use an SQLite database management tool or command-line tools to check.

[ownedbycats]

Originally Posted by davidfor

I don't think so. The reports of the scan prompt come from Windows users, but, that is because that is what Windows does. Linux is much less likely to report the filesystem as dirty. I don't know if Linux is less aggressive with this, or it does other checks, or not.

There's this thread from a few years ago where a Linux user was having trouble with the Kobo always mounting as read-only because of a dirty filesystem.

[rashkae]

Originally Posted by davidfor

I don't think so. The reports of the scan prompt come from Windows users, but, that is because that is what Windows does. Linux is much less likely to report the filesystem as dirty. I don't know if Linux is less aggressive with this, or it does other checks, or not.

The Error message is in the dmesg log, but the desktops don't pop up any kind of warning.