[Device Plugin] Kobo Touch Extended Driver

[Dfaure]

Hi,

Could someone confirm that the KoboTouchExtended is the only Kobo related plugin affected by the reported bug?

I was wondering if this apply to the KePub dedicated ones since they got the same release number...

[DNSB]

Originally Posted by Dfaure

Hi,

Could someone confirm that the KoboTouchExtended is the only Kobo related plugin affected by the reported bug?

I was wondering if this apply to the KePub dedicated ones since they got the same release number...

Which reported bug? The replacement of <br />many bits of text</p> with <br /></p>many bits of text<p></p>? According to message #2106 in this thread, the output plugins would suffer from the same bug. Or the bug involving UTF-8 which should be fixed for all the Kepub plugins?

[davidfor]

Originally Posted by Dfaure

Could someone confirm that the KoboTouchExtended is the only Kobo related plugin affected by the reported bug?

I was wondering if this apply to the KePub dedicated ones since they got the same release number...

There is shared code between the extended driver and the kepub related plugins. Errors in one might appear in the others.

But, in this case, I'm pretty sure that the problem is that you are running this under Python 3.8. The error is in one one the recent changes in the plugin to use a calibre supplied function. That is probably failing as the Python 3 version of calibre is still a work in progress. And it probably means the other plugins will fail in the same way.

A basic rule for calibre is don't use the distro version. They can work, but, eventually a problem comes up. Like this.

[madhatta]

Originally Posted by davidfor

But, in this case, I'm pretty sure that the problem is that you are running this under Python 3.8. The error is in one one the recent changes in the plugin to use a calibre supplied function. That is probably failing as the Python 3 version of calibre is still a work in progress. And it probably means the other plugins will fail in the same way.

It's interesting you say that, since I've just had to jump through the same hoop in exactly the opposite direction to get Obok working on the same system. Over in this GitHub issue you will see that the developers found the problem was that the plugin was not Python3-compatible when it needed to be, rather than vice-versa.

Nevertheless, if you hold that the issue is only resolvable by upgrading to the non-distro version of calibre, then I shall regretfully have to abandon the use of KoboTouchExtended at this time. I'll try to keep an eye out on this thread, and look forward to resuming the use of this excellent plugin at such a time as RedHat's provided python and upstream's python expectations come back into line.

Thanks for your time.

[davidfor]

Originally Posted by madhatta

It's interesting you say that, since I've just had to jump through the same hoop in exactly the opposite direction to get Obok working on the same system. Over in this GitHub issue you will see that the developers found the problem was that the plugin was not Python3-compatible when it needed to be, rather than vice-versa.

Nevertheless, if you hold that the issue is only resolvable by upgrading to the non-distro version of calibre, then I shall regretfully have to abandon the use of KoboTouchExtended at this time. I'll try to keep an eye out on this thread, and look forward to resuming the use of this excellent plugin at such a time as RedHat's provided python and upstream's python expectations come back into line.

You misunderstand. The distro versions of calibre have problems. The distro maintainers change things. Or they package wrong versions of libraries. In this case, you are attempting to run a version of calibre that is not fully compatible with Python 3. It is intended to be used with Python 2.7. Kovid has been moving towards Python 3 for nearly a year, but, it is not complete. And potentially won't be until version 5 is released.

The version of the plugin I posted should compatible with Python 3 versions of calibre. Or at least the beta builds that Kovid has produced. I was swapping between the release and the beta when I was doing the testing. But, I have only tested on Windows 10 with the 64bit version. But, I won't be at all surprised if we have still missed something.

The problem with Obok was due to all this. It was a plugin that wasn't completely converted to Python 3 running in a version of calibre built for Python 2.7 but running in Python 3. With that combination, are you sure surprised that it didn't work?

[pad01]

Hi there, I seem to have a strange problem and I'm not quite sure if I just have some miss-configuration on my end:

When using the default KoboTouch driver (With my Libre) to copy over ePubs, no series are displayed on my Kobo, but collections are created.

