VPS پر audiobooks کے لیے Chaptarr خود host کریں

Chaptarr کیا ہے، اور Readarr صارفین کو اس کی ضرورت کیوں ہے

Chaptarr، Readarr کا ایک fork ہے جو ایک ہی instance سے audiobooks اور ebooks کا انتظام کرتا ہے۔ یہ نئی releases پر نظر رکھتا ہے، انہیں آپ کے download client کو بھیجتا ہے، پھر حاصل شدہ فائلوں کے نام تبدیل کرکے انہیں آپ کی library میں منظم کرتا ہے۔ یہ کوئی media play نہیں کرتا، اس لیے اسے Audiobookshelf جیسے player کے ساتھ استعمال کریں۔

Readarr کو 27 June 2025 کو retire کر دیا گیا تھا۔ Servarr ٹیم کے اپنے notice میں وجہ بیان کی گئی ہے: project کا metadata ناقابل استعمال ہو گیا تھا، اور Open Library پر منتقل ہونے کی community کوشش رک گئی تھی۔ repository archive کر دی گئی ہے۔ اس کے نتیجے میں book اور audiobook collections بغیر کسی maintained manager کے رہ گئے، اور Chaptarr نے یہ ذمہ داری سنبھال لی۔ اس میں Sonarr اور Radarr سے پہلے سے معلوم structure برقرار ہے، جس میں indexers، download clients، quality profiles اور root folders شامل ہیں۔ اس کے علاوہ audiobook handling بھی شامل ہے: narrator کو مدنظر رکھتے ہوئے organisation، ایک ہی title کی متعدد editions، M4B اور chaptered MP3 support، اور MP3 کو M4B میں تبدیل کرنا۔

اس walkthrough میں image tag chaptarr/chaptarr:0.9.925 استعمال کیا گیا، جو 9 August 2026 کو تازہ ترین release تھا۔ Chaptarr خود کو beta software کہتا ہے۔ اسے ایسی library سے منسلک کرنے سے پہلے جسے آپ تبدیل نہیں کر سکتے، آخر میں موجود maintenance section پڑھیں۔

شروع کرنے سے پہلے درکار چیزیں

ایک VPS جس پر Docker اور Compose plugin چل رہے ہوں، اور library کے لیے کافی disk space ہو۔ Audiobooks بڑی فائلیں ہوتی ہیں، اور ایسا import جو hardlinks استعمال نہیں کر سکتا، کچھ وقت کے لیے فائل کی دو copies رکھتا ہے۔ ذیل کا volume section اس کی وضاحت کرتا ہے۔ اگر اس box پر ابھی Docker موجود نہیں ہے تو VPS پر Docker انسٹال اور چلائیں سے شروع کریں اور پھر یہاں واپس آئیں۔

Chaptarr فی الحال صرف Docker image کے طور پر دستیاب ہے۔ Native Windows build کو in progress کے طور پر درج کیا گیا ہے، اور کوئی distribution package موجود نہیں ہے۔ Container اپنی database کو /config میں بطور default SQLite کے طور پر محفوظ کرتا ہے، اور اگر آپ پہلے سے PostgreSQL server چلا رہے ہیں تو Chaptarr__Postgres__* environment variables کے ذریعے external PostgreSQL server استعمال کر سکتا ہے۔ ایک box پر ایک user کے لیے SQLite موزوں انتخاب ہے۔

Chaptarr کے لیے Compose سروس

