[Device Plugin] Kobo Touch Extended Driver

[arspr]

Originally Posted by davidfor

Oh, you were talking about the order of the pages, not the actual page number. The "page number" you were referring to was hardcoded text. When I open it with the calibre viewer I get:

- cubierta.xhtml -- 1/8
- sinopsis.xhtml -- 2/8
- titulo.xhtml -- 3/8
- info.xhtml -- 4/8
- Prologo.xhtml -- 5/8
- dedicatoria.xhtml -- 6/8
- Section0001.xhtml -- 7/8
- autor.xhtml -- 8/8

Because I was testing something else related to sending kepubs, I initially did a conversion to kepub and then sent it to my Glo. Paging through it I saw the same page sequence as above.

Then I deleted the kepub version from the Glo and calibre and enabled the extended driver. Exactly the same results as with the converted version and using the calibre viewer.

But, the numbers on the page do not agree with our original post. The file names do but not the numbers. Did you post the correct version of the epub? Or have I missed something?

Strange, because what you are actually saying is that you cannot replicate the issue. So either it's device dependant, (Glos are unaffected but Auras HD are) or something is wrong with my device.

I've retested following the next sequence:

1. I've delete the test ebook from my AuraHD and from my Calibre library.
2. I've downloaded the epub I previously uploaded and I've added it to Calibre. (No possible error about different versions of the test book).
3. With your Kobo Utils plugin I've performed a check on the Aura HD database. It's OK.
4. Using Calibre I've sent the ebook as epub to Aura HD. (I've disabled "Enable Extended Kobo Features" option in KoboTouchExtended driver).
5. Picture taken from the fourth page (info.xhtml) in RMSDK viewer. All is fine.
6. I've deleted the ebook within Aura HD.
7. I've re-sent the same test ebook but as kepub ("Enable Extended Kobo Features" on).
8. The bug is present. Picture taken from the same page.

What else can I check?

[davidfor]

Weird. There should be no difference between the devices for this. The database is common and I'd be stunned if the code for loading the books and displaying them isn't as well. Get the generated kepub from the device and post that. Then we can see how it is different.

[jgoguen]

Are you using full-book page numbers in the driver options? Can you post both your original ePub and the generated KePub?

unaj41, if you have the extended driver enabled you are working with side loaded KePub files. If you refer to side loaded ePub files, that implies either the extended driver is disabled or manually copying ePub files that haven't been converted to KePub. It's just a terminology thing so we all know what's going on.

[AJvK]

Latest version fails install - 1.5.0 installed, 2.2.13 available. Calibre is updated to 1.11.0.

Error message: calibre, version 1.11.0
ERROR: Install Plugin Failed: A problem occurred while installing this plugin. This plugin will now be uninstalled. Please post the error message in details below into the forum thread for this plugin and restart Calibre.

Traceback (most recent call last):
File "site-packages/calibre/gui2/dialogs/plugin_updater.py", line 685, in _install_clicked
File "site-packages/calibre/customize/ui.py", line 375, in add_plugin
File "site-packages/calibre/customize/ui.py", line 53, in load_plugin
File "site-packages/calibre/customize/zipplugin.py", line 191, in load
File "site-packages/calibre/customize/zipplugin.py", line 175, in load_module
File "calibre_plugins.kobotouch_extended.__init__", line 7, in <module>
ImportError: cannot import name KOBOTOUCHEXTENDED

Any advice?

[jgoguen]

Two pieces of advice actually

1. Remove the plugin, restart calibre, install the plugin, and restart calibre again
2. Update both calibre and this plugin much more frequently

The first is what you have to do because you left old versions installed for so long. The second is how you prevent this from happening again.

[arspr]

Originally Posted by davidfor

Weird. There should be no difference between the devices for this. The database is common and I'd be stunned if the code for loading the books and displaying them isn't as well. Get the generated kepub from the device and post that. Then we can see how it is different.

Originally Posted by jgoguen

Are you using full-book page numbers in the driver options? Can you post both your original ePub and the generated KePub?

I upload the kepub from the device.

And yes, I'm using full-book page numbers. Nevertheless in my first post about this issue I uploaded a screenshot with all the driver settings I use.

[jgoguen]

This is nothing to do with the driver. I took your source ePub file, renamed it to have the ".kepub.epub" extension, copied it to the device, and the same bug occurred. There's surely a reason for it, but it may take some digging to find out why.

It's clear why info.xhtml is the fourth in order - it's the fourth in the book's spine ToC. But I can't see why the page numbering in full-book mode goes 1, 2, 3, 6, 7, 8, 4, 5. But I can tell you it isn't something to do with this driver, rather some bug (or something we don't understand) with the way the ACCESS reader is used.

[arspr]

Originally Posted by jgoguen

This is nothing to do with the driver. I took your source ePub file, renamed it to have the ".kepub.epub" extension, copied it to the device, and the same bug occurred. There's surely a reason for it, but it may take some digging to find out why.

