התקנת Chaptarr לניהול ספרי שמע על שרת VPS

מהו Chaptarr ומדוע משתמשי Readarr זקוקים לו

Chaptarr הוא fork של Readarr המנהל ספרי שמע וספרים אלקטרוניים מתוך מופע יחיד. הוא מנטר מהדורות חדשות, שולח אותן ללקוח ההורדות שלכם, ולאחר מכן משנה את שמות הקבצים ומסדר אותם בספרייה שלכם. הוא אינו מנגן תוכן, לכן יש לשלב אותו עם נגן כגון Audiobookshelf.

הפיתוח של Readarr הופסק ב-27 ביוני 2025. ההודעה הרשמית של צוות Servarr מפרטת את הסיבה: המטא-דאטה של הפרויקט הפך לבלתי שמיש, והמאמץ הקהילתי למעבר ל-Open Library נתקע. המאגר הועבר לארכיון. מצב זה הותיר אוספי ספרים וספרי שמע ללא מנהל מתוחזק, ו-Chaptarr נטל על עצמו את המשימה. הוא שומר על המבנה המוכר לכם מ-Sonarr ומ-Radarr (אינדקסרים, לקוחות הורדה, פרופילי איכות, תיקיות שורש) ומוסיף יכולות טיפול בספרי שמע: ארגון מבוסס קריינים, מהדורות מרובות לאותו כותר, תמיכה ב-M4B וב-MP3 עם פרקים, והמרה מ-MP3 ל-M4B.

מדריך זה השתמש בתגית האימג' chaptarr/chaptarr:0.9.925, שהייתה המהדורה החדשה ביותר ב-9 באוגוסט 2026. נכון ל-11 באוקטובר 2026, המהדורה החדשה ביותר היא 0.9.965, שפורסמה ב-27 בספטמבר 2026. השלבים להלן נבדקו על גרסה 0.9.925 בלבד, ולכן הקבצים שומרים על תגית זו; קראו את הערות המהדורה לפני שתעברו לגרסה חדשה יותר. Chaptarr מגדיר את עצמו כתוכנת בטא. קראו את סעיף התחזוקה לקראת סוף המדריך לפני שתפנו אותו לספרייה שאינכם יכולים לשחזר.

מה נדרש לפני שמתחילים

שרת VPS המריץ את Docker ואת התוסף Compose, ושטח אחסון מספיק עבור הספרייה. ספרי שמע תופסים נפח רב, ופעולת ייבוא שאינה יכולה להשתמש ב-hardlinks שומרת זמנית שני עותקים של הקובץ, כפי שמוסבר בסעיף ה-volumes להלן. אם Docker עדיין לא מותקן על השרת, התחילו ב-התקנה והרצה של Docker על שרת VPS וחזרו לכאן.

נכון לעכשיו, Chaptarr מופץ כ-Docker image בלבד. תמיכה מקומית (native) מוגדרת כעבודה בתהליך, מתוכננת גרסת Windows ניסיונית, ואין חבילות הפצה זמינות. הקונטיינר מאחסן את מסד הנתונים שלו ב-/config כ-SQLite כברירת מחדל, והוא יכול להשתמש בשרת PostgreSQL חיצוני באמצעות משתני סביבה מסוג Chaptarr__Postgres__* אם אתם כבר מריצים שרת כזה. עבור משתמש יחיד על שרת בודד, SQLite היא הבחירה המתאימה.

שירות ה-Compose עבור Chaptarr

שירות זה משתלב במערך קיים. הוא מקבע תג גרסה ששוחרר, חושף את ממשק ה-web ב-loopback בלבד, ומצטרף לרשת שבה כבר משתמש לקוח ההורדות שלכם.

services:
  chaptarr:
    image: chaptarr/chaptarr:0.9.925
    container_name: chaptarr
    environment:
      - PUID=1000
      - PGID=1000
      - UMASK=002
      - TZ=Europe/Berlin
    volumes:
      - ./config:/config
      - /srv/media/audiobooks:/audiobooks
      - /srv/media/ebooks:/ebooks
      - /srv/media/downloads:/downloads
    ports:
      - 127.0.0.1:8789:8789
    restart: unless-stopped
    networks:
      - arr

