Failed SABnzbd downloads stuck on "Snatched"

[Balcony3871]

I am running Version: v0.8.0 (master) of Mylar3, installed on UNRAID via the linuxserver Docker image.

I have SABnzbd set up, and mostly working as expected. Mylar is able to search my indexer, download the nzb file, send it to SABnzbd, recognize when a download completes, and postprocess the newly downloaded file. It does all this without any intervention from me, and it's great.

The problem comes when a download fails in SABnzbd. The issue stays marked as "Snatched" in Mylar, instead of switching over to "Failed". Because of this, Mylar never tries again, and the issue is never downloaded, even if it exists on GetComics. I suspect that this might be a bug, since the logs seem to indicate that Mylar knows that the download failed. The last line in the logs after a failed download is

22-Jul-2024 07:03:22 - WARNING :: mylar.cdh_monitor.3642 : AUTO-COMPLETE-NZB : Failure returned from SAB for SABnzbd_nzo_cdrly1_n for some reason. You should probably check your SABnzbd logs

Here is a longer hunk of the log: https://pastebin.com/C5UMditL

Here is a partial care package with the logs removed: https://drive.google.com/file/d/170YmRvS_7AavyYqoakWQjMGKTI-scqx6/view?usp=sharing

I would like to upload a full care package, but at least one API key isn't getting removed from the logs. Most are replaced with "xUDONTNEEDTOKNOWTHISx", but one full key is slipping though. I should probably make a new thread for that, but in the meantime I don't want to go through the hassle of manually scrubbing the logs unless it's absolutely necessary. I will do it if you need to full logs to be able to help, though.

[evilhero]

As far as the api key being not removed, it's the one-time internal apikey that mylar uses to request the hit back from sab. Once it is hit once, the key becomes invalid and cannot be used again - this is by design, so there's no need to scrub the carepackage logs as any apikey therein has been run thru against your config values and removed. You're not the first to mention it nor the last I'm sure - but it's not any of your actual api keys that's in the scrubbed logs so you'd be fine to post the carepackage link

I can't remember if a failed download goes back into the search queue (at the end of the queue), or if it triggers an immediate search thereafter.

It's quite possible if it's the auto search being triggered that it has to get thru any subsequent searches before it can retry the failed downlaod.

You can test it if you'd like by just making sure no auto-search is running, and click on thr magnifying glass icon beside one issue to get it to search immediately. If it doesn't trigger the failed handling and retry it (provided you have those options enabled in the config), then it's most likely some kind of bug that we'd need to address.

[Balcony3871]

I tried the search again. I had already turned off Auto-Search to keep it from starting new downloads and muddying up the logs. The search queue is empty. Either way, if my understanding of how Mylar works is correct, the search queue shouldn't be a factor here. Until the download is marked as "Failed", it shouldn't be going to the search queue at all. The failed downloads aren't getting marked as failed, either on the issue itself or on the "Manage Failed Downloads" page.

I think I have failed handling turned on. Both "Enable Failed Download Handling" and "Enable Automatic-Retry for Failed Downloads" are checked under "Failed Download Handling" on the "Quality & Post Processing" tab of settings.


Here is the full care package: https://drive.google.com/file/d/1y0QXFf ... sp=sharing

[evilhero]

Unfortunately your understanding of Mylar's search is a bit misinformed.

There are several different queues in place that items get handed off to as they proceed thru a download (the search queue passes off to the download queue which passes off to the post-processing queue). The download queue can also be subsetted more depending on if it's a ddl or nzb type of download (the monitoring of via CDH).

So it could be still attempting to download an issue with sab while it's moved onto another search, and a failed download retry may not jump the queue to the top, but just be added to the end (as that's the type of queue it is, FIFO). The CDH queue marks it as failed, not the search queue, as the search queue has already moved onto the next item in the queue once its passed off to the CDH queue. I just can't recall if it jumps the queue on a retry or if it just resubmits it back into the queue.

However, all that being said, it does look like sab is returning a different value than expected which is why it's not getting set to a Failed status and firing off subsequent searches. I'm guessing they changed some of the responses that are hardcoded in mylar, and because it's not in its list, it just throws the general failure error about checking the logs.

I'll have to take a look at it when I get some time, but given the summer months and family time, it might be abit before I'm able to dedicate time to look at it.

[Balcony3871]

I can definitely understand having to limited time to dedicate to a volunteer project. DDL is working fine, so I'll just use that for now.

In the meantime, I'm running version 4.3.2 of SABnzbd. Here is my config file: https://drive.google.com/file/d/1TX1u9V ... sp=sharing

I don't expect you to troubleshoot my SABnzbd, but if there's a bug in how Mylar interacts with SABnzbd, I thought being able to get an instance of SABnzbd set up exactly like mine might help you reproduce it.