Dealing with mass feed URL changes

[lexfiend]

Hi! I use an NZB feed provider that augments all their feed URLs with access tokens for authentication purposes. As you might have guessed, they just reset my access token, so SABnzbd got errors on all my feeds.

I stopped SABnzbd, did a search-and-replace in

Code: Select all

sabnzbd.ini

to replace all the access tokens, then restarted it...before I realized that it would now see 200+ brand-new feeds. Cue 100,000+ NZB downloads. (I'm still cleaning up the mess as I write this post.)

As I'm fairly sure this will happen again at some point in the future, what's the best way to deal with such a situation? In particular, how can I tell SABnzbd that the feed URL may have changed, but it's still the same feed?

Thanks much!

[sander]

You mean you have 200 RSS feeds in SABnzbd? I have 2.

AFAIK SAB stores all history info in the directory

Code: Select all

 .sabnzbd/admin

. So have you checked that directory?

[lexfiend]

You mean you have 200 RSS feeds in SABnzbd? I have 2.

245, to be precise. I should probably clear out the ones I don't expect further updates on, but that still leaves about 100.

AFAIK SAB stores all history info in the directory

Code: Select all

 .sabnzbd/admin

. So have you checked that directory?

Yup, I stumbled across that while trying to figure out what to edit. However, everything under that directory is an opaque binary file, except one SQLite database named history1.db, so editing those sensibly would require (AFAICT) knowing undocumented details.

[sander]

In history1.db (indeed sqlite) did you find what SAB had already downloaded? Full URLs, or unique ID's?

You could change a few entries with "DB Browser for SQLite"?

If that works, you could write a sqlite command or a python script to correct your 100.000 entries.

Oh, and: No, SABnzbd cannot do it for you. I've never heard of an indexer changing stuff. Which indexer is that?

[safihre]

He changed his api key at the indexer, so he needs to update the url.
The RSS data is not stored in the SQL, but in the data file in the Admin folder.
Your method was correct of updating the sabnzbd.ini, but indeed I think the check for existing downloads is also url based (we only have that to go on). So I don't think we could have prevented that realistically..

[lexfiend]

So I don't think we could have prevented that realistically..

Yeah, I didn't think so, but was hoping I'd missed something in the docs.

Feature request:- Enable templating in RSS URLs, e.g.:

Code: Select all

my . rss . net/dl/12345?key={{KEY}}

for "stable" URLs that allow for parameters that don't actually change the RSS content. Maybe I'm the first feed user whose API key was forcibly changed without his knowledge and consent, but I doubt I'll be the last.