每次重啟後，sabnzbd 都無法識別已安裝的 par2cmdline turbo qpkg。
我必須手動停止並啟動兩 ink，才能讓 sabnzbd 識別 par2cmdline turbo。
我認為在重啟時，par2cmdline turbo 必須在 sabnzbd 之前啟動。有什麼方法可以做到嗎？
可惜 sortmyqpkg 套件已知不再正常運作，還有其他可能的方法嗎？
嗨，朋友。
這應該會自動發生。
我需要一些有關你系統的資訊。請你執行以下每個指令，並將結果貼回這裡嗎？
sherpa about
sherpa list installed
getcfg sabnzbd dependency -f /etc/config/qpkg.conf
getcfg par2turbo enable -f /etc/config/qpkg.conf
[~] # sherpa 關於
sherpa v251210-stable
dbug: (II) --------------------------------------------------------------------------------------------------------
dbug: () 硬體: NAS 型號: TS-251
dbug: () 硬體: 處理器: Intel(R) Celeron(R) CPU J1800 @ 2.41GHz
dbug: () 硬體: 處理器核心數: 2
dbug: () 硬體: 處理器架構: x86_64
(64位元)
dbug: () 硬體: 基本 CPU SHA1 效能測試: 55.0MB/s
dbug: () 硬體: 記憶體: 3.74GiB
dbug: () 核心: 名稱: GNU/Linux
dbug: () 核心: 版本: 5.10.60-qnap
dbug: () 核心: 頁面大小: 4096B
dbug: () 韌體: 作業系統: QTS
dbug: () 韌體: 版本: 5.2.8.3332
dbug: () 韌體: 建置日期: 20251128 (2025年11月28日 星期五)
dbug: () 韌體: 平台: X86_BAYTRAIL
dbug: () 作業系統: 狀態: 線上
dbug: () 作業系統: 開機時間: 11小時11分23秒
dbug: () 作業系統: 負載平均值: 1分鐘:0.23, 5分鐘:0.23, 15分鐘:0.29
dbug: () 儲存空間: 預設磁區已掛載: /share/MD1_DATA
dbug: () 儲存空間: 基本寫入效能測試: 331MB/s
dbug: () 儲存空間: /opt: /share/MD1_DATA/.qpkg/Entware
dbug: () 使用者空間: libc: (GNU libc) 2.21
dbug: () 使用者空間: libc 版權: Copyright (C) 2015 Free Software Foundation, Inc.
dbug: () 使用者空間: $EUID: 0
dbug: (NA) 使用者空間: $SUDO_UID: N/A
dbug: () 使用者空間: BusyBox 版本: BusyBox v1.24.1 (2025-11-28 02:14:32 CST) multi-call binary.
dbug: () 使用者空間: BusyBox 版權: BusyBox 由多位作者在 1998-2015 年間共同擁有版權。
dbug: () 使用者空間: BusyBox 功能數量: 166
dbug: () 腳本: QPKG 版本: 250927
(2025年9月27日 星期六)
dbug: () 腳本: 管理器版本: 251210-stable
dbug: () 腳本: 管理器紀元: 1765404323 (2025年12月10日 星期三 11:05:23 PM CET)
dbug: () 腳本: 物件紀元: 1765404318 (2025年12月10日 星期三 11:05:18 PM CET)
dbug: () 腳本: 套件紀元: 1765404085 (2025年12月10日 星期三 11:01:25 PM CET)
dbug: () 腳本: 日誌路徑: /share/MD1_DATA/.qpkg/sherpa/log
dbug: () QPKG: 套件發行版本: v251211 (2025年12月11日 星期四)
dbug: (NA) QPKG: 允許非官方: N/A
dbug: () QPKG: 需要簽名: 否
dbug: () QPKG: 架構: i64 (Intel x86-64)
dbug: () QPKG: Entware 安裝日期: 2025-10-23 (2025年10月23日 星期四)
dbug: () QPKG: Entware 類型: 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
希望這對你有幫助……
一切看起來都沒問題。
這表示：QTS 似乎沒有根據其列出的相依性來啟動 QPKG。
我目前其實也在一個幾乎相同的環境上測試（而且運作正常）。不過我有安裝所有 sherpa QPKG。我會嘗試只保留你正在使用的那些，看看能否重現這個錯誤。
我會再回覆你。
沒有，在我這邊運作正常。
@jimpoison，SABnzbd 有顯示找不到 Par2cmdline-turbo 嗎？
發生這種情況時，請你執行 sherpa 狀態報告嗎？
sherpa status
如果你只重啟 SABnzbd QPKG，這樣會恢復正常嗎？
是的，sabnzbd 顯示 par2cmdline 不可用。但 Sherpa 狀態告訴我，par2cmdline 在重啟後處於非活動狀態。我認為這就是 sabnzbd 無法識別它的原因。不過如果我重新啟動 par2cmdline，Sherpa 狀態就顯示它是活動的，sabnzbd 也能識別它。所以問題是，為什麼重啟後 par2cmdline 會變成非活動狀態？
開機後你多快檢查 SABnzbd 的狀態？
當你產生 sherpa 狀態報告時，有沒有通知 QTS 仍在啟動 QPKG？
請你貼上 SABnzbd 服務日誌腳本嗎？
/etc/init.d/sabnzbd.sh log
嗨，我在使用 SickGear 時遇到一些問題，它可以啟動，但幾秒鐘後就停止了。一切看起來都正常，可以手動停止和啟動，也能登入，但過幾秒就死掉了。有什麼想法嗎？
QPKG 名稱: 狀態: 最後動作（結果）: QPKG 版本: 應用程式版本: 位置:
* ClamAV * 不相容作者 N/A N/A N/A /share/MD0_DATA/.qpkg/ClamAV
Entware - 已啟用，運作中 不支援 1.03a 1.03a /share/MD0_DATA/.qpkg/Entware
nzbToMedia - 已啟用，運作中 重新啟動（OK） 251226 dynamic /share/MD0_DATA/.qpkg/nzbToMedia
OSickGear - 已啟用，未運作 啟動（OK） 250124 dynamic /share/MD0_DATA/.qpkg/OSickGear
Par2turbo - 已啟用，運作中 不支援 1.2.0 1.2.0 /share/MD0_DATA/.qpkg/Par2turbo
SABnzbd - 已啟用，運作中 啟動（OK） 251226 dynamic /share/MD0_DATA/.qpkg/SABnzbd
sherpa - 已啟用，運作中 啟動（OK） 251212 251212 /share/MD0_DATA/.qpkg/sherpa
Unrar - 已啟用，運作中 不支援 7.0.8 7.01 beta 1 /share/MD0_DATA/.qpkg/Unrar
以前運作得很好，不確定是不是我的 QNAP 有什麼地方出錯了還是其他原因。就我檢查和理解，Sherpa 的相關內容看起來沒問題。
有一點是，即使沒有變動（沒有新增應用程式或更改設定），QNAP 的處理器使用率偏高（大約 50%），記憶體也在 30%左右。
[~] # sherpa about
sherpa v251226-stable
dbug: (II) --------------------------------------------------------------------------------------------------------
dbug: (**) 硬體: NAS 型號: TS-253A
dbug: (**) 硬體: CPU: Intel(R) Celeron(R) CPU N3150 @ 1.60GHz
dbug: (**) 硬體: CPU 核心數: 4
dbug: (**) 硬體: CPU 架構: x86_64 (64b)
dbug: (**) 硬體: 基本 CPU SHA1 效能測試: 48.7MB/s
dbug: (**) 硬體: RAM: 7.69GiB
dbug: (**) 核心: 名稱: GNU/Linux
dbug: (**) 核心: 版本: 5.10.60-qnap
dbug: (**) 核心: 頁面大小: 4096B
dbug: (**) 韌體: 作業系統: QTS
dbug: (**) 韌體: 版本: 5.2.8.3359
dbug: (**) 韌體: 建置日期: 20251225 (週四 2025年12月25日)
dbug: (**) 韌體: 平台: X86_BRASWELL
dbug: (**) 作業系統: 狀態: 線上
dbug: (**) 作業系統: 開機時間: 98h:22m:51s
dbug: (**) 作業系統: 負載平均值: 1m:2.08, 5m:2.77, 15m:3.52
dbug: (**) 儲存空間: 預設磁區已掛載: /share/MD0_DATA
dbug: (**) 儲存空間: 基本寫入效能測試: 243MB/s
dbug: (**) 儲存空間: /opt: /share/MD0_DATA/.qpkg/Entware
dbug: (**) 使用者空間: libc: (GNU libc) 2.21
dbug: (**) 使用者空間: libc 版權: Copyright (C) 2015 Free Software Foundation, Inc.
dbug: (**) 使用者空間: $EUID: 0
dbug: (NA) 使用者空間: $SUDO_UID: N/A
dbug: (**) 使用者空間: BusyBox 版本: BusyBox v1.24.1 (2025-12-25 02:11:02 CST) multi-call binary.
dbug: (**) 使用者空間: BusyBox 版權: BusyBox 由多位作者於 1998-2015 年間共同著作。
dbug: (**) 使用者空間: BusyBox 功能數量: 166
dbug: (**) 腳本: QPKG 版本: 251212 (週五 2025年12月12日)
dbug: (**) 腳本: 管理器版本: 251226-stable
dbug: (**) 腳本: 管理器 epoch: 1766706808 (週五 2025年12月26日 1:53:28 AM EET)
dbug: (**) 腳本: 物件 epoch: 1766706803 (週五 2025年12月26日 1:53:23 AM EET)
dbug: (**) 腳本: 套件 epoch: 1766706667 (週五 2025年12月26日 1:51:07 AM EET)
dbug: (**) 腳本: 日誌路徑: /share/MD0_DATA/.qpkg/sherpa/log
dbug: (**) QPKG: 套件發行版本: v251226 (週五 2025年12月26日)
dbug: (NA) QPKG: 允許非官方: N/A
dbug: (**) QPKG: 需要簽名: 否
dbug: (**) QPKG: 架構: i64 (Intel x86-64)
dbug: (**) QPKG: Entware 安裝日期: 2025-11-30 (週日 2025年11月30日)
dbug: (**) QPKG: Entware 類型: std
dbug: (NA) QPKG: SortMyQPKGs: N/A
dbug: (NA) QPKG: IncreaseTimeouts: N/A
dbug: (II) --------------------------------------------------------------------------------------------------------
謝謝！
嗨 @Vasarolli，歡迎來到新論壇。
你目前使用的是舊版「OSickGear」QPKG。這需要被新版「SickGear」QPKG取代。
請參閱此討論頁以了解詳情：New QPKG names, and how-to start using them · OneCDOnly/sherpa · Discussion #321 · GitHub
Omygod，謝謝你，我之前沒注意到這個，也許真的需要常常來這裡和 Git 上逛逛……這就是只在出問題時才試著解決的後果。如果有類似電子報的東西就太棒了
看起來這次沒有成功，但我相信你知道接下來該怎麼做。
[~] # sherpa backup osickgear rm osickgear rebuild sickgear
sherpa v251226-stable
done: actions complete.
• 套件操作開始於 11:22:24 PM，結束於 11:32:45 PM，耗時 = 10m:21s
• 以下套件操作已成功完成：
meta-rebuild SickGear QPKG 於 1 秒內
download SickGear QPKG 於 1 秒內
deactivate OSickGear QPKG 於 1 秒內
backup OSickGear QPKG 於 1m:54s
uninstall OSickGear QPKG 於 12 秒內
reactivate Entware QPKG 於 2 秒內
install SickGear QPKG 於 1m:30s（v251226）
• 此套件操作已略過（原因如下）：
「sign」SickGear QPKG 於 1 秒內（已簽名）
• 此套件操作失敗（原因如下）：
restore SickGear QPKG 於 6m:19s（嘗試啟動 4 次，無法再重試）
[~] #
請您提供 SickGear 服務日誌嗎？
/etc/init.d/sickgear.sh log
我特別需要查看最後執行的動作日誌（應該是 restore）。如果您能夠辨識每個動作區塊，請只貼出最後一個。
1 - 沒有設定檔，使用預設作為範本
2 - 應用程式自動更新：true
3 ⟨E2⟩⟨80⟩⟨A2⟩
4 - 來源：sickgear.sh，動作：啟動，時間：2026年1月12日 星期一 11:24:57 PM EET，負載：5.73
5 - 套件：251226，服務：251226，函式庫：251226
6 - QPKG 啟用：true
7 - 應用程式自動更新：true
8 - 活動 git 分支：
9 - 守護程序 PID：無
10 - 檔案存在：/opt/bin/git
11 > 從遠端儲存庫建立 'SickGear'：OK
12 - 活動 git 分支：main
13 > 建立新的虛擬 Python 環境：OK
14 > 建立 QPKG 'pip' 設定：OK
15 > 新增位置 '/share/MD0_DATA/.qpkg/SickGear/pip-cache' 作為 'pip' 快取：OK
16 > 新增位置 '/share/MD0_DATA/.qpkg/SickGear/qpkg-wheels' 到 'pip' 搜尋路徑：OK
17 > 從 'requirements.txt' 排除有問題的 PyPI 模組：OK
18 > 從 'recommended.txt' 排除有問題的 PyPI 模組：OK
19 > 從 'base.txt' 安裝 PyPI 模組：OK
20 > 從 'requirements.txt' 安裝 PyPI 模組：OK
21 > 從 'recommended.txt' 安裝 PyPI 模組：OK
22 > 從設定檔載入埠口：OK
23 > 啟動守護程序：OK
24 > 監控守護程序名稱出現（不超過168秒）：OK
25 = 程序名稱於1秒內出現
26 > 等待14秒以確認 PID 仍存活：完成
27 - 守護程序 PID：27994
28 - 守護程序監聽地址：0.0.0.0
29 - HTTPS 埠口啟用：false
30 - HTTP 埠口：7181
31 > 測試7181埠口回應（不超過168秒）：OK
32 = 0秒內回應
33 > 以 UI 埠口更新 QPKG 圖示：OK
34 = 來源：sickgear.sh，動作：啟動，時間：2026年1月12日 星期一 11:26:18 PM EET，結果：OK，耗時：0小時01分22秒，負載：5.8
34 4
35 ⟨E2⟩⟨80⟩⟨A2⟩
36 - 來源：sickgear.sh，動作：還原，時間：2026年1月12日 星期一 11:26:26 PM EET，負載：5.87
37 - 套件：251226，服務：251226，函式庫：251226
38 - 守護程序 PID：27994
39 > 用 SIGTERM 停止守護程序 PID 27994（不超過168秒）：OK
40 - 4秒內停止
41 - 守護程序 PID：無
42 > 還原設定備份：OK
43 - 守護程序 PID：無
44 - 檔案存在：/opt/bin/git
45 > 從遠端儲存庫更新 'SickGear'：OK
46 - 活動 git 分支：main
47 > 從設定檔載入埠口：OK
48 > 啟動守護程序：OK
49 > 監控守護程序名稱出現（不超過168秒）：OK
50 = 程序名稱於1秒內出現
51 > 等待14秒以確認 PID 仍存活：完成
52 - 守護程序 PID：無
53 w 守護程序 PID 檢查失敗：似乎啟動後發生故障
54 ~ 重試 1/3
55 > 啟動守護程序：OK
56 > 監控守護程序名稱出現（不超過144秒）：w 未找到程序名稱（超時：144秒）
56 秒
57 > 等待10秒以確認 PID 仍存活：完成
58 - 守護程序 PID：無
59 w 守護程序 PID 檢查失敗：似乎啟動後發生故障
60 ~ 重試 2/3
61 > 啟動守護程序：OK
62 > 監控守護程序名稱出現（不超過120秒）：w 未找到程序名稱（超時：120秒）
62 秒
63 > 等待10秒以確認 PID 仍存活：完成
64 - 守護程序 PID：無
65 w 守護程序 PID 檢查失敗：似乎啟動後發生故障
66 ~ 重試 3/3
67 > 啟動守護程序：OK
68 > 監控守護程序名稱出現（不超過120秒）：OK
69 = 程序名稱於1秒內出現
70 > 等待10秒以確認 PID 仍存活：完成
71 - 守護程序 PID：無
72 w 守護程序 PID 檢查失敗：似乎啟動後發生故障
73 ! 已嘗試啟動4次，無法再重試
74 = 來源：sickgear.sh，動作：還原，時間：2026年1月12日 星期一 11:32:44 PM EET，結果：失敗，耗時：0小時06分18秒，負載：3.64
75 ⟨E2⟩⟨80⟩⟨A2⟩
76 - 來源：sickgear.sh，動作：停止，時間：2026年1月12日 星期一 11:38:24 PM EET，負載：2.29
77 - 套件：251226，服務：251226，函式庫：251226
78 - QPKG 啟用：false
79 - 應用程式自動更新：true
80 - 活動 git 分支：main
81 - 守護程序 PID：無
82 = 來源：sickgear.sh，動作：停止，時間：2026年1月12日 星期一 11:38:24 PM EET，結果：OK，耗時：142毫秒，負載：2.29
83 ⟨E2⟩⟨80⟩⟨A2⟩
84 - 來源：sickgear.sh，動作：啟動，時間：2026年1月12日 星期一 11:38:34 PM EET，負載：3.17
85 - 套件：251226，服務：251226，函式庫：251226
86 - QPKG 啟用：true
87 - 應用程式自動更新：true
88 - 活動 git 分支：main
89 - 守護程序 PID：無
90 - 檔案存在：/opt/bin/git
91 > 從遠端儲存庫更新 'SickGear'：OK
92 - 活動 git 分支：main
93 > 從設定檔載入埠口：OK
94 > 啟動守護程序：OK
95 > 監控守護程序名稱出現（不超過120秒）：OK
96 = 程序名稱於1秒內出現
97 > 等待10秒以確認 PID 仍存活：完成
98 - 守護程序 PID：無
99 w 守護程序 PID 檢查失敗：似乎啟動後發生故障
100 ~ 重試 1/3
101 > 啟動守護程序：OK
102 > 監控守護程序名稱出現（不超過132秒）：w 未找到程序名稱（超時：132秒）
102 秒
103 > 等待10秒以確認 PID 仍存活：完成
104 - 守護程序 PID：無
105 w 守護程序 PID 檢查失敗：似乎啟動後發生故障
106 ~ 重試 2/3
107 > 啟動守護程序：OK
108 > 監控守護程序名稱出現（不超過120秒）：w 未找到程序名稱（超時：120秒）
108 秒
109 > 等待18秒以確認 PID 仍存活：
好的，讓我們先進行一次 clean：
/etc/init.d/sickgear.sh clean
…然後以除錯模式執行 start：
/etc/init.d/sickgear.sh start debug
如果你看到守護程序檢查失敗一次，請用 CTRL+C 取消。請回報你在執行 start 操作時看到的內容。
[~] # /etc/init.d/sickgear.sh clean
- 來源：sickgear.sh，動作：清理，時間：2026年1月12日 星期一 11:52:54 PM EET，負載：8.48
- 套件：251226，服務：251226，函式庫：251226
- QPKG 啟用：true
- 應用程式自動更新：true
- 活動 git 分支：main
- 守護程序 PID：無
> 清理本地儲存庫：OK
> 清理虛擬 Python 環境：OK
> 清理 PyPI 快取：OK
> 清理暫存路徑：OK
= 來源：sickgear.sh，動作：清理，時間：2026年1月12日 星期一 11:52:56 PM EET，結果：OK，耗時：2,556毫秒，負載：8.20
到目前為止都很好……現在用 debug 來 start。
你是指這個嗎？
成功安裝 orjson-3.11.5 rapidfuzz-3.14.3
} exec: 完成 OK (0)
> 從設定檔載入埠口：OK
> 啟動守護程序：
{ 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: 完成 OK (0)
> 監控守護程序進程名稱是否出現（最多 132 秒）：1，OK
> 等待 11 秒以確認 PID 仍然存活：1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 完成
- 守護程序 PID：無
w 守護程序 PID 檢查失敗：啟動後似乎發生故障
~ 重試 1/3
> 啟動守護程序：
{ 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: 完成 OK (0)
> 監控守護程序進程名稱是否出現（最多 120 秒）：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 未找到進程名稱（超過時限：120 秒）
> 等待 10 秒以確認 PID 仍然存活：1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 完成
- 守護程序 PID：無
w 守護程序 PID 檢查失敗：啟動後似乎發生故障
~ 重試 2/3
讓我們嘗試手動非守護程序啟動。這將嘗試以互動模式啟動 SickGear。請複製並貼上以下整個指令並執行：
/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
之前有 3 篇貼文的限制，也許現在已經沒有了……
[~] # /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
正在從 /share/MD0_DATA/.qpkg/SickGear/config/config.ini 啟動 SickGear
00:03:48 INFO TORNADO :: SickGear 正在 http://0.0.0.0:8081/ 啟動
00:03:48 INFO MAIN :: 資料庫結構已是最新，無需升級
00:03:48 INFO MAIN :: 正在檢查資料庫結構……
00:03:48 INFO MAIN :: 正在檢查資料庫結構……
00:03:48 INFO MAIN :: 沒有孤立集數，檢查通過
00:03:48 INFO MAIN :: 沒有未播出集數，檢查通過
00:03:48 ERROR MAIN :: 執行查詢時發生致命錯誤：資料庫磁碟映像已損壞
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: 資料庫磁碟映像已損壞
00:03:48 INFO MAIN :: SickGear.Start() 捕獲到例外，資料庫磁碟映像已損壞：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: 資料庫磁碟映像已損壞
看來它不接受你舊安裝的原始 SickGear 資料庫。
我猜你需要重建你的電視節目資料庫。這表示要清除目前的資料庫，然後用全新的設定啟動 SickGear，接著讓它掃描你現有的電視節目。
我們先用乾淨的設定啟動 SickGear，並確保它能正確載入：
/etc/init.d/sickgear.sh reset-config
…然後再用除錯模式 start 它：
/etc/init.d/sickgear.sh start debug
- 沒有設定檔，使用預設作為範本
- 來源：sickgear.sh，動作：啟動，時間：2026年1月13日 星期二 12:09:25 AM EET，負載：2.19
- 套件：251226，服務：251226，函式庫：251226
- QPKG 啟用：true
- 應用程式自動更新：true
- 活動 git 分支：main
- 守護程序 PID：無
- 檔案存在：/opt/bin/git
> 從遠端儲存庫更新 'SickGear'：
{ 執行：'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 現在位於 8769b3d 合併分支 'hotfix/3.34.9'
已是最新狀態。
} 執行：完成 OK (0)
- 活動 git 分支：main
> 從設定檔載入埠口：OK
> 啟動守護程序：
{ 執行：'/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'
} 執行：完成 OK (0)
> 監控守護程序進程名稱出現（不超過120秒）：1，OK
> 等待10秒以確認 PID 仍存活：1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 完成
- 守護程序 PID：31186
- 守護程序監聽位址：0.0.0.0
- HTTPS 埠口啟用：false
- HTTP 埠口：7181
> 測試埠口 7181 回應（不超過120秒）：OK
> 使用 UI 埠口更新 QPKG 圖示：OK
= 來源：sickgear.sh，動作：啟動，時間：2026年1月13日 星期二 12:09:42 AM EET，結果：OK，耗時：0小時:00分:17秒，負載：2.59