Firmware 4.17.13651

[Cyfranek]

I've got a problems with my Kobo Aura ONE. Some books apeears and disappears, Calibre reports problems with database as well. I have had to do factory reset and downgrade to precious cersion. I don't know if it's any connection with error reported by 7zip while try to expand archive.

[geek1011]

Originally Posted by JIPG-reader

As I mentioned in the 4.16 thread, now the header and footer are "crowded", specially in Spanish, as we have normally longer titles than in English. It seems that we have two additional lines of text, been even difficult to read the page number (now you have two!).

If a patch can be available to have them as before, fine. If not, for me is more a "no go" than a "what an improvement!".

Here is a patch for this: https://github.com/geek1011/kobopatc...0df3b0008ef427 . You can install it separately if you want, or you can wait until the full release later this week.

[kurai]

Originally Posted by NiLuJe

@davidfor: Thanks for asking!

I'll double-check if that blacklist is hard-coded, or if we can get away with using .kobo-adds or something .

EDIT: Yup, hard-coded. .kobo/addons it is, then (which does work, and is properly ignored).
Off to fix my rpaths, then .

Thanks for that - time for some path fettling for me also

Originally Posted by mathil

Yes, it's been discussed above. Apparently Kobo changed this because it was requested by users.

Thanks - I went back and found the discussion. I'd missed it because I was only searching for ".noscan"

[JIPG-reader]

Originally Posted by geek1011

Here is a patch for this: https://github.com/geek1011/kobopatc...0df3b0008ef427 . You can install it separately if you want, or you can wait until the full release later this week.

This sounds very promising!. Thank you .

This patch removes the book/chapter title, but, is there any way to remove the chapter page from the header and leave the book title as before?.

I know they are too many requests, but you are so kind...

[davidfor]

Originally Posted by Semwize

I can't believe anyone would like it, much less need such a change... For what?

Let's ask here, are there those who complained and asked?

I'm reporting what I was told. And I have seen the same question asked here. But, to most people, the question is why should those directories be special. Why shouldn't they put books in directories named like that and expect the device to load them?

And for the record, the device we are talking about is a Kobo eReader. It has no other function but to store books of various formats and allow the device owner to read them using the Kobo supplied software. Why shouldn't the device find all possible books on it and present them to the user? It not doing it's primary function is a bug isn't it?

[davidfor]

Originally Posted by NiLuJe