یہ سروس پہلے سے موجود stack میں شامل ہو جاتی ہے۔ اس میں جاری کردہ tag مقرر کیا گیا ہے، web UI صرف loopback پر دستیاب ہے، اور یہ اس network سے منسلک ہوتی ہے جسے آپ کا download client پہلے ہی استعمال کرتا ہے۔

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 لائن کا مطلب ہے: "یہ network پہلے سے موجود ہے، اسے اس سے منسلک کریں۔" اسے اس وقت استعمال کریں جب Prowlarr اور آپ کا torrent client کسی دوسرے Compose project سے آتے ہوں، کیونکہ دوسری Compose file بصورتِ دیگر اپنا الگ isolated network بناتی ہے۔ ایسی صورت میں Chaptarr، qbittorrent کو نام کے ذریعے resolve نہیں کر سکتا۔ اصل نام docker network ls سے حاصل کریں۔ اگر آپ کا stack پہلے ہی ایک ہی file میں موجود ہے تو chaptarr: سروس اسی file میں شامل کریں اور پورا networks: block حذف کر دیں۔ مجموعی layout کی وضاحت Docker Compose کے تحت مکمل arr stack میں، جبکہ naming rules کی وضاحت Compose networks اور service names کیسے resolve ہوتے ہیں میں کی گئی ہے۔

config directory خود بنائیں، پھر اسے start کریں۔

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

docker compose ps میں container کو Up کے طور پر دکھایا جانا چاہیے۔ اگر container Restarting کے طور پر درج ہو تو وہ start ہونے میں ناکام ہوا ہے اور دوبارہ کوشش کی جا رہی ہے۔ اس کی وجہ تقریباً ہمیشہ config directory ہوتی ہے۔ جب app port 8789 پر listening شروع کر دے تو log scrolling رک جاتی ہے۔

PUID، PGID، اور وہ ڈائریکٹری جسے Docker root کے طور پر بناتا ہے

اگر آپ PUID=99 اور PGID=100 متعین نہ کریں تو Chaptarr پہلے سے PUID=99 اور PGID=100 استعمال کرتا ہے۔ یہ unRAID کی values ہیں۔ عام Ubuntu VPS پر یہ کسی مفید user سے متعلق نہیں ہوتیں، اس لیے فائلیں ایسے owner کے ساتھ محفوظ ہوتی ہیں جس میں آپ کا login لکھ نہیں سکتا۔ id -u اور id -g سے اپنے اعداد معلوم کریں اور انہیں فائل میں درج کریں۔

ایک ہی فائلوں تک رسائی رکھنے والے ہر container کے لیے یہی pair درکار ہے۔ download client /srv/media/downloads میں لکھتا ہے، Chaptarr فائل کو /srv/media/audiobooks میں منتقل کرتا ہے، اور player اسے وہیں سے پڑھتا ہے۔ اگر download client 1000:1000 کے طور پر لکھے اور Chaptarr 99:100 کے طور پر چلے تو import ناکام ہو جاتا ہے، کیونکہ Chaptarr ایسی فائل کو delete یا move نہیں کر سکتا جس کا owner وہ نہ ہو۔ UMASK=002 نئی فائلوں کو group-writable بناتا ہے۔ جب متعدد containers ایک ہی media group استعمال کریں تو یہی مطلوبہ طرزِ عمل ہے۔ مکمل mapping PUID اور PGID کس طرح container user کو host files سے map کرتے ہیں میں موجود ہے۔

README ایک مخصوص مسئلے سے خبردار کرتا ہے، اور اسے دہرانا ضروری ہے۔ اگر ./config کو docker compose up چلاتے وقت موجود نہ ہو تو Docker اسے خود بناتا ہے اور اس کا owner root:root مقرر کرتا ہے۔ اس کے بعد container UID 1000 کے طور پر چلتا ہے اور اپنے database میں لکھ نہیں سکتا، اس لیے وہ exit ہو کر مسلسل restart ہوتا رہتا ہے۔ ls -ln ./config سے تصدیق کریں۔ یہ ناموں کے بجائے numeric owners دکھاتا ہے۔ دو zeros کا مطلب ہے کہ owner root ہے۔ اسے sudo chown -R 1000:1000 ./config سے درست کریں اور container دوبارہ start کریں۔

الگ الگ audiobook اور ebook volumes کی وجہ سے hardlinks کام نہیں کرتے

