लेखक: Matt Connor 2026-10-10

VPS पर Jellyfin कैसे सेटअप करें: पूरी गाइड

Q: स्कैन के बाद मेरी Jellyfin लाइब्रेरी खाली क्यों है?

इसका कारण लगभग हमेशा permissions होता है। आधिकारिक jellyfin/jellyfin image उस user: के रूप में चलती है जिसे आप सेट करते हैं (या root), और यदि फाइलें उस uid द्वारा पढ़ने योग्य नहीं हैं, तो स्कैन logs में Access to the path ... is denied दिखाई देता है और वे फाइलें छोड़ दी जाती हैं। chown -R 1000:1000 /mnt/media के साथ ownership ठीक करें, directories को execute bit (755) दें, और फिर से स्कैन करें। parent directory की भी जाँच करें, क्योंकि यदि container का uid /mnt/media तक नहीं पहुँच सकता है, तो वह लाइब्रेरी फोल्डर तक कभी नहीं पहुँचेगा और सब कुछ खाली दिखाई देगा। दूसरा सबसे आम कारण ऐसा फोल्डर लेआउट है जो Jellyfin की अपेक्षाओं से मेल नहीं खाता है।

VPS पर Docker के जरिए Jellyfin इंस्टॉल करने का तरीका जानें। इस गाइड में block storage, फाइल permissions और CPU transcoding की समस्याओं को हल करने के सटीक उपाय दिए गए हैं।

आप क्या बना रहे हैं

एक VPS पर Jellyfin मीडिया सर्वर: एक container, तीन volumes, और आपकी फिल्मों और शो को रखने वाली एक block-storage डिस्क, जिसे किसी भी ब्राउज़र या Jellyfin ऐप से एक्सेस किया जा सकता है। यह इंस्टॉलेशन पंद्रह लाइनों की एक compose फाइल है। इसके बाद आने वाली सभी समस्याएं दो कारणों से होती हैं: फाइल अनुमतियां (permissions) जिन्हें container पढ़ नहीं सकता, और बिना GPU वाले VPS से वीडियो ट्रांसकोड करने के लिए कहना जिसे करने में वह सक्षम नहीं है। यह गाइड अपना अधिकांश समय इन्हीं दो बिंदुओं पर केंद्रित करती है, क्योंकि अधिकांश सहायता टिकट यहीं से आते हैं।

Jellyfin पूरी तरह से मुफ्त और ओपन सोर्स है, जिसमें कोई अकाउंट, कोई पेवॉल फीचर और कोई टेलीमेट्री नहीं है, यही कारण है कि यह 2026 में सेल्फ-होस्ट करने योग्य चीजें की लगभग हर सूची में शामिल है। यह आपके द्वारा स्वामित्व वाली मीडिया फाइलों को चलाता है। यह कोई कंटेंट प्रदान नहीं करता है, और यह गाइड किसी भी प्रकार की कंटेंट प्राप्त करने के बारे में नहीं है।

Transcoding की वास्तविकता, कुछ भी किराए पर लेने से पहले

इसे पहले पढ़ें, क्योंकि यह आपके खरीदारी के निर्णय को बदल देगा। जब आप play दबाते हैं, तो एक media server दो में से एक काम करता है। Direct play फाइल को वैसे ही stream करता है जैसी वह है: VPS डिस्क से bytes पढ़ता है और उन्हें network पर भेज देता है, जिसमें लगभग शून्य CPU खर्च होता है। Transcoding वीडियो को चलते-फिरते (on the fly) फिर से encode करता है, जिसमें नया resolution, नया codec या subtitles को वीडियो में burn करना शामिल है, और यह पूरी तरह से CPU का काम है।

एक सामान्य VPS में GPU नहीं होता है। इसलिए हर वीडियो transcode CPU पर libx264/libx265 के साथ चलता है, और software encoding बहुत महंगी पड़ती है। एक single 1080p H.264 transcode कई shared vCPUs को पूरी तरह व्यस्त कर सकता है; 4K या HEVC transcode आमतौर पर real-time गति के साथ नहीं चल पाते, जिससे playback रुक जाता है और लगातार buffering होती है। Hardware transcoding, जो घर पर रखे Intel iGPU या Nvidia card वाले box पर इसे सस्ता बनाता है, आपके लिए उपलब्ध नहीं है जब तक कि आपका provider GPU instances किराए पर न देता हो।

