SSD Nodes Learn Hosting plans →
गाइड Matt Connorलेखक: Matt Connor

VPS पर Chaptarr कैसे इंस्टॉल करें: पूरी गाइड

Readarr के बंद होने के बाद Chaptarr सबसे अच्छा विकल्प है। इस गाइड में जानें कि कैसे Docker Compose, PUID और PGID का उपयोग करके मेटाडेटा की समस्याओं को ठीक करें और सेटअप करें।

Chaptarr क्या है, और Readarr उपयोगकर्ताओं को इसकी आवश्यकता क्यों है

Chaptarr, Readarr का एक fork है जो एक ही instance से audiobooks और ebooks को manage करता है। यह नए releases पर नज़र रखता है, उन्हें आपके download client पर भेजता है, और फिर परिणामों का नाम बदलकर उन्हें आपकी library में व्यवस्थित करता है। यह कुछ भी play नहीं करता है, इसलिए आप इसे Audiobookshelf जैसे player के साथ उपयोग करते हैं।

Readarr को 27 June 2025 को retired कर दिया गया था। Servarr टीम की अपनी सूचना में इसका कारण बताया गया है: project का metadata अनुपयोगी हो गया था, और Open Library पर जाने का सामुदायिक प्रयास रुक गया था। repository को archive कर दिया गया है। इसने पुस्तक और audiobook संग्रहों को बिना किसी maintained manager के छोड़ दिया, और Chaptarr ने यह कार्यभार संभाल लिया। यह Sonarr और Radarr से परिचित संरचना (indexers, download clients, quality profiles, root folders) को बनाए रखता है और audiobook हैंडलिंग जोड़ता है: narrator-aware संगठन, एक ही title के कई संस्करण, M4B और chaptered MP3 समर्थन, और MP3 से M4B रूपांतरण।

इस walkthrough में chaptarr/chaptarr:0.9.925 image tag का उपयोग किया गया है, जो 9 August 2026 को सबसे नया release था। 11 October 2026 तक सबसे नया release 0.9.965 है, जिसे 27 September 2026 को प्रकाशित किया गया था। नीचे दिए गए चरणों का परीक्षण केवल 0.9.925 पर किया गया था, इसलिए files में वही tag है; किसी नए version पर जाने से पहले release notes पढ़ें। Chaptarr खुद को beta software कहता है। यदि आपके पास ऐसी library है जिसे आप replace नहीं कर सकते, तो उसे Chaptarr से जोड़ने से पहले अंत में दिए गए maintenance अनुभाग को पढ़ें।

शुरू करने से पहले आपकी आवश्यकताएं

एक VPS जिस पर Docker और Compose plugin चल रहे हों, और library के लिए पर्याप्त disk space। Audiobooks का आकार बड़ा होता है, और यदि import प्रक्रिया hardlinks का उपयोग नहीं कर पाती है, तो कुछ समय के लिए फाइल की दो प्रतियां बनी रहती हैं, जिसे नीचे volume अनुभाग में समझाया गया है। यदि Docker अभी तक server पर नहीं है, तो VPS पर Docker इंस्टॉल और रन करें से शुरुआत करें और फिर वापस आएं।

Chaptarr अभी केवल Docker image के रूप में उपलब्ध है। Native support पर काम चल रहा है, एक experimental Windows build की योजना है, और इसका कोई distribution package नहीं है। container डिफ़ॉल्ट रूप से अपना database /config में SQLite के रूप में store करता है, और यदि आप पहले से ही PostgreSQL का उपयोग कर रहे हैं, तो यह Chaptarr__Postgres__* environment variables के माध्यम से एक external PostgreSQL server का उपयोग कर सकता है। एक server पर एक user के लिए SQLite ही सही विकल्प है।

Chaptarr के लिए Compose सर्विस

यह सर्विस एक मौजूदा stack में फिट हो जाती है। यह एक released tag को पिन करती है, web UI को केवल loopback पर प्रकाशित करती है, और उस नेटवर्क से जुड़ती है जिसका उपयोग आपका 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 लाइन का अर्थ है "यह नेटवर्क पहले से मौजूद है, इससे जुड़ें"। इसका उपयोग तब करें जब Prowlarr और आपका torrent client किसी अलग Compose प्रोजेक्ट से हों, क्योंकि अन्यथा एक दूसरी Compose फ़ाइल अपना अलग नेटवर्क बना लेगी और Chaptarr कभी भी qbittorrent को नाम से resolve नहीं कर पाएगा। docker network ls से वास्तविक नाम प्राप्त करें। यदि आपका stack पहले से ही एक फ़ाइल में है, तो उस फ़ाइल में chaptarr: सर्विस जोड़ें और पूरे networks: ब्लॉक को हटा दें। व्यापक लेआउट Docker Compose के अंतर्गत एक पूर्ण arr stack में कवर किया गया है, और नामकरण के नियम Compose नेटवर्क और सर्विस नाम कैसे resolve होते हैं में दिए गए हैं।

