Downloads.db3-shm, -wal files

[petewagner2002]

Not sure what these files do. I've had three recent crashes where Newsbin stopped working and was forced to close by Win7 (1 in 6.34, 2 crashes in 6.41B1-2101 - the upgrade prompted by the first crash). Never had a crash in years until these three. What I found was that if I deleted these files, it would resume normally with the download list intact. The download.db3 file did not have to be deleted. Is this indicative of anything?

On another item, is it possible to add an "UnRar Path" column to the download list much like the "Download Path"? Because of the complexity of the options, I am not always certain that I've set them correctly and would like to see where Newsbin will put the end files (and correct it if I need to). I work mostly from header lists.

Thanks!

[petewagner2002]

Earlier I said that the download list was intact. Actually, it resumed but used the latest setting in the options for the unrar path even though I had specified different options at the time of original queuing.

[Quade]

During the crash, it probably couldn't save off the updated data to the database. That's why it reverted to an earlier version of the database. That's what's supposed to happen in a crash.

[petewagner2002]

Is it possible that the cause of the crash is that it could not write to the database? Or could I be overloading the database with multiple changes to the unrar options as I queue up files. That's the only change in usage I have implemented as I consider why Newsbin is now crashing on me.

Do I need to move my question about unrar path visibility to another topic or can you answer it here?

[Quade]

Well, we're here already discussing your problems here.

The unrar path changes don't get written to the DB till you exit so, I'm skeptical about your theory. It is possible the downloads.db3 is simply corrupted and needs to be deleted. If you're getting crashing that's probably where I'd start.

[petewagner2002]

Well that tells me a couple of things. First, after I queue a list, I should exit to save my work in case of a crash. Second, the more I queue, the larger amount of memory I have in use. The memory usage is probably suspect in the crash behavior. I remember in older versions, once I reached a certain queue volume, the system became noticeably unstable. [I was working with "fresh" downloads.db3 files prior to the crashes.]

Why doesn't the unrar path detail get written to the db 'live'? Seems non-db like. If that is the case, you probably can't really add a column to the downloads list since the info isn't really in the db. Too bad.

[Quade]

I try to minimize the number of times I open the downloads.db3 file. The more often it's open, the more likely it is to get corrupted. Particularly on normal PC's. I have to set the order on exit so, I save the unrar path the same time I set the file order.

I really think you'd have to have a huge download list for it to cause any crashing, even then it shouldn't crash but, just get slower. I've never seen the download list crash but, I never have more then 40 GB in the download list (typically much less).

It should never crash. So, the question is, why does it crash for you and not for me? How much do you typically have in the download list?