MobileRead Forums - View Single Post

phil_ga · 07-24-2011, 06:01 PM

Thanks for all this feedback. Firstly I am not new to the PC. Its not underpowered, dirty, fragged nor overclocked. It does not run unusually hot. I am referring only to response time after the drive is already awake. If do realise that editing metadata with a background conversion running will be slow - I am not referring to that. No other programs have issues or delays, including 500 mb files in photoshop. Does not matter if its a fresh reboot with nothing else running. I run the library from the HDD, a 1 TB internal drive. I have never used a network or flash drive for the library. Maybe I could try a faster drive? but one would think its a memory and chip speed issue, not a slow HDD issue. I moved the library to the primary HDD and the response rates are the same... Thats why I posted - nothing seems to indicate its my PC (of course I am always open to this!). I have had more program crashes than 3, but the 3 refers to when the database could not be read upon restarting everything. (Actually this program does not crash much - its other things that mostly take my PC down and calibre with it. I am only concerned about the restarts and inability to open the database again).

@Chaley - I get nothing like the response times you indicate (apart from the program start time), with similar specc'ed PC (but Vista). Searching from the tag browser is anything from 5 secs (which is ok) to 30 seconds - with the program appearing to freeze while it does so.

Secondly it seems the sluggishness and lack of responsiveness is just me? Yet I have read posts of others with this problem and have assumed its widespread. It still happens if its the portable version of the app. Same problem of sluggishness occurs on my other PC with my same library, and on my work PC. Does all this suggest the problem IS the metadata.db file?

The opf files are confusing themselves. When exactly are they updated? eg if i add AU information to the comments section - when does this get copied into the opf file? I am assuming never, untill you manually do a library maintenance. There appears to be no function to update only the opf files from the books you first select, you seem to need to do the whole data base (several hours). A deterrent. "The backup/restore of the main library is up to each of us...via the Library Maintenance". Maybe its just the wording, but it is NOT clear what any of these functions do. It took me a lot of reading to assume that backup merely means copying the db information into 10,000 opf individual files. Its not a backup of the library, but only of metadata.db file? Taking 6 hours to do this is still a deterrent (despite that its a background operation).

@itimpi "There has not been a dependency on the metadata.db not being corrupted and has not been for some time. It is always possible to rebuild the database using the files in the library.". This makes many assumptions that are not clear. If this is true, why does the program report to me a corrupt database, then say it gives up and starts a new empty one? This is a confusing response.

Should I perhaps "backup the database" THEN delete the metadata.db file and deliberately rebuild it? Is that what "restore database" does? Is this worth testing?
Ok then, I should rebuild - but a) how do you know the opf files are updated so that you are rebuilding all the changes you made in the comments etc? Many of them are probably old? I frequently edit groups of 10-20, adding AU biography to each for example. How does one "backup" those ones specifically? and b) how long would it take for 10k books - again presumably many hours? I guess I am just scared to manually delete this pesky file and rebuild it....

...again, thanks for so many responses.

07-24-2011, 06:01 PM	#6
phil_ga Member Posts: 10 Karma: 280 Join Date: Feb 2011 Device: kindle	Thanks for all this feedback. Firstly I am not new to the PC. Its not underpowered, dirty, fragged nor overclocked. It does not run unusually hot. I am referring only to response time after the drive is already awake. If do realise that editing metadata with a background conversion running will be slow - I am not referring to that. No other programs have issues or delays, including 500 mb files in photoshop. Does not matter if its a fresh reboot with nothing else running. I run the library from the HDD, a 1 TB internal drive. I have never used a network or flash drive for the library. Maybe I could try a faster drive? but one would think its a memory and chip speed issue, not a slow HDD issue. I moved the library to the primary HDD and the response rates are the same... Thats why I posted - nothing seems to indicate its my PC (of course I am always open to this!). I have had more program crashes than 3, but the 3 refers to when the database could not be read upon restarting everything. (Actually this program does not crash much - its other things that mostly take my PC down and calibre with it. I am only concerned about the restarts and inability to open the database again). @Chaley - I get nothing like the response times you indicate (apart from the program start time), with similar specc'ed PC (but Vista). Searching from the tag browser is anything from 5 secs (which is ok) to 30 seconds - with the program appearing to freeze while it does so. Secondly it seems the sluggishness and lack of responsiveness is just me? Yet I have read posts of others with this problem and have assumed its widespread. It still happens if its the portable version of the app. Same problem of sluggishness occurs on my other PC with my same library, and on my work PC. Does all this suggest the problem IS the metadata.db file? The opf files are confusing themselves. When exactly are they updated? eg if i add AU information to the comments section - when does this get copied into the opf file? I am assuming never, untill you manually do a library maintenance. There appears to be no function to update only the opf files from the books you first select, you seem to need to do the whole data base (several hours). A deterrent. "The backup/restore of the main library is up to each of us...via the Library Maintenance". Maybe its just the wording, but it is NOT clear what any of these functions do. It took me a lot of reading to assume that backup merely means copying the db information into 10,000 opf individual files. Its not a backup of the library, but only of metadata.db file? Taking 6 hours to do this is still a deterrent (despite that its a background operation). @itimpi "There has not been a dependency on the metadata.db not being corrupted and has not been for some time. It is always possible to rebuild the database using the files in the library.". This makes many assumptions that are not clear. If this is true, why does the program report to me a corrupt database, then say it gives up and starts a new empty one? This is a confusing response. Should I perhaps "backup the database" THEN delete the metadata.db file and deliberately rebuild it? Is that what "restore database" does? Is this worth testing? Ok then, I should rebuild - but a) how do you know the opf files are updated so that you are rebuilding all the changes you made in the comments etc? Many of them are probably old? I frequently edit groups of 10-20, adding AU biography to each for example. How does one "backup" those ones specifically? and b) how long would it take for 10k books - again presumably many hours? I guess I am just scared to manually delete this pesky file and rebuild it.... ...again, thanks for so many responses.