config डायरेक्टरी को स्वयं बनाएँ, फिर इसे 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 होने में विफल रहा है और उसे फिर से प्रयास किया जा रहा है, और इसका कारण लगभग हमेशा config डायरेक्टरी होती है। जब ऐप port 8789 पर listening मोड में होता है, तो लॉग स्क्रॉल करना बंद कर देता है।

PUID, PGID, और Docker द्वारा root के रूप में बनाई गई डायरेक्टरी

जब आप PUID=99 और PGID=100 को सेट नहीं करते हैं, तो Chaptarr डिफ़ॉल्ट रूप से इनका उपयोग करता है। ये unRAID के मान हैं, और एक सामान्य Ubuntu VPS पर ये किसी उपयोगी उपयोगकर्ता के नहीं होते, इसलिए फाइलें ऐसे ओनर के साथ सेव होती हैं जिसे आपका लॉगिन एक्सेस नहीं कर सकता। id -u और id -g के साथ अपने स्वयं के नंबर देखें और उन्हें फाइल में डालें।

जो भी कंटेनर समान फाइलों को एक्सेस करते हैं, उन सभी के लिए एक ही जोड़ी का होना आवश्यक है। डाउनलोड क्लाइंट /srv/media/downloads में लिखता है, Chaptarr फाइल को /srv/media/audiobooks में ले जाता है, और प्लेयर उसे वहां से पढ़ता है। यदि डाउनलोड क्लाइंट 1000:1000 के रूप में लिखता है और Chaptarr 99:100 के रूप में चलता है, तो इम्पोर्ट विफल हो जाता है। फाइल का ओनर होना ही एकमात्र कारक नहीं है: फाइल को बनाने, नाम बदलने या हटाने के लिए उस डायरेक्टरी पर राइट परमिशन की आवश्यकता होती है जिसमें वह फाइल स्थित है। सामान्य 755 मोड के साथ यूजर 1000 द्वारा बनाई गई डायरेक्टरी 99:100 को राइट एक्सेस नहीं देती है, इसलिए Chaptarr न तो किताब को लाइब्रेरी में फाइल कर सकता है और न ही उसे डाउनलोड फोल्डर से हटा सकता है। UMASK=002 नई फाइलों को ग्रुप-राइटेबल बनाता है, जो तब आवश्यक होता है जब कई कंटेनर एक ही मीडिया ग्रुप साझा करते हैं। पूर्ण मैपिंग PUID और PGID कंटेनर यूजर को होस्ट फाइलों पर कैसे मैप करते हैं में दी गई है।

README एक विशिष्ट समस्या के बारे में चेतावनी देता है, जिसे दोहराना महत्वपूर्ण है। यदि docker compose up चलाने के समय ./config मौजूद नहीं है, तो Docker इसे आपके लिए बना देता है, जिसका ओनर root:root होता है। इसके बाद कंटेनर UID 1000 के रूप में चलता है और अपना डेटाबेस नहीं लिख पाता, इसलिए यह बंद हो जाता है और बार-बार रीस्टार्ट होता रहता है। ls -ln ./config के साथ जांचें, जो नामों के बजाय संख्यात्मक ओनर दिखाता है। दो शून्य का मतलब है कि इसका ओनर root है। इसे sudo chown -R 1000:1000 ./config के साथ ठीक करें और कंटेनर को फिर से शुरू करें।

ऑडियोबुक और ईबुक वॉल्यूम को अलग रखने से हार्डलिंक क्यों काम नहीं करते

ऊपर दिया गया लेआउट /audiobooks, /ebooks और /downloads को अलग-अलग बाइंड के रूप में माउंट करता है, जो प्रोजेक्ट की अपनी रन कमांड के अनुरूप है। इसे पढ़ना आसान है, लेकिन इसकी एक वास्तविक कीमत है: हार्डलिंक काम करना बंद कर देते हैं।

