VPS پر Chaptarr self-host کر کے audiobooks چلائیں

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

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

Readarr کو 27 June 2025 کو ریٹائر کر دیا گیا تھا۔ Servarr ٹیم کے اپنے notice میں وجہ بتائی گئی ہے: project کا metadata ناقابل استعمال ہو گیا تھا، اور Open Library پر منتقل ہونے کی community کوشش رک گئی تھی۔ repository archive کر دی گئی ہے۔ اس کے نتیجے میں books اور audiobooks کی 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 کو newest release تھا۔ 11 October 2026 تک newest release 0.9.965 ہے، جو 27 September 2026 کو published ہوئی تھی۔ ذیل کے steps صرف 0.9.925 پر test کیے گئے تھے، اس لیے files میں یہی tag موجود ہے؛ newer release پر منتقل ہونے سے پہلے release notes پڑھیں۔ Chaptarr خود کو beta software کہتا ہے۔ اسے ایسی library سے منسلک کرنے سے پہلے، جسے آپ replace نہیں کر سکتے، آخر کے قریب موجود maintenance section پڑھیں۔

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

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

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

Chaptarr کے لیے Compose سروس

یہ سروس موجودہ stack میں شامل ہو جاتی ہے۔ اس میں جاری کردہ tag مقرر کیا گیا ہے، web UI صرف loopback پر publish ہوتا ہے، اور یہ اس 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 میں موجود ہے تو اسی file میں chaptarr: سروس شامل کریں اور پورا 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 دکھائی دینی چاہیے۔ Restarting کے طور پر درج container start ہونے میں ناکام ہو چکا ہے اور دوبارہ کوشش کی جا رہی ہے؛ وجہ معلوم کرنے کے لیے اس کے logs پڑھیں۔ جب app port 8789 پر listening شروع کر دے گی تو log کی scrolling رک جائے گی۔

PUID، PGID، اور وہ directory جو Docker root کے طور پر بناتا ہے

اگر آپ PUID=99 اور PGID=100 کو unset چھوڑ دیں تو Chaptarr ان کی default values استعمال کرتا ہے۔ یہ unRAID کی values ہیں، اور عام Ubuntu VPS پر کسی مفید user سے متعلق نہیں ہوتیں۔ اس لیے files ایسے owner کے ساتھ بنتی ہیں جس میں آپ کا login write نہیں کر سکتا۔ اپنی values id -u اور id -g سے معلوم کریں اور انہیں file میں درج کریں۔

ایک ہی files کو استعمال کرنے والے ہر container کے لیے یہی pair ضروری ہے۔ Download client /srv/media/downloads میں لکھتا ہے، Chaptarr file کو /srv/media/audiobooks میں منتقل کرتا ہے، اور player وہیں سے اسے پڑھتا ہے۔ اگر download client 1000:1000 کے طور پر لکھے اور Chaptarr 99:100 کے طور پر چلے تو import ناکام ہو جاتا ہے۔ File کا owner ہونا فیصلہ کن نہیں ہے۔ File بنانے، rename کرنے یا delete کرنے کے لیے اس directory پر write permission درکار ہوتی ہے جس میں file موجود ہے۔ User 1000 کی بنائی ہوئی directories، جن پر عام 755 mode ہو، 99:100 کو write access نہیں دیتیں۔ اس لیے Chaptarr نہ book کو library میں شامل کر سکتا ہے اور نہ downloads سے اسے ہٹا سکتا ہے۔ UMASK=002 نئی files کو group-writable بناتا ہے۔ متعدد containers کے ایک ہی media group کو share کرنے کی صورت میں یہی مطلوب ہے۔ مکمل mapping PUID اور PGID کس طرح container user کو host files سے منسلک کرتے ہیں میں موجود ہے۔