networks:
  arr:
    external: true

השורה external: true מציינת "רשת זו כבר קיימת, התחבר אליה". השתמשו בה כאשר Prowlarr ולקוח ה-torrent שלכם מגיעים ממיזם Compose נפרד, שכן אחרת קובץ Compose שני יוצר רשת מבודדת משלו ו-Chaptarr לעולם לא יוכל לפתור את qbittorrent לפי שם. השיגו את השם האמיתי באמצעות docker network ls. אם המערך שלכם כבר נמצא בקובץ אחד, הוסיפו את שירות chaptarr: לאותו קובץ ומחקו את כל בלוק ה-networks:. המבנה הרחב יותר מכוסה ב-מערך arr מלא תחת Docker Compose, וכללי השמות ב-כיצד רשתות Compose ושמות שירותים נפתרים.

צרו את תיקיית התצורה בעצמכם, ולאחר מכן הפעילו אותו.

mkdir -p ./config
sudo chown 1000:1000 ./config
docker compose up -d
docker compose ps
docker compose logs -f chaptarr

docker compose ps אמור להציג את המכולה כ-Up. מכולה שמופיעה כ-Restarting נכשלה בעלייה ומתבצעים ניסיונות חוזרים להפעלתה; קראו את הלוגים שלה כדי למצוא את הסיבה. הלוג מפסיק לרוץ ברגע שהיישום מאזין בפורט 8789.

PUID, PGID והספרייה ש-Docker יוצר כ-root

כאשר משאירים את PUID=99 ו-PGID=100 ללא הגדרה, Chaptarr משתמשת בערכי ברירת המחדל שלהם. אלו הם ערכים המיועדים ל-unRAID, ובשרת VPS מבוסס Ubuntu הם אינם משויכים למשתמש בעל הרשאות מתאימות; כתוצאה מכך, קבצים נוצרים עם בעלות שאינה מאפשרת למשתמש שלכם לבצע בהם פעולות כתיבה. בדקו את המספרים שלכם באמצעות הפקודות id -u ו-id -g והזינו אותם לקובץ.

כל מכולה (container) שניגשת לאותם קבצים חייבת להשתמש באותו זוג ערכים. לקוח ההורדות כותב ל-/srv/media/downloads, Chaptarr מעבירה את הקובץ ל-/srv/media/audiobooks, והנגן קורא אותו משם. אם לקוח ההורדות כותב כ-1000:1000 ו-Chaptarr רצה כ-99:100, תהליך הייבוא ייכשל. הבעלות על הקובץ אינה הגורם הקובע: יצירה, שינוי שם או מחיקה של קובץ דורשים הרשאות כתיבה בספרייה המכילה אותו. ספריות שנוצרו על ידי משתמש 1000 עם מצב 755 נפוץ אינן מעניקות ל-99:100 הרשאות כתיבה, ולכן Chaptarr לא תוכל לשייך את הספר לספרייה ולא תוכל למחוק אותו מתיקיית ההורדות. UMASK=002 מאפשרת כתיבה לקבוצה עבור קבצים חדשים, וזהו המצב הרצוי כאשר כמה מכולות חולקות קבוצת מדיה אחת. המיפוי המלא מופיע ב-כיצד PUID ו-PGID ממפים משתמש מכולה לקבצי המארח.