इसलिए VPS पर पूरी रणनीति यह है: transcoding से बचें। अपनी library को उन codecs में रखें जिन्हें आपके clients natively play कर सकें, जैसे H.264 वीडियो, AAC या AC3 audio, MP4 या MKV container में, और ऐसे client apps चुनें जो direct-play का समर्थन करते हों: Android TV, iOS और Roku के लिए native Jellyfin apps, साथ ही Infuse, Kodi, और desktop Jellyfin Media Player। यदि आप ऐसा करते हैं, तो VPS को playback के दौरान कभी भी ffmpeg transcode चलाने की आवश्यकता नहीं होगी, और एक साधारण 2 vCPU वाला box एक साथ कई लोगों को stream कर पाएगा। यदि आप transcoding की योजना बनाते हैं, तो आपको बहुत बड़े और महंगे box की आवश्यकता होगी, और तब भी 4K एक जोखिम भरा विकल्प है।

Bandwidth की गणना भी करें, क्योंकि यह दूसरी चौंकाने वाली बात है। Direct play फाइल को उसके वास्तविक bitrate पर भेजता है। एक compressed 1080p फाइल 8-12 Mbps लेती है; 1080p Blu-ray remux 20-30 Mbps; 4K HDR 40-80 Mbps। तीन लोग यदि 10 Mbps वाली फाइलें direct-play कर रहे हैं, तो यह आपके VPS से 30 Mbps का निरंतर upload traffic होगा। अपने plan पर दो संख्याएँ जाँचें: port speed (क्या यह 30 Mbps upstream दे सकता है?) और monthly transfer cap। दो घंटे की एक 10 Mbps वाली फिल्म लगभग 9 GB data लेती है, इसलिए 1 TB/month की metered limit का मतलब है महीने में लगभग सौ ऐसी फिल्में, यानी दिन में तीन या चार, और 4K देखने वाला परिवार, जो चार से आठ गुना अधिक bitrate लेता है, इसे बहुत तेजी से खत्म कर देगा। उसी box से बाहर जाने वाले किसी भी अन्य traffic को भी इसी budget में गिनें, जिसमें a self-hosted RustDesk relay भी शामिल है, जो तब पूरा remote desktop session carry करता है जब दो peers सीधे connect नहीं हो पाते।

आवश्यक शर्तें

root या sudo एक्सेस के साथ एक नया Ubuntu 24.04 KVM VPS, जिसमें Docker और Compose plugin इंस्टॉल हो।
आपकी लाइब्रेरी के आकार के अनुसार मीडिया के लिए एक block-storage volume (नीचे sizing देखें)। VPS के साथ मिलने वाली छोटी root disk पर फिल्में स्टोर न करें।
यदि आप public HTTPS एक्सेस चाहते हैं तो एक domain name, या यदि आप इसे पूरी तरह निजी रखना चाहते हैं तो उसी VPS पर WireGuard VPN।
ऐसा मीडिया जिसे स्ट्रीम करने के लिए आप कानूनी रूप से अधिकृत हैं, जैसे कि आपकी अपनी rips, आपकी अपनी रिकॉर्डिंग, या ऐसी फाइलें जिनके आप मालिक हैं।

सबसे पहले block storage को mount करें

अपने provider के panel में volume को attach करें, फिर उसे ढूँढें और mount करें। lsblk से device का नाम प्राप्त करें, यह /dev/sdb या /dev/vdb जैसा कुछ होगा, यह कभी भी root disk नहीं होता है।

lsblk
sudo mkfs.ext4 /dev/sdb          # ONLY on a new, empty volume: this ERASES it
sudo mkdir -p /mnt/media
sudo blkid /dev/sdb              # copy the UUID shown for this device

इसे UUID द्वारा mount करें, न कि /dev/sdb द्वारा, क्योंकि reboot के दौरान device के अक्षर बदल सकते हैं और आप गलत disk को format या mount कर सकते हैं। /etc/fstab में एक line जोड़ें:

UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx  /mnt/media  ext4  defaults,nofail  0  2

sudo mount -a
df -h /mnt/media

nofail महत्वपूर्ण है: इसके बिना, यदि block volume कभी detach हो जाता है, तो server boot होने से मना कर देगा और emergency shell में चला जाएगा। यहाँ सबसे बड़ी गलती उस volume पर mkfs.ext4 चलाना है जिसमें पहले से data मौजूद है, यह उसे मिटा देता है। केवल नई volumes को ही format करें; यदि disk पर पहले से आपकी library मौजूद है, तो सीधे fstab line पर जाएँ।