When using KoboTouchExtended to copy over KePubs, I have the same behaviour, BUT: If there are already some ePubs on my Kobo that originated from the default KoboTouch driver, and I just use KoboTouchExtended to rewrite metadata, the suddenly I get perfectly nice series information on by Kobo! And it works flawlessly, the correct sort order is applied and everything. BUT: This applies only to the existing ePubs. All KePubs don't get series information.

So this is a strange situation, I would absolutely love to have correct series to show up, but currently for that I would have to:

Use KoboTouch to copy all ePubs over, switch to KoboTouchExtented to rewrite Metadata, don't use any KePubs.

Is this a known Problem? Is there a way to get series working for KePubs?

Thanks.

[DNSB]

Originally Posted by pad01

So this is a strange situation, I would absolutely love to have correct series to show up, but currently for that I would have to:

Use KoboTouch to copy all ePubs over, switch to KoboTouchExtented to rewrite Metadata, don't use any KePubs.

Is this a known Problem? Is there a way to get series working for KePubs?

Thanks.

Series should work using either driver. Two caveats are in calibre's preferences/Sending books to device, make sure the Metadata management is set to Automatic management and that you need to connect twice (the first time you send the books, safely eject and let your Kobo import them, the second connect now has database entries to update). Otherwise, check the 3rd configuration tab (Metadata, on device and advanced) for both the KT and KTE drivers and make sure they are set the same. I've attached an image of what mine looks like -- basically, the Set series information checkbox needs to be checked. You can disregard the Advanced options, that setting is just handy when Kobo updates and the calibre driver has not been updated.

[madhatta]

Originally Posted by davidfor

You misunderstand. The distro versions of calibre have problems. The distro maintainers change things. Or they package wrong versions of libraries. In this case, you are attempting to run a version of calibre that is not fully compatible with Python 3. It is intended to be used with Python 2.7. Kovid has been moving towards Python 3 for nearly a year, but, it is not complete. And potentially won't be until version 5 is released.

The version of the plugin I posted should compatible with Python 3 versions of calibre. Or at least the beta builds that Kovid has produced. I was swapping between the release and the beta when I was doing the testing. But, I have only tested on Windows 10 with the 64bit version. But, I won't be at all surprised if we have still missed something.

The problem with Obok was due to all this. It was a plugin that wasn't completely converted to Python 3 running in a version of calibre built for Python 2.7 but running in Python 3.

Everything you say makes sense, and thanks for writing it - and for the other work on this plugin, which you do out of the goodness of your heart. I quite acknowledge that you owe nobody anything in respect of it.

Nevertheless, an unwillingness to support your plugin in the context of calibre as it is used by many people will simply mean that less people can use your plugin, which is a shame. That doesn't place any obligation on you: as I say, you're doing this out of the goodness of your heart, and how you do it is entirely up to you. I'm just letting you know that when you make people choose between running your (excellent) plugin, and running the distro version of calibre, some will for very good reasons choose to stick with the distro version of calibre.

With that combination, are you sure surprised that it didn't work?

Surprised? No; it's free software, I expect it to break. But apparently the developers didn't think that the desire to have it work on my system was an unreasonable one.

[DNSB]

Originally Posted by madhatta

Nevertheless, an unwillingness to support your plugin in the context of calibre as it is used by many people will simply mean that less people can use your plugin, which is a shame. That doesn't place any obligation on you: as I say, you're doing this out of the goodness of your heart, and how you do it is entirely up to you. I'm just letting you know that when you make people choose between running your (excellent) plugin, and running the distro version of calibre, some will for very good reasons choose to stick with the distro version of calibre.

If you were running calibre in a supported configuration, your complaint might be valid. As it is, running a version of calibre designed for Python2 under Python3 is not a supported configuration. I'd suggest addressing your complaints to the producers of your distro.