اوپر والا layout /audiobooks، /ebooks اور /downloads کو الگ الگ binds کے طور پر mount کرتا ہے، جو project کے اپنے run command سے مطابقت رکھتا ہے۔ اسے سمجھنا آسان ہے، لیکن اس کی ایک حقیقی قیمت ہے: hardlinks کام کرنا بند کر دیتے ہیں۔

hardlink ڈسک پر موجود اسی data کا دوسرا نام ہوتا ہے۔ یہ اضافی جگہ استعمال نہیں کرتا اور فوراً بن جاتا ہے، اسی لیے arr family اسے copying پر ترجیح دیتی ہے۔ hardlink صرف ایک ہی filesystem کے اندر کام کرتا ہے۔ Container کے اندر یہ تین الگ mount points ہیں، اس لیے kernel link بنانے سے انکار کر دیتا ہے، چاہے host paths ایک ہی disk پر موجود ہوں۔ خود اس کی جانچ کریں۔

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

یہ command ایسے error پر ناکام ہوتی ہے جس کا اختتام Invalid cross-device link پر ہوتا ہے۔ اس کا مطلب ہے کہ kernel mount points کے درمیان link بنانے سے انکار کر رہا ہے، اور یہی وہ وجہ ہے جس کے باعث Chaptarr file کو copy کرنے پر آ جاتا ہے۔ Copy درست ہوتی ہے، لیکن سست ہوتی ہے، اور audiobook اس وقت تک دو مرتبہ موجود رہتی ہے جب تک آپ torrent حذف نہ کریں۔ جب تک آپ seeding کر رہے ہوں گے، آپ torrent حذف نہیں کریں گے۔ اس کے بعد /srv/media/downloads/linktest حذف کریں۔

hardlinks برقرار رکھنے کے لیے ایک parent directory mount کریں:

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

اس کے بعد Chaptarr میں root folders کو /data/audiobooks اور /data/ebooks پر set کریں، اور download client کو بھی وہی /srv/media:/data mount دیں تاکہ دونوں containers کو ایک جیسا path نظر آئے۔ پہلے تصدیق کریں کہ host side ایک ہی filesystem پر ہے: df -h /srv/media/downloads /srv/media/audiobooks کے output میں دونوں کے لیے Filesystem column میں ایک ہی value ہونی چاہیے۔ مختلف values کا مطلب ہے کہ disks مختلف ہیں، اور کوئی بھی mount layout ان کے درمیان hardlink نہیں بنا سکتا۔ اس طریقے اور named storage کے درمیان trade-off کی وضاحت media کے لیے bind mounts اور named volumes کا موازنہ میں کی گئی ہے۔

ویب UI تک رسائی، اسے public طور پر ظاہر کیے بغیر

port line میں 127.0.0.1 استعمال کرنے کی وجہ ہے۔ ufw deny 8789 published Docker port کو محفوظ نہیں کرتا، کیونکہ Docker اپنی NAT (network address translation) rules ایک ایسی chain میں لکھتا ہے جس تک kernel، ufw کی chain سے پہلے پہنچتا ہے۔ اس لیے traffic آپ کی rule پر غور ہونے سے پہلے ہی forward ہو جاتا ہے۔ یہ رویہ اکثر لوگوں کو مشکل میں ڈالتا ہے، اور اس کی وضاحت published Docker port آپ کی ufw rules کو کیوں نظرانداز کرتا ہے میں کی گئی ہے۔ loopback پر bind کرنے سے یہ مسئلہ مکمل طور پر ختم ہو جاتا ہے۔

اپنی مشین سے SSH tunnel کے ذریعے UI تک رسائی حاصل کریں:

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