मीडिया को उस तरह व्यवस्थित करें जैसा Jellyfin चाहता है

Jellyfin फोल्डर और फाइल के नामों के आधार पर मेटाडेटा का मिलान करता है। यदि लेआउट गलत हुआ, तो फिल्में बिना शीर्षक वाली फाइलों के रूप में दिखाई देंगी जिनमें कोई पोस्टर नहीं होगा, या कोई एपिसोड गलत सीरीज से मेल खा जाएगा। चार नियम लगभग सारा काम कर देते हैं: प्रत्येक फिल्म अपने स्वयं के फोल्डर में एक मेल खाते हुए फाइल नाम के साथ रहती है, जिसे Name (Year) नाम दिया जाता है (Jellyfin वर्ष को वैकल्पिक मानता है, लेकिन यह मिलान को अधिक विश्वसनीय बनाता है); सीजन फोल्डर को Season 01 नाम दिया जाता है, न कि S01; एपिसोड फाइलें S01E01 का उपयोग करती हैं; और स्पेशल एपिसोड Season 00 में जाते हैं।

/mnt/media
├── Movies
│   ├── Blade Runner (1982)
│   │   └── Blade Runner (1982).mkv
│   └── Arrival (2016)
│       └── Arrival (2016).mkv
└── Shows
    └── Severance (2022)
        ├── Season 01
        │   ├── Severance - S01E01.mkv
        │   └── Severance - S01E02.mkv
        └── Season 00
            └── Severance - The Lexington Letter.mkv

फिल्मों पर (Year) केवल सजावट नहीं है, यह रीमेक के बीच अंतर स्पष्ट करता है ताकि मैचिंग टूल सही शीर्षक चुन सके। Movies और Shows को अलग-अलग टॉप-लेवल फोल्डर के रूप में रखें क्योंकि प्रत्येक एक विशिष्ट कंटेंट प्रकार की Jellyfin लाइब्रेरी बन जाता है, और उन्हें मिलाने से मेटाडेटा प्रदाता भ्रमित हो जाता है। Jellyfin खुशी-खुशी तस्वीरों के तीसरे फोल्डर को भी इंडेक्स कर लेगा, लेकिन यह एक समर्पित फोटो सर्वर की तुलना में बहुत सीमित अनुभव है। इसलिए यदि आपके एल्बम महत्वपूर्ण हैं, तो उन्हें PhotoPrism या Immich चलाने वाले अपने स्वयं के सर्वर पर रखें और इसे केवल फिल्म और टीवी के लिए छोड़ दें।

अनुमतियाँ (Permissions): लाइब्रेरी खाली दिखने का सबसे मुख्य कारण

यह वह गलतफहमी है जिसमें लोगों की पूरी शाम बर्बाद हो जाती है। आधिकारिक jellyfin/jellyfin इमेज PUID/PGID एनवायरनमेंट वेरिएबल्स का सम्मान नहीं करती है, वे LinuxServer.io इमेज (lscr.io/linuxserver/jellyfin) से संबंधित हैं। आधिकारिक इमेज पर आप compose में user: की (key) के साथ यूजर को नियंत्रित करते हैं, और यदि आप इसे छोड़ देते हैं तो कंटेनर root के रूप में चलता है। आप जो भी उपयोग करें, नियम एक ही है: जिस uid/gid पर कंटेनर चलता है, उसे हर मीडिया डायरेक्टरी को पढ़ने और उसमें जाने (traverse) में सक्षम होना चाहिए।

हम uid/gid 1000 के रूप में चलेंगे, जो एक स्टॉक Ubuntu बॉक्स पर पहला नॉन-रूट यूजर है। अपना uid/gid कन्फर्म करें और ओनरशिप सेट करें:

id                                  # confirm your user is uid=1000 gid=1000
sudo chown -R 1000:1000 /mnt/media
sudo find /mnt/media -type d -exec chmod 755 {} \;
sudo find /mnt/media -type f -exec chmod 644 {} \;
mkdir -p ~/jellyfin/config ~/jellyfin/cache
sudo chown -R 1000:1000 ~/jellyfin

