- no configuration file, using default as template
- source: sickgear.sh, action: start, time: Tue 13 Jan 2026 12:09:25 AM EET, load: 2.19
- package: 251226, service: 251226, library: 251226
- QPKG enabled: true
- application auto-update: true
- active git branch: main
- daemon PID: none
- file exists: /opt/bin/git
> update 'SickGear' from remote repository:
{ exec: 'cd /tmp;/opt/bin/git -C "/share/MD0_DATA/.qpkg/SickGear/repo-cache" clean -f;/opt/bin/git -C "/share/MD0_DATA/.qpkg/SickGear/repo-cache" reset --hard origin/main;/opt/bin/git -C "/share/MD0_DATA/.qpkg/SickGear/repo-cache" pull'
HEAD is now at 8769b3d Merge branch 'hotfix/3.34.9'
Already up to date.
} exec: completed OK (0)
- active git branch: main
> load ports from configuration file: OK
> start daemon:
{ exec: '/share/MD0_DATA/.qpkg/SickGear/venv/bin/python3 /share/MD0_DATA/.qpkg/SickGear/repo-cache/sickgear.py --daemon --nolaunch --datadir /share/MD0_DATA/.qpkg/SickGear/config'
} exec: completed OK (0)
> watch for daemon process name to appear (no-more than 120 seconds): 1, OK
> wait 10 seconds to confirm PID is still alive: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, done
- daemon PID: 31186
- daemon listening address: 0.0.0.0
- HTTPS port enabled: false
- HTTP port: 7181
> test for port 7181 response (no-more than 120 seconds): OK
> update QPKG icon with UI ports: OK
= source: sickgear.sh, action: start, time: Tue 13 Jan 2026 12:09:42 AM EET, result: OK, elapsed: 0h:00m:17s, load: 2.59
Looks good. 
Now you get to setup SickGear from scratch again. 
Can an old config be used to ease the process?
Was there a way to scan current shows to it somehow?
Seem to have a few backups?
[/share/MD0_DATA/.qpkg/SickGear/config] # ll
total 1008K
drwxr-xr-x 4 admin administrators 4.0K 2026-01-13 00:14 ./
drwxrwxr-x 10 admin administrators 4.0K 2026-01-13 00:09 ../
drwx------ 6 admin administrators 4.0K 2026-01-13 00:09 cache/
-rw------- 1 admin administrators 524K 2026-01-13 00:09 cache.db
-rw-r--r-- 1 admin administrators 5.2K 2026-01-13 00:09 config.bak
-rw-r--r-- 1 admin administrators 5.2K 2026-01-13 00:09 config.ini
-rw-r--r-- 1 admin administrators 4.6K 2026-01-12 23:26 config.ini.def
-rw-r--r-- 1 admin administrators 4.6K 2026-01-13 00:09 config.ini.v20
-rw-r--r-- 1 admin administrators 5.2K 2026-01-13 00:09 config.ini.v21
-rw-r--r-- 1 admin administrators 5.2K 2026-01-13 00:09 config.ini.v22
-rw-r--r-- 1 admin administrators 5.2K 2026-01-13 00:09 config.ini.v23
-rw------- 1 admin administrators 16K 2026-01-13 00:09 failed.db
drwx------ 2 admin administrators 4.0K 2026-01-13 00:09 logs/
-rw------- 1 admin administrators 388K 2026-01-13 00:09 sickbeard.db
at least the bak might be something i made long ago…
The files you’re looking-at have just been created. They are not your original config files. Your original config and database are still available in the sherpa config backup directory.
The problem you have is: the database stored in that backed-up location isn’t being accepted by your current SickGear instance. You could try asking the SickGear developers if they can assist here. But they might also suggest you just rebuild your database from scratch.
I don’t have a running SickGear instance available right-now, but in Medusa, you select from the Shows menu, then Add Existing Shows, and point it to your existing shows directory. It allows a mass-import.
The real problem is your config. You’ll need to update API keys and all your settings.
1 Like
Thanks for the help, it works now (mostly), database recreated and fingers crossed on that side. that 3 post limit… thanks for bumping my rights.
What i could not figure out is why nzbtomedia/sickgear does not save the episodes under the TV/show/season folder but saves it under the TV folder like /share/MD0_DATA/TV/Catastrophe.2015.S01E05.1080p.AMZN.WEB-DL.DD5.1.x264-DRACULA
probably something very obvious, but not seeing it.
Sickgear episode naming is Season 02/Show.Name.S02E03.HD.TV-RLSGROUP.ext, post processing left empty…
Sorry, I can’t assist there. You may need help from the SickGear folks for this, or anyone who is familiar with SickGear configs.
Also, I just remembered the nzbToMedia QPKG was updated in November 2025 and works differently now: How to use the new nzbToMedia QPKG · OneCDOnly/sherpa Wiki · GitHub
Good evening my friend - I’m baaack! Been running into issues with Sonarr. Every time I go to the GUI lately, it’s off line. QNAP app center shows it’s running - so I have to stop and start. Then it comes up just fine - but eventually shuts down.
According to the Sonarr log, it’s attempting an update, shuts down but never restarts. I tried really hard using Grok to figure this out, but ultimately felt like I was chaing my own tail.
I know you can resolve this for me in less than three rounds… so, here I am to be spoiled again 
Hi mate.
Let’s try cleaning it:
/etc/init.d/sonarr.sh clean
… and if it didn’t startup afterward, please start it:
/etc/init.d/sonarr.sh start
Thanks for the reply… Just a heads up - I went into the settings/general/updates and disabled updates and it’s stayed online ever since.
source: sonarr.sh, action: clean, time: Wed 28 Jan 2026 5:41:31 PM CST, load: 0.55
package: 251226, service: 251226, library: 251226
QPKG enabled: true
application auto-update: true
daemon PID: 11104
stop daemon PID 11104 with SIGTERM (no-more than 120 seconds): 1, OK
daemon PID: none
clean local repository: OK
remove previous ‘screen’ session log: OK
clean temp path: OK
get latest remote release package filename (no-more than 5 seconds): OK
= release package filename: Sonarr.main.4.0.16.2944.linux-x64.tar.gz
release package name reference exists locally: false
release package exists locally: false
download latest release package: OK
extract from release package: OK
create release package name reference: OK
load ports from configuration file: OK
start daemon (in ‘screen’ session): OK
watch for daemon process name to appear (no-more than 120 seconds): 1, OK
daemon PID: 6105
daemon listening address: 0.0.0.0
HTTPS port enabled: false
HTTP port: 8989
test for port 8989 response (no-more than 120 seconds): 1, 2, OK
update QPKG icon with UI ports: OK
= source: sonarr.sh, action: clean, time: Wed 28 Jan 2026 5:41:45 PM CST, result: OK, elapsed: 0h:00m:14s, load: 0.58
[Eric@QNAP451 ~]$
It was running when I ran the clean command - and it was running when I checked afterwards. But as mentioned, I have the auto update check turned off… Should I turn it back on, or leave it as is?
Good-call. Yes, please leave the internal application auto-update disabled.
To update, restart the QPKG. This will automatically pull the latest application package down and install it.
I must have been messing around under the hood at some point and pushed where I shouldn’t have When you say restart the QPKG, is that just a matter of stopping the application from the QNAP app center and restarting?
Yes.
It would be nice to have the internal application update work as it should, but for-now, I’m unable to support it. So, we have to update the application by restarting the QPKG.
Thanks for setting me straight. This was a non-problem… and as usual, I found a way to make it a self-inflicted issue Much appreciated, ‘mate…
1 Like
Today i noticed that sherpa check is changed to sherpa fix 
Yup, it aligns better with what it actually does. 
1 Like