Kobo Bug thread

[User_Name]

Originally Posted by PeterT

Glo / 3.12.1 reproduces this.

Stack dump saved and forwarded to Kobo.

Thank you!
So it's not just me.
(I assume that the post is about the bug with wiki menu button freezing Kobo ;-) )

May I know how you produce stack dumps? Do you just

cat /proc/`pgrep nickel`/stack

, or is there a better way for this? For me, nickel was still running, so it didn't dump core or even looked abnormal in console.

[PeterT]

When the device reboots quite often a stackdump will be created in the .kobo directory (/mnt/onboard/.kobo)

[User_Name]

Originally Posted by PeterT

When the device reboots quite often a stackdump will be created in the .kobo directory (/mnt/onboard/.kobo)

Wow, that's been a fast answer!
And you're right, now as I looked there, extra files stack_0?.log have shown up.
To be honest, I've been expecting some sophisticated method of forcing a core dump of a running process ;-)

[mathil]

There is a minor translation bug with the latest firmware 3.12.1. When trying to access the annotations while reading an ebook, the menu entry called 'Annotations' remains in English no matter what language the system locale is set to.
I checked on a Kobo Glo, Aura and on my H2O and the problem is present in all of them. The only file types I tested are .kepub (both sideloaded and downloaded from Kobobooks) and .cbz.

EDIT: I noticed that 'Books' and 'Table of Contents' from the navigation menu inside ebooks remain in English as well.

[hannah]

Originally Posted by mathil

There is a minor translation bug with the latest firmware 3.12.1. When trying to access the annotations while reading an ebook, the menu entry called 'Annotations' remains in English no matter what language the system locale is set to.
I checked on a Kobo Glo, Aura and on my H2O and the problem is present in all of them. The only file types I tested are .kepub (both sideloaded and downloaded from Kobobooks) and .cbz.

EDIT: I noticed that 'Books' and 'Table of Contents' from the navigation menu inside ebooks remain in English as well.

I just updated and have the same bug on my H2O with sideloaded epub books, it wasn't the case in 3.12.0

[PeterT]

Kobo know about this.

[fdant]

When the text is justified I can't view the dictionary description for the final word at the end of each line. If I set the alignment to left it will display correctly.

I didn't notice before and I'm constantly using the dictionary, so I think this is a bug from the last update.


EDIT: I've found out that the source of the problem is the fullscreen mode. Removing "FullScreenReading=true" from the .config file solved the problem.

[jbennion]

So I am having this problem with reading books on my Kobo that I have converted from Kindle (.mobi or .azw3). In some of the books the last page of the chapter will not render. I am not sure if this is a bug in the Calibre conversion from AZW to KEPUB format, or some rendering bug in the Kobo firmware, but it's pretty frustrating... I can provide a sample book that has the problem in both formats (without DRM) to reproduce the problem...

[PeterT]

@jbennon: what version of f/w? What Kobo device? Any patches installed (or mods to the configuration file)?

[jbennion]

I have firmware 3.12.1, but it has happened in prior versions of the firmware too. I don't have any patches or mods installed.

[arspr]

I can test if you want. Even if it's DRM free, check that it's a free book before publicly posting it. If you have doubts PM it (or a link to google drive or whatever) with a clear reference where you get the issue.