डायरेक्टरीज के लिए केवल रीड (read) ही नहीं, बल्कि execute बिट (755 में x) की भी आवश्यकता होती है। इसके बिना, कंटेनर फोल्डर के अंदर नहीं जा सकता, भले ही वह फाइलों के नाम देख सके। वह जाल जो पूरी लाइब्रेरी को खाली कर देता है, वह पैरेंट डायरेक्टरी है: यदि कंटेनर का uid माउंट को ही पार (traverse) नहीं कर सकता, तो वह कभी /media/Movies या /media/Shows तक नहीं पहुँच पाता, और लॉग में Access to the path ... is denied के साथ पूरी लाइब्रेरी एक साथ खाली दिखाई देती है। किसी भी मीडिया फोल्डर को जिसे वह पढ़ नहीं सकता, उसे लॉग कर दिया जाता है और छोड़ दिया जाता है। इसलिए, root के रूप में कॉपी की गई फाइलों का पूरा बैच चुपचाप लाइब्रेरी से गायब हो जाता है। यही कारण है कि हम एक फोल्डर को ठीक करने के बजाय हर डायरेक्टरी पर रिकर्सिवली (recursively) chown करते हैं और execute बिट सेट करते हैं।

docker-compose फ़ाइल

services:
  jellyfin:
    image: jellyfin/jellyfin:12
    container_name: jellyfin
    user: "1000:1000"
    restart: unless-stopped
    ports:
      - "127.0.0.1:8096:8096"
    volumes:
      - ./config:/config
      - ./cache:/cache
      - /mnt/media:/media:ro
    environment:
      - JELLYFIN_PublishedServerUrl=https://jellyfin.example.com

लाइन-दर-लाइन विवरण: jellyfin/jellyfin:12 वर्तमान 12.x रिलीज़ लाइन को ट्रैक करता है (2026-10-10 तक 12.2)। user: "1000:1000" वह uid/gid सेट करता है जिस पर Jellyfin प्रक्रिया चलती है। यह किसी भी फ़ाइल के स्वामित्व या मोड को नहीं बदलता है, क्योंकि Docker माउंट की गई डायरेक्टरी पर होस्ट के uid/gid को बनाए रखता है, यही कारण है कि ऊपर दिया गया chown इससे मेल खाना चाहिए। /config में पूरा सर्वर, अकाउंट्स, लाइब्रेरीज़, मेटाडेटा और वॉच स्टेट होता है, इसलिए इसे writable होना चाहिए और यही वह चीज़ है जिसका आपको बैकअप लेना है। /cache एक अस्थायी वर्किंग स्पेस है। मीडिया माउंट जानबूझकर :ro (read-only) रखा गया है: Jellyfin डिफ़ॉल्ट रूप से आर्टवर्क और मेटाडेटा को /config के अंतर्गत स्टोर करता है, इसलिए इसे आपकी लाइब्रेरी में कभी कुछ लिखने की आवश्यकता नहीं होती है, और read-only मोड आपकी फ़ाइलों को आकस्मिक विलोपन या किसी खराब प्लगइन से सुरक्षित रखता है। पोर्ट को जानबूझकर 127.0.0.1 पर बाइंड किया गया है, Jellyfin का वेब लॉगिन सामान्य HTTP है, इसलिए हम 8096 को सार्वजनिक इंटरनेट पर कभी पब्लिश नहीं करते हैं। JELLYFIN_PublishedServerUrl वह पता है जिसे सर्वर लोकल ऑटो-डिस्कवरी (LAN UDP ब्रॉडकास्ट) के लिए विज्ञापित करता है, इसलिए इंटरनेट पर मौजूद क्लाइंट इसे कभी नहीं देखते हैं और केवल उस URL का उपयोग करते हैं जिसे आप ऐप में टाइप करते हैं। इसे उस पते पर सेट करें जो क्लाइंट्स को बताया जाना चाहिए, और रिमोट डिवाइस पर उस URL को मैन्युअल रूप से दर्ज करने की अपेक्षा रखें।

इसे compose डायरेक्टरी से शुरू करें:

docker compose up -d
docker logs -f jellyfin

पहली बार चलाना: सेटअप विज़ार्ड और आपकी लाइब्रेरीज़

चूंकि port localhost से bind है, इसलिए firewall में छेद करने के बजाय अपने laptop से SSH tunnel के माध्यम से विज़ार्ड तक पहुँचें:

ssh -L 8096:127.0.0.1:8096 you@your-vps-ip

