良さそうですね。
これで、SickGear（SickGear）をもう一度最初からセットアップすることになります。
古い設定ファイルを使って作業を簡単にすることはできますか？
現在の番組を何らかの方法でスキャンして追加する方法はありましたか？
バックアップがいくつかあるようですね？
[/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
少なくともbak（バックアップ）は、昔自分で作ったものかもしれません…
ご覧になっているファイルは新しく作成されたものです。これらは元の設定ファイルではありません。元の設定ファイルとデータベースは、sherpaの設定バックアップディレクトリにまだ保存されています。
現在抱えている問題は、バックアップされた場所に保存されているデータベースが、現在のSickGearインスタンスで受け入れられていないことです。この件についてSickGearの開発者に相談してみるのも良いでしょう。ただし、データベースを一から再構築するように勧められる可能性もあります。
今、SickGearの稼働中インスタンスは手元にありませんが、Medusaの場合はShowsメニューから「Add Existing Shows（既存の番組を追加）」を選択し、既存の番組ディレクトリを指定します。これにより一括インポートが可能です。
本当の問題は設定です。APIキーやすべての設定を更新する必要があります。
助けてくれてありがとう、今は（ほとんど）動いています。データベースも再作成して、その点はうまくいくことを願っています。3投稿制限…権限を上げてくれてありがとう。
まだ分からないのは、なぜ nzbtomedia/sickgear（シックギア）がエピソードを TV/show/season フォルダに保存せず、/share/MD0_DATA/TV/Catastrophe.2015.S01E05.1080p.AMZN.WEB-DL.DD5.1.x264-DRACULA のように TV フォルダ直下に保存してしまうのかということです。
おそらくとても明白なことだと思いますが、気づけていません。
Sickgear のエピソード命名は Season 02/Show.Name.S02E03.HD.TV-RLSGROUP.ext で、ポストプロセッシングは空欄にしています…
申し訳ありませんが、そこはお手伝いできません。SickGear の関係者や、SickGear の設定に詳しい方に相談する必要があるかもしれません。
また、nzbToMedia QPKG は 2025年11月にアップデートされ、現在は動作が異なることを思い出しました: How to use the new nzbToMedia QPKG · OneCDOnly/sherpa Wiki · GitHub
こんばんは、友人よ――ただいま戻りました！Sonarr（ソナー）で問題が発生しています。最近、GUIにアクセスするたびにオフラインになっています。QNAPアプリセンターでは稼働中と表示されているので、一度停止してから再起動しています。すると問題なく立ち上がるのですが、最終的にはまたシャットダウンしてしまいます。
Sonarrのログによると、アップデートを試みてシャットダウンするものの、再起動されないようです。Grok（グロック）を使って何とか解決しようと頑張りましたが、結局は自分の尻尾を追いかけているような気分になりました。
あなたなら3ラウンド以内で解決できると分かっているので、また甘えに来ました 
こんにちは、友人。
では、クリーンアップを試してみましょう：
/etc/init.d/sonarr.sh clean
…その後起動しなかった場合は、以下で起動してください：
/etc/init.d/sonarr.sh start
返信ありがとうございます… 参考までにお伝えしますが、設定/一般/アップデートに入り、アップデートを無効にしたところ、それ以降ずっとオンラインのままです。
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 ~]$
クリーンコマンドを実行した時も動作していて、その後確認した時も動作していました。ただし、前述の通り自動アップデートのチェックはオフにしています… 自動アップデートを再びオンにした方がいいでしょうか、それともこのままにしておいた方がいいでしょうか？
良い判断です。はい、内部アプリケーションの自動アップデートは無効のままにしてください。
アップデートするには、QPKGを再起動してください。これにより最新のアプリケーションパッケージが自動的にダウンロード・インストールされます。
たぶん、どこかで内部をいじってはいけないところまで手を加えてしまったんだと思います 「QPKGを再起動する」とは、QNAPアプリセンターからアプリケーションを停止して再起動するだけでいいのでしょうか？
はい。
内部アプリケーションのアップデートが正常に動作すれば良いのですが、現時点ではサポートできません。そのため、QPKGを再起動してアプリケーションをアップデートする必要があります。
正しい方向に導いてくれてありがとう。これは問題ですらなかったのに…いつものように自分で問題を作り出してしまったよ 本当に感謝してるよ、‘mate…
今日、sherpa check が sherpa fix に変更されたことに気付きました 
はい、実際にやっていることにより合っていますね。
小さなアップデート：
Entwareパッケージが最近アップデートされ、Python3が3.13.9に更新されました。
その結果、Mylar3 およびWatcher3はサポートされなくなりました。Watcher3はすでに開発が終了しており、Mylar3の開発者たちもPython 3.13への互換性をすぐに確保する予定はありません。
これらのQPKGはApp Center経由でアンインストールしてください。
Entwareのアップデートによって。gitおよびgit-httpのIPKも動作しなくなっています。つまり、リポジトリからgitソースを取得するQPKGはすべて失敗します
現在、一時的な対応策に取り組んでおり、まもなくリリースする予定です。
本日、新しいパッケージがリリースされました！うまく動くことを願っています。
また、重要な変更があります：QPKGは今後、デフォルトで再起動時に自動更新されなくなります。これは各QPKGごとに再度有効化できますが、オペレーターが設定する必要があります。これにより、より安定して高速な体験が得られるはずです。
QPKG名: ステータス: 最終操作（結果）: QPKGバージョン: アプリ>
Entware - 有効、非アクティブ 非対応 1.03a 1.>
こんにちは、「非アクティブ」とはどういう意味ですか?!
これは、SherpaがEntware QPKGのインストールを検出しましたが、QTSで起動されておらず利用できないことを意味します。
Entwareを再起動していただけますか？
/etc/init.d/entware.sh restart
[~] # /etc/init.d/entware.sh restart
-sh: /etc/init.d/entware.sh: そのようなファイルやディレクトリはありません
[~] # cd /etc/init.d/
[/etc/init.d] # ls
add_cloud_key.sh* porter.sh*
add_cloud_nat_rule.sh* power_button.sh*
addshare.sh* poweroff*
adjust_sync_speed.sh* pp_qcoolie.sh*
ads_register_dns.sh* push_notification_daemon.sh*
AdvancedNetDriver.sh.patch* pw_sleep.sh*
adv_net_drv.sh* qaccess.sh*
antivirus.sh* qanalytic_init.sh*
atalk.sh* qapi.sh*
avahi.sh* qat_setup.sh*
aws_key.sh* qboost.sh@
backup_conf.sh* qbutton.sh*
bcclient.sh* qcloud_blob_daemon.sh*
bluetooth.sh* qcloud_init.sh*
bonjour.sh@ QcloudSSLCertificate.sh@
boot_done.sh* qdff_mount.sh*
cacd.sh* qlsmd.sh*
callhome_upload_disk_phy_event.sh* qm2_nic.sh*
callhome_upload_disk_smart.sh* QMediaService.sh*
callhome_upload_fan.sh* qmigrate.sh*
callhome_upload_network_nic.sh* qpkg_res.sh@
callhome_upload_network_stack.sh* qpkg.sh@
callhome_upload_psu.sh* qplayd.sh*
cdrom.sh* qraid1.sh*
check_bootcmd.sh* qsnapman.sh*
check_ddns_external_ip.sh* qstorman.sh*
check_fw_update_cs.sh* qsyncsrv_install.sh*
check_lan_port.sh* qsyncsrv.sh@
_check_nss2* qtag.sh*
check_nss2* Qthttpd.sh*
check_service_noshare_run* qts_notice.sh*
chkcfgpart.sh* qulog.sh@
cloudinstall_finish.sh* qunetswitch.sh*
cloudinstall_init_daemon.sh* radius.sh*
cloudinstall_init.sh* radvd.sh*
cloudinstall_report_complete_daemon.sh* rcK*
cloudinstall_report_offline.sh* rcS*
convert2_ext4.sh* rcS_normal*
create_udev_rule.sh* rcv_port.sh*
crond.sh* reboot*
cs_daemon.sh* recoverd.sh*
cs_fw_verify.sh* recycled.sh*
cs_verify_tool* refresh_internet_status.sh*
da_iotest.sh* refresh_nvr_crontab.sh*
dbus.sh* report_cloud_platform.sh*
ddns_update_for_cgi.sh* reset_all.sh*
ddns_update.sh* reset_sata.sh*
disk_data_collection.sh* reset_tl_rxx00pes.sh*
dump_all_trct_log.sh* reverse_proxy.sh*
enc_migrate.sh* rfsd.sh*
Entware.sh@ root_cert
変ですね、そのようなファイルは存在しないのに、Entware.sh@ がリストにあります。「@」はファイル名の末尾についていますが、これは何でしょうか？