又有壞消息（真的沒完沒了）：Lidarr 的開發者現在編譯的二進位檔需要 libc 2.29 或更高版本，而這在 QTS 上是無法取得的。
所以，目前為止，Lidarr 套件無法運行。現有的 Lidarr 用戶在下次更新後會發現安裝損壞，並且 Lidarr 將在下一個穩定版 QPKG 發布時從 sherpa 支援中移除。
如果你想繼續使用這個應用程式，可以在 myQNAP 儲存庫中找到各種版本，但這些需要購買 Stéphane 的核心 QPKG。
你也許可以將現有的設定檔轉移過去。但在安裝 myQNAP 版本之前，請務必手動備份你的設定檔。
你的 sherpa Lidarr 應該透過 QTS 應用中心手動解除安裝。
p.s. 有沒有人知道如何編譯較新版本的 glibc 並讓特定應用程式使用？如果會的話，我需要你的協助，請聯絡我。
嗨，
關於 nzbMedia 路徑，我又發現了一個小問題。
最近我發現我的 SabNZB 裡的腳本突然不能用了，結果發現 nzbMedia 的腳本現在連結到 /share/Public/Downloads，而不是原本的 /share/Download
所以我看了一下 nzbmedia.sh：
default_download_share 是從 /etc/config/def_share.info 讀取的。我的檔案內容如下：
[SHARE_DEF]
defPublic = Public
defDownload = Download
defMultimedia = Multimedia
defRecordings = none
defUsb = Usb
defWeb = Web
defVolMP = /share/CACHEDEV1_DATA
所以我這邊會得到 /share/CACHEDEV1_DATA/Download。
但在 nzbmedia.sh 裡有這段判斷：
if [[ -z $default_download_share ]]||[[ -n $default_download_share && ! -L $default_download_share ]];then
default_download_share=unspecified
fi
而這裡的 ! -L $default_download_share 就是問題所在。
-L 是「如果檔案存在且是符號連結則為 True」。
但 /share/CACHEDEV1_DATA/Download 是實際的共享資料夾位置，是一個資料夾而不是符號連結。
/share/Download 才是正確的符號連結。
所以 default_download_share=unspecified 被設定，最後腳本的符號連結就建立在 /share/Public/Download。
我暫時的解決方法是在 /etc/config/qpkg.conf 加入了這一行 Scripts_Path = /share/Download。但我不確定這樣在 nzbMedia-QPKG 更新後還會不會有效。
所以如果 @OneCD 有在開發新版 QPKG，也許這裡還需要一個小修正。
嗨，朋友，感謝你分享你的發現。
新的 nzbToMedia QPKG 已經完成，但正在等待下一個 sherpa 軟體包的發布（我希望會在這個週末）。我已經修改了 nzbToMedia QPKG 的邏輯，現在它是自給自足的，不會再嘗試連結到其他應用程式（如 SABnzbd 或 nzbget）所使用的下載位置。
現在由使用者自行決定要在哪裡建立這個連結——甚至不再需要符號連結（symlink）。這意味著後處理腳本不再需要放在「downloads」路徑下。
對於現有用戶，他們已經有一個連結。對於新用戶（或現有用戶想要更改腳本位置），只需在 SABnzbd（或 nzbget）中直接設定「Scripts Folder」位置。
剩下的就是我需要建立一個新的 wiki 頁面來解釋這些內容。
新的 sherpa 套件版本已經發佈到 GitHub：v20251108
這次有很多變更，如有任何問題請告知。希望一切能像之前一樣正常運作。
nzbToMedia QPKG 的操作方式也有變更，詳情請見：How to use the new nzbToMedia QPKG · OneCDOnly/sherpa Wiki · GitHub
此外，對於 Sonarr、Readarr 和 Whisparr 的使用者，請在升級 QPKG 之後重新啟動您的 NAS。升級過程中可能會出現失敗報告：請忽略這些報告並照常重新啟動。
好久不見.. 在今天的更新中，scripts 資料夾消失了.. 它已經不在 share/CACHEDEV1_DATA/.qpkg/nzbToMedia/repo-cache 了
nzbToMedia 安裝在哪裡？
getcfg nzbToMedia Install_path -f /etc/config/qpkg.conf
在這個目錄下有 repo-cache 嗎？
ll $(getcfg nzbToMedia Install_path -f /etc/config/qpkg.conf)/repo-cache
我必須堅持下去，但現在已經運作了，腳本現在可以使用了..謝謝
腳本現在位於倉庫的根目錄..
當你克隆 GitHub 儲存庫時，nzbToMedia 腳本應該會在那裡。
你有把自己的腳本加到 repo-cache 嗎？
@Potestus，非常重要的是你不要把自己的腳本放在 repo-cache。每次升級 nzbToMedia 時，這個位置都會被清除。
如果你有自己的腳本，請告訴我，我們可以一起討論如何處理它們。 
我現在在 sab 裡遇到 watcher 3 的錯誤嗎？
Watcher3: 後處理失敗 - 狀態已更改為 Disabled！
我還是以 sideload 方式運行
ClamAV * 不相容的作者 N/A N/A N/A /share/CAC>
Entware - 已啟用，運作中 不支援 1.03a 1.03a /share/CAC>
Headphones - 已啟用，運作中 啟動 (OK) 251116 dynamic /share/CAC>
LazyLibrarian - 已啟用，運作中 啟動 (OK) 251116 dynamic /share/CAC>
nzbToMedia - 已啟用，運作中 啟動 (OK) 251116 dynamic /share/CAC>
OSickGear - 已啟用，運作中 啟動 (OK) 250628 dynamic /share/CAC>
Par2turbo - 已啟用，運作中 不支援 1.2.0 1.2.0 /share/CAC>
SABnzbd - 已啟用，運作中 啟動 (OK) 251116 dynamic /share/CAC>
sherpa - 已啟用，運作中 啟動 (OK) 251101 251101 /share/CAC>
Unrar - 已啟用，運作中 不支援 7.0.8 7.01 beta 1 /share/CAC>
我該怎麼辦…它還能用，但這個錯誤很煩人…？
嗨，朋友。
Watcher3 已經不再開發了。由於沒有人維護，它會以各種有趣且不可預測的方式繼續出錯。
建議改用 Radarr。
Hello @onecd…. 又是我……那個只有在事情出錯時才會出現的麻煩新手 
最近我的 QNAP 進行了更新。不確定是不是從那時開始就出問題了，但總之，我又來了。
我可以打開並看到大部分由 sherpa 安裝的程式——radarr、sonarr 等等。不過，我的下載器 SABNZBD 無法連線。我已經在應用中心裡停止/重啟過它，但當我用本地 IP:8900 進入時，卻遇到 ERR_CONNECTION_REFUSED……
我用 putty 嘗試了 sudo sherpa reinstall sabnzbd，但沒有解決問題……我真的試過了……
沒有你，這台 qnap 早就丟到垃圾桶了
嗨，朋友。
你可以用服務腳本檢查 SABnzbd 的狀態嗎？
/etc/config/sabnzbd.sh s
- QPKG 啟用：true
- 應用程式自動更新：true
- 使用中的 git 分支：master
- 守護程序 PID：無
希望這就是你要找的？
沒錯，就是那個。
現在，嘗試啟動它：
/etc/init.d/sabnzbd.sh start
! 無法安裝附加元件：虛擬 Python 環境不存在
= 來源：sabnzbd.sh，動作：start，時間：2025年12月3日 星期三 11:59:13 PM CST，結果：
嗯……
作為這個論壇的新用戶，我對同一主題只能回覆3次（“暫時”）。所以我必須編輯這篇文章（如果允許的話）來回覆你……
[Eric@QNAP451 ~]$ sudo /etc/init.d/sabnzbd.sh clean
- 來源：sabnzbd.sh，動作：clean，時間：2025年12月4日 星期四 12:02:59 AM CST，負載：0.18
- 套件：251121，服務：251121，函式庫：251121
- QPKG 啟用：true
- 應用程式自動更新：true
- 活動 git 分支：master
- 守護程序 PID：無
> 清理本地儲存庫：OK
> 清理虛擬 Python 環境：OK
> 清理 PyPI 快取：OK
> 清理暫存路徑：OK
= 來源：sabnzbd.sh，動作：clean，時間：2025年12月4日 星期四 12:02:59 AM CST，結果：OK，耗時：76ms，負載：0.18
[Eric@QNAP451 ~]$ sudo /etc/init.d/sabnzbd.sh start
- 來源：sabnzbd.sh，動作：start，時間：2025年12月4日 星期四 12:03:14 AM CST，負載：0.14
- 套件：251121，服務：251121，函式庫：251121
- QPKG 啟用：true
- 應用程式自動更新：true
- 活動 git 分支：
- 守護程序 PID：無
- 檔案存在：/opt/bin/git
> 從遠端儲存庫建立 'SABnzbd'：OK
- 活動 git 分支：master
> 建立新的虛擬 Python 環境：失敗
> 建立 QPKG 'pip' 設定：OK
> 新增位置 '/share/CACHEDEV1_DATA/.qpkg/SABnzbd/pip-cache' 為 'pip' 快取：OK
> 新增位置 '/share/CACHEDEV1_DATA/.qpkg/SABnzbd/qpkg-wheels' 至 'pip' 搜尋路徑：OK
! 無法安裝附加元件：虛擬 Python 環境不存在
= 來源：sabnzbd.sh，動作：start，時間：2025年12月4日 星期四 12:03:15 AM CST，結果：FAILED，耗時：1,431ms，負載：0.14
[Eric@QNAP451 ~]$
保持它們為最新？沒有特意這麼做……除非它會自動更新，我沒有執行過任何相關指令。Qnap 會自動進行韌體更新，但我盡量不去動 Sherpa 的底層設定，因為我已經很不好意思來這裡求助了……
好的，讓我們清理並啟動它：
/etc/init.d/sabnzbd.sh clean
/etc/init.d/sabnzbd.sh start
順帶一提：你的 sherpa QPKG 有保持更新嗎？
我剛剛提升了你的用戶等級，看看現在是否可以了。
別擔心，朋友，我在這裡就是為了幫忙。
你的套件版本相當新，所以情況還不算太糟。
讓我們看看 sherpa 能不能修復這個問題：
sherpa check