अब http://localhost:8096 पर ब्राउज़ करें। विज़ार्ड आपको भाषा चुनने और फिर एक मजबूत पासवर्ड के साथ admin user बनाने की प्रक्रिया से ले जाएगा। यह account आपका सर्वर है, इसलिए किसी पुराने या सामान्य पासवर्ड का उपयोग न करें। अपनी पहली लाइब्रेरी जोड़ें: content type Movies चुनें, इसे /media/Movies पर इंगित करें (यह container के अंदर का path है, host का path नहीं), और Shows के लिए /media/Shows के साथ इसे दोहराएं। समाप्त करें, और Jellyfin स्कैन करेगा। एक छोटी लाइब्रेरी के लिए एक या दो मिनट के भीतर posters और titles का दिखाई देना एक सही परिणाम है। लाइब्रेरीज़ को बाद में Dashboard → Libraries के अंतर्गत जोड़ें या संपादित करें, और Scan All Libraries के साथ rescan को force करें। ये posters ही एक alternative frontend को आज़माने लायक बनाते हैं, क्योंकि Halcyon उसी लाइब्रेरी को 90 के दशक के एक वीडियो स्टोर की तरह Jellyfin द्वारा पहले से प्राप्त artwork से फिर से तैयार करता है।

यदि आप किसी भी प्रकार की transcoding पर निर्भर हैं, तो Dashboard → Playback → Transcoding खोलें और transcode temp path को /cache/transcodes पर सेट करें ताकि डेटा का बोझ /config को भरने के बजाय cache volume पर रहे। hardware acceleration को None पर ही रहने दें, क्योंकि accelerate करने के लिए कोई GPU मौजूद नहीं है।

रिमोट एक्सेस: TLS रिवर्स प्रॉक्सी, या इसे VPN पर रखें

Jellyfin को बाहर से एक्सेस करने के दो सुरक्षित तरीके हैं, और एक असुरक्षित तरीका है जिससे बचना चाहिए। असुरक्षित तरीका है पोर्ट 8096 को सीधे इंटरनेट पर पब्लिश करना: लॉगिन जानकारी cleartext में जाती है और कुछ ही घंटों में पोर्ट पर brute-force हमले होने लगते हैं।

विकल्प A, TLS रिवर्स प्रॉक्सी। Jellyfin को Traefik with automatic TLS for your Docker apps के पीछे किसी सबडोमेन पर रखें, या nginx के पीछे Let's Encrypt certificate issued by Certbot का उपयोग करें। Jellyfin रियल-टाइम अपडेट के लिए WebSockets का उपयोग करता है, इसलिए प्रॉक्सी को upgrade headers को फॉरवर्ड करना होगा। Traefik इसे स्वचालित रूप से करता है; nginx में इन्हें स्पष्ट रूप से कॉन्फ़िगर करना पड़ता है, और अपस्ट्रीम के लिए HTTP/1.1 की आवश्यकता होती है, अन्यथा अपग्रेड कभी नहीं होगा:

location / {
    proxy_pass http://127.0.0.1:8096;
    proxy_http_version 1.1;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
}

JELLYFIN_PublishedServerUrl को https:// पते पर सेट करें ताकि कोई भी लोकल ऑटो-डिस्कवरी सही URL का विज्ञापन करे, रिमोट ऐप्स आपके द्वारा दिए गए पते का उपयोग करें, और लॉगिन के खिलाफ fail2ban to slow brute-force attempts जोड़ें। एक बार सर्वर पब्लिक हो जाने के बाद, Uptime Kuma को URL पर पॉइंट करें ताकि आपके दर्शकों को पता चलने से पहले आपको डाउनटाइम की जानकारी मिल जाए। इसकी नोटिफिकेशन को a self-hosted ntfy server पर पॉइंट करें ताकि चेक फेल होने पर आपको ईमेल के बजाय फोन पर पुश नोटिफिकेशन मिले। पब्लिक इंटरनेट पर लॉगिन रखना बाकी सर्वर का ऑडिट करने का भी एक अच्छा समय है, बजाय इसके कि केवल यह भरोसा करें कि केवल पोर्ट 443 ही जवाब दे रहा है: sudo ss -tlnp हर लिसनिंग पोर्ट और उसके पीछे की प्रोसेस को लिस्ट करता है। यदि आप बॉक्स पर अपना खुद का कोड भी डिप्लॉय करते हैं, तो open-kritt scans repositories and their dependencies for vulnerabilities; यह सोर्स कोड का ऑडिट करता है, लिसनिंग पोर्ट्स का नहीं।