یہ tunnel چلتا رہنے دیں اور اپنے browser میں http://127.0.0.1:8789 کھولیں۔ پہلی بار چلانے پر authentication ترتیب دیں۔ اس کے بعد ہی اس کے سامنے TLS (transport layer security) کے ساتھ reverse proxy استعمال کرنے پر غور کریں۔ جب آپ ان میں سے تین یا چار tools تک الگ الگ tunnel بنا کر ہر ایک میں الگ password استعمال کر رہے ہوں، تو زیادہ منظم حل یہ ہے کہ proxy کے پیچھے Authentik جیسا self-hosted single sign-on server رکھیں، تاکہ ایک login سے ہر app تک رسائی ملے اور ایک revocation سے سبھی کی رسائی بند ہو جائے۔

انڈیکسرز اور download client کو مربوط کریں

Chaptarr معیاری arr indexer اور download client protocols استعمال کرتا ہے۔ اس لیے Prowlarr، Sonarr کی طرح ہی indexers کو اس میں بھیجتا ہے، اور عام torrent اور usenet clients بغیر کسی خصوصی configuration کے connect ہو جاتے ہیں۔

ایک setting تقریباً ہر شخص کو الجھا دیتی ہے۔ جب Chaptarr download client کے host کے بارے میں پوچھے تو localhost یا 127.0.0.1 درج نہ کریں۔ container کے اندر یہ address خود اسی container کا ہوتا ہے۔ اس لیے Chaptarr اپنے ہی port 8080 سے رابطہ کرنے کی کوشش کرتا ہے اور connection failure رپورٹ کرتا ہے۔ اس کے بجائے port 8080 کے ساتھ container name، qbittorrent، استعمال کریں۔ docker network inspect arr سے تصدیق کریں کہ دونوں containers ایک ہی network پر ہیں۔ یہ command network سے منسلک ہر container کو اس کے name کے ساتھ دکھاتی ہے۔

اگر آپ کا download client VPN container کے ذریعے network_mode: "service:gluetun" کے ساتھ چلتا ہے تو network پر اس کا اپنا کوئی name نہیں ہوتا، کیونکہ یہ Gluetun کا network namespace شیئر کرتا ہے۔ اسے اس port پر gluetun کے طور پر address کریں جسے Gluetun expose کرتا ہے۔ اس arrangement اور اس سے متعلق routing کی تفصیل Gluetun کے ذریعے download client کو route کرنا میں ہے۔

Readarr میں تعطل: منتقلی کی اصل لاگت

Chaptarr، Readarr کے metadata sources کے ساتھ compatible نہیں ہے۔ یہ متعدد providers کے ذریعے اپنی pipeline میں titles، authors اور editions resolve کرتا ہے، اس لیے Readarr میں محفوظ identifiers یہاں کوئی معنی نہیں رکھتے۔ Database import موجود نہیں ہے، اور نہ ہی براہِ راست upgrade کا راستہ ہے۔

موجودہ library کے لیے اس کا مطلب ہے کہ files محفوظ رہتی ہیں، لیکن settings محفوظ نہیں رہتیں۔ اس عمل میں disk پر پہلے سے موجود کسی چیز کو نہیں چھیڑا جاتا۔ آپ ایک root folder شامل کرتے ہیں، library import چلاتے ہیں، اور Chaptarr ملنے والی files کو اپنے metadata کے مطابق match کرتا ہے۔ آپ کو یہ چیزیں دستی طور پر دوبارہ بنانی ہوں گی: quality profiles، naming format، indexer اور client settings، اور ہر وہ match جس میں Chaptarr غلطی کرے۔ بڑی library میں دستی corrections کا ایک مرحلہ درکار ہوگا، اس لیے دس منٹ کے بجائے ایک شام کا وقت مختص کریں۔

یہ کام اسی ترتیب سے کریں۔ Readarr container کو stop کریں، لیکن اس کا config volume برقرار رکھیں، تاکہ settings دوبارہ درج کرتے وقت آپ پرانی settings پڑھ سکیں۔ پہلے Chaptarr کو ایک چھوٹے folder کی طرف point کریں اور مکمل import سے پہلے matches کی جانچ کریں۔ پرانے container کو صرف اس وقت remove کریں جب آپ نتائج سے مطمئن ہوں۔

