再起動のたびに、sabnzbdがインストール済みのpar2cmdline turbo qpkgを認識しません。
par2cmdline turboをsabnzbdに認識させるには、両方を手動で停止してから再起動する必要があります。
再起動時に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: () ハードウェア: CPU: Intel(R) Celeron(R) CPU J1800 @ 2.41GHz
dbug: () ハードウェア: CPUコア数: 2
dbug: () ハードウェア: CPUアーキテクチャ: x86_64
(64b)
dbug: () ハードウェア: 基本CPU SHA1ベンチマーク: 55.0MB/s
dbug: () ハードウェア: RAM: 3.74GiBdbug: () カーネル: 名前: GNU/Linux
dbug: () カーネル: バージョン: 5.10.60-qnap
dbug: () カーネル: ページサイズ: 4096B
dbug: () ファームウェア: OS: QTS
dbug: () ファームウェア: バージョン: 5.2.8.3332
dbug: () ファームウェア: ビルド日: 20251128 (金 2025年11月28日)
dbug: () ファームウェア: プラットフォーム: X86_BAYTRAIL
dbug: () OS: 状態: オンライン
dbug: () OS: 稼働時間: 11h:11m:23s
dbug: () OS: 負荷平均: 1m:0.23, 5m:0.23, 15m:0.29
dbug: () ストレージ: デフォルトボリュームマウント済み: /share/MD1_DATA
dbug: () ストレージ: 基本書き込みベンチマーク: 331MB/sdbug: () ストレージ: /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日 23:05:23 CET)
dbug: () スクリプト: オブジェクトエポック: 1765404318 (水 2025年12月10日 23:05:18 CET)
dbug: () スクリプト: パッケージエポック: 1765404085 (水 2025年12月10日 23:01:25 CET)
dbug: () スクリプト: ログパス: /share/MD1_DATA/.qpkg/sherpa/log
dbug: () QPKG: パッケージリリース: v251211 (木 2025年12月11日)
dbug: (NA) QPKG: 非公式許可: N/A
dbug: () QPKG: 署名必須: no
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を認識しない理由だと思います。しかし、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: (**) ファームウェア: OS: QTS
dbug: (**) ファームウェア: バージョン: 5.2.8.3359
dbug: (**) ファームウェア: ビルド日: 20251225 (木 25 Dec 2025)
dbug: (**) ファームウェア: プラットフォーム: X86_BRASWELL
dbug: (**) OS: 状態: オンライン
dbug: (**) OS: 稼働時間: 98h:22m:51s
dbug: (**) OS: 負荷平均: 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 (金 12 Dec 2025)
dbug: (**) スクリプト: マネージャーバージョン: 251226-stable
dbug: (**) スクリプト: マネージャーエポック: 1766706808 (金 26 Dec 2025 1:53:28 AM EET)
dbug: (**) スクリプト: オブジェクトエポック: 1766706803 (金 26 Dec 2025 1:53:23 AM EET)
dbug: (**) スクリプト: パッケージエポック: 1766706667 (金 26 Dec 2025 1:51:07 AM EET)
dbug: (**) スクリプト: ログパス: /share/MD0_DATA/.qpkg/sherpa/log
dbug: (**) QPKG: パッケージリリース: v251226 (金 26 Dec 2025)
dbug: (NA) QPKG: 非公式許可: N/A
dbug: (**) QPKG: 署名必須: no
dbug: (**) QPKG: アーキテクチャ: i64 (Intel x86-64)
dbug: (**) QPKG: Entwareインストール日: 2025-11-30 (日 30 Nov 2025)
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、経過 = 10分21秒
• 以下のパッケージ処理は正常に完了しました:
meta-rebuild SickGear QPKG 1秒
download SickGear QPKG 1秒
deactivate OSickGear QPKG 1秒
backup OSickGear QPKG 1分54秒
uninstall OSickGear QPKG 12秒
reactivate Entware QPKG 2秒
install SickGear QPKG 1分30秒 (v251226)
• このパッケージ処理はスキップされました（理由）:
"sign" SickGear QPKG 1秒（すでに署名済み）
• このパッケージ処理は失敗しました（理由）:
restore SickGear QPKG 6分19秒（4回起動を試みましたが、これ以上の再試行はできません）
[~] #
SickGearサービスのログを投稿していただけますか？
/etc/init.d/sickgear.sh log
特に、最後に実行されたアクション（restoreのはず）のログを確認したいです。各アクションブロックを識別できる場合は、最後のものだけを投稿してください。
1 - 設定ファイルなし、デフォルトをテンプレートとして使用
2 - アプリケーション自動更新: true
3 ＜E2＞＜80＞＜A2＞
4 - ソース: sickgear.sh、アクション: 開始、時刻: 2026年1月12日(月) 23:24:57 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 ＞PIDが生存していることを確認するため14秒待機: 完了
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日(月) 23:26:18 EET、結果: OK、経過: 0h:01m:22s、負荷: 5.8
34 4
35 ＜E2＞＜80＞＜A2＞
36 - ソース: sickgear.sh、アクション: 復元、時刻: 2026年1月12日(月) 23:26:26 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 ＞PIDが生存していることを確認するため14秒待機: 完了
52 - デーモン PID: なし
53 w デーモンPIDチェック失敗: 起動後に障害が発生したようです
54 ~ リトライ 1/3
55 ＞デーモン開始: OK
56 ＞デーモンプロセス名が表示されるまで監視 (最大144秒): w プロセス名が見つかりません (タイムアウト超過: 144秒)
56 秒)
57 ＞PIDが生存していることを確認するため10秒待機: 完了
58 - デーモン PID: なし
59 w デーモンPIDチェック失敗: 起動後に障害が発生したようです
60 ~ リトライ 2/3
61 ＞デーモン開始: OK
62 ＞デーモンプロセス名が表示されるまで監視 (最大120秒): w プロセス名が見つかりません (タイムアウト超過: 120秒)
62 秒)
63 ＞PIDが生存していることを確認するため10秒待機: 完了
64 - デーモン PID: なし
65 w デーモンPIDチェック失敗: 起動後に障害が発生したようです
66 ~ リトライ 3/3
67 ＞デーモン開始: OK
68 ＞デーモンプロセス名が表示されるまで監視 (最大120秒): OK
69 = プロセス名が1秒で表示された
70 ＞PIDが生存していることを確認するため10秒待機: 完了
71 - デーモン PID: なし
72 w デーモンPIDチェック失敗: 起動後に障害が発生したようです
73 ! 4回起動を試みましたが、これ以上リトライできません
74 = ソース: sickgear.sh、アクション: 復元、時刻: 2026年1月12日(月) 23:32:44 EET、結果: 失敗、経過: 0h:06m:18s、負荷: 3.64
75 ＜E2＞＜80＞＜A2＞
76 - ソース: sickgear.sh、アクション: 停止、時刻: 2026年1月12日(月) 23:38:24 EET、負荷: 2.29
77 - パッケージ: 251226、サービス: 251226、ライブラリ: 251226
78 - QPKG 有効: false
79 - アプリケーション自動更新: true
80 - アクティブな git ブランチ: main
81 - デーモン PID: なし
82 = ソース: sickgear.sh、アクション: 停止、時刻: 2026年1月12日(月) 23:38:24 EET、結果: OK、経過: 142ms、負荷: 2.29
83 ＜E2＞＜80＞＜A2＞
84 - ソース: sickgear.sh、アクション: 開始、時刻: 2026年1月12日(月) 23:38:34 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 ＞PIDが生存していることを確認するため10秒待機: 完了
98 - デーモン PID: なし
99 w デーモンPIDチェック失敗: 起動後に障害が発生したようです
100 ~ リトライ 1/3
101 ＞デーモン開始: OK
102 ＞デーモンプロセス名が表示されるまで監視 (最大132秒): w プロセス名が見つかりません (タイムアウト超過: 132秒)
102 秒)
103 ＞PIDが生存していることを確認するため10秒待機: 完了
104 - デーモン PID: なし
105 w デーモンPIDチェック失敗: 起動後に障害が発生したようです
106 ~ リトライ 2/3
107 ＞デーモン開始: OK
108 ＞デーモンプロセス名が表示されるまで監視 (最大120秒): w プロセス名が見つかりません (タイムアウト超過: 120秒)
108 秒)
109 ＞PIDが生存していることを確認するため18秒待機:
OK、それではまず 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日(月) 23:52:54 EET、負荷: 8.48
- パッケージ: 251226、サービス: 251226、ライブラリ: 251226
- QPKG有効: true
- アプリケーション自動更新: true
- アクティブなgitブランチ: main
- デーモンPID: なし
> ローカルリポジトリのクリーン: OK
> 仮想Python環境のクリーン: OK
> PyPIキャッシュのクリーン: OK
> 一時パスのクリーン: OK
= ソース: sickgear.sh、アクション: クリーン、時刻: 2026年1月12日(月) 23:52:56 EET、結果: OK、経過: 2,556ms、負荷: 8.20
ここまでは順調です…次はデバッグ付きで start してください。
これのことを言っているのでしょうか？
Successfully installed orjson-3.11.5 rapidfuzz-3.14.3
} exec: 正常に完了しました (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: 正常に完了しました (0)
> デーモンプロセス名が表示されるか監視 (最大132秒): 1, OK
> PIDが生存していることを11秒間確認: 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: 正常に完了しました (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秒超過)
> PIDが生存していることを10秒間確認: 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 :: http://0.0.0.0:8081/ で SickGear を開始します
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データベースは受け付けないみたいですね。
TV番組のデータベースを再構築する必要がありそうです。これは現在のデータベースをクリアして、SickGearを新しい設定で起動し、既存のTV番組をスキャンさせるということです。
まず、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 Merge branch 'hotfix/3.34.9'です
すでに最新です。
} 実行: 正常に完了 (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'
} 実行: 正常に完了 (0)
> デーモンプロセス名が表示されるまで監視 (最大120秒): 1, OK
> PIDが生存していることを確認するため10秒待機: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 完了
- デーモンPID: 31186
- デーモンのリッスンアドレス: 0.0.0.0
- HTTPSポート有効: false
- HTTPポート: 7181
> ポート7181の応答をテスト (最大120秒): OK
> QPKGアイコンをUIポートで更新: OK
= ソース: sickgear.sh、アクション: 開始、時刻: 2026年1月13日(火) 12:09:42 AM EET、結果: OK、経過: 0h:00m:17s、負荷: 2.59