हार्डलिंक डिस्क पर मौजूद एक ही डेटा के लिए दूसरा नाम होता है। यह कोई अतिरिक्त जगह नहीं लेता और तुरंत बन जाता है, इसीलिए arr परिवार इसे कॉपी करने के बजाय प्राथमिकता देता है। एक हार्डलिंक केवल एक फाइलसिस्टम के भीतर ही काम करता है। कंटेनर के अंदर ये तीन अलग-अलग माउंट पॉइंट हैं, इसलिए कर्नल लिंक बनाने से मना कर देता है, भले ही होस्ट पाथ एक ही डिस्क पर स्थित हों। इसे स्वयं टेस्ट करें।

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

यह कमांड एक त्रुटि के साथ विफल हो जाती है जो Invalid cross-device link पर समाप्त होती है। यह कर्नल है जो माउंट पॉइंट के बीच लिंक करने से मना कर रहा है, और यही सटीक कारण है कि Chaptarr वापस फाइल कॉपी करने पर निर्भर हो जाता है। कॉपी सही है लेकिन धीमी है, और ऑडियोबुक तब तक दो बार मौजूद रहती है जब तक आप टोरेंट को हटा नहीं देते, जिसे आप तब तक नहीं हटाएंगे जब तक आप उसे सीड कर रहे हैं। बाद में /srv/media/downloads/linktest को डिलीट कर दें।

हार्डलिंक बनाए रखने के लिए, इसके बजाय एक पैरेंट डायरेक्टरी को माउंट करें:

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

फिर Chaptarr के अंदर रूट फोल्डर को /data/audiobooks और /data/ebooks पर सेट करें, और डाउनलोड क्लाइंट को वही /srv/media:/data माउंट दें ताकि दोनों कंटेनर एक समान पाथ देख सकें। पहले पुष्टि करें कि होस्ट साइड एक ही फाइलसिस्टम है: df -h /srv/media/downloads /srv/media/audiobooks को दोनों के लिए Filesystem कॉलम में समान मान प्रिंट करना चाहिए। अलग-अलग मानों का मतलब अलग-अलग डिस्क है, और कोई भी माउंट लेआउट उनके बीच हार्डलिंक नहीं बना सकता। इसके और नेम्ड स्टोरेज के बीच के अंतर को मीडिया के लिए बाइंड माउंट बनाम नेम्ड वॉल्यूम में समझाया गया है।

Web UI को expose किए बिना उस तक पहुँचना

Port लाइन को 127.0.0.1 पर पब्लिश करने का एक कारण है। ufw deny 8789 किसी पब्लिश किए गए Docker port को सुरक्षित नहीं करता है, क्योंकि Docker अपने स्वयं के NAT (network address translation) नियमों को एक ऐसी chain में लिखता है जिसे kernel, ufw के नियमों से पहले प्रोसेस करता है। इसलिए, आपके नियम के जाँचे जाने से पहले ही traffic को forward कर दिया जाता है। यह व्यवहार अक्सर लोगों को भ्रमित करता है, और इसे Docker द्वारा पब्लिश किए गए port के ufw नियमों को अनदेखा करने के कारण में समझाया गया है। Loopback पर bind करने से यह समस्या पूरी तरह से टल जाती है।

अपनी मशीन से SSH tunnel के माध्यम से UI तक पहुँचें:

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

इसे चलते रहने दें और अपने browser में http://127.0.0.1:8789 खोलें। पहली बार चलाने पर authentication सेट करें। उसके बाद ही इसके सामने TLS (transport layer security) के साथ reverse proxy लगाने पर विचार करें। जब आप इनमें से तीन या चार tools में अलग-अलग password के साथ tunnel करने लगें, तो बेहतर समाधान यह है कि proxy को Authentik जैसे self-hosted single sign-on सर्वर के पीछे रखा जाए, ताकि एक login सभी apps के लिए काम करे और एक बार revoke करने पर वे सभी बंद हो जाएँ।

Indexers और download client को कनेक्ट करना

Chaptarr मानक arr indexer और download client protocols का उपयोग करता है। इसलिए Prowlarr उसी तरह indexers को इसमें push करता है जैसे वह Sonarr के लिए करता है। सामान्य torrent और usenet clients बिना किसी विशेष हैंडलिंग के कनेक्ट हो जाते हैं।