README پہلے config directory بنانے اور Compose کے user: override سے گریز کرنے کی تجویز دیتا ہے۔ اگر ./config، docker compose up چلانے کے وقت موجود نہ ہو تو Docker اسے خود بناتا ہے اور اس کا owner root:root ہوتا ہے۔ pinned 0.9.925 image میں entrypoint root کے طور پر شروع ہوتا ہے۔ یہ configured UID اور GID پر منتقل ہونے سے پہلے /config اور اس کی database files کی ownership درست کرتا ہے۔ اس لیے عموماً نئی root-owned directory restart loop پیدا نہیں کرتی۔ user: override اس setup کو bypass کرتا ہے۔ Read-only mount یا ownership changes سے انکار کرنے والا filesystem پھر بھی database writes کو روک سکتا ہے۔ ls -ln ./config سے تصدیق کریں۔ یہ names کے بجائے numeric owners دکھاتا ہے۔ دو صفر اس بات کی علامت ہیں کہ owner root ہے۔ اگر logs writable local directory پر permissions failure کی تصدیق کریں تو 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 کے لیے یہ معمول کی بات ہے، لیکن پھر بھی یہ فیصلہ جان بوجھ کر کریں۔

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

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 کے طور پر شامل کیا جا سکتا ہے، اور یہ فائلیں چلا دے گا۔ اس حصے کی configuration VPS پر Jellyfin کو media server کے طور پر چلانا میں بیان کی گئی ہے۔ ebooks کے لیے /srv/media/ebooks کسی reader application کے حوالے کریں؛ Chaptarr کا کام اس وقت ختم ہو جاتا ہے جب فائل کا نام مقرر کر کے اسے درست جگہ رکھ دیا جائے۔

لائسنس، runtime اور تیزی سے بدلتا ہوا tag: maintenance risk

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

Version numbers تیزی سے بدلتے ہیں۔ 0.9.925 کو 9 August 2026 کو publish کیا گیا، اور اگلے سات ہفتوں میں مزید پانچ releases جاری ہوئیں۔ 0.9.958 تک ہر release کو pre-release کے طور پر publish کیا گیا۔ 0.9.965، جو 27 September 2026 کو جاری ہوا، پہلی version ہے جسے full release کے طور پر mark کیا گیا ہے۔ ایک exact tag pin کریں۔ latest استعمال کرنے سے unattended docker compose pull ایک ہفتے میں آپ کو کئی versions آگے لے جا سکتا ہے، اور اتنے نئے fork میں releases کے درمیان API بدل سکتی ہے۔ اس سے وہ script یا dashboard ٹوٹ سکتا ہے جو آپ نے اس کے خلاف لکھا ہو۔ Pinning کی عادت ہر ایسے نئے project کے لیے اپنائیں جسے آپ خود host کرتے ہیں۔ اسی وجہ سے openGym کو self-hosted workout tracker کے طور پر چلانے کا walkthrough بھی بالکل اسی مقصد سے fixed git tag سے deploy کرتا ہے۔

ہر 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 کے مطابق تقریباً چھ ماہ اور گیارہ ہزار سے زیادہ users کے دوران data loss کا کوئی واقعہ رپورٹ نہیں ہوا۔ اس کے باوجود project backups برقرار رکھنے اور اسے ایسی library کی طرف point نہ کرنے کا مشورہ دیتا ہے جسے آپ کھونا برداشت نہیں کر سکتے۔ دونوں باتوں کو سنجیدگی سے لیں۔ Config archive کو server سے باہر copy کریں، کیونکہ جس disk پر محفوظ کی جانے والی چیز موجود ہو، اسی disk پر رکھا backup backup نہیں ہوتا۔ یہ واحد tarball app کی local state کو cover کرتا ہے، کیونکہ اس میں /config کے تحت SQLite databases اور configuration شامل ہوتے ہیں۔ الگ database server پر موجود کسی بھی data کے لیے database dump بھی درکار ہے۔ VPS پر Postgres data اور uploaded files کے ساتھ Chatwoot کو self-host کرنے کے backup step کی ساخت بھی یہی ہے۔

ناکامی کی صورتیں، اور وہ strings جو آپ دیکھیں گے

Container ایک loop میں restart ہوتا رہتا ہے۔ docker compose ps میں Restarting دکھائی دیتا ہے۔ پہلے docker compose logs chaptarr پڑھیں۔ صرف root-owned ./config اس loop کی وضاحت نہیں کرتا: entrypoint عموماً app شروع کرنے سے پہلے اس کی ownership درست کر دیتا ہے۔ اگر logs میں بتایا جائے کہ data directory writable نہیں ہے تو Compose کے user: override، read-only mount، یا ایسے filesystem کی جانچ کریں جو ownership changes قبول نہیں کرتا۔ Override ہٹا دیں تاکہ entrypoint اپنا setup مکمل کر سکے؛ writable local directory کی غلط ownership درست کرنے کے لیے sudo chown -R 1000:1000 ./config چلائیں۔

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

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

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

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

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

FAQ

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

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

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

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

Import کے بعد میری disk usage دوگنی کیوں ہو گئی؟

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

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

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

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

یہ ایک نوجوان fork کا beta software ہے، اور 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 سے باہر محفوظ رکھیں۔