It's clear why info.xhtml is the fourth in order - it's the fourth in the book's spine ToC. But I can't see why the page numbering in full-book mode goes 1, 2, 3, 6, 7, 8, 4, 5. But I can tell you it isn't something to do with this driver, rather some bug (or something we don't understand) with the way the ACCESS reader is used.

But at least you can replicate the issue, can't you?

I was starting to get VERY nervous as davidfor didn't seem to be able to get it in his Glo...

[PeterT]

Is that actually a valid book? I thought the <head> section in toc.ncx had certain required info http://www.niso.org/workrooms/daisy/...-2005.html#toc

Two metadata items must be present in the <head> of compliant textual content files, contained in a <meta> element: dtb:uid and dc:Title. dtb:uid is the globally unique identifier for the DTB. The value is the same as that of the dc:Identifier element referenced by the package file's unique-identifier element. See section 3.1, "Package Identity. dc:Title contains the title of the DTB. Inclusion of the full range of applicable Dublin Core elements is recommended, to make a DTBook document more useful as stand-alone content.

[davidfor]

Originally Posted by arspr

But at least you can replicate the issue, can't you?

I was starting to get VERY nervous as davidfor didn't seem to be able to get it in his Glo...

I've replicated it now. I missed the need for the full book page numbering.

But, I think PeterT has it. When I open either the epub or kepub version in Sigil and check for errors, I get one error. The message is "empty content is not valid for content model '(meta+)'". Try doing a epub-to-epub conversion in calibre and then resend it using the extended driver. That conversion should probably fix the error in the book and the device should handle it properly.

[arspr]

I think that that's not the issue. My original ebook with the bug has those fields on it, but I deleted them in my stripping down process.

Nevertheless, I'll make a copy of those data back to the test book and I will post the updated file ASAP. (And I will also try making the epub-to-epub conversion).

[iGeorg]

Hello, thank you for your effort of further developing this great Kobo-plug in!
I just upgraded my KoboAuraHD to the newest Firmware 2.10.0 and calibre to 1.3.0

While reading a ebub to kepub converted book now, the reading stats menu is not shown anymore. I see the icon in the help section of my kobo, but not when i touch the chapter number, like it used to.

Were can the reading stats now be found?
Is this a bug in the kobo firmware, the KoboTouch 2.1.5 plug-in or calibre?

Thanks for your help!

[Leonatus]

A tiny little question concerning the hyphenation function of the plugin:

I come from reading in an older Kobo thread that after installing the KoboRoot.tgz with the hyphenation dictionary, processing it by the reader and rebooting the device this file will disappear, the device having extracted the hyphenation dictionary. Is this correct?

If so, it would explain hours of (alleged) unsuccessful Saturday evening and Sunday morning trials to "update" the hyphenation function that I spent with always creating and installing the KoboRoot.tgz from scratch after verifying that after rebooting the file had vanished.

Is there a way to control if the dictionary has been successfully extracted (I'm Windows user)?

Thanks a lot!

[jgoguen]

Originally Posted by iGeorg

Hello, thank you for your effort of further developing this great Kobo-plug in!
I just upgraded my KoboAuraHD to the newest Firmware 2.10.0 and calibre to 1.3.0

While reading a ebub to kepub converted book now, the reading stats menu is not shown anymore. I see the icon in the help section of my kobo, but not when i touch the chapter number, like it used to.

Were can the reading stats now be found?
Is this a bug in the kobo firmware, the KoboTouch 2.1.5 plug-in or calibre?

Thanks for your help!

First, this has been discussed at great length in this and many other threads. Kobo has removed reading stats for side-loaded KePub books.

Second, for my own curiosity, why do you still have such old versions if calibre and the extended driver installed? Why not upgrade to the current versions?

Originally Posted by Leonatus

I come from reading in an older Kobo thread that after installing the KoboRoot.tgz with the hyphenation dictionary, processing it by the reader and rebooting the device this file will disappear, the device having extracted the hyphenation dictionary. Is this correct?

The KoboRoot.tgz file is automatically removed from the device as part of the device's extraction process.

Originally Posted by Leonatus

Is there a way to control if the dictionary has been successfully extracted (I'm Windows user)?

Not really. Use 7-Zip for all of your archive viewing, extraction, and creation - that's probably your best chance. And when you view files, use an editor that's aware of UNIX line endings, like Notepad++.

[Leonatus]

Originally Posted by jgoguen

The KoboRoot.tgz file is automatically removed from the device as part of the device's extraction process.

Not really. Use 7-Zip for all of your archive viewing, extraction, and creation - that's probably your best chance. And when you view files, use an editor that's aware of UNIX line endings, like Notepad++.

But the hyphenation dictionary is not stored in the dict folder, obviously?
The search function in Notepad++ didn't show the dictionary at all.

Only for understanding: Does the device recognize the the <language> attribute of a text and apply the respective hyphenation dictionary? (For I'm not only reading german books).

Thanks for the great job anyway!