پوری library scan کرنے سے پہلے privacy کی ایک بات جاننا ضروری ہے: metadata lookups api2.chaptarr.com کو بھیجے جاتے ہیں۔ README کے مطابق ان requests میں provider IDs، search text، media type، tags اور filenames شامل ہو سکتے ہیں، جبکہ full paths، user identity اور credentials شامل نہیں ہوتے۔ Filenames آپ کے server سے باہر بھیجے جاتے ہیں۔ Metadata service کے لیے یہ معمول کی بات ہے، لیکن پھر بھی یہ فیصلہ جان بوجھ کر کریں۔

آڈیو بکس کسی پلیئر کے حوالے کریں

Chaptarr فائلوں کو منظم کرتا ہے۔ انہیں چلانا کسی دوسرے پروگرام کا کام ہے، اور Audiobookshelf عموماً موزوں انتخاب ہے، کیونکہ یہ مختلف devices پر آپ کی listening position محفوظ رکھتا ہے اور phone apps بھی فراہم کرتا ہے۔ اس کی official image ghcr.io/advplyr/audiobookshelf:latest ہے، اور اس کی documented Compose مثال host port 13378 کو container port 80 پر publish کرتی ہے۔

  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

وہی host path mount کریں جس میں Chaptarr فائلیں لکھتا ہے، پھر web UI میں /audiobooks کو library کے طور پر شامل کریں۔ اگلی scan کے بعد نیا import ظاہر ہو جائے گا۔

اگر آپ پہلے سے Jellyfin چلا رہے ہیں تو اس folder کو وہاں library کے طور پر شامل کر کے فائلیں چلا سکتے ہیں، تاہم ایک ہی طویل audiobook file کے لیے resume behaviour purpose-built audiobook server کے مقابلے میں کم مؤثر ہوتا ہے۔ اس حصے کی configuration VPS پر Jellyfin کو media server کے طور پر چلانا میں بیان کی گئی ہے۔ ebook کے لیے /srv/media/ebooks کسی reader application کے حوالے کریں؛ Chaptarr کا کام اس وقت مکمل ہو جاتا ہے جب file کو نام دے کر درست جگہ پر رکھ دیا جائے۔

مینٹیننس کا خطرہ: لائسنس، runtime، اور تیزی سے بدلتا ہوا tag

Chaptarr کا لائسنس GPL-3.0 ہے۔ اس کا copyright Chaptarr کے contributors کے پاس ہے، جبکہ اس میں کچھ حصے Servarr team سے لیے گئے ہیں۔ اس لیے code open رہتا ہے، اور اگر موجودہ maintainer کام چھوڑ دے تو کوئی بھی اسے دوبارہ fork کر سکتا ہے۔ یہ .NET 10 پر مبنی ہے، جو August 2026 تک runtime کی موجودہ long term support release ہے۔ اس کا مطلب ہے کہ بنیادی runtime کو مہینوں کے بجائے کئی سال تک support حاصل رہے گا۔ اگر آپ یہ جانچ رہے ہیں کہ آیا یہ project اگلے سال بھی موجود رہے گا، تو دونوں حقائق اہم ہیں۔

Version numbers تیزی سے بدلتے ہیں۔ Releases کو pre-releases کے طور پر شائع کیا جاتا ہے، اور 0.9.925 اسی دن جاری ہوا جس دن یہ walkthrough لکھا گیا۔ کسی exact tag کو pin کریں۔ latest استعمال کرنے سے unattended docker compose pull ایک ہفتے میں آپ کو کئی versions آگے لے جا سکتا ہے۔ اتنے نئے fork میں releases کے درمیان API بھی تبدیل ہو سکتی ہے، جس سے اس کے خلاف لکھی گئی کوئی بھی script یا dashboard کام کرنا چھوڑ سکتی ہے۔