@davidfor: Another question, since I've just remembered why we weren't putting stuff inside .kobo to begin with: it used to get (recursively) deleted in some circumstances (account reset? Database crash? I don't exactly recall, unfortunately :/).

Does that ring a bell? Is it still relevant?

If you logout of the Kobo account, it does remove a lot of what is in the .kobo directory somewhere between then and when it does the setup. I don't think I've ever looked to see exactly what. I think it was generally accepted that we shouldn't play in that directory if we could avoid it.

[MGlitch]

Originally Posted by davidfor

I'm reporting what I was told. And I have seen the same question asked here. But, to most people, the question is why should those directories be special. Why shouldn't they put books in directories named like that and expect the device to load them?

And for the record, the device we are talking about is a Kobo eReader. It has no other function but to store books of various formats and allow the device owner to read them using the Kobo supplied software. Why shouldn't the device find all possible books on it and present them to the user? It not doing it's primary function is a bug isn't it?

I forget if Windows showss the directories without enabling 'show hidden files/folders", I know OS X doesn't unless the user specifically enables that. I imagine with Linux it's also down to the user though it may be enabled by default rather than disabled I haven't booted a Linux system since the early 2000s and even then it was for at most a week.

Why not have a directory called "Books" which would be the only source the device looks at?

Yes I realize you're only relaying a message, I'm just pointing out an alternative which would steer even the most novice of users to a conclusion.

[the.Mtn.Man]

Originally Posted by davidfor

I'm reporting what I was told. And I have seen the same question asked here. But, to most people, the question is why should those directories be special. Why shouldn't they put books in directories named like that and expect the device to load them?

And for the record, the device we are talking about is a Kobo eReader. It has no other function but to store books of various formats and allow the device owner to read them using the Kobo supplied software. Why shouldn't the device find all possible books on it and present them to the user? It not doing it's primary function is a bug isn't it?

I'm not sure why anybody who actually knows what a hidden directory is would want to store books there.

[davidfor]

Originally Posted by MGlitch

I forget if Windows showss the directories without enabling 'show hidden files/folders", I know OS X doesn't unless the user specifically enables that. I imagine with Linux it's also down to the user though it may be enabled by default rather than disabled I haven't booted a Linux system since the early 2000s and even then it was for at most a week.

Windows doesn't have the concept of hidden files or directories based on something in their name. You set the appropriate attributes if needed. Or an application does.

Why not have a directory called "Books" which would be the only source the device looks at?

Yes I realize you're only relaying a message, I'm just pointing out an alternative which would steer even the most novice of users to a conclusion.

A change like that would be a problem as all the sideloaded books would have to be moved. If the system was designed that way from the start, it would have worked. But, people would be complaining they can't do whatever-the-hell they want. Just as they are now. It is also a little problem as FAT32 is used for the book partition and that does have a maximum path length and this would effectively reduces the allowable name by five characters.

At this point, defining a directory name to ignore is probably the simpler way to go. And I think more in keeping with the idea that the device has a particular function, but maybe we can let you do other things with it.

And if Kobo do decide to make a change such as all sideloaded books have to be in a particular directory, I'll be taking a holiday from MR for a few days.

[davidfor]

Originally Posted by the.Mtn.Man

I'm not sure why anybody who actually knows what a hidden directory is would want to store books there.

Have you read the thread? Someone has been using a directory starting with a dot to backup all their books onto the device, but not load them into nickel.

But, this change has nothing to do with that. This is about people who have no idea that in a Linux based system a directory starting with a dot can be treated differently to other directories. This is about people who don't have a clue, or even need to have a clue, that the device is running Linux. They connect it to their PC, copy books to it and expect the books to be presented to them when they disconnect the device. Anything else is a bug.

And if you want to know why they used a dot at the start of the name, my bets are either a typo, or they wanted the directory to sort first in Explorer.

[Terisa de morgan]

Originally Posted by davidfor

And if Kobo do decide to make a change such as all sideloaded books have to be in a particular directory, I'll be taking a holiday from MR for a few days.

[Cootey]

Originally Posted by ZodWallop

For me, it's just enabling ligatures in kepub. I don't understand why that isn't standard out of the box.

I'd *love* to see ligature support out of the box.

[Cootey]

Originally Posted by davidfor

Have you read the thread? Someone has been using a directory starting with a dot to backup all their books onto the device, but not load them into nickel.

But, this change has nothing to do with that. This is about people who have no idea that in a Linux based system a directory starting with a dot can be treated differently to other directories. This is about people who don't have a clue, or even need to have a clue, that the device is running Linux. They connect it to their PC, copy books to it and expect the books to be presented to them when they disconnect the device. Anything else is a bug.

And if you want to know why they used a dot at the start of the name, my bets are either a typo, or they wanted the directory to sort first in Explorer.

This response is on the money. Thanks for all your commentary, davidfor. I appreciate the insider scoop you provide from time to time.

[Cootey]

So far, I'm liking the changes. My muscle memory will need to adjust to the missing topleft menu when within a book, but I believe the change simplifies and clarifies the experience. I appreciate the removal of the extra step to get to Home. The geek in me would like to define "My Books" over Home, but I think my family members will appreciate this particular change.

[Elim Garak]

A little hint.
If, after the firmware update, contents of the hidden directories are displayed on the Kobo, you may want to uninstall KoboCloud. Afterwards KoboCloud can be reinstalled.

https://www.mobileread.com/forums/sh...d.php?t=311977