Firmware3.17.0 Discussion

[akorx]

Originally Posted by akorx

Hi guys,

I've got a Glo model (not HD) and I would like to buy a Glo HD or an Aura HD but before I've got a question : on the Glo I've added a resistor of 20k to reduce brightness because at 1% it was too bright for me (see https://www.mobileread.com/forums/sho...=200706&page=7)... now I set it to 3% and all is ok (an d I use night mode v13 too).

Can you tell me if i will have to do the same on Glo HD (or Aura HD) or with those 2 models 0% is equal to "no light" ?

PS : sorry for my english...

And what about "Glo HD" model ?

[psom]

Updated to 3.17.0 from patched 3.16.0 on H2O w/out reset and all went smoothly save for one issue: though my shelves were untouched, my sideloaded epubs were removed from them. Kepubs remained on their assigned shelves. No problems with reboots here as I patched it right away; don't read many pdf''s anyway.

Is there a way to restore my books to their shelves w/out overwriting essential data?

[davidfor]

Originally Posted by arspr

Kobo DOES NOTHING to solve issues... They have clearly identified and reported two bugs with pdfs (in the performance thread) for ages. And, can you tell me what they've done? (Or are you going to tell me that they don't know about them?...)

The problem with fixing bugs in PDFs is that it probably isn't Kobo fixing them. They are probably in the RMSDK. That means that they have to wait for someone else to fix them. Then test and integrate the updated library.

Come on Davidfor, Kobo is one of the worst companies I've seen treating bugs.

(How long have you reported the wrong annotation list in epubs?)

(How long did they take in solving the BROKEN <img> support in ACCESS? How long did they take in more or less solving OBVIOUS navigation issues in pdfs?)

I can't really comment on this statement as I don't closely watch the bugs for any other companies. And I have no idea what their bug-fixing policies are. As you have state, they do fix bugs, just not as fast as you would like. And it is hard for me to get upset about this. Kobo have fixed a lot more bugs that I have reported than they have ignored.

[booklover6]

Originally Posted by arspr

[This copyrighted PDF has been deleted from Mobileread - MODERATOR]

So you are having problems with an illegal scanned PDF, and you are blaming Kobo? Have you gone through the PDF file line by line to see if there are any codes in there that could be screwing it up?

How about trying a legal, professionally done PDF and see if you have the same issues on your Kobo?

[Nick_1964]

Originally Posted by booklover6

So you are having problems with an illegal scanned PDF, and you are blaming Kobo? Have you gone through the PDF file line by line to see if there are any codes in there that could be screwing it up?

How about trying a legal, professionally done PDF and see if you have the same issues on your Kobo?

Stepping aside the problems with the PDF,be a bit "careful" about what you call "illegal scanned" PDF's.
In my country it is legal to scan a book as long as you destroy the book after that and don't spread the copy.
Illegal is, when you make a scanned copy,keep that and sell the book/give it away, then you reproducing it.
Making a copy of a buyed cd/dvd is legal,as long as it is for own use.
When you buy a phone,cd player,dvd player or even blancs, you pay a fee (copy fee) for it,even when you put only homemade pictures on it.
Every device that has something in it with store capacity,has got this fee.
Even when you never play a single mp3 from your phone,you have to pay it,it is included in the price, even in e-readers.
All that money is going to a foundation that spread it to artists,performers..name it.
So illegal is not always the case.
I was not intending to attack you, just inform you

[Ripplinger]

