EDIT: The issue discussed in this post is not related to Docudesk or readerfs. It was bad LRF generation on my part (now fixed) and never had anything to do with Docudesk/readerfs.
There was some previous discussion about Metadata, and I
think this may be a real problem.
I generated two LRF files with TOCs in the Menu. Just to make sure I'm clear, when you've selected a book, it's entry #5 "Table of Contents" which you can select by pressing 5 on the Reader. So I'm not talking a TOC page, but the TOC menu.
I used
Docudesk on one LRF, and after I unmounted/restarted the Reader, it spun for a VERY LONG TIME... generating new metadata I assume. When I went to my new LRF, selected #5 - "Table of Contents" the Reader locked up for over a minute! Once it came back, I was able to select an item. However, if I returned to the TOC Menu, I was dead again for a minute or two. This basically rendered the TOC unusable.
With my second LRF, I used the Connect Software to transfer. Selecting the TOC here had about a 5 second delay, even though it was about the same size as the other LRF. I've generated a few other LRFs with 25 or more TOC entries, and these also worked fine when using Connect to transfer.
Even using Connect to re-transfer the "bad" LRF doesn't help. It looks like the Reader re-uses the Metadata, and it makes determining the problem all that much harder (is it that particular file? is it the metadata? etc.)
The only solution I can think of is reformatting the Reader and starting over (how?). Or maybe I can delete one of the two media.xml files, and the reader will be forced to use the other (assuming the one to delete is in /tmp/database/cache).
Any thoughts?
-Pie