एक सेटिंग में लगभग हर कोई गलती करता है। जब Chaptarr download client host के बारे में पूछे, तो localhost या 127.0.0.1 न लिखें। कंटेनर के अंदर वह पता स्वयं कंटेनर ही होता है। इसलिए Chaptarr अपने ही port 8080 से बात करने की कोशिश करता है और रिपोर्ट करता है कि वह कनेक्ट नहीं हो पा रहा है। कंटेनर के नाम, qbittorrent, और port 8080 का उपयोग करें। सुनिश्चित करें कि दोनों कंटेनर एक ही नेटवर्क पर हैं, इसके लिए docker network inspect arr चलाएं, जो नाम के अनुसार हर जुड़े हुए कंटेनर की सूची दिखाता है।

यदि आपका download client network_mode: "service:gluetun" वाले VPN कंटेनर के माध्यम से चलता है, तो नेटवर्क पर उसका अपना कोई नाम नहीं होता है, क्योंकि वह Gluetun के network namespace को साझा करता है। इसे Gluetun द्वारा expose किए गए port पर gluetun के रूप में संबोधित करें। वह व्यवस्था और उससे संबंधित राउटिंग, Gluetun के माध्यम से download client को राउट करना में दी गई है।

Readarr का बदलाव: माइग्रेशन की वास्तविक लागत

Chaptarr, Readarr के metadata sources के साथ compatible नहीं है। यह कई providers के माध्यम से अपनी खुद की pipeline का उपयोग करके titles, authors और editions को resolve करता है, इसलिए Readarr द्वारा store किए गए identifiers का यहाँ कोई अर्थ नहीं है। इसमें कोई database import नहीं है और न ही कोई सीधा upgrade path उपलब्ध है।

मौजूदा library के लिए, इसका मतलब है कि आपकी files सुरक्षित हैं लेकिन settings नहीं। इस प्रक्रिया में disk पर मौजूद किसी भी चीज़ को नहीं बदला जाता है। आप एक root folder जोड़ते हैं, library import चलाते हैं, और Chaptarr अपनी मिली हुई files को अपने metadata के साथ match करता है। आपको ये चीज़ें मैन्युअल रूप से फिर से बनानी होंगी: quality profiles, naming format, indexer और client settings, और हर वह match जिसे Chaptarr गलत तरीके से पहचानता है। एक बड़ी library को मैन्युअल सुधार की आवश्यकता होगी, इसलिए 10 मिनट के बजाय एक पूरी शाम का समय लेकर चलें।

इसे इसी क्रम में करें। Readarr container को stop करें लेकिन इसके config volume को रहने दें, ताकि आप अपनी पुरानी settings को देखते हुए उन्हें फिर से type कर सकें। पहले Chaptarr को एक छोटे folder पर point करें और सब कुछ import करने से पहले matches की जाँच करें। जब आप पूरी तरह संतुष्ट हो जाएं, तभी पुराने container को हटाएँ।

पूरी library को scan करने से पहले गोपनीयता (privacy) से जुड़ा एक विवरण जानना आवश्यक है: metadata lookups api2.chaptarr.com पर जाते हैं। README में उल्लेख है कि उन requests में provider IDs, search text, media type, tags और filenames हो सकते हैं, और वे full paths, user identity और credentials को शामिल नहीं करते हैं। Filenames आपके सर्वर से बाहर जाते हैं। metadata service के लिए यह सामान्य है, और आपको फिर भी इसे सोच-समझकर तय करना चाहिए।

ऑडियोबुक्स को प्लेयर तक पहुँचाना

Chaptarr फाइलों को व्यवस्थित करता है। उन्हें प्ले करना किसी अन्य प्रोग्राम का काम है, और Audiobookshelf इसके लिए सबसे आम साथी है क्योंकि यह विभिन्न डिवाइसों पर आपकी सुनने की स्थिति (listening position) को ट्रैक करता है और इसके फोन ऐप्स भी उपलब्ध हैं। इसका आधिकारिक इमेज 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

उसी होस्ट पाथ को माउंट करें जहाँ Chaptarr लिखता है, फिर वेब UI के अंदर एक लाइब्रेरी के रूप में /audiobooks को जोड़ें। अगले स्कैन के बाद एक नया इम्पोर्ट दिखाई देगा।

यदि आप पहले से ही Jellyfin चला रहे हैं, तो आप उस फोल्डर को वहां एक लाइब्रेरी के रूप में जोड़ सकते हैं और यह फाइलों को प्ले कर देगा, हालाँकि एक लंबी ऑडियोबुक फाइल पर रिज्यूम (resume) करने की क्षमता एक समर्पित ऑडियोबुक सर्वर की तुलना में कम प्रभावी है। उस सेटअप को VPS पर मीडिया सर्वर के रूप में Jellyfin चलाना में कवर किया गया है। ई-बुक के हिस्से के लिए, /srv/media/ebooks को किसी रीडर एप्लिकेशन को सौंप दें; Chaptarr का काम फाइल का नामकरण और फाइलिंग पूरी होने के बाद समाप्त हो जाता है।