I'd have to agree that it's probably something messed up in the PDF you created. I took screenshots of a nicely illustrated purchased children's book that I also wanted available on my ereader (one of the purchased books I posted about on Page 10), the size is 86.5MB and it opens perfectly on my Kobo readers with 3.17.0 and I don't have the sickel patch installed. This PDF is all images, I can zoom in on every page, everything works as it should and never once times out (in fact it's pretty responsive, only taking 3 seconds to open up, page turns very fast as well).

And there's a larger purchased PDF heavy with images but mixed with text, 94.2MB in size, that also opens perfectly just as quickly, zero issues reading through the book.

So apparently it's not the size that's an issue, it must have something to do with how you created the PDF, maybe your images you started with, but something must be off. You can't blame Kobo, or any other ereader manufacturer, for that.

[booklover6]

Originally Posted by Nick_1964

Stepping aside the problems with the PDF,be a bit "careful" about what you call "illegal scanned"

I have no argument with you, Nick, but he himself said it was an illegally downloaded PDF.

[davidfor]

Originally Posted by GeoffR

I can still test it. Although I have patched sickel I can still tell when the original sickel would have rebooted by the amount of time the reading stats takes to open.

The time the reading stats tile takes to open after a device restart does seem to be related to the current read. I guess it doesn't keep the stats as running totals but has to trawl through the database to compute them from the individual reading session data for the book. So if you have a large book that has taken a long time to read (i.e. many sessions over many days) then it will take much longer to open the tile than for a book which hasn't had many reading sessions. So perhaps not directly related to the size of the epub itself, but to how complicated the reading history for that book is.

I guess some of the reading stats have to be computed when you open the book for the first time after a device restart too, so it can compute and display the time to finish.

The book was this one, it has the problem where the publisher has put more than one chapter in a file, and it has an incomplete TOC so the KePub synced from Kobo has some automatically-generated TOC entries titled "Untitled chapter". Unfortunately that is not altogether uncommon for backlist books. Stats say it took me 31.1 hours to read at an average 42 minutes per session, but I took a break and read another book part way through so it was spread out over a week, and I might have opened the book a few times back around the time I bought it which was a few months (and firmware versions) ago.

Edit: Another factor is probably that I keep all the books I have finished on the device, and it has been a long time since I did a factory reset, so to compute the stats for total hours read is always going to be slow the first time if no running total is kept. Even with a newly opened book as current read, the stats tile takes a long time to open the first time after the device starts.

My database probably has a fair bit of cruft, but this is just a consequence of the hardware and firmware being so solid and reliable, I've never had a corrupt database and so never needed to do a factory reset (although I did do one by accident last year sometime.)

That's all pretty much what I thought. A big book with lots of ToC entries and a "mature" database.

For the stats, I don't know if they store the totals. For each book you read, there are multiple rows in the Events table. Two of these are about opening and closing the book. There is a counter for the number of times an a blob that seems to record a timestamp each time this happens. I assume the time for the book is calculated from the difference of the pairs of these in each row.

Hopefully there is a separate counter for total hours read. The above is probably OK for the time for a book, but for the total time, it would be take a fair bit of time once you have read a few hundred books. But calculating it once when the device starts might be how they do it. And that could explain a restart if the calculation hasn't finished when the stats is opened.

Unfortunately, I can't think of a good way to reproduce this. It needs a database like yours. I've done a factory reset on each of mine recently while fiddling around. The last time I tried creating rows in the Events table it didn't work. This is probably a place where the only choice is to increase the sickel timeout, or for the nickel to turn this off for a little bit.

[fxp33]

@DavidFor

Thank you very much for the image. Worked a treat!

It was my first time ever with the "fatal error screen" and the tantalizing interrogation: do you want to erase all or come again to this question?

And after a few loop reboot, nothing anymore.

By the way, it is a lot harder to open an Aura than a Glo!!

@frostschutz

Thanks for the hack, hope it avoids more reboots... enough for today...

Cheers

François

[JSWolf]

Originally Posted by davidfor

That's all pretty much what I thought. A big book with lots of ToC entries and a "mature" database.

The ToC in Judas Unchained only has 27 ToC entries in the NCX? If you want a book that has a LOT of ToC entries, pick up a James Patterson book. You can get over 100 ToC entries.

[Nick Payne]

Well, on one of our Aura HD it is impossible to patch 3.17 to make it usable, as the device continually reboots within a few seconds of the home page appearing after it is started up - too quickly to manage to insert a USB cable and tap the "Connect" button. If I boot it up with the cable already connected, the "Connect" button appears, but the device appears already frozen as there is no response to tapping on it, and the device reboots again within a few seconds. I've twice performed a factory reset, then used Kobo Desktop to install 3.15, then put the 3.17 files in /.kobo to upgrade, with the same problem each time.

Used the same procedure to upgrade the other Aura HD in the house to 3.17 without any problem, and have had no problems using that reader since the upgrade.

[GeoffR]

My Glo with 3.17.0 is showing the wrong percentage remaining on the sleep screen. It happens with sideloaded ePubs and Kobo-synced KePubs.

The percentage shown on the sleep screen seems to be the position at which the device was last woken from sleep, not the position it was at when put to sleep.

E.g. If I wake the device when the book is 10% read, then read until the book progress shows 20% and put the device to sleep, then the sleep screen shows 10% instead of 20%. If I wake it again and advance to 25%, the sleep screen then shows 20% when I put it to sleep again.

[davidfor]

Originally Posted by GeoffR

My Glo with 3.17.0 is showing the wrong percentage remaining on the sleep screen. It happens with sideloaded ePubs and Kobo-synced KePubs.

The percentage shown on the sleep screen seems to be the position at which the device was last woken from sleep, not the position it was at when put to sleep.

E.g. If I wake the device when the book is 10% read, then read until the book progress shows 20% and put the device to sleep, then the sleep screen shows 10% instead of 20%. If I wake it again and advance to 25%, the sleep screen then shows 20% when I put it to sleep again.

I can see that to. If I return to the home screen before sleeping, it has the right percentage. My guess would be that the sleep screen is reading the percent read from the database before it is updated.

I'll report it on the beta list.

[anacreon]

I read only kepubs, and I always set the reading parameters for pages per chapter. For the last 2 or 3 F/W, this occasionally switches over to % per chapter, and I have to go to the parameters to reset it. Anybody else has seen this?

[GeoffR]

Originally Posted by anacreon

I read only kepubs, and I always set the reading parameters for pages per chapter. For the last 2 or 3 F/W, this occasionally switches over to % per chapter, and I have to go to the parameters to reset it. Anybody else has seen this?

If you long-press the footer where the page number is while reading, the footer will cycle through the different reading progress options. Could it be you did that by accident?