ה-README ממליץ ליצור את ספריית התצורה מראש ולהימנע משימוש ב-override של user: ב-Compose. אם ./config אינה קיימת בעת הרצת docker compose up, Docker תיצור אותה עבורכם, כשהבעלים הוא root:root. בגרסה הנעוצה 0.9.925, נקודת הכניסה (entrypoint) מתחילה כ-root ומתקנת את הבעלות על /config ועל קובצי מסד הנתונים שלה לפני שהיא עוברת ל-UID ו-GID שהוגדרו, כך שספרייה חדשה בבעלות root בדרך כלל אינה גורמת ללולאת אתחול. שימוש ב-override של user: עוקף את תהליך ההגדרה הזה, ו-mount לקריאה בלבד או מערכת קבצים שאינה מאפשרת שינויי בעלות עלולים למנוע כתיבה למסד הנתונים. בדקו זאת באמצעות ls -ln ./config, המציגה בעלים מספריים במקום שמות. שני אפסים מציינים שהבעלים הוא root. אם הלוגים מאשרים כשל בהרשאות בספרייה מקומית שניתן לכתוב אליה, תקנו זאת באמצעות sudo chown -R 1000:1000 ./config והפעילו את המכולה מחדש.

מדוע הפרדת נפחי ספרי שמע וספרים אלקטרוניים מונעת שימוש ב-hardlinks

המבנה שלעיל מעגן את /audiobooks, /ebooks ו-/downloads כ-bind mounts נפרדים, בהתאם לפקודת ההרצה של הפרויקט עצמו. מבנה זה קריא ונוח, אך יש לו מחיר אחד משמעותי: הפסקת העבודה של hardlinks.

‏Hardlink הוא שם נוסף לאותו מידע על הדיסק. הוא אינו צורך שטח אחסון נוסף ופעולתו מיידית, וזו הסיבה שמשפחת ה-arr מעדיפה אותו על פני העתקה. ‏Hardlink עובד רק בתוך מערכת קבצים אחת. בתוך ה-container אלו הן שלוש נקודות עיגון (mount points) נפרדות, לכן ה-kernel מסרב ליצור את הקישור גם כאשר הנתיבים ב-host נמצאים על אותו דיסק. ניתן לבדוק זאת בעצמכם.

docker exec chaptarr sh -c 'touch /downloads/linktest && ln /downloads/linktest /audiobooks/linktest'

הפקודה נכשלת עם שגיאה שמסתיימת ב-Invalid cross-device link. זהו ה-kernel שמסרב לבצע קישור בין נקודות עיגון שונות, וזו הסיבה המדויקת לכך ש-Chaptarr חוזר לביצוע העתקה של הקובץ. ההעתקה תקינה אך איטית יותר, וספר השמע קיים כעת פעמיים עד למחיקת ה-torrent, דבר שלא תעשו כל עוד אתם עדיין בסטטוס seeding. מחקו את /srv/media/downloads/linktest לאחר מכן.

כדי לשמר את ה-hardlinks, עגנו תיקיית אב אחת בלבד:

    volumes:
      - ./config:/config
      - /srv/media:/data

לאחר מכן, הגדירו את תיקיות השורש בתוך Chaptarr ל-/data/audiobooks ו-/data/ebooks, ותנו ללקוח ההורדות את אותו עיגון /srv/media:/data כך ששני ה-containers יראו נתיב זהה. ודאו תחילה שהצד של ה-host הוא מערכת קבצים אחת: df -h /srv/media/downloads /srv/media/audiobooks חייב להציג את אותו ערך בעמודת ה-Filesystem עבור שניהם. ערכים שונים משמעותם דיסקים שונים, ושום מבנה עיגון לא יאפשר יצירת hardlinks ביניהם. הפשרה בין שיטה זו לבין named storage מפורטת ב-bind mounts מול named volumes עבור מדיה.

גישה לממשק הניהול ללא חשיפה לרשת

שורת ה־port מפרסמת את השירות ב־127.0.0.1 מסיבה מסוימת. ufw deny 8789 אינו מגן על פורט של Docker שפורסם, כיוון ש־Docker כותב חוקי NAT (תרגום כתובות רשת) משלו לשרשרת שהקרנל ניגש אליה לפני זו של ufw, ולכן התעבורה מועברת לפני שהחוק שלכם נבדק בכלל. התנהגות זו מפתיעה משתמשים לעיתים קרובות, והיא מוסברת ב־מדוע פורט של Docker שפורסם מתעלם מחוקי ה-ufw שלכם. קישור (binding) ל-loopback עוקף זאת לחלוטין.

