Note that I edited this post within an hour after posting.
@hugbug
I'll add a new env var for scripts, something like "NZBNA_QUEUEDFILE" which will point directly to the nzb-file (.nzb.X.queued). For older NZBGet version you will need the workaround.
Today I were trying to figure out / implement the future option, and noticed that you wanted to add it as a queue (NZBNA) call instead of a scan (NZBNP) call. When it would be available only when a file is added in the queue, there would not be an option to store/get the full nzb extension for DUPEs, because DUPEs won't get called via a queue call. (the script needs to check the DUPEs
before they are moved back into the queue: it could be that the nzb in the queue is propagating, as well might are the DUPEs in the history, no need to rotate the file from and to the history all the time during bad propagation for like hours).
I also encountered the following issue with my scripts and thoughts: When the
scan script call happens there is no NZBID yet, and the files are also not queued, so an option as NZBN
P_QUEUEDFILE would not be possible.
This makes a thought of me not possible, I cannot log the items the script pauses via the scan call, because I cannot ID them (although the NZBNP_NZBNAME is given, there could be similar ones, with the same NZBNP_NZBNAME).
A little shorter:
- How to know each QUEUEDFILE full extension for each NZBID?
- maybe easiest for you hugbug to add the extension in 'history' and 'listgroups' option. Too keep data to minimum, limit it to full extension (.nzb.X.queued) only as separate item ('NZBExtension') or maybe add the .X.queued to 'NZBFilename', as that is the actual file name on the disk.
- Is there a way to know which nzb (NZBID) the script paused in the scan call?
sorry for all these questions.