विकल्प B, इसे VPN पर प्राइवेट रखें। 8096 को पब्लिक इंटरनेट पर बिल्कुल भी पब्लिश न करें; Jellyfin तक केवल उसी बॉक्स पर समाप्त होने वाले WireGuard टनल के माध्यम से पहुँचें। एक घर के लिए यह सबसे सरल सुरक्षित विकल्प है, इसमें कोई सर्टिफिकेट, कोई पब्लिक एक्सपोज़र और कोई brute-force सरफेस नहीं होता। यहाँ compose फाइल से localhost बाइंडिंग अपने आप में पर्याप्त नहीं है, क्योंकि 127.0.0.1 पर पब्लिश किया गया पोर्ट केवल VPS से ही एक्सेस किया जा सकता है, VPN पीयर्स से नहीं। इसे सर्वर के टनल एड्रेस पर पब्लिश करें (उदाहरण के लिए "10.8.0.1:8096:8096", अपने WireGuard सर्वर IP का उपयोग करके), या localhost रखें और उसके सामने टनल एड्रेस पर लिसन करने वाली एक प्रॉक्सी रखें, फिर VPN के माध्यम से कनेक्ट करें। टनल के लिए WireGuard VPN setup for a private VPS देखें।

स्टोरेज साइजिंग और बैकअप

गुणवत्ता के आधार पर बजट तय करें, फाइलों की संख्या के आधार पर नहीं। कंप्रेस्ड 1080p फिल्में 4-15 GB की होती हैं; 1080p remux 20-40 GB का; 1080p TV शो का एक सीजन 15-40 GB का; और 4K कंटेंट 40-100 GB प्रति फिल्म तक हो सकता है। कुछ सौ फिल्मों और शो की लाइब्रेरी के लिए 2-4 TB का वॉल्यूम आवश्यक है, और बाद में माइग्रेट करने की तुलना में एक बार में ही अधिक क्षमता वाला ब्लॉक वॉल्यूम लेना सस्ता पड़ता है।

/config पूरे सर्वर की स्थिति है, इसलिए यही वह एकमात्र चीज है जिसका आपको बैकअप लेना चाहिए। इसका स्नैपशॉट लें या इसे स्टॉप करके tar फाइल बनाएं और इसकी कॉपी को सर्वर से बाहर रखें:

docker compose down
sudo tar czf jellyfin-config-$(date +%F).tgz -C ~/jellyfin config
docker compose up -d

/cache और ट्रांसकोड फोल्डर डिस्पोजेबल हैं। /mnt/media पर मौजूद मीडिया का बैकअप आप अलग से ले सकते हैं या इसे दोबारा रिप करने योग्य मान सकते हैं, आकार को देखते हुए अधिकांश लोग बाद वाला विकल्प चुनते हैं। अपग्रेड docker compose pull && docker compose up -d होते हैं; ऊपर दिया गया :12 टैग 12.x लाइन के भीतर ही रहता है, इसलिए अगले मेजर वर्जन पर जाना एक सोच-समझकर किया गया टैग एडिट है। ऐसा करने से पहले Jellyfin रिलीज नोट्स को ध्यान से पढ़ें, क्योंकि मेजर वर्जन पर लाइब्रेरी स्कीमा माइग्रेशन होते हैं। Jellyfin ने 12.0 (सितंबर 2026) के साथ अपने वर्जन नंबर से शुरुआती "10." को हटा दिया है: 12.0 वही है जो 10.12 होता, इसमें कोई 11.x नहीं है, और 10.11.x पुरानी स्कीम की अंतिम लाइन थी। यदि आपकी पुरानी compose फाइल में अभी भी jellyfin/jellyfin:10 लिखा है, तो यह 10.11 पर फ्रीज है (वह टैग आखिरी बार 2026-06-06 को 10.11.11 पर अपडेट हुआ था) और यह कभी भी 12.x को पुल नहीं करेगा। इसे :12 पर ले जाना केवल टैग एडिट से कहीं अधिक है: 12.0 डेटाबेस स्कीमा को बदल देता है और पहली बार बूट होने पर डेटा को फिर से लिखता है, इसलिए सर्वर को रोकें और पहले ऊपर बताया गया बैकअप लें, क्योंकि वही बैकअप वापस जाने का एकमात्र तरीका है। 12.0 सीधे 10.10.7 या किसी भी 10.11.x रिलीज से अपग्रेड हो जाता है, और इसके बाद इसे पूर्ण लाइब्रेरी स्कैन की आवश्यकता होती है, जिसमें सामान्य से काफी अधिक समय लगता है। एक पिन किया हुआ टैग और एक बैकअप लिया हुआ स्टेट डायरेक्टरी किसी भी हमेशा चलने वाले कंटेनर के लिए पूरा नुस्खा है, और यही वह पैटर्न है जो रीबूट के दौरान self-hosted एजेंट की मेमोरी और शेड्यूल को सुरक्षित रखने के पीछे काम करता है।

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