ہر upgrade سے پہلے backup لیں، پھر upgrade جان بوجھ کر کریں۔

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

یہ project تقریباً چھ ماہ اور 11000 سے زیادہ users کے دوران data loss کا کوئی واقعہ رپورٹ نہیں کرتا، پھر بھی یہ backups رکھنے اور اسے ایسی library کی طرف point نہ کرنے کا مشورہ دیتا ہے جس کے ضائع ہونے کا نقصان آپ برداشت نہ کر سکیں۔ ان دونوں باتوں کو سنجیدگی سے لیں۔

config archive کو server سے باہر copy کریں، کیونکہ جس disk پر محفوظ کی جانے والی چیز موجود ہو، اسی disk پر رکھا ہوا backup دراصل backup نہیں ہوتا۔ یہ واحد tarball صرف اس لیے کافی ہے کہ Chaptarr اپنی state ایک SQLite file میں /config کے تحت رکھتا ہے۔ کسی الگ database server پر موجود data کے لیے database dump بھی بنانا ہوگا۔ یہی backup step کی صورت بنتی ہے جب VPS پر Chatwoot کو self-host کرنا ہو اور اس کے Postgres data اور uploaded files بھی ساتھ موجود ہوں۔

خرابی کی صورتیں، اور دکھائی دینے والے پیغامات

کنٹینر بار بار restart ہوتا ہے۔ docker compose ps میں Restarting دکھائی دیتا ہے۔ ls -ln ./config چلائیں۔ owner columns میں دو صفر ظاہر کرتے ہیں کہ Docker نے directory کو root کے طور پر بنایا ہے اور container user اپنی database میں لکھ نہیں سکتا۔ sudo chown -R 1000:1000 ./config چلائیں۔

Imports کبھی مکمل نہیں ہوتے اور files downloads میں رہتی ہیں۔ Chaptarr download کو پڑھ سکتا ہے، لیکن library میں لکھ نہیں سکتا۔ ls -ln /srv/media/audiobooks کا اپنے PUID اور PGID سے موازنہ کریں۔ کسی مختلف UID کی ملکیت والی directory، یا ایسی directory جس کا owner آپ کا group ہو لیکن group write permission نہ ہو، file کو منتقل ہونے سے روکتی ہے۔ نئی files کے لیے UMASK=002 دوسری صورت کو روکتا ہے۔

ہر import کے بعد disk usage دوگنا ہو جاتا ہے۔ hardlink نہیں بنایا گیا، اس لیے file copy ہو گئی۔ volumes section کا ln test چلائیں۔ Invalid cross-device link پر ختم ہونے والی error اس کی تصدیق کرتی ہے، اور single-parent mount اس کا حل ہے۔

Download client connect نہیں ہوتا۔ آپ نے host کے طور پر localhost درج کیا ہے۔ container کے اندر یہ خود Chaptarr ہے۔ container name استعمال کریں اور جانچیں کہ docker network inspect arr دونوں containers دکھاتا ہے۔

Compose service start کرنے سے انکار کرتا ہے۔ Bind for 127.0.0.1:8789 failed: port is already allocated کا مطلب ہے کہ کوئی اور process port استعمال کر رہا ہے۔ sudo ss -lntp | grep 8789 سے اسے تلاش کریں۔

Browser میں کچھ بھی ظاہر نہیں ہوتا۔ جب port 127.0.0.1 پر bound ہو تو internet کے ذریعے آپ کے laptop کے connect کرنے کے لیے کچھ موجود نہیں ہوتا۔ یہی مطلوبہ رویہ ہے۔ پہلے SSH tunnel کھولیں۔

FAQ

کیا میں اپنی Readarr library کو Chaptarr میں منتقل کر سکتا ہوں؟