גשו לממשק המשתמש דרך מנהרת SSH מהמחשב שלכם:

ssh -N -L 8789:127.0.0.1:8789 you@your-server

השאירו את התהליך רץ ופתחו את http://127.0.0.1:8789 בדפדפן. הגדירו אימות (authentication) בהרצה הראשונה. רק לאחר מכן כדאי לשקול שימוש ב-reverse proxy עם TLS (אבטחת שכבת תעבורה) לפניו. ברגע שתתחילו להשתמש במנהרות עבור שלושה או ארבעה כלים כאלו, כשבכל אחד מהם סיסמה נפרדת, הפתרון המסודר יותר הוא להציב את ה-proxy מאחורי שרת Single Sign-On בניהול עצמי כגון Authentik, כך שחיבור אחד יכסה את כל היישומים וביטול הרשאה אחד יחסום את כולם.

חיבור אינדקסרים ולקוח הורדות

Chaptarr משתמש בפרוטוקולים הסטנדרטיים של אינדקסרים ולקוחות הורדות מסדרת ה-arr. לכן, Prowlarr דוחף אליו אינדקסרים באותה הדרך שבה הוא עושה זאת עבור Sonarr, ולקוחות ה-torrent וה-usenet הרגילים מתחברים ללא צורך בטיפול מיוחד.

הגדרה אחת גורמת כמעט לכולם לטעות. כאשר Chaptarr מבקש את כתובת המארח (host) של לקוח ההורדות, אל תקלידו localhost או 127.0.0.1. בתוך מכולה (container), כתובת זו היא המכולה עצמה; לכן, Chaptarr מנסה לתקשר עם פורט 8080 של עצמו ומדווח על כשל בחיבור. השתמשו בשם המכולה, qbittorrent, עם הפורט 8080. ודאו ששתי המכולות נמצאות על אותה רשת באמצעות הפקודה docker network inspect arr, המציגה את כל המכולות המחוברות לפי שם.

אם לקוח ההורדות שלכם רץ דרך מכולת VPN עם network_mode: "service:gluetun", אין לו שם משלו ברשת, כיוון שהוא חולק את מרחב השמות (namespace) של הרשת עם Gluetun. פנו אליו כ-gluetun בפורט ש-Gluetun חושף. סידור זה, והניתוב הנלווה אליו, מפורטים ב-ניתוב לקוח הורדות דרך Gluetun.

המעבר ל-Readarr: מהו המחיר האמיתי של הגירה

Chaptarr אינו תואם למקורות המטא-דאטה של Readarr. הוא מבצע רזולוציה של כותרים, מחברים ומהדורות באמצעות צינור עיבוד נתונים (pipeline) עצמאי מול ספקים שונים, ולכן המזהים ש-Readarr שמר אינם רלוונטיים כאן. אין אפשרות לייבוא מסד נתונים ואין נתיב שדרוג ישיר.

עבור ספרייה קיימת, המשמעות היא שהקבצים בטוחים אך ההגדרות אינן כאלו. שום שלב בתהליך זה אינו נוגע למה שכבר קיים על הדיסק. עליך להוסיף תיקיית שורש (root folder), להריץ ייבוא ספרייה, ו-Chaptarr יבצע התאמה בין הקבצים שהוא מוצא לבין המטא-דאטה שלו. מה שתצטרך לבנות מחדש ידנית: פרופילי איכות, פורמט שמות קבצים, הגדרות אינדקסרים ולקוחות, וכל התאמה שגויה ש-Chaptarr יבצע. ספרייה גדולה תדרוש סבב תיקונים ידני, לכן הקצה לכך ערב שלם ולא עשר דקות.

בצע את הפעולות לפי הסדר הבא. עצור את ה-container של Readarr אך שמור את ה-volume של ההגדרות שלו, כדי שתוכל לקרוא את ההגדרות הישנות בזמן שאתה מקליד אותן מחדש. כוון את Chaptarr לתיקייה קטנה אחת תחילה ובדוק את ההתאמות לפני שאתה מייבא את הכל. הסר את ה-container הישן רק לאחר שאתה מרוצה מהתוצאות.