स्कैन के बाद लाइब्रेरी खाली है। Dashboard → Logs (या ~/jellyfin/config/log/log_*.log) पर लॉग यह दिखाता है:

System.UnauthorizedAccessException: Access to the path '/media/Movies' is denied.

कंटेनर का uid उस पाथ को पढ़ नहीं पा रहा है। कारण: मीडिया का स्वामित्व root के पास है या यह आपके user: मान के अलावा किसी अन्य uid के पास है, किसी डायरेक्टरी में execute बिट की कमी है, या पैरेंट माउंट स्वयं उस uid द्वारा एक्सेस नहीं किया जा सकता है। समाधान: chown -R 1000:1000 /mnt/media, डायरेक्टरी 755, फाइलें 644, और फिर rescan करें।

प्लेबैक CPU पर दबाव डालता है और बफर करता है। docker stats jellyfin में CPU उपयोग आपके कोर काउंट के अनुसार लगभग 100% के करीब दिखता है, और Dashboard → Playback में सेशन Transcode के रूप में सूचीबद्ध है जिसकी गति 1.0x से कम है। क्लाइंट direct-playing नहीं कर रहा है, इसलिए VPS CPU-transcoding को वास्तविक समय से धीमी गति से कर रहा है और पिछड़ रहा है। कारण: एक असमर्थित (unsupported) codec या कंटेनर, सबटाइटल बर्न-इन, या HDR टोन-मैपिंग। समाधान: direct-play क्लाइंट पर स्विच करें, सोर्स को H.264/AAC में रखें, image सबटाइटल (PGS/VOBSUB) के बजाय text सबटाइटल (SRT) का उपयोग करें, जिन्हें अधिकांश Jellyfin क्लाइंट स्वयं रेंडर नहीं कर सकते और इसलिए बर्न-इन के लिए मजबूर करते हैं, और 4K HDR को पूरी तरह से CPU-ओनली बॉक्स पर न चलाएं।

"No compatible streams are available." पूरा संदेश आमतौर पर यह होता है: "This client isn't compatible with the media and the server isn't sending a compatible media format." क्लाइंट ने सोर्स को अस्वीकार कर दिया और फॉलबैक ट्रांसकोड भी शुरू होने में विफल रहा। कारण: एक खराब ffmpeg कमांड, एक अपठनीय फाइल, या यूजर का प्रोफाइल जो वीडियो कन्वर्जन को ब्लॉक कर रहा है। समाधान: Dashboard → Logs में ffmpeg लाइन पढ़ें, पुष्टि करें कि फाइल चल रही है या नहीं, यदि आप ट्रांसकोडिंग पर निर्भर हैं तो यूजर की प्लेबैक अनुमतियों की जाँच करें, और ब्राउज़र कोडेक की समस्याओं को दूर करने के लिए दूसरे क्लाइंट का उपयोग करके देखें।

फिल्मों में पोस्टर नहीं हैं या गलत पोस्टर हैं। मेटाडेटा मेल नहीं खाया। कारण: एक फोल्डर या फाइल का नाम जो आपके मेटाडेटा प्रदाता द्वारा सूचीबद्ध शीर्षक से मेल नहीं खाता है, कोई रीमेक या सामान्य शीर्षक जिसमें संस्करणों को अलग करने के लिए वर्ष नहीं है, सीजन फोल्डर का नाम S01 के बजाय Season 01 होना, या एपिसोड का S01E01 प्रारूप में न होना। समाधान: ऊपर दिए गए लेआउट के अनुसार नाम बदलें, फिर Refresh metadata → Replace all करें, या सही TMDB/TVDB प्रविष्टि को पिन करने के लिए किसी एक आइटम पर Identify का उपयोग करें।

FAQ

क्या VPS बिना GPU के वीडियो transcode कर सकता है?