रखरखाव का जोखिम: लाइसेंस, रनटाइम और तेजी से बदलते टैग

Chaptarr का लाइसेंस GPL-3.0 है, जिसका कॉपीराइट Chaptarr योगदानकर्ताओं के पास है और इसके कुछ हिस्से Servarr टीम से लिए गए हैं। इसलिए कोड ओपन-सोर्स रहता है और यदि वर्तमान मेंटेनर काम बंद कर देता है, तो कोई भी इसे दोबारा फोर्क (fork) कर सकता है। यह .NET 10 पर आधारित है, जो अगस्त 2026 तक रनटाइम का वर्तमान लॉन्ग टर्म सपोर्ट (LTS) रिलीज है। इसका मतलब है कि इसका आधार महीनों के बजाय वर्षों तक समर्थित रहेगा। यदि आप यह आकलन कर रहे हैं कि क्या यह प्रोजेक्ट अगले वर्ष भी अस्तित्व में रहेगा, तो ये दोनों तथ्य महत्वपूर्ण हैं।

वर्जन नंबर तेजी से बदलते हैं। 0.9.925 को 9 अगस्त 2026 को पब्लिश किया गया था, और अगले सात सप्ताहों में पांच और रिलीज आए। 0.9.958 तक की हर रिलीज को प्री-रिलीज के रूप में पब्लिश किया गया था; 27 सितंबर 2026 को आया 0.9.965, पूर्ण रिलीज के रूप में चिह्नित पहला वर्जन है। एक सटीक टैग को पिन (pin) करें। latest का उपयोग करने का अर्थ है कि एक अनअटेंडेड docker compose pull आपको एक सप्ताह में कई वर्जन आगे ले जा सकता है। इतना नया फोर्क रिलीज के बीच अपना API बदल सकता है, जिससे आपके द्वारा इसके लिए लिखी गई कोई भी स्क्रिप्ट या डैशबोर्ड टूट सकता है। पिनिंग एक ऐसी आदत है जिसे आपको अपने द्वारा होस्ट किए जाने वाले हर नए प्रोजेक्ट के लिए अपनाना चाहिए। यही कारण है कि self-hosted workout tracker के रूप में 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 केवल इसलिए पर्याप्त है क्योंकि Chaptarr अपनी स्थिति (state) को /config के अंतर्गत एक SQLite फाइल में रखता है। किसी अलग डेटाबेस सर्वर पर मौजूद किसी भी चीज़ के लिए डेटाबेस का डंप लेना भी आवश्यक है। VPS पर Chatwoot को self-host करने के दौरान बैकअप स्टेप इसी तरह लिया जाता है, जिसमें Postgres डेटा और अपलोड की गई फाइलें शामिल होती हैं।

विफलता के प्रकार और दिखाई देने वाले स्ट्रिंग्स

कंटेनर लूप में रीस्टार्ट हो रहा है। docker compose ps में Restarting दिखाई देता है। ls -ln ./config चलाएं। ओनर कॉलम में दो शून्य का अर्थ है कि Docker ने डायरेक्टरी को root के रूप में बनाया है और कंटेनर यूजर उसके डेटाबेस में लिख नहीं सकता है। sudo chown -R 1000:1000 ./config चलाएं।

इंपोर्ट कभी पूरे नहीं होते और फाइलें डाउनलोड्स में ही रहती हैं। Chaptarr डाउनलोड को पढ़ तो सकता है लेकिन लाइब्रेरी में लिख नहीं सकता। ls -ln /srv/media/audiobooks की तुलना अपने PUID और PGID से करें। किसी अन्य UID के स्वामित्व वाली डायरेक्टरी, या ग्रुप राइट के बिना आपके ग्रुप के स्वामित्व वाली डायरेक्टरी, फाइल को मूव होने से रोकती है। UMASK=002 नई फाइलों के लिए दूसरे मामले को रोकता है।

हर इंपोर्ट के बाद डिस्क का उपयोग दोगुना हो जाता है। हार्डलिंक नहीं बना, इसलिए फाइल कॉपी हो गई। वॉल्यूम सेक्शन से ln टेस्ट चलाएं। Invalid cross-device link पर समाप्त होने वाली त्रुटि इसकी पुष्टि करती है, और सिंगल-पेरेंट माउंट ही इसका समाधान है।