פרט פרטיות אחד שכדאי לדעת לפני סריקת ספרייה שלמה: חיפושי מטא-דאטה מופנים ל-api2.chaptarr.com. ה-README מציין כי בקשות אלו עשויות לשאת מזהי ספק, טקסט חיפוש, סוג מדיה, תגיות ושמות קבצים, וכי הן אינן כוללות נתיבים מלאים, זהות משתמש או פרטי הזדהות. שמות קבצים עוזבים את השרת שלך. זהו מצב תקין עבור שירות מטא-דאטה, אך עליך להחליט על כך במודע.

העברת ספרי השמע לנגן

Chaptarr מארגן קבצים. השמעתם היא תפקידה של תוכנה אחרת, ו-Audiobookshelf הוא השותף המקובל לכך, כיוון שהוא עוקב אחר מיקום ההאזנה שלכם בין מכשירים שונים וכולל אפליקציות לטלפון. האימג' הרשמי שלו הוא ghcr.io/advplyr/audiobookshelf:latest, ודוגמת ה-Compose המתועדת שלו מפרסמת את פורט 13378 של המארח אל פורט 80 של המכולה.

  audiobookshelf:
    image: ghcr.io/advplyr/audiobookshelf:latest
    container_name: audiobookshelf
    ports:
      - 127.0.0.1:13378:80
    volumes:
      - ./abs/config:/config
      - ./abs/metadata:/metadata
      - /srv/media/audiobooks:/audiobooks
    environment:
      - TZ=Europe/Berlin
    restart: unless-stopped

בצעו mount לאותו נתיב מארח שאליו Chaptarr כותב, ולאחר מכן הוסיפו את /audiobooks כספרייה בתוך ממשק ה-web. ייבוא חדש יופיע לאחר הסריקה הבאה.

אם אתם כבר מריצים את Jellyfin, תוכלו להוסיף את התיקייה כספרייה שם והוא ינגן את הקבצים. הגדרת צד זה מכוסה ב-הרצת Jellyfin כשרת מדיה על גבי VPS. עבור החלק של הספרים האלקטרוניים, העבירו את /srv/media/ebooks ליישום קורא; תפקידו של Chaptarr מסתיים ברגע שהקובץ מקבל שם ומאוחסן.

סיכוני תחזוקה: רישיון, סביבת הרצה ותג גרסה דינמי

Chaptarr מופץ תחת רישיון GPL-3.0, זכויות היוצרים שייכות לתורמי Chaptarr עם חלקים מצוות Servarr, כך שהקוד נשאר פתוח וכל אחד יכול לבצע לו fork נוסף אם המפתח הנוכחי יפסיק את פעילותו. הפרויקט מבוסס על .NET 10, גרסת ה-LTS (תמיכה לטווח ארוך) העדכנית של סביבת ההרצה נכון לאוגוסט 2026, מה שאומר שהבסיס נתמך לשנים ולא לחודשים. שתי העובדות הללו חשובות אם אתם מעריכים האם הפרויקט הזה עדיין יהיה קיים בשנה הבאה.

מספרי הגרסאות מתעדכנים במהירות. גרסה 0.9.925 פורסמה ב-9 באוגוסט 2026, וחמישה עדכונים נוספים הגיעו בשבעת השבועות שלאחר מכן. כל גרסה עד 0.9.958 פורסמה כ-pre-release; גרסה 0.9.965, מה-27 בספטמבר 2026, היא הראשונה שמסומנת כגרסה מלאה. קבעו תג (tag) מדויק. שימוש ב-latest אומר ש-docker compose pull לא מנוטר עלול להקפיץ אתכם כמה גרסאות בשבוע, ופרויקט fork צעיר כל כך יכול לשנות את ה-API שלו בין גרסאות, מה שישבור כל סקריפט או לוח בקרה שכתבתם מולו. קיבוע גרסאות הוא הרגל שכדאי לאמץ לכל פרויקט צעיר שאתם מארחים בעצמכם, וזו הסיבה שהמדריך ל-הרצת openGym כמעקב אימונים בניהול עצמי פורס מתג git קבוע מאותה סיבה בדיוק.

