New QPKG names, and how-to start using them

[OneCDOnly]

Hi all,

From today (11th October 2025), there are some new QPKGs available. These are to replace the existing set of QPKGs who's name includes a leading 'O' (like OMedusa, OSickGear, OTransmission, etc...) with the non-leading-'O' equivalent (like Medusa, SickGear, Transmission, etc...)

I'll refer to these in this post as old QPKGs (those with a leading 'O' except for Olivetin), and new QPKGs (without a leading 'O').

From this point-forward:

• old QPKGs can no-longer be installed, reinstalled, rebuilt or upgraded.
• new QPKGs can't be installed if an equivalent old QPKG is installed.
• ensure you backup your old QPKG configuration with the backup action before uninstalling an old QPKG,
• then install the new QPKG via a rebuild action. This will use your data from the old QPKG backup, and restore it into the new QPKG.

This can all be done via sherpa with the following command (using Transmission as an example):

sherpa backup otransmission rm otransmission rebuild transmission

Important

I strongly suggest only processing one QPKG at-a-time. Ensure the new QPKG is running correctly before migrating your next QPKG. Your restored configurations will be auto-updated to adjust the internal application paths to the new migrated QPKGs, but these may be incorrect or incomplete. Please check these if the application doesn't work correctly.

And here are the commands to migrate the remaining packages. Select only the QPKGs installed on your NAS. Each line migrates a single QPKG from old to new:

sherpa backup olidarr rm olidarr rebuild lidarr

sherpa backup omedusa rm omedusa rebuild medusa

sherpa backup oqbittorrent rm oqbittorrent rebuild qbittorrent

sherpa backup oreadarr rm oreadarr rebuild readarr

sherpa backup osickgear rm osickgear rebuild sickgear

sherpa backup osonarr rm osonarr rebuild sonarr

sherpa backup otautulli rm otautulli rebuild tautulli

sherpa backup owatcher3 rm owatcher3 rebuild watcher3

sherpa backup owhisparr rm owhisparr rebuild whisparr

[Kvothe1970]

Worked like a charm :) Thanks a bunch! (still on the old NAS)

[Kvothe1970]

This is on the old NAS right after I switched over to the new QPKG names.

[OneCDOnly]

Okiedoke.

Yes, the nzbToMedia QPKG (should) create a symlink to its scripts path so SABnzbd can see it.

Managing this application (nzbToMedia) with the variety of possible other application locations is a bit of a nightmare sometimes. I'm considering removing it as a QPKG and letting end-users manage it themselves. 😁

But, let's get you running again.

Is /share/Download/nzbToMedia a symlink or a directory? It should be a symlink. Check this with:

[[ -L /share/Download/nzbToMedia ]] && echo symlink || echo directory

[Kvothe1970]

Oh dear. The directory is no longer there as I assumed it would be recreated during the reinstalltion. It was still there right after the migration but clearly didn’t allow SAB to see the scripts any more.

That’s entirely on me. I followed the advice from the old forum where you advised a user with a similar issue to delete the folder as it was supposed to be recreated during reinstalling nzbToMedia.

[OneCDOnly]

The directory can be recreated as a "real" directory by SABnzbd if SABnzbd starts-up before nzbToMedia.

If nzbToMedia starts first, it should create it as a symlink.

No problems. Where do you want it to be?

[Kvothe1970]

The original folder /share/CACHEDEV1_DATA/Download/nzbToMedia is probably best. This is already configured in sab and will also be automatically available on the new NAS

[OneCDOnly]

Hi mate, the GitHub UI isn't coping well with this discussion, so I'll start again in root. 😉

So, if you've confirmed /share/Download/nzbToMedia doesn't exist in any sense, then let's create it as a symlink:

ln -s /share/CACHEDEV1_DATA/.qpkg/nzbToMedia/repo-cache/ /share/Download/nzbToMedia

[Kvothe1970]

Alright! So just to be really sure:

1. I cannot see the folder via the filemanger, winscp or sftp.
2. However, I just noticed I can browse it via SAB?
3. and running
   [[ -L /share/Download/nzbToMedia ]] && echo symlink || echo directory
   returns:
   directory

I am honestly.. a bit confused now. I am logged in as the admin so I should have all the rights to see the folder / symlink. Should I still run

ln -s /share/CACHEDEV1_DATA/.qpkg/nzbToMedia/repo-cache/ /share/Download/nzbToMedia ?

[OneCDOnly]

So, /share/Download/nzbToMedia exists as a real directory. Let's move it aside:

mv /share/Download/nzbToMedia /share/Download/nzbToMedia.old

... then create the symlink as-show in my last post.

[Kvothe1970]

Done:

[~] # mv /share/Download/nzbToMedia /share/Download/nzbToMedia.old

[~] # ln -s /share/CACHEDEV1_DATA/.qpkg/nzbToMedia/repo-cache/ /share/Download/nzbToMedia

[~] # [[ -L /share/Download/nzbToMedia ]] && echo symlink || echo directory

symlink
[~] #

[OneCDOnly]

Good!

Now, can you browse the post-processing scripts in SABnzbd?

[Kvothe1970]

yep, that fixed it!

[OneCDOnly]

Excellent. 👍🏽

[Kvothe1970]

You are once again, my hero :) thanks a bunch. I am still not quite sure how it broke in the first place. This has persisted throughout all upgrades of the past years without any issues.

But, unless the Medua Maintainers update the Repo, I will have to setup Sonarr anyway on the new NAS to work with sabnzdb,.

[OneCDOnly]

We still have some cleanup do-to.

Please delete that old directory we just moved-aside:

rm -r /share/Download/nzbToMedia.old

[Kvothe1970]

Done, all nice and tidy again :)

[OneCDOnly]

Good work mate. 🤓