डाउनलोड क्लाइंट कनेक्ट नहीं होगा। आपने होस्ट के रूप में localhost दर्ज किया है। कंटेनर के अंदर वह स्वयं 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 में माइग्रेट कर सकता हूँ?

इसे import के रूप में नहीं किया जा सकता। Chaptarr, Readarr के metadata sources के साथ संगत नहीं है और अपने स्वयं के provider pipeline का उपयोग करता है। इसलिए, Readarr के stored identifiers का कोई अर्थ नहीं है और डेटाबेस का कोई conversion संभव नहीं है। डिस्क पर मौजूद आपकी फाइलें सुरक्षित रहेंगी। आप उन्हीं paths को root folders के रूप में जोड़ें, library import चलाएं और Chaptarr को स्वयं फाइलें match करने दें। Quality profiles, naming format, indexer settings और गलत matches को ठीक करने का काम आपको मैन्युअल रूप से करना होगा, इसलिए सब कुछ import करने से पहले एक छोटे फोल्डर के साथ शुरुआत करें।

Chaptarr मेरे audiobook फोल्डर में लिख (write) क्यों नहीं पा रहा है?

कंटेनर के user के पास उस directory पर write permission नहीं है, आमतौर पर ऐसा इसलिए होता है क्योंकि यह उस UID से अलग UID पर चलता है जिसके पास इसका स्वामित्व है। जब PUID=99 और PGID=100 variables सेट नहीं होते हैं, तो Chaptarr डिफ़ॉल्ट रूप से इनका उपयोग करता है, जो unRAID के मान हैं और सामान्य Ubuntu VPS पर गलत होते हैं। इन्हें अपने स्वयं के id -u और id -g पर सेट करें, download client पर भी उसी pair का उपयोग करें, और UMASK=002 सेट करें ताकि नई फाइलें group-writable बनी रहें। Library directory पर ls -ln के साथ ownership की जाँच करें, क्योंकि यह नामों के बजाय numbers प्रिंट करता है जिन्हें आप सीधे compare नहीं कर सकते।

import के बाद मेरे डिस्क का उपयोग दोगुना क्यों हो गया?

Chaptarr ने फाइल को copy किया क्योंकि वह उसे hardlink नहीं कर सका। /downloads और /audiobooks को अलग-अलग binds के रूप में mount करने से वे कंटेनर के अंदर अलग-अलग mount points बन जाते हैं, और kernel Invalid cross-device link के कारण mount points के बीच hardlink करने से मना कर देता है। किसी एक parent directory जैसे कि /srv/media:/data को mount करें और ऐप के अंदर /data/downloads और /data/audiobooks का उपयोग करें। दोनों paths का एक ही host filesystem पर होना भी आवश्यक है, जिसकी पुष्टि df -h करता है।

क्या Chaptarr मेरे audiobooks को play करता है?

नहीं। यह उन्हें ढूंढता है, डाउनलोड करता है, rename करता है और व्यवस्थित करता है; playback एक अलग प्रोग्राम का काम है। Audiobookshelf इसके साथ सबसे आम pairing है क्योंकि यह विभिन्न उपकरणों पर आपकी position को याद रखता है, इसके लिए आधिकारिक image ghcr.io/advplyr/audiobookshelf:latest का उपयोग करें जिसमें वही host audiobook path mount हो। यदि आप फोल्डर को library के रूप में जोड़ते हैं तो Jellyfin भी फाइलें play करेगा, हालांकि लंबी single-file audiobooks पर इसमें resume करने की सुविधा उतनी बेहतर नहीं है।

क्या जिस लाइब्रेरी की मैं परवाह करता हूँ, उस पर Chaptarr चलाना सुरक्षित है?

यह एक नए fork का beta software है। प्रोजेक्ट स्वयं भी यही कहता है, हालांकि लगभग छह महीनों और ग्यारह हजार से अधिक उपयोगकर्ताओं के दौरान डेटा हानि की कोई घटना सामने नहीं आई है। आश्वस्त करने वाले पहलू इसका GPL-3.0 licence है, जो कोड को fork करने योग्य रखता है, और .NET 10 बेस है, जो अगस्त 2026 तक एक long term support runtime है। latest के बजाय 0.9.925 जैसे सटीक image tag को पिन करें, प्रत्येक upgrade से पहले /config का बैकअप लें, और उस archive को सर्वर से बाहर सुरक्षित रखें।