Changing legacygetepub… naming conventions

[Cootey]

I've noticed on my Kobo Clara that the ebooks that I sideload through Calibre on the desktop are sorted into neat author directories with an ebook name that's legible by a human. I'm assuming that Calibre is doing this organization because books I sideload manually by dragging and dropping into the root directory of the mounted Kobo drive sit at root with whatever name they had before.

However, the books I grab through the server all have the following naming convention like this: legacygetkepub1111my_server_namebook - author_1111.kepub.epub. Is there a setting in Calibre I can use to clean this up? Obviously, Kobo is grabbing the filename as is and downloading it onto the root directory. I don't expect the Calibre web server to change Kobo's downloading behavior. But maybe there is someway to shape the Calibre names to be less machine code-like? I've been looking, and if it's there, I'm missing it. Thanks.

[kovidgoyal]

The server download links include a suggested file name, via the Content-Disposition HTTP header, the kobo is ignoring that and generating its own. There isnt really anything the server can do to control that.

[davidfor]

Yes, it is a problem with the browser on the device. I looked back at a conversation I had with Kobo when the big changes to the calibre content server were being made. They are using the URL with the Content-Disposition used if that fails somehow. The conversation did include a suggestion they might change to use the Content-Disposition first, but, it looks like that never happened.

[davidfor]

I had the chance to ask a Kobo about this. They did implement the change to use the Content-Disposition header if it was supplied. But, the problem is that calibre is sending "filename" and "filename*" and they aren't handling that properly. I don't think they were expecting the latter. I don't remember it being there the last time I looked at this. I'm pretty sure this will be fixed in the next firmware update. I expect that they will just use "filename" and ignore "filename*".

And to check, I did find a site that only sent "filename" and it worked as desired.

[Cootey]

Originally Posted by kovidgoyal

The server download links include a suggested file name, via the Content-Disposition HTTP header, the kobo is ignoring that and generating its own. There isnt really anything the server can do to control that.

I had a feeling the Kobo browser was at fault, but hoped you had a work around. Thanks for replying.

[Cootey]

Originally Posted by davidfor

I had the chance to ask a Kobo about this. They did implement the change to use the Content-Disposition header if it was supplied. But, the problem is that calibre is sending "filename" and "filename*" and they aren't handling that properly. I don't think they were expecting the latter. I don't remember it being there the last time I looked at this. I'm pretty sure this will be fixed in the next firmware update. I expect that they will just use "filename" and ignore "filename*".

And to check, I did find a site that only sent "filename" and it worked as desired.

Fascinating! Thanks for checking into this, David. I'll look forward to the update. Do you know if there's a way to tell a Calibre to only submit the non asterisked "filename"?

[davidfor]

Originally Posted by Cootey

Fascinating! Thanks for checking into this, David. I'll look forward to the update. Do you know if there's a way to tell a Calibre to only submit the non asterisked "filename"?

A quick look at the server code says you would need to modify the calibre code and run from source. The change is in one place only, so it isn't hard. But, whether it is worth it is another thing.

[kovidgoyal]

Originally Posted by davidfor

I had the chance to ask a Kobo about this. They did implement the change to use the Content-Disposition header if it was supplied. But, the problem is that calibre is sending "filename" and "filename*" and they aren't handling that properly. I don't think they were expecting the latter. I don't remember it being there the last time I looked at this. I'm pretty sure this will be fixed in the next firmware update. I expect that they will just use "filename" and ignore "filename*".

And to check, I did find a site that only sent "filename" and it worked as desired.

Note that as per the spec when both are present filename* should be preferred and allows for arbitrary unicode in filenames.

[davidfor]

Originally Posted by kovidgoyal

Note that as per the spec when both are present filename* should be preferred and allows for arbitrary unicode in filenames.

We did discuss this. That's part of the reason I'm expecting a quick fix and maybe the rest addressed later. I think it not using the filename right now was because it was coded without expecting both. But, they might decide not to support filename*. In the context of a dedicated ereader, it just isn't needed. The filenames are not really there to be seen. And it is similar to what calibre does when you do a send-to-device.