בצעו גיבוי לפני כל שדרוג, ולאחר מכן שדרגו באופן יזום.

docker compose stop chaptarr
sudo tar czf chaptarr-config-backup.tgz ./config
docker compose start chaptarr

docker compose pull chaptarr
docker compose up -d chaptarr

הפרויקט מדווח על אפס אירועי אובדן נתונים לאורך כשישה חודשים ועם יותר מאחד-עשר אלף משתמשים, אך הוא עדיין ממליץ לשמור גיבויים ולא להפנות אותו לספרייה שאינכם יכולים להרשות לעצמכם לאבד. התייחסו לשני חלקי ההמלצה ברצינות. העתיקו את ארכיון התצורה מחוץ לשרת, כיוון שגיבוי שנמצא על אותו דיסק של המידע שהוא מגן עליו אינו גיבוי. קובץ tarball יחיד זה מכסה את המצב המקומי של היישום כיוון שהוא כולל את מסדי הנתונים של SQLite ואת התצורה תחת /config; כל מה שנמצא על שרת מסד נתונים נפרד דורש גם את גיבוי מסד הנתונים, שזו צורת הפעולה של שלב הגיבוי כאשר מארחים את Chatwoot ב-VPS לצד נתוני ה-Postgres והקבצים שהועלו.

מצבי כשל והודעות שגיאה נפוצות

המכולה מבצעת אתחול בלולאה. docker compose ps מציג Restarting. קראו תחילה את docker compose logs chaptarr. בעלות של root על ./config אינה מסבירה כשלעצמה את הלולאה: נקודת הכניסה (entrypoint) בדרך כלל מתקנת את הבעלות על הקבצים לפני הפעלת היישום. אם הלוגים מדווחים שתיקיית הנתונים אינה ניתנת לכתיבה, בדקו אם קיימת דריסת user: ב-Compose, mount במצב קריאה בלבד, או מערכת קבצים שאינה מאפשרת שינויי בעלות. הסירו את הדריסה כדי לאפשר ל-entrypoint לבצע את ההגדרה; עבור בעלות שגויה בתיקייה מקומית שניתן לכתוב אליה, הריצו את sudo chown -R 1000:1000 ./config.

ייבוא אינו מסתיים וקבצים נשארים בתיקיית ההורדות. Chaptarr מסוגל לקרוא את ההורדה אך אינו יכול לכתוב לספרייה. השוו את ls -ln /srv/media/audiobooks מול ה-PUID וה-PGID שלכם. תיקייה בבעלות UID שונה, או בבעלות הקבוצה שלכם ללא הרשאות כתיבה לקבוצה, תמנע את העברת הקבצים. UMASK=002 מונע את המקרה השני עבור קבצים חדשים.

ניצול הדיסק מוכפל לאחר כל ייבוא. לא נוצר hardlink, ולכן הקובץ הועתק. הריצו את בדיקת ln מתוך סעיף ה-volumes. שגיאה שמסתיימת ב-Invalid cross-device link מאשרת זאת, והפתרון הוא שימוש ב-mount בעל הורה יחיד (single-parent mount).

לקוח ההורדות אינו מתחבר. הזנתם את localhost בתור ה-host. בתוך המכולה, זהו Chaptarr עצמו. השתמשו בשם המכולה ובדקו ש-docker network inspect arr מציג את שתי המכולות.

Compose מסרב להפעיל את השירות. Bind for 127.0.0.1:8789 failed: port is already allocated מציין שמשהו אחר תופס את הפורט. מצאו אותו באמצעות sudo ss -lntp | grep 8789.

הדפדפן אינו מציג דבר. כאשר הפורט קשור ל-127.0.0.1, אין שום דבר שהמחשב הנייד שלכם יכול להתחבר אליו דרך האינטרנט. זוהי התנהגות מכוונת. פתחו תחילה מנהרת SSH.