हाँ, लेकिन यह केवल CPU पर होता है और यह काफी महंगा है। एक 1080p software transcode कई vCPUs का उपयोग कर सकता है, और 4K या HEVC आमतौर पर real-time में नहीं चल पाते, जिससे playback में बफरिंग होती है। सबसे अच्छा तरीका यह है कि transcoding से बचें: अपनी लाइब्रेरी को H.264/AAC में रखें और ऐसे client apps का उपयोग करें जो direct-play करते हों, ताकि VPS केवल bytes को stream करे। GPU instance तभी किराए पर लें यदि आपको वास्तव में on-the-fly transcoding की आवश्यकता हो।

स्कैन के बाद मेरी Jellyfin लाइब्रेरी खाली क्यों है?

इसका कारण लगभग हमेशा permissions होता है। आधिकारिक jellyfin/jellyfin image उस user: के रूप में चलती है जिसे आप सेट करते हैं (या root), और यदि फाइलें उस uid द्वारा पढ़ने योग्य नहीं हैं, तो स्कैन logs में Access to the path ... is denied दिखाई देता है और वे फाइलें छोड़ दी जाती हैं। chown -R 1000:1000 /mnt/media के साथ ownership ठीक करें, directories को execute bit (755) दें, और फिर से स्कैन करें। parent directory की भी जाँच करें, क्योंकि यदि container का uid /mnt/media तक नहीं पहुँच सकता है, तो वह लाइब्रेरी फोल्डर तक कभी नहीं पहुँचेगा और सब कुछ खाली दिखाई देगा। दूसरा सबसे आम कारण ऐसा फोल्डर लेआउट है जो Jellyfin की अपेक्षाओं से मेल नहीं खाता है।

मैं Jellyfin को दूरस्थ रूप से और सुरक्षित रूप से कैसे एक्सेस करूँ?

दो अच्छे विकल्प हैं। इसे एक subdomain पर TLS reverse proxy के पीछे रखें ताकि login और stream एन्क्रिप्टेड रहें, और fail2ban जोड़ें। कभी भी plain port 8096 को expose न करें, जो आपके पासवर्ड को cleartext में भेजता है। या इसे पूरी तरह से निजी रखें और केवल VPN के माध्यम से एक्सेस करें, जो घर के उपयोग के लिए सबसे सरल और सुरक्षित विकल्प है। apps को सीधे public address दें, क्योंकि autodiscovery एक local-network broadcast है, इसलिए यह इंटरनेट के माध्यम से आने वाले clients तक नहीं पहुँचता है।

Jellyfin VPS को कितनी डिस्क और बैंडविड्थ की आवश्यकता होती है?

डिस्क की आवश्यकता गुणवत्ता पर निर्भर करती है: प्रति compressed 1080p फिल्म के लिए 4-15 GB, प्रति remux के लिए 20-40 GB, और 4K के लिए 40-100 GB का बजट रखें, इसलिए अधिकांश लाइब्रेरी के लिए 2-4 TB block volume की आवश्यकता होती है। बैंडविड्थ direct-play bitrate द्वारा निर्धारित होती है, जो प्रति 1080p stream 8-12 Mbps है, और 4K के लिए इससे कहीं अधिक है। इसलिए सुनिश्चित करें कि आपका port speed एक साथ देखने वाले दर्शकों की संख्या को संभाल सके और मासिक transfer cap पर नज़र रखें। यदि आप transcode करने की योजना बना रहे हैं तो CPU headroom बढ़ाएँ; यदि आप direct-play करने की योजना बना रहे हैं तो cores के बजाय बैंडविड्थ को प्राथमिकता दें।

क्या VPS पर Jellyfin चलाना कानूनी है?

Jellyfin स्वयं एक मुफ्त, open-source सॉफ्टवेयर है और इसे चलाना पूरी तरह से कानूनी है। मायने यह रखता है कि सामग्री क्या है: केवल वही मीडिया stream करें जिसे आप own करते हैं या जिसे रखने के लिए आप लाइसेंस प्राप्त हैं, जैसे कि आपके अपने disc rips, रिकॉर्डिंग, या ऐसी फाइलें जिनका आपके पास अधिकार है। Jellyfin कोई मीडिया प्रदान नहीं करता है और इसे प्राप्त करने का कोई तरीका नहीं देता है; यह केवल उस लाइब्रेरी के लिए एक प्लेयर है जिसे आप पहले से ही own करते हैं।

#jellyfin #media-server #Docker #सेल्फ़-होस्टिंग #transcoding