Would you benefit from file manager on your Kobo reader?

Originally Posted by theonna

But... If Kobo had made shelves more easily created- like being able to search for author and add all results to the shelf, search for title and add to another shelf, find all items not in any shelf and add them yet to another.

Creating shelves on a Kobo is definitely an issue, especially for larger libraries. Some of your ideas are good ones, though it would probably be better to have them as saved searches that are updated when you update your library. (I think iTunes does this, and likely other products.)

Of course needs of people that read books with different not supported alphabets, seem to be so unimportant, that nobody so far even considered how having a file manager in lieu of being able to search for books would help them.

I'm confused. Wouldn't this depend more upon the input method than database vs. file manager?

Now I hear again and again, how having a file manager would increase user error

When I say such things, I mean that a file manager would make it much more difficult to keep data synchronized. Keep in mind, reader software probably reads a book once to retrieve the relevant metadata (title, author, cover, etc.) and stores that data somewhere else. In Kobo's case, that's a database. Now a file manager would either have to update that data itself or force the system to update the data upon exit, otherwise inconsistencies will pop up. There is also a chance that a user will modify/remove a file that they shouldn't, such as the Kobo database or key for encrypted ePubs.

Unfortunately with shelves, you find yourself needing them, yet managing them on your reader, if you have significant amount of books is impossible.

Shelves have to be created somewhere. For Kobo, that's on the reader or in Calibre. Directories also have to be created somewhere, may that be on the reader or on a computer. Not a huge difference in my opinion. Now directories are easier to create in some respects. Shelves are easier to create in other respects. On the other hand, shelves are much more powerful, since they easily accommodate having a book on multiple shelves. (You can easily do this with links, in Unix parlance, and aliases, using the Mac terminology. But it is a more complex concept. We also have to face the fact that the world runs on Windows, where the use of this idea seems much less common outside of the icons used to launch programs.)

As things stand today, I agree that Kobo does a very poor job at managing large libraries. Assuming that you use shelves, I would argue that anyone browsing through more than a thousand books is going to hate Kobo's software. If you're creating the shelves using Kobo's software, you're probably going to hate them if you're managing more than a hundred books. So yes, there is definite room for improvement. I just don't think that directories are the best way for Kobo to solve the problem. Something like saved searches and making better use of the available metadata, certainly.

[davidfor]

Originally Posted by theonna

I guess you are correct.
But... If Kobo had made shelves more easily created- like being able to search for author and add all results to the shelf, search for title and add to another shelf, find all items not in any shelf and add them yet to another. Something that does not require you to go through all of the books each time you need to add one to the shelf.

From a book you can get a list of shelves and add the book to the shelf.

From the shelf manage screen, you can do a search of all the books and select from the result. It would be good to have an "select all" on the results list.

A few people have mentioned the idea of a "unshelved shelf:, but I've never seen the point. All my shelves have a reason: SciFi, a particular series, Test Samples etc. Not being on a shelf just means that. Of course, for real books, that would mean they are lying around on the floor. And yes, they are

Something that does not require you to run third party software either, Calibre is great, but if you talking easy and user friendly, it seems to make sense not to have to rely on it, right?

I'm probably not the person to answer that

[theonna]

Originally Posted by BWinmill

I'm confused. Wouldn't this depend more upon the input method than database vs. file manager?

Оf course it would depend on input method, but since for years now there weren't readers with cyrillic, hindu or other non english keyboards, it was possible to read those with unicode fonts, but impossible to use any search functions. Thus- a solution- file manager.

Originally Posted by BWinmill

When I say such things, I mean that a file manager would make it much more difficult to keep data synchronized.

Why? Kobo database already coexists just fine with file manager, the only thing that would be different for user- is ability to see their file structure from reader and browse it, it is not even necessary to have any file/folder creating or moving abilities from the reader itself. it is all comes down to using your desktop with faster processor and bigger monitor to deal with organizing library, it does not matter much how, as long as it is not tediously tapping 100+ pages for each book, or having to mark each of them manually. And in case of someone who already has a collection organized, they can just request not to even put them into a database, just use the books as is. Which should not at all encumber other readers choices about search, shelves and facebook and twitter support. As it is now it seems Kobo does a lot that some people don't need, thus making them wait needlessly, and not giving them an easy tool to avoid all the shelving headaches. Though so far it seems people who would like a file manager are in minority. Which does not invalidate the idea.

Originally Posted by theonna

Оf course it would depend on input method, but since for years now there weren't readers with cyrillic, hindu or other non english keyboards, it was possible to read those with unicode fonts, but impossible to use any search functions. Thus- a solution- file manager.

I wish that I could comment further on this, but I'm kinda anglo-centric.

Why? Kobo database already coexists just fine with file manager

Huh? If you're talking about the computer's file manager, it could be argued that Kobo does so because it suspends access to file system while connected to the computer via USB, and rebuilds the database when the connection is terminated. It works, sometimes ...

... but not always. Try adding books by FTPing into a modded Kobo device and you'll find that reboot is necessary in order to detect the new books.

