Feature Request - send nzb title

[Prinz23]

I have 1 request when clicking a nzb and sending it to NzbGet it doesn't send the nzb name/title (using newznab indexer, probably others too).

NzbGet uses the nzb name for a duplicate check and if it finds the same name it will not download the nzb in the first place. This also saves Api hits and if you have multiple queued url in the queue it's more clear what is in there instead just seening urls as the nzb name until it's downloaded.

So it would be useful if NZB Unity could also send the name/tile of the nzb.

[clutterskull]

Hi, sorry for long time without a response.

I looked into the NZBGet API, and while I cannot add a title manually (this comes from the NZB itself), I can add a "duplicate key" to assist NZBGet's internal smart duplicate system (ie the title or imdb id), but this might be finicky and prone to false positives, as this is primarily a feature used for RSS feeds and would only work for 1-click sites where I can control what is sent.

I will keep this in mind for a future release, but in the meantime I would suggest looking into what options the NZBGet smart duplicates system offers or see if maybe SABnzbd works better for your use case.

[Prinz23]

Yes you can add the name. It's the first parameter (NZBFilename) in the append command. Nzbget API docu

If it's not provided (empty) like now (this is possible with urls) the title will be taken from the nzbname downloaded and the nzbname is on newznab indexers the same as the title.

So simply send the title as nzbname + .nzb extension, this works fine and nzbget detects then if it's the same same name as a previous downloaded nzb.

I personally are a SickGear developer and coded this in it, the app sends urls with the title as NZBFilename. So it's works.

[clutterskull]

Seems a bit weird that it would evaluate it based on filename, or even require a "filename" rather than just using what's in the NZB, but it should be easy enough.

[clutterskull]

Yeah, like you said, it takes the filename from the download headers, which is why I left that blank. Most sites use the title + nzb as the filename (like you are suggesting and what newznab does). Without doing some extensive text transformations on the title (given variations in year, release group, quality, etc tags) I can't reliably give it anything more meaningful than what it's already getting and would require updating all the site profiles to do it.

Do you have some examples of failing false negatives? Like some examples of titles / filenames that correctly trigger the NZBGet duplicate detection and some that are not correctly detected?

I'll try some things tomorrow and see what I can come up with. Assuming Google doesn't continue rejecting my updates out of hand like they did last time...

Since you are a developer, I'd be willing to look at a pull request if you're feeling up to it? FWIW, Sickbeard has an advantage that an extension doesn't in that it knows about and has nicely separated values for series title, episode title, episode number, and desired quality profiles. I don't have that luxury on an index site; I just have what they display, and usually the data in the nzb is more accurate.

Thanks!

[Prinz23]

My main point was that the same release will not be redownloaded (as in the nzb not downloaded), because if it's the exact same nzb name, nzbget will not download the url/nzb. Since it's possible that you have forgotten that you already previously had downloaded that nzb before.

This mainly saves API hits, besides that you than have a meaningful name in the queue before the nzb is downloaded, nice if you send a bunch of nzb url at once.

SickGear (and sickbeard previously) doesn't generate an nzb file name it simply uses the given title, the only transformations that are done is striping the string and doing a space to point replacement:

title = ('%s' % item.findtext('title')).strip()
title = re.sub(r'\s+', '.', title)

# then this title is send with appended .nzb
rpc_client.append('%s.nzb' % title,  ... 

I would maybe have coded myself, but i have no idea about the TypeScript coding language used in this extension and i have also no experience about coding and debugging a browser extension.

[clutterskull]

Oh ok, you don't mean the same "media", you mean literally the same release?

For example, this item here:

This would just get "Ubuntu-16.04.1-server-I386.nzb" sent along as the filename and that would be sufficient to filter it out again if downloaded from here or any other site?

It would be ideal if I knew which site profiles are not sending this already in the download headers, since scraping the HTML is likely to break if they update anything. Categories are done this way and break fairly often; there's 14 different sites I have to keep an eye on. It'd be nice it they tagged table fields to make it easier for me, but I guess they weren't actually expecting someone to go peeking in there, lol.

I'll have a look at feasibility today, and hopefully I can get to it soon. I was going to make this current release (v1.15.0) the last before rewriting the whole thing to drop dependencies, so I can do it for v2 if nothing else.

It's good to have input from someone who actually uses and has worked with the NZBGet API before.

Side note, TypeScript is just a superset of JS, it's worth learning if you get a wild hair. That said, I personally need more practice in Python, so it is what it is, haha.

Thanks

[Prinz23]

This would just get "Ubuntu-16.04.1-server-I386.nzb" sent along as the filename and that would be sufficient to filter it out again if downloaded from here or any other site?

Yes. NZBGet first compares the NZBFilename, if the same is found as queued or successfully downloaded it will directly move the url to History as Copy/Dupe without downloading the nzb via url. It is also smart enough, if the existing same named nzb has failed status it will still download a same named Nzb.