I can't see any reason for preferring the distro version over the version available from the calibre site never mind "very good reasons". Admittedly, that may be influenced by one distro I run which still shows calibre 3.3 as their preferred version.

[NiLuJe]

For a bit of context, almost *every* distro has been packaging calibre in a subtly to overtly broken way (and usually also based on an hilariously outdated version, as @DNSB just showed), which is why it's *always* been considered an unsupported configuration. Might work well enough, or it might not. In any case, as soon as you start asking for support, the first answer will *always* be: come back after trying the actually supported setup (i.e., the upstream binary install).

The Python 2 EoL just made everything "worse" in that respect, but it's not a new thing.

If you want your distro's package to behave properly (or at least better), complain to its package maintainer. And point him/her to the Arch package, which is the gold standard for a downstream calibre package.

(Which won't change the fact that running Calibre under Python 3 is currently still considered experimental).

[davidfor]

Originally Posted by madhatta

Everything you say makes sense, and thanks for writing it - and for the other work on this plugin, which you do out of the goodness of your heart. I quite acknowledge that you owe nobody anything in respect of it.

Nevertheless, an unwillingness to support your plugin in the context of calibre as it is used by many people will simply mean that less people can use your plugin, which is a shame. That doesn't place any obligation on you: as I say, you're doing this out of the goodness of your heart, and how you do it is entirely up to you. I'm just letting you know that when you make people choose between running your (excellent) plugin, and running the distro version of calibre, some will for very good reasons choose to stick with the distro version of calibre.



Surprised? No; it's free software, I expect it to break. But apparently the developers didn't think that the desire to have it work on my system was an unreasonable one.

I honestly don't know how to respond to that. Apart from stating how insulting it is. And how contradictory it is.

But, lets try...

Firstly, it is completely and utterly impossible to support the plugin, or anything for that matter, running in absolutely all platform combinations. No one has the capability do that. We can only do my best. And for me, the best I can do is to support the official release of calibre. Especially on platforms that I personally don't use. I don't not support other combinations, but, I know I won't always be able to.

In this case, how do we fix it?

The error that you are seeing is not in the plugin code. It is in calibre code that the plugin is calling. And is actually failing in a call to Python.

We can change the code in the plugin to do this in another way. That means we have to test it on all platforms to make sure it works. It also means we have more code to maintain and test. It also means we wouldn't be doing this in the way that the main developer of calibre is recommending.

We could also fix it in calibre. That means that you would only get the fix when the distro maintainers decide to update calibre to the version that has the fixed in it. Or, you would have to install the official release version rather than the distro version.

And that would put us back where we started. The recommendation to not use the distro version so that the application actually works.

[Dfaure]

Please, could you give us hints on the availability of a "stable" 3.2.8+ release, at least for the platforms where the distro hell doesn't apply, for all the concerned plugins?

[davidfor]

Originally Posted by Dfaure

Please, could you give us hints on the availability of a "stable" 3.2.8+ release, at least for the platforms where the distro hell doesn't apply, for all the concerned plugins?

Use the beta I posted above. It should work anywhere that a official calibre release is being used. Or the calibre Python 3 beta's are being used. And if it doesn't work, we need to know so we can fix it.

[giddie]

For Linux users: I guess I'm fortunate in that I use Arch, and I've never had any problems with Calibre. But for those that do:

Can I suggest you try the Flatpak package for Calibre:
https://flathub.org/apps/details/com..._ebook.calibre

Flatpak is supported on every Linux distro, and it does a good job of bundling the application with everything it needs to function correctly, regardless of the system it's running on.

[JSWolf]

Originally Posted by giddie

For Linux users: I guess I'm fortunate in that I use Arch, and I've never had any problems with Calibre. But for those that do:

Can I suggest you try the Flatpak package for Calibre:
https://flathub.org/apps/details/com..._ebook.calibre

Flatpak is supported on every Linux distro, and it does a good job of bundling the application with everything it needs to function correctly, regardless of the system it's running on.

Why not just get Calibre from the Calibre website?