it is not even necessary to have any file/folder creating or moving abilities from the reader itself. it is all comes down to using your desktop with faster processor and bigger monitor to deal with organizing library

Processor and screen size aren't really an issue here. The issue is that people are typically more concerned with the book title, author, and cover than the file name. I'd have to check the specification again, but I'm pretty sure that the author and title bit can be retrieved by opening the file, going to a particular offset, doing a minor amount of parsing, then closing the file. (Covers though are more complicated.) This has to be done on a book by book basis. The database approach is different: the file is opened and closed once per query, rather than once per book. The data is gathered and returned at one time, which makes filtering more efficient. Data structures are such that sorting is more efficient, as well as the original query.

they can just request not to even put them into a database, just use the books as is.

Which only works if you don't want any data stored about your reading, which includes the last page read. But let's ignore the counter arguments for a moment.

For the most part, I probably agree with you on a personal level. I like bypassing the cruft and getting down to business. For me, the filesystem does that well.

I just don't think that serves Kobo's business model very well, since that model probably depends upon both readers who probably lack basic tech skills and their bookstore.

[theonna]

Originally Posted by davidfor

A few people have mentioned the idea of a "unshelved shelf:, but I've never seen the point.

I think the only point here is that if you are viewing your library by shelves, books that are not included in any shelves aren't shown, and if you viewing library by books to get to those, you are presented with long list, where as my luck would have it those unshelved ones would be on the last page.

[theonna]

Originally Posted by BWinmill

The issue is that people are typically more concerned with the book title, author, and cover than the file name.

I think here we have conflict of new and old, meaning when computer era started, there were no meta information and people would name their files using system, for books often author_book title. Unfortunately even now metadata in books is not always uniformly standardized, which brings necessity of manually adding that information. Fortunately there are massive file naming and renaming programs, Calibre is one of them, that lets you name files following your set template, which makes them quite useable in file manager situation. Of course 43234280.epub is not something that anyone could appreciate, which means that most Kobo purchased books would have to rely on database.
All I am saying there is room for both. File manager is a poor man's library organization, when sophisticated tools have not yet caught up. But until they do, why not have a useful tool?
P.S. I thought of a compromise- have everything as is for Kobo books, give people a choice for sideloaded books- to process into database or not, and give ability to see them in file manager. And process sideloaded books into database either on user command or book by book on opening. Then everyone can have their cake and eat it too.

[parkher]

I am using a hierarchical directory structure on T2, but I never have to browse very far.
I am always in Cool Reader. So I am reading a book. Then I click on a hardware button where I have "Recent Books" conveniently mapped. The list (or rather the stack) of last opened books appears. Here I can switch to another book, as I like reading many books at once. But also I can get directly to the actual directory of any book on the list.
If I want to open a new book, I don't have to navigate very far, I can choose where to start. Or in a case of the next book in the series of the same author - no navigation required.

So the thing I really want in a file manager: a stack (of unlimited length) of last read books, and the possibility to get from it to the folder of any book in it.

However, even if there is no file manager, I hope that at least the list of last opened books of an unlimited length is available on Aura right now?
For example, if the list of all the books can be sorted by the time they were last opened.
It is certainly possible even on not rooted T2.
Such a list is needed to be able to read many books and switch between them.
If you only have several last opened books on the home screen (desktop), or even a list of 30 books (as on PB902) - it is not enough. On PB, I have to count how many books I still can open without losing a book from that list of 30 and then perhaps forgetting that I am still reading it

[davidfor]

Originally Posted by parkher

I am using a hierarchical directory structure on T2, but I never have to browse very far.
I am always in Cool Reader. So I am reading a book. Then I click on a hardware button where I have "Recent Books" conveniently mapped. The list (or rather the stack) of last opened books appears. Here I can switch to another book, as I like reading many books at once. But also I can get directly to the actual directory of any book on the list.
If I want to open a new book, I don't have to navigate very far, I can choose where to start. Or in a case of the next book in the series of the same author - no navigation required.

So the thing I really want in a file manager: a stack (of unlimited length) of last read books, and the possibility to get from it to the folder of any book in it.

However, even if there is no file manager, I hope that at least the list of last opened books of an unlimited length is available on Aura right now?
For example, if the list of all the books can be sorted by the time they were last opened.
It is certainly possible even on not rooted T2.
Such a list is needed to be able to read many books and switch between them.
If you only have several last opened books on the home screen (desktop), or even a list of 30 books (as on PB902) - it is not enough. On PB, I have to count how many books I still can open without losing a book from that list of 30 and then perhaps forgetting that I am still reading it

The library list can be sorted by "Recently Read". That isn't completely correct because i include books recently put onto the device. Maybe "Recently Touched" would be better. In any case, the list contains every book on the device.

The home screen also shows these books plus other recently accessed tasks. These can be dismissed from the home screen or fall of after other tasks/books are opened. The home screen can hold nine books. I think this will work for you.

[paola]