I suppose you are using plain epubs not kepubs? (If you don't know what I asking you then you are using epubs)

EDITED....

Oooops. I am not a good tester as I'm on FW 3.13.1....

[arspr]

@jbennion, I think the problem with your book is in its linked but not present fonts.

I do not get exactly your troubles, but "random" FUBAR rendering. I mean, sometimes when you load a chapter it blinks several times and you can see how its rendering is fully wrong (half lines at the beginning or ending of the pages) and also of course missing text at the end of the chapter.

As I've said it does not *always* happen, but I think I've always got it when:

• I've gone backwards to the previous chapter through page turn.
• I've jumped to a new chapter using ToC instead of the >> arrows.

But as I've said I think the problem is in missing fonts. Your book has a page_styles.css which sets:

@page {
    margin-bottom: 5pt;
    margin-top: 5pt
    }
@font-face {
    font-family: "Caecilia";
    font-weight: normal;
    font-style: normal;
    src: url(res:///Data/fonts/Caecilia-Roman.otf)
    }
@font-face {
    font-family: "Caecilia";
    font-weight: bold;
    font-style: normal;
    src: url(res:///Data/fonts/Caecilia-Heavy.otf)
    }
@font-face {
    font-family: "Caecilia";
    font-weight: normal;
    font-style: italic;
    src: url(res:///Data/fonts/Caecilia-Italic.otf)
    }
@font-face {
    font-family: "Caecilia";
    font-weight: bold;
    font-style: italic;
    src: url(res:///Data/fonts/Caecilia-HeavyItalic.otf)
    }

But those Caecilia...otf files are not present in your book (and those paths are reaaally strange).

That font family is used EVERYWHERE as it is used in the "calibre_" class and you always have a <body class="calibre_"> in your html files.

The solution is really easy. Just edit the book and comment out (or delete) those lines. I mean leave just the initial @page{...} or if you want to keep them for tracing purposes put /* and */ enclosing the conflictive lines:

@page {
    margin-bottom: 5pt;
    margin-top: 5pt
    }
/*
@font-face {
    font-family: "Caecilia";
    font-weight: normal;
    font-style: normal;
    src: url(res:///Data/fonts/Caecilia-Roman.otf)
    }
@font-face {
    font-family: "Caecilia";
    font-weight: bold;
    font-style: normal;
    src: url(res:///Data/fonts/Caecilia-Heavy.otf)
    }
@font-face {
    font-family: "Caecilia";
    font-weight: normal;
    font-style: italic;
    src: url(res:///Data/fonts/Caecilia-Italic.otf)
    }
@font-face {
    font-family: "Caecilia";
    font-weight: bold;
    font-style: italic;
    src: url(res:///Data/fonts/Caecilia-HeavyItalic.otf)
    }
*/

I've done it and my rendering troubles have completely disappeared.

Nevertheless I'm going to post a comment in the Calibre > Editor section of these forums in case there were a bug in Calibre. I mean, AFAIK page_styles.css is created by Calibre itself during the conversion if some settings (as page margin ones) are used. I think it is strange that Calibre creates the link to font files but not includes them in the book. In addition those urls are really strange also.

How have you converted the ebook? Have you deleted those font files? Have you manually edited that css file?

[davidfor]

Another reason for text missing at the end of a chapter is unbalanced tags. I discovered this while reading a book where a chapter finished with the lyrics of a song. The next chapter start logically from that (he'd won the girl over with the song and the next chapter was the next morning). But, a few pages in something was mentioned that happened after the song and before waking that was important. When I opened the book in the calibre viewer, there was a lot of action after the song.

Looking at the code for the song it was something like:

<blockquote>
<p><i>Line one of yet another love song</p>
<p>Line two of yet another love song</i></p>
</blockquote>

The calibre viewer handled this OK, but the firmware stopped at the end of the song.

I wouldn't expect code like this to be generated by a calibre conversion, but there might be a bug.

[arspr]

Originally Posted by davidfor

Another reason for text missing at the end of a chapter is unbalanced tags. I discovered this while reading a book where a chapter finished with the lyrics of a song. The next chapter start logically from that (he'd won the girl over with the song and the next chapter was the next morning). But, a few pages in something was mentioned that happened after the song and before waking that was important. When I opened the book in the calibre viewer, there was a lot of action after the song.

Looking at the code for the song it was something like:

<blockquote>
<p><i>Line one of yet another love song</p>
<p>Line two of yet another love song</i></p>
</blockquote>

The calibre viewer handled this OK, but the firmware stopped at the end of the song.

I wouldn't expect code like this to be generated by a calibre conversion, but there might be a bug.

Yes, I really expect Kobo renderers not being really robust about bad code...

But there's a little BIG difference between a renderer failing with bad code (yes, it would be nice that the software were more robust but, in fact, I cannot blame Kobo if they don't do it) and a renderer failing with just unreferenced fonts (which is not bad code in any way; maybe in some systems those paths have full meanings as it's said in this thread in the Calibre > Editor subforum by jackie_w).

I do think Kobo has a serious bug here.

Nevertheless I've uploaded several pictures in that thread about jbennion's book.

[Rev. Bob]

I've mentioned this one before, but it's worth mentioning again. Any time the the font size changes, whether by keyword (x-small, bigger, etc.), by relative measure (1.2em, 20px), or simply by tag (h1, sub, sup), the firmware needs to recalculate the line-height. It does not do so at present, at least with sideloaded books.

My current workaround is to put line-height: normal; into the book's stylesheet for every such class, but that shouldn't be necessary in the majority of cases.