Import کے طور پر نہیں۔ Chaptarr، Readarr کے metadata sources کے ساتھ compatible نہیں ہے اور اپنی provider pipeline استعمال کرتا ہے، اس لیے Readarr میں محفوظ identifiers کی یہاں کوئی معنویت نہیں رہتی اور database conversion بھی موجود نہیں ہے۔ آپ کی disk پر موجود files میں کوئی تبدیلی نہیں ہوتی۔ وہی paths بطور root folders شامل کریں، library import چلائیں، اور Chaptarr کو files خود match کرنے دیں۔ Quality profiles، naming format، indexer settings اور غلط matches کو درست کرنا دستی کام ہے، اس لیے سب کچھ import کرنے سے پہلے ایک چھوٹے folder سے آغاز کریں۔

Chaptarr میرے audiobook folder میں کیوں نہیں لکھ سکتا؟

Container کا user ان files کا مالک نہیں ہے۔ جب یہ variables unset ہوں تو Chaptarr PUID=99 اور PGID=100 پر fallback کرتا ہے۔ یہ unRAID کی values ہیں اور عام Ubuntu VPS پر غلط ہیں۔ انہیں اپنے id -u اور id -g پر set کریں، download client میں بھی یہی pair استعمال کریں، اور UMASK=002 set کریں تاکہ نئی files group-writable رہیں۔ Library directory پر ls -ln سے ownership چیک کریں، کیونکہ یہ names کے بجائے numbers دکھاتا ہے اور اسی طرح آپ values کا موازنہ کر سکتے ہیں۔

Import کے بعد disk usage دوگنا کیوں ہو گیا؟

Chaptarr نے file copy کر دی کیونکہ وہ اسے hardlink نہیں کر سکا۔ /downloads اور /audiobooks کو الگ binds کے طور پر mount کرنے سے container کے اندر یہ الگ mount points بن جاتے ہیں، اور kernel mount points کے درمیان hardlink سے انکار کرتے ہوئے Invalid cross-device link دیتا ہے۔ /srv/media:/data جیسی ایک parent directory کو mount کریں اور app کے اندر /data/downloads اور /data/audiobooks استعمال کریں۔ دونوں paths ایک ہی host filesystem پر بھی ہونے چاہئیں، جس کی تصدیق df -h کرتا ہے۔

کیا Chaptarr میری audiobooks چلاتا ہے؟

نہیں۔ یہ audiobooks تلاش، download، rename اور file کرتا ہے، جبکہ playback الگ program کی ذمہ داری ہے۔ Audiobookshelf عام طور پر اس کے ساتھ استعمال کیا جاتا ہے، کیونکہ یہ devices کے درمیان آپ کی playback position محفوظ رکھتا ہے۔ اس کے لیے official image ghcr.io/advplyr/audiobookshelf:latest استعمال کریں اور اسی host audiobook path کو mount کریں۔ اگر آپ folder کو library کے طور پر شامل کریں تو Jellyfin بھی files چلا سکتا ہے، لیکن طویل single-file audiobooks میں اس کا resume behaviour کمزور ہے۔

کیا Chaptarr کو اس library پر چلانا محفوظ ہے جس کی مجھے فکر ہے؟

یہ ایک نوجوان fork کا beta software ہے، اور project خود بھی یہی بتاتا ہے۔ تاہم project کے مطابق تقریباً چھ ماہ اور گیارہ ہزار سے زیادہ users کے دوران data loss کا کوئی واقعہ رپورٹ نہیں ہوا۔ اطمینان بخش پہلوؤں میں GPL-3.0 licence شامل ہے، جو code کو fork کرنے کے قابل رکھتا ہے، اور .NET 10 base بھی شامل ہے، جو August 2026 تک long term support runtime ہے۔ latest کے بجائے 0.9.925 جیسا exact image tag pin کریں، ہر upgrade سے پہلے /config کا backup لیں، اور اس archive کو server سے باہر محفوظ رکھیں۔