Hi Andy and welcome to the new forum! 
After reboot every time sabnzbd does not recognize the installed par2cmdline turbo qpkg.
I have to manually stop and start both to have par2cmdline turbo recognized by sabnzbd.
I think par2cmdline turbo has to be started before sabnzbd on reboot. Is there any way to do this?
The sortmyqpkg package sadly is known to not work correctly anymore, so are there other possibilities?
Hi mate. 
This should be happening automatically.
I’ll need some information about your setup. Can you please run each of the following commands and post the results back here?
sherpa about
sherpa list installed
getcfg sabnzbd dependency -f /etc/config/qpkg.conf
getcfg par2turbo enable -f /etc/config/qpkg.conf
[\~\] # sherpa about
sherpa v251210-stable
dbug: (II) --------------------------------------------------------------------------------------------------------
dbug: (**) HARDWARE: NAS model: TS-251
dbug: (**) HARDWARE: CPU: Intel(R) Celeron(R) CPU J1800 @ 2.41GHz
dbug: (**) HARDWARE: CPU cores: 2
dbug: (**) HARDWARE: CPU architecture: x86_64 (64b)
dbug: (**) HARDWARE: basic CPU SHA1 benchmark: 55.0MB/s
dbug: (**) HARDWARE: RAM: 3.74GiB
dbug: (**) KERNEL: name: GNU/Linux
dbug: (**) KERNEL: version: 5.10.60-qnap
dbug: (**) KERNEL: page size: 4096B
dbug: (**) FIRMWARE: OS: QTS
dbug: (**) FIRMWARE: version: 5.2.8.3332
dbug: (**) FIRMWARE: build date: 20251128 (Fri 28 Nov 2025)
dbug: (**) FIRMWARE: platform: X86_BAYTRAIL
dbug: (**) OS: state: online
dbug: (**) OS: uptime: 11h:11m:23s
dbug: (**) OS: load averages: 1m:0.23, 5m:0.23, 15m:0.29
dbug: (**) STORAGE: default volume mounted: /share/MD1_DATA
dbug: (**) STORAGE: basic write benchmark: 331MB/s
dbug: (**) STORAGE: /opt: /share/MD1_DATA/.qpkg/Entware
dbug: (**) USERSPACE: libc: (GNU libc) 2.21
dbug: (**) USERSPACE: libc copyright: Copyright (C) 2015 Free Software Foundation, Inc.
dbug: (**) USERSPACE: $EUID: 0
dbug: (NA) USERSPACE: $SUDO_UID: N/A
dbug: (**) USERSPACE: BusyBox version: BusyBox v1.24.1 (2025-11-28 02:14:32 CST) multi-call binary.
dbug: (**) USERSPACE: BusyBox copyright: BusyBox is copyrighted by many authors between 1998-2015.
dbug: (**) USERSPACE: BusyBox function count: 166
dbug: (**) SCRIPT: QPKG version: 250927 (Sat 27 Sep 2025)
dbug: (**) SCRIPT: manager version: 251210-stable
dbug: (**) SCRIPT: manager epoch: 1765404323 (Wed 10 Dec 2025 11:05:23 PM CET)
dbug: (**) SCRIPT: objects epoch: 1765404318 (Wed 10 Dec 2025 11:05:18 PM CET)
dbug: (**) SCRIPT: packages epoch: 1765404085 (Wed 10 Dec 2025 11:01:25 PM CET)
dbug: (**) SCRIPT: logs path: /share/MD1_DATA/.qpkg/sherpa/log
dbug: (**) QPKG: packages release: v251211 (Thu 11 Dec 2025)
dbug: (NA) QPKG: allow unofficial: N/A
dbug: (**) QPKG: require signed: no
dbug: (**) QPKG: architecture: i64 (Intel x86-64)
dbug: (**) QPKG: date Entware installed: 2025-10-23 (Thu 23 Oct 2025)
dbug: (**) QPKG: Entware type: std
dbug: (NA) QPKG: SortMyQPKGs: N/A
dbug: (NA) QPKG: IncreaseTimeouts: N/A
dbug: (II) --------------------------------------------------------------------------------------------------------
[\~\] # sherpa list installed
Entware
Par2turbo
SABnzbd
sherpa
Unrar
[\~\] # getcfg sabnzbd dependency -f /etc/config/qpkg.conf
Entware:Unrar:Par2turbo
[\~\] # getcfg par2turbo enable -f /etc/config/qpkg.conf
TRUE
I hope that helps…
All looks good. 
Which means: it appears QTS isn’t starting QPKGs according to their listed dependencies.
I’m actually testing on an almost identical setup at the moment (which is working fine). But I have all the sherpa QPKGs installed. I’ll try reducing to just the ones you’re using and see if I can replicate this error.
I’ll get back to you.
Nope, works fine here.
@jimpoison, is SABnzbd stating it can’t find Par2cmdline-turbo?
When this happens, can you please run the sherpa status report?
sherpa status
If you only restart the SABnzbd QPKG, does that get it working again?
Yes sabnzbd says par2cmdline not available. But Sherpa status tells me that par2cmdline is inactive after reboot. I think that is the reason why sabnzbd does not recognize it. But if restart par2cmdline sherpa status says it is active and it is recognized by sabnzbd. So the question is why is it inactive after reboot?
Only restarting sabnzbd does not help, I have to restart par2cmdline
How soon after bootup are you checking the status of SABnzbd?
When you generated the sherpa status report, was there a notification QTS was still starting QPKGs?
Can you please post the SABnzbd service log script?
/etc/init.d/sabnzbd.sh log
Hi, having some issues with SickGear, it is starting but stops in a few seconds. All seems to be good, can manually stop and start, log in, but in a few secs it’s dead. Any ideas?
QPKG name: Status: Last action (result): QPKG version: Appl. version: Location:
* ClamAV * incompatible author N/A N/A N/A /share/MD0_DATA/.qpkg/ClamAV
Entware - enabled, active unsupported 1.03a 1.03a /share/MD0_DATA/.qpkg/Entware
nzbToMedia - enabled, active restart (OK) 251226 dynamic /share/MD0_DATA/.qpkg/nzbToMedia
OSickGear - enabled, inactive start (OK) 250124 dynamic /share/MD0_DATA/.qpkg/OSickGear
Par2turbo - enabled, active unsupported 1.2.0 1.2.0 /share/MD0_DATA/.qpkg/Par2turbo
SABnzbd - enabled, active start (OK) 251226 dynamic /share/MD0_DATA/.qpkg/SABnzbd
sherpa - enabled, active start (OK) 251212 251212 /share/MD0_DATA/.qpkg/sherpa
Unrar - enabled, active unsupported 7.0.8 7.01 beta 1 /share/MD0_DATA/.qpkg/Unrar
Used to work well, not sure if something on my qnap that is messed up or something else. Sherpa stuff looks good as far as i checked and understand.
One thing is that even nothing changed (new apps or configuration) the qnap is running high on processor (50%ish) and memory (30%ish).
[~] # sherpa about
sherpa v251226-stable
dbug: (II) --------------------------------------------------------------------------------------------------------
dbug: (**) HARDWARE: NAS model: TS-253A
dbug: (**) HARDWARE: CPU: Intel(R) Celeron(R) CPU N3150 @ 1.60GHz
dbug: (**) HARDWARE: CPU cores: 4
dbug: (**) HARDWARE: CPU architecture: x86_64 (64b)
dbug: (**) HARDWARE: basic CPU SHA1 benchmark: 48.7MB/s
dbug: (**) HARDWARE: RAM: 7.69GiB
dbug: (**) KERNEL: name: GNU/Linux
dbug: (**) KERNEL: version: 5.10.60-qnap
dbug: (**) KERNEL: page size: 4096B
dbug: (**) FIRMWARE: OS: QTS
dbug: (**) FIRMWARE: version: 5.2.8.3359
dbug: (**) FIRMWARE: build date: 20251225 (Thu 25 Dec 2025)
dbug: (**) FIRMWARE: platform: X86_BRASWELL
dbug: (**) OS: state: online
dbug: (**) OS: uptime: 98h:22m:51s
dbug: (**) OS: load averages: 1m:2.08, 5m:2.77, 15m:3.52
dbug: (**) STORAGE: default volume mounted: /share/MD0_DATA
dbug: (**) STORAGE: basic write benchmark: 243MB/s
dbug: (**) STORAGE: /opt: /share/MD0_DATA/.qpkg/Entware
dbug: (**) USERSPACE: libc: (GNU libc) 2.21
dbug: (**) USERSPACE: libc copyright: Copyright (C) 2015 Free Software Foundation, Inc.
dbug: (**) USERSPACE: $EUID: 0
dbug: (NA) USERSPACE: $SUDO_UID: N/A
dbug: (**) USERSPACE: BusyBox version: BusyBox v1.24.1 (2025-12-25 02:11:02 CST) multi-call binary.
dbug: (**) USERSPACE: BusyBox copyright: BusyBox is copyrighted by many authors between 1998-2015.
dbug: (**) USERSPACE: BusyBox function count: 166
dbug: (**) SCRIPT: QPKG version: 251212 (Fri 12 Dec 2025)
dbug: (**) SCRIPT: manager version: 251226-stable
dbug: (**) SCRIPT: manager epoch: 1766706808 (Fri 26 Dec 2025 1:53:28 AM EET)
dbug: (**) SCRIPT: objects epoch: 1766706803 (Fri 26 Dec 2025 1:53:23 AM EET)
dbug: (**) SCRIPT: packages epoch: 1766706667 (Fri 26 Dec 2025 1:51:07 AM EET)
dbug: (**) SCRIPT: logs path: /share/MD0_DATA/.qpkg/sherpa/log
dbug: (**) QPKG: packages release: v251226 (Fri 26 Dec 2025)
dbug: (NA) QPKG: allow unofficial: N/A
dbug: (**) QPKG: require signed: no
dbug: (**) QPKG: architecture: i64 (Intel x86-64)
dbug: (**) QPKG: date Entware installed: 2025-11-30 (Sun 30 Nov 2025)
dbug: (**) QPKG: Entware type: std
dbug: (NA) QPKG: SortMyQPKGs: N/A
dbug: (NA) QPKG: IncreaseTimeouts: N/A
dbug: (II) --------------------------------------------------------------------------------------------------------
Thanks!
Hi @Vasarolli and welcome to the new forum. 
You’re using the old ‘OSickGear’ QPKG. This needs to be replaced with the new ‘SickGear’ QPKG.
Please see this discussion page for details: New QPKG names, and how-to start using them · OneCDOnly/sherpa · Discussion #321 · GitHub
Omygod, thanks, did not notice this, maybe need to visit here and to Git regularly… This is what happens when only in case of problems i try resolve issues. A newsletter of some sort would be great
Seems it was not successful but i am sure you know what to do next.
[~] # sherpa backup osickgear rm osickgear rebuild sickgear
sherpa v251226-stable
done: actions complete.
• Package actions started @ 11:22:24 PM, ended @ 11:32:45 PM, elapsed = 10m:21s
• These package actions completed OK:
meta-rebuild SickGear QPKG in 1 second
download SickGear QPKG in 1 second
deactivate OSickGear QPKG in 1 second
backup OSickGear QPKG in 1m:54s
uninstall OSickGear QPKG in 12 seconds
reactivate Entware QPKG in 2 seconds
install SickGear QPKG in 1m:30s (v251226)
• This package action was skipped (and why):
"sign" SickGear QPKG in 1 second (already signed)
• This package action failed (and why):
restore SickGear QPKG in 6m:19s (tried to launch 4 times, no further retries are possible)
[~] #
Can you please post your SickGear service log?
/etc/init.d/sickgear.sh log
Specifically, I need to see the log for the last action performed (which should be restore). If you’re able to identify each action block, please post only the last one.
1 - no configuration file, using default as template
2 - application auto-update: true
3 <E2><80><A2>
4 - source: sickgear.sh, action: start, time: Mon 12 Jan 2026 11:24:57 PM EET, load: 5.73
5 - package: 251226, service: 251226, library: 251226
6 - QPKG enabled: true
7 - application auto-update: true
8 - active git branch:
9 - daemon PID: none
10 - file exists: /opt/bin/git
11 > create 'SickGear' from remote repository: OK
12 - active git branch: main
13 > create new virtual Python environment: OK
14 > create QPKG 'pip' config: OK
15 > add location '/share/MD0_DATA/.qpkg/SickGear/pip-cache' as 'pip' cache: OK
16 > add location '/share/MD0_DATA/.qpkg/SickGear/qpkg-wheels' to 'pip' search path: OK
17 > exclude problematic PyPI modules from 'requirements.txt': OK
18 > exclude problematic PyPI modules from 'recommended.txt': OK
19 > install PyPI modules from 'base.txt': OK
20 > install PyPI modules from 'requirements.txt': OK
21 > install PyPI modules from 'recommended.txt': OK
22 > load ports from configuration file: OK
23 > start daemon: OK
24 > watch for daemon process name to appear (no-more than 168 seconds): OK
25 = process name appeared in 1 second
26 > wait 14 seconds to confirm PID is still alive: done
27 - daemon PID: 27994
28 - daemon listening address: 0.0.0.0
29 - HTTPS port enabled: false
30 - HTTP port: 7181
31 > test for port 7181 response (no-more than 168 seconds): OK
32 = responded in 0 seconds
33 > update QPKG icon with UI ports: OK
34 = source: sickgear.sh, action: start, time: Mon 12 Jan 2026 11:26:18 PM EET, result: OK, elapsed: 0h:01m:22s, load: 5.8
34 4
35 <E2><80><A2>
36 - source: sickgear.sh, action: restore, time: Mon 12 Jan 2026 11:26:26 PM EET, load: 5.87
37 - package: 251226, service: 251226, library: 251226
38 - daemon PID: 27994
39 > stop daemon PID 27994 with SIGTERM (no-more than 168 seconds): OK
40 - stopped in 4 seconds
41 - daemon PID: none
42 > restore configuration backup: OK
43 - daemon PID: none
44 - file exists: /opt/bin/git
45 > update 'SickGear' from remote repository: OK
46 - active git branch: main
47 > load ports from configuration file: OK
48 > start daemon: OK
49 > watch for daemon process name to appear (no-more than 168 seconds): OK
50 = process name appeared in 1 second
51 > wait 14 seconds to confirm PID is still alive: done
52 - daemon PID: none
53 w daemon PID check failed: there appears to have been a post-launch failure
54 ~ retry 1/3
55 > start daemon: OK
56 > watch for daemon process name to appear (no-more than 144 seconds): w process name not found (exceeded timeout: 144 s
56 econds)
57 > wait 10 seconds to confirm PID is still alive: done
58 - daemon PID: none
59 w daemon PID check failed: there appears to have been a post-launch failure
60 ~ retry 2/3
61 > start daemon: OK
62 > watch for daemon process name to appear (no-more than 120 seconds): w process name not found (exceeded timeout: 120 s 62 econds)
63 > wait 10 seconds to confirm PID is still alive: done
64 - daemon PID: none
65 w daemon PID check failed: there appears to have been a post-launch failure
66 ~ retry 3/3
67 > start daemon: OK
68 > watch for daemon process name to appear (no-more than 120 seconds): OK
69 = process name appeared in 1 second
70 > wait 10 seconds to confirm PID is still alive: done
71 - daemon PID: none
72 w daemon PID check failed: there appears to have been a post-launch failure
73 ! tried to launch 4 times, no further retries are possible
74 = source: sickgear.sh, action: restore, time: Mon 12 Jan 2026 11:32:44 PM EET, result: FAILED, elapsed: 0h:06m:18s, loa 74 d: 3.64
75 <E2><80><A2>
76 - source: sickgear.sh, action: stop, time: Mon 12 Jan 2026 11:38:24 PM EET, load: 2.29
77 - package: 251226, service: 251226, library: 251226
78 - QPKG enabled: false
79 - application auto-update: true
80 - active git branch: main
81 - daemon PID: none
82 = source: sickgear.sh, action: stop, time: Mon 12 Jan 2026 11:38:24 PM EET, result: OK, elapsed: 142ms, load: 2.29
83 <E2><80><A2>
84 - source: sickgear.sh, action: start, time: Mon 12 Jan 2026 11:38:34 PM EET, load: 3.17
85 - package: 251226, service: 251226, library: 251226
86 - QPKG enabled: true
87 - application auto-update: true
88 - active git branch: main
89 - daemon PID: none
90 - file exists: /opt/bin/git
91 > update 'SickGear' from remote repository: OK
92 - active git branch: main
93 > load ports from configuration file: OK
94 > start daemon: OK
95 > watch for daemon process name to appear (no-more than 120 seconds): OK
96 = process name appeared in 1 second
97 > wait 10 seconds to confirm PID is still alive: done
98 - daemon PID: none
99 w daemon PID check failed: there appears to have been a post-launch failure
100 ~ retry 1/3
101 > start daemon: OK
102 > watch for daemon process name to appear (no-more than 132 seconds): w process name not found (exceeded timeout: 132 s 102 econds)
103 > wait 10 seconds to confirm PID is still alive: done
104 - daemon PID: none
105 w daemon PID check failed: there appears to have been a post-launch failure
106 ~ retry 2/3
107 > start daemon: OK
108 > watch for daemon process name to appear (no-more than 120 seconds): w process name not found (exceeded timeout: 120 s 108 econds)
109 > wait 18 seconds to confirm PID is still alive:
OK, let’s begin with a clean:
/etc/init.d/sickgear.sh clean
… then a start in debug mode:
/etc/init.d/sickgear.sh start debug
If you see the daemon check fail once, cancel with CTRL+C. Please post back what you see during the start action.
[~] # /etc/init.d/sickgear.sh clean
- source: sickgear.sh, action: clean, time: Mon 12 Jan 2026 11:52:54 PM EET, load: 8.48
- package: 251226, service: 251226, library: 251226
- QPKG enabled: true
- application auto-update: true
- active git branch: main
- daemon PID: none
> clean local repository: OK
> clean virtual Python environment: OK
> clean PyPI cache: OK
> clean temp path: OK
= source: sickgear.sh, action: clean, time: Mon 12 Jan 2026 11:52:56 PM EET, result: OK, elapsed: 2,556ms, load: 8.20
Good so-far… now the start with debug.
Guess you mean this?
Successfully installed orjson-3.11.5 rapidfuzz-3.14.3
} exec: completed OK (0)
> 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 132 seconds): 1, OK
> wait 11 seconds to confirm PID is still alive: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, done
- daemon PID: none
w daemon PID check failed: there appears to have been a post-launch failure
~ retry 1/3
> 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, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, w process name not found (exceeded timeout: 120 seconds)
> wait 10 seconds to confirm PID is still alive: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, done
- daemon PID: none
w daemon PID check failed: there appears to have been a post-launch failure
~ retry 2/3
Let’s try a manual non-daemon start. This will attempt to launch SickGear in interactive mode. Please copypaste the whole command below and run it:
/share/MD0_DATA/.qpkg/SickGear/venv/bin/python3 /share/MD0_DATA/.qpkg/SickGear/repo-cache/sickgear.py --nolaunch --datadir /share/MD0_DATA/.qpkg/SickGear/config
There was a 3 post limit earlier, maybe it is gone now…
[~] # /share/MD0_DATA/.qpkg/SickGear/venv/bin/python3 /share/MD0_DATA/.qpkg/SickGear/repo-cache/sickgear.py --nolaunch --datadir /share/MD0_DATA/.qpkg/SickGear/config
Starting up SickGear from /share/MD0_DATA/.qpkg/SickGear/config/config.ini
00:03:48 INFO TORNADO :: Starting SickGear on http://0.0.0.0:8081/
00:03:48 INFO MAIN :: Database schema is up-to-date, no upgrade required
00:03:48 INFO MAIN :: Checking database structure...
00:03:48 INFO MAIN :: Checking database structure...
00:03:48 INFO MAIN :: No orphan episodes, check passed
00:03:48 INFO MAIN :: No UNAIRED episodes, check passed
00:03:48 ERROR MAIN :: Fatal error executing query: database disk image is malformed
Traceback (most recent call last):
File "/share/MD0_DATA/.qpkg/SickGear/repo-cache/sickgear.py", line 823, in <module>
SickGear().start()
File "/share/MD0_DATA/.qpkg/SickGear/repo-cache/sickgear.py", line 491, in start
sickgear.initialize(console_logging=self.console_logging)
File "/share/MD0_DATA/.qpkg/SickGear/repo-cache/sickgear/__init__.py", line 659, in initialize
return init_stage_2()
^^^^^^^^^^^^^^
File "/share/MD0_DATA/.qpkg/SickGear/repo-cache/sickgear/__init__.py", line 1565, in init_stage_2
db.sanity_check_db(my_db, mainDB.MainSanityCheck)
File "/share/MD0_DATA/.qpkg/SickGear/repo-cache/sickgear/db.py", line 420, in sanity_check_db
sanity_check(connection).check()
File "/share/MD0_DATA/.qpkg/SickGear/repo-cache/sickgear/databases/mainDB.py", line 43, in check
self.fix_scene_exceptions()
File "/share/MD0_DATA/.qpkg/SickGear/repo-cache/sickgear/databases/mainDB.py", line 257, in fix_scene_exceptions
sql_result = self.connection.select(
^^^^^^^^^^^^^^^^^^^^^^^
File "/share/MD0_DATA/.qpkg/SickGear/repo-cache/sickgear/db.py", line 296, in select
sql_results = self.action(query, args).fetchall()
^^^^^^^^^^^^^^^^^^^^^^^^
File "/share/MD0_DATA/.qpkg/SickGear/repo-cache/sickgear/db.py", line 276, in action
sql_result = self.connection.execute(query)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
sqlite3.DatabaseError: database disk image is malformed
00:03:48 INFO MAIN :: SickGear.Start() exception caught database disk image is malformed: Traceback (most recent call last):
File "/share/MD0_DATA/.qpkg/SickGear/repo-cache/sickgear.py", line 823, in <module>
SickGear().start()
File "/share/MD0_DATA/.qpkg/SickGear/repo-cache/sickgear.py", line 491, in start
sickgear.initialize(console_logging=self.console_logging)
File "/share/MD0_DATA/.qpkg/SickGear/repo-cache/sickgear/__init__.py", line 659, in initialize
return init_stage_2()
^^^^^^^^^^^^^^
File "/share/MD0_DATA/.qpkg/SickGear/repo-cache/sickgear/__init__.py", line 1565, in init_stage_2
db.sanity_check_db(my_db, mainDB.MainSanityCheck)
File "/share/MD0_DATA/.qpkg/SickGear/repo-cache/sickgear/db.py", line 420, in sanity_check_db
sanity_check(connection).check()
File "/share/MD0_DATA/.qpkg/SickGear/repo-cache/sickgear/databases/mainDB.py", line 43, in check
self.fix_scene_exceptions()
File "/share/MD0_DATA/.qpkg/SickGear/repo-cache/sickgear/databases/mainDB.py", line 257, in fix_scene_exceptions
sql_result = self.connection.select(
^^^^^^^^^^^^^^^^^^^^^^^
File "/share/MD0_DATA/.qpkg/SickGear/repo-cache/sickgear/db.py", line 296, in select
sql_results = self.action(query, args).fetchall()
^^^^^^^^^^^^^^^^^^^^^^^^
File "/share/MD0_DATA/.qpkg/SickGear/repo-cache/sickgear/db.py", line 276, in action
sql_result = self.connection.execute(query)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
sqlite3.DatabaseError: database disk image is malformed
Damn, looks like it won’t accept the original SickGear database from your old installation. 
I suspect you’ll need to rebuild your TV show database. This means clearing the current database and starting SickGear with a fresh config. Then letting it scan your existing TV shows.
Let’s start SickGear with a clean config and ensure it loads correctly:
/etc/init.d/sickgear.sh reset-config
… then start it in debug mode again:
/etc/init.d/sickgear.sh start debug