Beta testers for calibre 3.0 needed

[gbm]

Originally Posted by kovidgoyal

@gbm: Doesn't happen on my linux Firefox. When the relaod question popup appears, I can still open pother tabs in firefox and interact with them.

As far as I can tell, if it does happen, it's a bug in firefox. The updated notification is created using the standard window.confirm() javascript API.

Most likely, you still have a single process firefox on your system so the dialog is application modal -- it will be fine when you update to multiprocess firefox.

I had an extension that was not compatible with multiprocess, disabled that extension and it now works. Also found webgl2 Renderer was not loading so disabled that also.

bernie

P.S.
This Firefox extension checks for multiprocess compatibility.

https://addons.mozilla.org/en-US/fir...orter/?src=api

[kovidgoyal]

Released 2.99.10 with the following changes:

1. Fix error handling for various IndexedDB (the database used in the browser) related error conditions is present at all
2. Fix an error rendering books with svg images
3. Fix error caused by refactoring of advanced search dialog code

Hopefully, this will be the last beta release. The only outstanding issues I am aware of are: downloads not working on the Kobo browser, and JSWolf's last column being occasionally skipped issue.

[Martina Schein]

Wow. You work with speed of light, is not it Kovid.
Several providers of paid software should take an example.

Thank you for your commitment to Calibre. I love this program since I started working on it a couple of years ago.

[kovidgoyal]

You are welcome

[JimmXinu]

I've been successfully using the beta version (running from source usually) for a week or so. It's looking really good.

There are a few cosmetic differences in the GUI, but the only substantial change I've noticed is that 'sending metadata to device' (ie, writing the metadata file) is hugely faster. Thanks for that.

In the new Content Server a couple nitpicks I've noticed:

• content_server_will_display and content_server_wont_display tweaks don't work. Tweaks specific to older versions could be removed, hidden or documented as older-version-only perhaps?
• 'Comma' formatting on custom Integer('{:,}') and Float('{0:,.3f}') columns isn't being applied. (1234 vs 1,234 and 1234.11 vs 1,234.11) Float decimal format ('{0:,.3f}' vs '{0:,.2f}') is applied. I assume comma grouping is a calibre extension to Python's formatting?

FYI, the links you gave in first post to github are broken with removal of branch v2015. v2015->master gives usable links:

https://github.com/kovidgoyal/calibr...e/srv/TODO.rst
https://github.com/kovidgoyal/calibr.../custom.py#L99

I'm looking at the source for the server and the calibredb client. I'll need a while before I'm familiar enough to offer any useful comment myself, but do you have any plans or ideas for content server plugins, or integrations so GUI plugins could be called from content server or calibredb?

Semi-related, are DB updates transacted now such that plugins could skip using proceed_question() to obtain DB lock before updating metadata?

As always, thanks for all your great work on calibre.

[kovidgoyal]

@JimmXinu:

The tweaks still apply, but they apply to the tag browser only not the book details panel. The tag browser in the content server is now what you get when you click the search button

IIRC , is a python formatting operator. I just haven't got around to porting it to RapydScript which is what does string formatting in the browser.

I'll fix the links in the first post, thanks.

You will never be able to run GUI plugins in the server. At some point I might add the ability to create plugins to modify the server interface, but that is not going to be any time soon. There is lots of work to do on the core code still.

All DB functions have been thread-safe since calibre 1.0

What is not thread safe is the GUI itself, proceed_question() is for the latter not the former.

[davidfor]

@Kovid: I've found out more about the Kobo browser and why it isn't working with the new server.

Basically, the browser is getting the file name from the URL. If it can't find one, or the file name isn't one it can handle, the file isn't downloaded. The browser doesn't use the "Content-Disposition" header field, so it cannot download the file. I've put a longer description at https://www.mobileread.com/forums/sh....php?p=3531644. I have reported the problem to Kobo. We'll see when a fix comes out.

I've hacked some code to include a file name in the requests to prove it works. That of course broke other things, but the file downloaded.

[kovidgoyal]

@davidfor: Wow, that was some great analysis. Thanks for following up on it as there was not much I could do about it myself.

I can probably create a special file name including endpoint for the mobile view so it works with the Kobo. Does the filename have to be part of the path or can it be a query parameter?

[chaley]

Originally Posted by kovidgoyal

I can probably create a special file name including endpoint for the mobile view so it works with the Kobo. Does the filename have to be part of the path or can it be a query parameter?

This triggered a memory. I have run into this problem with other devices and browsers, IIRC old windows and android phones. What worked the best for me was to add a pseudo filename at the end of the "real" URL. Something like

http://foo.com:1234/real/api/stuff/foo.txt

where /foo.txt was ignored by the server. Query strings didn't work.

In a few cases I had problems if the name in the content disposition header didn't match the name in the trailing segment of the URL path. I never did figure out why.

[kovidgoyal]

I committed some code to use a URL with the filename in the /mobile page. Hopefully that fixes the Kobo. I left the content-disposition header in there.

[davidfor]

Originally Posted by kovidgoyal

@davidfor: Wow, that was some great analysis. Thanks for following up on it as there was not much I could do about it myself.

It wasn't all me. I got close, but was able to ask the right person the right question

I can probably create a special file name including endpoint for the mobile view so it works with the Kobo. Does the filename have to be part of the path or can it be a query parameter?

It looks like it needs to be part of the URL. My earlier test that worked earlier was:

/get/EPUB/938/Unclean/Unclean_938.epub

Trying:

/get/EPUB/938/Unclean/rubbish?q=Unclean_938.epub

didn't work.

The hack I've done is to simply generate the file name and append it. Then if there is a dot in the URL, strip everything after the last slash.

And I'd agree with chaley. I know I've seen problems like this before with other sites and browser combinations. They were older browsers, but unfortunately, the browsers on the ereaders seem to be old and simple.

[davidfor]

Originally Posted by kovidgoyal

I committed some code to use a URL with the filename in the /mobile page. Hopefully that fixes the Kobo. I left the content-disposition header in there.

To fast And content-disposition header is OK as it was there with the old server.

That has fixed it. But, (you knew there was going to be one) kepubs don't downoad. Unfortunately, these need to have the extension as ".kepub.epub". There was code in the old server to do this if the user agent was the Kobo browser.

Edit: Need "ext.lower()" in the test in book_filename.

[kovidgoyal]

ext now lowered

[davidfor]

And it works!

[mcglyph]

Hi! I have edited my book. When I view the book on Calibre, all edits are clearly in the book. When I save to disk, the edits are not there. What is going on? Someone help please.