Should have a way to change status of a wanted book away from "Failed".

[adamgoldberg]

If I have sabnzbd misconfigured (forgot to put in the api key), when LL tries to download, it fails, and it falls through to the end of searchnzb.py: myDB.action('UPDATE wanted SET status = "Failed" WHERE NZBurl="%s"' % nzburl)

That marks that book in wanted as failed. That failed record in wanted is never deleted (not even when you delete the book, or delete the author).

It seems like

• The record in wanted should be deleted when the book is deleted (and the author, if that's different)
• All "failed" records in wanted should be changed to something other than "Failed" when any downloaders settings are changed (or at least as an option)

I can take a stab at this, but can you tell me what are the expected values for 'status' in wanted??

[philborman]

The "wanted" table is used by the search routines and also your download history, what books you asked for and what happened when we tried to download them. The "failed" status is used as part of the retry process. If a book download fails for any reason (eg no torrent seeders, password protected rar, no book found in the download) the search routines will try to download a different copy (different url) next time around. You can clear the failed downloads from the history page.

[adamgoldberg]

Ok, so in my case, when I made a book 'wanted' after changing configuration, and the download failed... then I fixed the configuration ... It doesn't seem like I should have to go to a different page and "clear failed". ..

[philborman]

You don't have to clear the failed entry, lazylibrarian still has the book marked as wanted and will try to download a different copy next time the search tasks run. It's only marked the attempted download as failed for info purposes, and so it doesn't retry the same file again. Assumption is that if it failed (eg not enough seeders, password protected file, not an ebook or wrong ebook type) there's no point retrying the same one as it will probably fail again. It would be quite complicated to track which types of fail are ok to try again and which are not, so that's left to the user ;-)

On Sat, 27 May 2017 at 16:14 Adam Goldberg notifications@github.com wrote:

Ok, so in my case, when I made a book 'wanted' after changing configuration, and the download failed... then I fixed the configuration ... It doesn't seem like I should have to go to a different page and "clear failed". ..

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/DobyTang/LazyLibrarian/issues/804#issuecomment-304454489, or mute the thread https://github.com/notifications/unsubscribe-auth/ALmHOS_ib-GnhthvXH-J78w8R5hYwZxaks5r-C_JgaJpZM4NoJEu .

[adamgoldberg]

Yea, ok, but once you change the configuration for downloaders (at least for adding and changing them), shouldn't it retry everything that had failed before?

Or at least put a button on the downloader configuration page?

[philborman]

It may have found the book on a subsequent search, maybe that one downloader failed but a torrent succeeded, we don't keep track of that. Could probably delete all failures for a bookID every time a matching bookID is successfully processed. Will look at that.

On Sat, 27 May 2017 at 17:46 Adam Goldberg notifications@github.com wrote:

Yea, ok, but once you change the configuration for downloaders (at least for adding and changing them), shouldn't it retry everything that had failed before?

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/DobyTang/LazyLibrarian/issues/804#issuecomment-304459875, or mute the thread https://github.com/notifications/unsubscribe-auth/ALmHOX9hNZhDhZQS5wsXoP0Z4pdOFe_5ks5r-EVNgaJpZM4NoJEu .

[adamgoldberg]

That'd be good cleanup - no need to remember failures for a book that was successfully completed.

That doesn't solve the problem reported, though. When adding a downloader or changing a downloader's configuration, that might solve the problem that was causing a failure, but one would never know unless one clears failures (or an alternate is eventually downloaded - which, for some things, might be never)

[philborman]

Ok will look into that. Easy to detect a deleted downloader but checking each config change is a bit more work.

On Sat, 27 May 2017, 21:04 Adam Goldberg, notifications@github.com wrote:

That'd be good cleanup - no need to remember failures for a book that was successfully completed.

That doesn't solve the problem reported, though. When adding a downloader or changing a downloader's configuration, that might solve the problem that was causing a failure, but one would never know unless one clears failures (or an alternate is eventually downloaded - which, for some things, might be never)

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/DobyTang/LazyLibrarian/issues/804#issuecomment-304470562, or mute the thread https://github.com/notifications/unsubscribe-auth/ALmHOYEV5pob-j5WVFXU1HRqwGr55Q9Eks5r-HOwgaJpZM4NoJEu .

[philborman]

Actually this turns out to be quite tricky to do. Have to check every provider parameter on every config save. Might leave this as the user can delete manually. Also it might be useful to know if all your requests to one provider fail, but another provider succeeds. Could highlight a config problem or a provider issue, eg libgen.io changed their html again.