I like to keep all my books on my reader, you never know :-)
My first reader was a Pocketbook, so was the second, and they all have a filebrowser, whose depth limit, if there is one, I've never hit. So when I got a Mini I was initially very disappointed to find there is no filebrowser.

However after overcoming the initial shock and horror, I've come to quite prefer shelves: with this I can "tag" a book multiple times, whereas with a filebrowser I would need multiple copies of the same book. As search is very quick in the Mini, I have ended up actually preferring the shelves when it comes to managing books.

A file browser is still very handy to see/edit what else is in the device (e.g. if you look at the hacks in the developers' forum, there is a text editor with which you can for instance modify .ini files)

[DNSB]

Originally Posted by BWinmill

Huh? If you're talking about the computer's file manager, it could be argued that Kobo does so because it suspends access to file system while connected to the computer via USB, and rebuilds the database when the connection is terminated. It works, sometimes ...

... but not always. Try adding books by FTPing into a modded Kobo device and you'll find that reboot is necessary in order to detect the new books.

I seem to remember having to write a USB plug add, delay, USB plug remove to a hardware status file to trigger the book processing without needing a reboot. I haven't done it in a while so my memory may be wrong and it may not work with the current firmware.

Originally Posted by BWinmill

Processor and screen size aren't really an issue here. The issue is that people are typically more concerned with the book title, author, and cover than the file name. I'd have to check the specification again, but I'm pretty sure that the author and title bit can be retrieved by opening the file, going to a particular offset, doing a minor amount of parsing, then closing the file. (Covers though are more complicated.) This has to be done on a book by book basis. The database approach is different: the file is opened and closed once per query, rather than once per book. The data is gathered and returned at one time, which makes filtering more efficient. Data structures are such that sorting is more efficient, as well as the original query.

The author, title, etc. are stored in the content.opf file. I've seen several epubs where the directory structure, file names, etc. have been total garbage. Sigil actually does a fairly decent job of automagically cleaning up those files. Add in manual editing, Flightcrew and epubcheck and you can get an epub that is pretty standards compliant. If nothing else, simply opening the epub in Sigil and then saving it takes care of ensuring the directory structure is good, content.opf file has the correct file name -- I've seen multiple names such as package.opf and content.xhtml and the toc.ncx file has the correct name and structure. Doing this seems to keep my Kobos as happy campers.

For the few non-English books I have, I edit the metadata to give me a transliterated/Anglicized author and title. Calibre works very well for doing this in bulk if need be.

Originally Posted by BWinmill

Which only works if you don't want any data stored about your reading, which includes the last page read. But let's ignore the counter arguments for a moment.

For the most part, I probably agree with you on a personal level. I like bypassing the cruft and getting down to business. For me, the filesystem does that well.

I just don't think that serves Kobo's business model very well, since that model probably depends upon both readers who probably lack basic tech skills and their bookstore.

I suppose you could add a mass of little .xml files for every book carrying the same information. Doing so would make retrieving data a slow and painful process in my opinion.

Given that Kobo purchased .kepubs are stored in a single directory with a hex string as the file name, it would take a fairly major rewrite to change to a directory based file oriented system. Minor correction: if I fill the internal storage on my Kobo, it will start storing .kepubs purchased from the Kobo store in a directory on the uSD card. I don't purchase enough books from there to make this an issue except when I was testing and filled the internal card just to see what would happen.

Regards,
David

[taming]

There is a calibre catalog generater plugin by Greg Riker called Calalog_CSV_XML. Has anyone used it?

[Ripplinger]

Originally Posted by taming

There is a calibre catalog generater plugin by Greg Riker called Calalog_CSV_XML. Has anyone used it?

I've used the plugin before for awhile, thinking it would be an easy way to search for books in one location and include the descriptions. The plugin is already included in Calibre, you don't have to download it separately.

It takes awhile for it to complete, not unbearably long though, but the file output size is huge. Depending on how the comments section was formatted, you might find odd characters scattered throughout that may annoy you (I think it comes from some spaces in the descriptive comments), and text size isn't always consistent, it will be whatever was used in the comments for each book.

But it does work to give you a complete listing of all your books with a nice index at the beginning.

It wouldn't replace using shelves for me though on the Kobo, or collections on the Sonys. But you should give it a try in all the formats possible to see if it might suit your needs for some cataloging purpose.

Edit: The odd character you'll find is a black diamond with a white question mark inside.

[taming]

I don't actually need this, but I belileve someone wrote about using and editing an xml file on the kindle device and liking that.

[david_e]

Originally Posted by frddgls

Because you can choose more than one answer. I use the search function and I use shelves, the poll let me enter both answers.

Originally Posted by DNSB

Possibly quite a few people did as I and voted in two or more check boxes. For me, I checked I'm using search and I don't need it.

Regards,
David

Thank you.

[theonna]

Originally Posted by taming

I don't actually need this, but I belileve someone wrote about using and editing an xml file on the kindle device and liking that.

Kindle collections are written in one file on the device, so you can create that file on your computer and then transfer it to you KIndle, this way creating your collections faster. On Kobo all recordings go through database, so this way would be impossible.