SSD Nodes Learn Hosting plans →
गाइड Matt Connorलेखक: Matt Connor · अपडेट किया गया: 2026-08-27

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

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

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

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

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

इस वॉकथ्रू में chaptarr/chaptarr:0.9.925 image tag का उपयोग किया गया है, जो 9 August 2026 को सबसे नया release था। Chaptarr खुद को beta software कहता है। यदि आप इसे ऐसी library पर point कर रहे हैं जिसे आप replace नहीं कर सकते, तो अंत के पास दिए गए maintenance सेक्शन को जरूर पढ़ें।

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

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

Chaptarr फिलहाल केवल Docker image के रूप में उपलब्ध है। एक native Windows build पर काम चल रहा है, और इसका कोई distribution package नहीं है। कंटेनर डिफ़ॉल्ट रूप से अपना डेटाबेस /config में SQLite के रूप में स्टोर करता है, और यदि आप पहले से ही PostgreSQL का उपयोग कर रहे हैं, तो यह Chaptarr__Postgres__* environment variables के माध्यम से एक बाहरी PostgreSQL सर्वर का उपयोग कर सकता है। एक सर्वर पर एक उपयोगकर्ता के लिए 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 के साथ अपने स्वयं के नंबर देखें और उन्हें फाइल में डालें।

जो भी कंटेनर समान फाइलों को एक्सेस करते हैं, उन सभी के लिए समान पेयर (pair) का होना आवश्यक है। डाउनलोड क्लाइंट /srv/media/downloads में लिखता है, Chaptarr फाइल को /srv/media/audiobooks में ले जाता है, और प्लेयर उसे वहाँ से पढ़ता है। यदि डाउनलोड क्लाइंट 1000:1000 के रूप में लिखता है और Chaptarr 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 रिलीज हुआ था। एक सटीक टैग को पिन (pin) करें। latest का उपयोग करने का अर्थ है कि एक अनअटेंडेड docker compose pull आपको एक सप्ताह में कई वर्जन आगे ले जा सकता है। इतना नया फोर्क होने के कारण, रिलीज के बीच इसका API बदल सकता है, जो आपके द्वारा लिखे गए किसी भी स्क्रिप्ट या डैशबोर्ड को खराब कर सकता है। पिनिंग एक ऐसी आदत है जिसे आपको अपने द्वारा होस्ट किए जाने वाले हर नए प्रोजेक्ट के लिए अपनाना चाहिए। यही कारण है कि running openGym as a self-hosted workout tracker के वॉकथ्रू में ठीक इसी कारण से एक फिक्स्ड 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

यह प्रोजेक्ट लगभग छह महीनों और 11,000 से अधिक users के दौरान data loss की कोई घटना report नहीं करता। फिर भी यह backups रखने और इसे ऐसी library की ओर point न करने की सलाह देता है जिसे खोना आपके लिए स्वीकार्य न हो। इन दोनों बातों को गंभीरता से लें। Config archive को server से बाहर copy करें, क्योंकि जिस disk पर सुरक्षित की जाने वाली चीज़ मौजूद हो, उसी disk पर रखा backup backup नहीं होता। यह एक tarball तभी पर्याप्त है क्योंकि Chaptarr अपना state /config के अंतर्गत एक SQLite file में रखता है। अलग database server पर मौजूद किसी भी data के लिए database dump भी बनाना होगा। यही वह रूप है जो backup step लेता है, जब VPS पर Chatwoot को self-host करना हो और उसके Postgres data तथा uploaded files भी साथ हों।

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

कंटेनर लूप में रीस्टार्ट हो रहा है। 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 के संग्रहीत identifiers का यहाँ कोई अर्थ नहीं है और कोई database conversion संभव नहीं है। डिस्क पर आपकी फाइलें सुरक्षित रहेंगी। आप उन्हीं paths को root folders के रूप में जोड़ें, library import चलाएं और Chaptarr को स्वयं फाइलें match करने दें। Quality profiles, naming format, indexer settings और गलत matches को ठीक करने का काम आपको मैन्युअल रूप से करना होगा, इसलिए सब कुछ import करने से पहले एक छोटे फोल्डर के साथ शुरुआत करें।

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

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

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

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

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

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

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

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