FAQ

האם ניתן להעביר את ספריית ה-Readarr שלי ל-Chaptarr?

לא באמצעות ייבוא ישיר. Chaptarr אינו תואם למקורות המטא-דאטה של Readarr ומשתמש בצינור ספקים (provider pipeline) משלו, לכן המזהים השמורים של Readarr חסרי משמעות ואין אפשרות להמיר את מסד הנתונים. הקבצים שלך על הדיסק נשארים ללא שינוי. עליך להוסיף את אותם נתיבים כתיקיות שורש (root folders), להריץ ייבוא ספרייה, ולתת ל-Chaptarr לבצע התאמה לקבצים בעצמו. פרופילי איכות, פורמט שמות, הגדרות אינדקסרים וכל התאמה שגויה דורשים עבודה ידנית, לכן מומלץ להתחיל עם תיקייה קטנה אחת לפני ייבוא של הכל.

מדוע Chaptarr לא יכול לכתוב לתיקיית ספרי השמע שלי?

למשתמש של המכולה (container) אין הרשאות כתיבה על אותה תיקייה, בדרך כלל משום שהוא רץ תחת UID שונה מזה שבבעלותו התיקייה. Chaptarr חוזר לערכי ברירת המחדל PUID=99 ו-PGID=100 כאשר משתנים אלו אינם מוגדרים; אלו ערכים של unRAID והם שגויים בשרת VPS מבוסס Ubuntu סטנדרטי. הגדירו אותם ל-id -u ו-id -g שלכם, השתמשו באותו זוג בלקוח ההורדות, והגדירו את UMASK=002 כדי שקבצים חדשים יישארו ניתנים לכתיבה על ידי הקבוצה. בדקו בעלות עם ls -ln על תיקיית הספרייה, מכיוון שהפקודה מציגה מספרים במקום שמות ולא ניתן להשוות ביניהם אחרת.

מדוע ניצול הדיסק שלי הוכפל לאחר הייבוא?

Chaptarr העתיק את הקובץ מכיוון שלא היה יכול ליצור קישור קשיח (hardlink). מיפוי של /downloads ו-/audiobooks כ-binds נפרדים הופך אותם לנקודות עיגון (mount points) נפרדות בתוך המכולה, וה-kernel מסרב לבצע קישור קשיח בין נקודות עיגון שונות עם השגיאה Invalid cross-device link. עגנו תיקיית אב אחת כגון /srv/media:/data והשתמשו ב-/data/downloads ו-/data/audiobooks בתוך היישום. שני הנתיבים חייבים גם לשבת על אותה מערכת קבצים מארחת, עובדה שניתן לאמת עם df -h.

האם Chaptarr מנגן את ספרי השמע שלי?

לא. הוא מוצא, מוריד, משנה שמות ומסדר אותם, אך הניגון הוא תפקידה של תוכנה נפרדת. Audiobookshelf הוא השילוב הנפוץ מכיוון שהוא זוכר את מיקום הניגון שלך בין מכשירים שונים, תוך שימוש בתמונה הרשמית ghcr.io/advplyr/audiobookshelf:latest עם אותו נתיב ספרי שמע מארח מעוגן. גם Jellyfin ינגן את הקבצים אם תוסיף את התיקייה כספרייה.

האם בטוח להריץ את Chaptarr על ספרייה שחשובה לי?

זוהי תוכנת בטא מתוך fork צעיר, והפרויקט מצהיר על כך בעצמו, אם כי לא דווח על אירועי אובדן נתונים במשך כשישה חודשים ועל ידי יותר מאחד-עשר אלף משתמשים. החלקים המרגיעים הם רישיון ה-GPL-3.0, ששומר על הקוד כניתן להפצה, והבסיס של .NET 10, שהוא runtime עם תמיכה ארוכת טווח (LTS) נכון לאוגוסט 2026. קבעו תג תמונה מדויק כגון 0.9.925 במקום latest, בצעו גיבוי ל-/config לפני כל שדרוג, ושמרו את הארכיון מחוץ לשרת.