VPS پر Jellyfin: اپنی media stream کریں

آپ کیا بنا رہے ہیں

ایک VPS پر Jellyfin media server: ایک container، تین volumes، اور block-storage disk جس میں آپ کی فلمیں اور شوز محفوظ ہوں گے۔ یہ server کسی بھی browser یا Jellyfin app سے قابل رسائی ہوگا۔ Installation کے لیے صرف پندرہ سطروں والی compose file درکار ہے۔ اس کے بعد پیدا ہونے والے تقریباً تمام مسائل دو وجوہات سے ہوتے ہیں: file permissions جن کی وجہ سے container فائلیں پڑھ نہیں سکتا، اور GPU کے بغیر VPS سے ایسی video transcode کرنے کی کوشش جسے transcode کرنا اس کی ذمہ داری نہیں۔ اس guide کا زیادہ تر حصہ انہی دو مسائل کے لیے ہے، کیونکہ support tickets عموماً یہیں سے آتی ہیں۔

Jellyfin مفت اور مکمل طور پر open source ہے۔ اس کے لیے account درکار نہیں، کوئی paywalled feature نہیں، اور telemetry بھی نہیں۔ اسی وجہ سے یہ تقریباً ہر اس فہرست میں شامل ہوتا ہے جس میں 2026 میں self-host کرنے کے قابل چیزیں شامل ہوں۔ یہ آپ کی اپنی media چلاتا ہے۔ اس کے ساتھ کوئی content فراہم نہیں کیا جاتا، اور یہ guide کوئی content حاصل کرنے کے بارے میں نہیں ہے۔

کرایہ لینے سے پہلے transcoding کی حقیقت

یہ پہلے پڑھیں، کیونکہ اس سے طے ہوتا ہے کہ آپ کیا خریدیں گے۔ جب آپ play دباتے ہیں تو media server دو میں سے ایک کام کرتا ہے۔ Direct play فائل کو اسی حالت میں stream کرتا ہے: VPS ڈسک سے bytes پڑھ کر network پر بھیجتا ہے، جس میں تقریباً CPU استعمال نہیں ہوتا۔ Transcoding ویڈیو کو اسی وقت دوبارہ encode کرتا ہے، مثلاً نئی resolution، نیا codec، یا ویڈیو میں subtitles شامل کرنے کے لیے؛ یہ مکمل طور پر CPU کا کام ہے۔

عام VPS میں GPU نہیں ہوتا۔ اس لیے ہر transcode CPU پر libx264/libx265 کے ساتھ چلتا ہے، اور software encoding مہنگی پڑتی ہے۔ ایک 1080p H.264 transcode کئی shared vCPUs کو مکمل طور پر مصروف کر سکتا ہے؛ 4K یا HEVC transcode عموماً real time کے ساتھ نہیں چل پاتا، اس لیے playback رک رک کر چلتا ہے اور مسلسل buffer ہوتا رہتا ہے۔ Hardware transcoding، جو Intel iGPU یا Nvidia card والے home box پر یہ کام سستا بناتی ہے، آپ کے لیے دستیاب نہیں ہوتی، جب تک provider GPU instances کرایے پر نہ دے۔

اس لیے VPS پر پوری حکمت عملی یہ ہے: transcoding سے بچیں۔ اپنی library ایسے codecs میں رکھیں جنہیں آپ کے clients native طور پر چلا سکیں، یعنی H.264 video، AAC یا AC3 audio، اور MP4 یا MKV container۔ ایسی client apps منتخب کریں جو direct-play کریں: Android TV، iOS اور Roku کے لیے native Jellyfin apps، نیز Infuse، Kodi اور desktop Jellyfin Media Player۔ ایسا کرنے پر VPS کو ffmpeg کو بالکل استعمال نہیں کرنا پڑتا، اور ایک معمولی 2 vCPU box بیک وقت کئی افراد کو stream کر سکتا ہے۔ اگر آپ transcoding کا منصوبہ بناتے ہیں تو آپ کو کہیں بڑا اور مہنگا box درکار ہوگا، اور اس کے باوجود 4K ایک خراب انتخاب ہے۔

بینڈوڈتھ کا حساب بھی کریں، کیونکہ یہ دوسرا غیر متوقع مسئلہ ہے۔ Direct play میں فائل اپنے اصل bitrate پر بھیجی جاتی ہے۔ compressed 1080p فائل عموماً 8-12 Mbps استعمال کرتی ہے؛ 1080p Blu-ray remux 20-30 Mbps؛ اور 4K HDR 40-80 Mbps۔ اگر 3 افراد 10 Mbps والی فائلیں direct-play کریں تو آپ کے VPS سے مسلسل 30 Mbps upload ہوگا۔ اپنے plan میں 2 اعداد دیکھیں: port speed، یعنی کیا یہ 30 Mbps upstream بھیج سکتی ہے، اور ماہانہ transfer cap۔ 10 Mbps کی 2 گھنٹے کی ایک فلم تقریباً 9 GB outbound traffic بناتی ہے۔ اس لیے 1 TB/month کی metered allowance میں ماہانہ 100 سے کچھ زیادہ ایسی فلمیں، یعنی روزانہ 3 یا 4 فلمیں، شامل ہو سکتی ہیں۔ 4K مواد دیکھنے والا گھرانہ، جس میں bitrate 4 سے 8 گنا زیادہ ہوتی ہے، یہ allowance کہیں زیادہ تیزی سے ختم کر دے گا۔ اسی server سے باہر جانے والے دیگر تمام traffic کو بھی اسی budget میں شمار کریں، جس میں self-hosted RustDesk relay بھی شامل ہے۔ جب 2 peers براہِ راست connect نہ ہو سکیں تو یہ پوری remote desktop session منتقل کرتا ہے۔

شرائطِ ضروریہ

• ایک تازہ Ubuntu 24.04 KVM VPS، جس پر root یا sudo access ہو، اور Docker کے ساتھ Compose plugin بھی نصب ہو۔
• media کے لیے block-storage volume، جس کا سائز آپ کی library کے مطابق ہو۔ سائز متعین کرنے کے لیے ذیل میں دیکھیں۔ VPS کے ساتھ آنے والی چھوٹی root disk آپ کی فلموں کے لیے مناسب جگہ نہیں ہے۔
• اگر آپ public HTTPS access چاہتے ہیں تو ایک domain name، یا اگر آپ پوری سروس نجی رکھنا چاہتے ہیں تو اسی VPS پر WireGuard VPN۔
• ایسا media جسے stream کرنے کا آپ کو قانونی حق حاصل ہو: آپ کی اپنی rips، آپ کی اپنی recordings، یا وہ files جن کی ملکیت آپ کے پاس ہو۔

سب سے پہلے block storage mount کریں

اپنے provider کے panel میں volume attach کریں، پھر اسے تلاش کر کے mount کریں۔ lsblk سے device name حاصل کریں۔ یہ /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

اسے /dev/sdb کے بجائے UUID کے ذریعے mount کریں، کیونکہ reboot کے دوران device letters کی ترتیب بدل سکتی ہے، اور آپ غلط disk کو format یا mount کر سکتے ہیں۔ /etc/fstab میں ایک سطر شامل کریں:

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

sudo mount -a
df -h /mnt/media

nofail اہم ہے۔ اس کے بغیر، اگر block volume کبھی detach ہو جائے تو system boot ہونے سے انکار کر دیتا ہے اور emergency shell میں چلا جاتا ہے۔ یہاں سب سے بڑی عام غلطی ایسے volume پر mkfs.ext4 چلانا ہے جس میں پہلے سے data موجود ہو؛ اس سے data مٹ جاتا ہے۔ صرف نئے volumes کو format کریں۔ اگر disk پر پہلے ہی آپ کی library موجود ہے تو براہ راست fstab کی سطر پر جائیں۔

Jellyfin کے متوقع طریقے کے مطابق میڈیا ترتیب دیں

Jellyfin metadata کو فولڈر اور فائل کے ناموں کی بنیاد پر ملاتا ہے۔ اگر ترتیب غلط ہو تو فلمیں poster کے بغیر بے نام فائلوں کے طور پر ظاہر ہوتی ہیں، یا کوئی episode غلط series سے match ہو جاتا ہے۔ صرف تین قواعد ہیں: ہر movie اپنے الگ Name (Year) فولڈر میں ہو اور اس کا filename فولڈر کے نام سے مطابقت رکھتا ہو؛ season folders کا نام Season 01 ہو، S01 نہیں؛ episode files میں S01E01 استعمال ہو؛ اور specials کو 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) محض سجاوٹ نہیں ہے۔ یہ remakes میں فرق کرتا ہے، تاکہ matcher درست title منتخب کرے۔ Movies اور Shows کو الگ top-level folders کے طور پر رکھیں، کیونکہ ہر folder مخصوص content type کی Jellyfin library بنتا ہے، اور انہیں ملانے سے metadata provider الجھ جاتا ہے۔ Jellyfin تصاویر کے لیے تیسرا folder بھی آسانی سے index کر لے گا، لیکن purpose-built photo server کے مقابلے میں اس کا تجربہ محدود ہے۔ اس لیے اگر آپ کے albums اہم ہیں تو ان کے لیے PhotoPrism یا Immich چلانے والا الگ box رکھیں، اور اس server کو film اور TV کے لیے مختص رکھیں۔

اجازتیں: libraries کے خالی نظر آنے کی سب سے بڑی وجہ

یہ وہ غلط فہمی ہے جس کی وجہ سے لوگ پوری شام ضائع کر دیتے ہیں۔ سرکاری jellyfin/jellyfin image، PUID/PGID environment variables کو تسلیم نہیں کرتی؛ یہ LinuxServer.io image (lscr.io/linuxserver/jellyfin) سے متعلق ہیں۔ سرکاری image میں compose کے اندر user: key کے ذریعے user متعین کیا جاتا ہے۔ اگر یہ key نہ دی جائے تو container root** کے طور پر چلتا ہے۔ آپ جو بھی طریقہ استعمال کریں، اصول ایک ہی ہے: container جس uid/gid کے تحت چل رہا ہو، اسے ہر media directory کو read اور traverse کرنے کی اجازت ہونی چاہیے۔

ہم uid/gid 1000 کے تحت چلائیں گے۔ stock Ubuntu box پر یہ پہلا non-root user ہوتا ہے۔ اپنی uid/gid کی تصدیق کریں اور ownership مقرر کریں:

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

Directories کے لیے صرف read اجازت کافی نہیں؛ execute bit بھی درکار ہوتی ہے، یعنی 755 میں موجود x۔ اس کے بغیر container folder میں داخل نہیں ہو سکتا، چاہے وہ اس کا نام list کر سکے۔ پوری library کو خالی کر دینے والا مسئلہ parent directory ہوتا ہے: اگر container کے uid کو mount پر traverse کرنے کی اجازت نہ ہو تو وہ /media/Movies یا /media/Shows تک کبھی نہیں پہنچتا، اور ہر library ایک ہی وقت میں خالی نظر آتی ہے۔ Log میں Access to the path ... is denied درج ہوتا ہے۔ جس media folder کو container پڑھ نہیں سکتا، اسے log میں درج کرکے نظرانداز کر دیا جاتا ہے۔ اس لیے root کے طور پر copy کی گئی files کا پورا batch library سے خاموشی سے غائب ہو جاتا ہے۔ اسی وجہ سے ہم ownership کو recursively تبدیل کرتے ہیں اور صرف ایک folder ٹھیک کرنے کے بجائے ہر directory پر execute bit مقرر کرتے ہیں۔

Docker Compose فائل

services:
  jellyfin:
    image: jellyfin/jellyfin:10
    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

لائن بہ لائن: user: "1000:1000" وہ ترتیب ہے جو واقعی file permissions مقرر کرتی ہے اور اوپر بیان کردہ ownership سے مطابقت رکھتی ہے۔ /config میں پورا server state، accounts، libraries، metadata اور watch state موجود ہوتے ہیں، اس لیے اس میں write access ہونا ضروری ہے اور backup بھی اسی کا لیا جاتا ہے۔ /cache عارضی working space ہے۔ Media mount کو جان بوجھ کر :ro (read-only) رکھا گیا ہے۔ Jellyfin عام طور پر artwork اور metadata کو /config کے تحت محفوظ کرتا ہے، اس لیے اسے library میں write کرنے کی ضرورت نہیں ہوتی۔ Read-only mode آپ کی files کو accidental delete یا خراب plugin سے محفوظ رکھتا ہے۔ Port کو جان بوجھ کر 127.0.0.1 پر bind کیا گیا ہے۔ Jellyfin کا web login plain HTTP استعمال کرتا ہے، اس لیے ہم 8096 کو public internet پر publish نہیں کرتے۔ JELLYFIN_PublishedServerUrl وہ address ہے جسے server local autodiscovery کے لیے advertise کرتا ہے۔ یہ LAN UDP broadcast ہے، اس لیے internet پر موجود clients اسے نہیں دیکھ سکتے اور app میں درج کیے گئے URL کو ہی استعمال کرتے ہیں۔ اسے اس address پر set کریں جو clients کو بتایا جانا چاہیے، اور remote devices پر یہ URL manually درج کرنے کے لیے تیار رہیں۔

اسے compose directory سے start کریں:

docker compose up -d
docker logs -f jellyfin

پہلی بار چلانا: setup wizard اور آپ کی libraries

چونکہ port صرف localhost سے bind ہے، اس لیے firewall میں نیا راستہ کھولنے کے بجائے اپنے laptop سے SSH tunnel کے ذریعے wizard تک رسائی حاصل کریں:

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

اب http://localhost:8096 کھولیں۔ wizard پہلے language منتخب کرنے، پھر مضبوط password کے ساتھ admin user بنانے کے مراحل مکمل کراتا ہے۔ یہ account آپ کے server کے لیے ہے، اس لیے عارضی یا دوبارہ استعمال ہونے والا password نہ رکھیں۔ اپنی پہلی library شامل کریں: content type Movies منتخب کریں، اسے /media/Movies پر point کریں۔ یہ container کے اندر والا path ہے، host کا path نہیں۔ پھر Shows کے لیے یہی عمل /media/Shows کے ساتھ دہرائیں۔ setup مکمل کریں، پھر Jellyfin scan شروع کرے گا۔ درست نتیجے میں چھوٹی library کے لیے ایک یا دو منٹ کے اندر posters اور titles ظاہر ہو جانے چاہییں۔ بعد میں libraries کو Dashboard → Libraries کے تحت شامل یا edit کریں، اور Scan All Libraries سے دوبارہ مکمل scan شروع کریں۔

اگر آپ کسی بھی قسم کی transcoding استعمال کرتے ہیں تو Dashboard → Playback → Transcoding کھولیں اور transcode temp path کو /cache/transcodes پر set کریں، تاکہ عارضی data cache volume میں محفوظ ہو اور /config غیر ضروری طور پر نہ بھرے۔ hardware acceleration کو None پر رہنے دیں، کیونکہ acceleration کے لیے کوئی GPU موجود نہیں ہے۔

ریموٹ رسائی: TLS reverse proxy، یا اسے VPN پر نجی رکھیں

باہر سے Jellyfin تک رسائی کے لیے دو محفوظ طریقے ہیں، جبکہ ایک غیر محفوظ طریقے سے گریز کرنا چاہیے۔ غیر محفوظ طریقہ یہ ہے کہ port 8096 کو براہ راست internet پر شائع کر دیا جائے۔ اس صورت میں login کا ڈیٹا cleartext میں منتقل ہوتا ہے، اور چند گھنٹوں میں اس port پر brute-force حملے شروع ہو جاتے ہیں۔

Option A، TLS reverse proxy۔ Jellyfin کو کسی subdomain پر اپنی Docker apps کے لیے خودکار TLS کے ساتھ Traefik کے پیچھے رکھیں، یا nginx کے ساتھ Certbot سے جاری کردہ Let's Encrypt certificate استعمال کریں۔ Jellyfin حقیقی وقت کی updates کے لیے WebSockets استعمال کرتا ہے، اس لیے proxy کو upgrade headers آگے بھیجنے چاہییں۔ Traefik یہ کام خودکار طور پر کرتا ہے؛ nginx میں یہ headers واضح طور پر درج کرنے ہوتے ہیں، اور upstream کے لیے HTTP/1.1 درکار ہے، ورنہ upgrade کبھی مکمل نہیں ہوتا:

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:// address پر set کریں تاکہ مقامی autodiscovery درست URL کا اعلان کرے، remote apps آپ کے فراہم کردہ address کو استعمال کریں، اور login کے خلاف brute-force کوششیں سست کرنے کے لیے fail2ban شامل کریں۔ server کو public کرنے کے بعد Uptime Kuma کو اس URL پر point کریں تاکہ viewers سے پہلے آپ کو downtime کا علم ہو جائے۔

Option B، اسے VPN پر نجی رکھیں۔ port 8096 کو بالکل publish نہ کریں؛ Jellyfin تک صرف اسی machine پر terminate ہونے والے WireGuard tunnel کے ذریعے رسائی حاصل کریں۔ گھریلو استعمال کے لیے یہ سب سے سادہ محفوظ انتخاب ہے: certificate کی ضرورت نہیں، public exposure نہیں، اور brute-force کے لیے attack surface نہیں۔ container کو tunnel address یا localhost پر bind کریں اور VPN کے ذریعے connect کریں۔ tunnel کے لیے نجی VPS کے لیے WireGuard VPN setup دیکھیں۔

ذخیرے کا حجم اور بیک اپ

بجٹ فائلوں کی تعداد کے بجائے معیار کے مطابق بنائیں۔ Compressed 1080p فلمیں فی فلم 4-15 GB ہوتی ہیں؛ 1080p remux کا حجم 20-40 GB ہوتا ہے؛ 1080p ٹی وی کے ایک سیزن کے لیے 15-40 GB درکار ہوتے ہیں؛ 4K مواد میں ہر فلم کے لیے 40-100 GB درکار ہوتے ہیں۔ چند سو فلموں اور کچھ شوز پر مشتمل library کے لیے 2-4 TB volume درکار ہوگا۔ block volume کو بعد میں migrate کرنے کے بجائے ابتدا ہی میں قدرے زیادہ provision کرنا سستا پڑتا ہے۔

/config پورے server state پر مشتمل ہے، اس لیے بیک اپ لینے کے لیے یہی سب سے اہم چیز ہے۔ اس کا snapshot بنائیں یا server روک کر اسے tar archive میں محفوظ کریں، اور copy کو server سے باہر رکھیں:

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

/cache اور transcode folder دوبارہ بنائے جا سکتے ہیں۔ /mnt/media پر موجود media کا الگ بیک اپ لیں، یا اسے دوبارہ rip کرنے کے قابل سمجھیں۔ زیادہ تر لوگ حجم کی وجہ سے دوسرا طریقہ اختیار کرتے ہیں۔ Upgrades docker compose pull && docker compose up -d ہوتے ہیں؛ اوپر موجود :10 tag 10.x major کے اندر رہتا ہے، اس لیے اگلے major پر منتقل ہونا tag میں دانستہ ترمیم کا تقاضا کرتا ہے۔ یہ ترمیم کرنے سے پہلے Jellyfin کی release notes کا سرسری جائزہ لیں، کیونکہ library schema migrations major versions پر ہوتی ہیں۔ ایک pinned tag اور ایک backed-up state directory ہر ہمیشہ چلنے والے container کے لیے مکمل طریقۂ کار ہے۔ یہی pattern self-hosted agent کی memory اور schedules کو reboot کے بعد برقرار رکھنے کے پیچھے بھی ہے۔

خرابی کی صورتیں اور ظاہر ہونے والے پیغامات

اسکین کے بعد library خالی ہے۔ Dashboard → Logs (یا ~/jellyfin/config/log/log_*.log) میں یہ لاگ دکھائی دیتا ہے:

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

Container کا uid اس path کو پڑھ نہیں سکتا۔ وجہ یہ ہو سکتی ہے کہ media کی ملکیت root یا آپ کی user: قدر سے مختلف uid کے پاس ہے، کسی directory میں execute bit موجود نہیں، یا parent mount خود اس uid کے لیے قابل رسائی نہیں ہے۔ حل: chown -R 1000:1000 /mnt/media، directories کے لیے 755، اور files کے لیے 644 set کریں، پھر دوبارہ scan کریں۔

Playback کے دوران CPU پوری طرح استعمال ہوتا ہے اور buffering ہوتی ہے۔ docker stats jellyfin میں CPU آپ کے core count کے قریب 100% دکھاتا ہے، اور Dashboard → Playback session کو Transcode کے طور پر دکھاتا ہے، جبکہ speed 1.0x سے کم ہوتی ہے۔ Client direct-playing نہیں کر رہا، اس لیے VPS CPU کے ذریعے real time سے کم رفتار پر transcoding کر رہا ہے اور playback پیچھے رہ جاتا ہے۔ وجہ unsupported codec یا container، subtitle burn-in، یا HDR tone-mapping ہو سکتی ہے۔ حل: direct-play client استعمال کریں، sources کو H.264/AAC میں رکھیں، image subtitles (PGS/VOBSUB) کے بجائے text subtitles (SRT) استعمال کریں، کیونکہ image subtitles burn-in پر مجبور کرتے ہیں، اور CPU-only box پر 4K HDR مکمل طور پر استعمال نہ کریں۔

"No compatible streams are available." مکمل پیغام عموماً "This client isn't compatible with the media and the server isn't sending a compatible media format." ہوتا ہے۔ Client نے source مسترد کر دیا اور fallback transcode بھی شروع نہیں ہو سکا۔ وجہ خراب ffmpeg command، ناقابلِ مطالعہ file، یا user profile میں video conversion کی پابندی ہو سکتی ہے۔ حل: Dashboard → Logs میں ffmpeg line پڑھیں، تصدیق کریں کہ file مکمل طور پر play ہوتی ہے، اگر transcoding پر انحصار ہے تو user کی playback permissions چیک کریں، اور browser codec کی مخصوص خرابی کو خارج کرنے کے لیے دوسرے client سے آزمائیں۔

Films کے لیے poster موجود نہیں یا غلط poster دکھائی دیتا ہے۔ Metadata کا match نہیں ہوا۔ وجہ یہ ہو سکتی ہے کہ movie اپنی الگ Name (Year) folder میں نہیں ہے، season folder کا نام S01 کے بجائے Season 01 ہے، episodes S01E01 format میں نہیں ہیں، یا year موجود نہیں ہے۔ حل: اوپر دیے گئے layout کے مطابق نام تبدیل کریں، پھر Refresh metadata → Replace all منتخب کریں، یا کسی ایک item پر درست TMDB/TVDB entry مقرر کرنے کے لیے Identify استعمال کریں۔

FAQ

کیا VPS کسی GPU کے بغیر ویڈیو کو transcode کر سکتا ہے؟

ہاں، لیکن صرف CPU پر، اور یہ مہنگا پڑتا ہے۔ ایک 1080p software transcode کئی vCPUs کو مکمل طور پر استعمال کر سکتا ہے، جبکہ 4K یا HEVC عموماً real time کے ساتھ رفتار برقرار نہیں رکھتا، اس لیے playback buffer ہونے لگتی ہے۔ بہتر طریقہ transcoding سے گریز ہے: اپنی library کو H.264/AAC میں رکھیں اور ایسی client apps استعمال کریں جو direct-play کریں، تاکہ VPS صرف bytes stream کرے۔ GPU instance صرف اسی وقت کرائے پر لیں جب واقعی on-the-fly transcoding درکار ہو۔

scan کے بعد میری Jellyfin library خالی کیوں ہے؟

تقریباً ہمیشہ وجہ permissions ہوتی ہے۔ official jellyfin/jellyfin image اسی user: کے طور پر چلتی ہے جو آپ نے set کیا ہو، یا root کے طور پر، اور اگر files اس uid کے لیے readable نہ ہوں تو scan logs Access to the path ... is denied لکھ کر انہیں نظرانداز کرتی ہے۔ chown -R 1000:1000 /mnt/media سے ownership درست کریں، directories کو execute bit 755 دیں، پھر دوبارہ scan کریں۔ parent directory بھی چیک کریں، کیونکہ اگر container کا uid خود /mnt/media میں traverse نہ کر سکے تو وہ library folders تک پہنچ ہی نہیں پاتا اور سب کچھ خالی دکھائی دیتا ہے۔ دوسری عام وجہ ایسا folder layout ہے جو Jellyfin کی متوقع ساخت کے مطابق نہیں ہوتا۔

میں Jellyfin تک remotely اور محفوظ طریقے سے کیسے رسائی حاصل کروں؟

دو اچھے طریقے ہیں۔ اسے subdomain پر TLS reverse proxy کے پیچھے رکھیں تاکہ login اور stream encrypted رہیں، اور fail2ban شامل کریں۔ plain port 8096 کو کبھی expose نہ کریں، کیونکہ اس کے ذریعے آپ کا password cleartext میں بھیجا جاتا ہے۔ یا اسے مکمل طور پر private رکھیں اور صرف VPN کے ذریعے رسائی حاصل کریں؛ گھر کے استعمال کے لیے یہ سب سے آسان محفوظ انتخاب ہے۔ Apps کو public address براہ راست نہ دیں، کیونکہ autodiscovery local-network broadcast ہے اور internet کے ذریعے آنے والے clients تک نہیں پہنچتی۔

Jellyfin کے VPS کو کتنی disk اور bandwidth درکار ہے؟

Disk کا انحصار quality پر ہے: compressed 1080p film کے لیے 4-15 GB، remux کے لیے 20-40 GB، اور 4K کے لیے 40-100 GB مختص کریں۔ اس لیے زیادہ تر libraries کو 2-4 TB block volume درکار ہوتا ہے۔ Bandwidth کا تعین direct-play bitrate سے ہوتا ہے: ہر 1080p stream کے لیے 8-12 Mbps، جبکہ 4K کے لیے اس سے کہیں زیادہ درکار ہوتا ہے۔ اس لیے تصدیق کریں کہ آپ کی port speed بیک وقت viewers کی تعداد سنبھال سکتی ہے، اور ماہانہ transfer cap کو monitor کریں۔ اگر آپ transcoding کا ارادہ رکھتے ہیں تو CPU headroom شامل کریں؛ اگر direct-play کرنا ہے تو cores کے مقابلے میں bandwidth کو ترجیح دیں۔

کیا VPS پر Jellyfin چلانا قانونی ہے؟

Jellyfin خود free، open-source software ہے، اور اسے چلانا مکمل طور پر قانونی ہے۔ اہم چیز content ہے: صرف وہ media stream کریں جو آپ کی ملکیت ہو یا جسے رکھنے کا آپ کو license حاصل ہو، مثلاً اپنی disc rips، recordings یا وہ files جن کے استعمال کا آپ کو حق حاصل ہو۔ Jellyfin کوئی media فراہم نہیں کرتا اور اسے حاصل کرنے کا کوئی طریقہ بھی نہیں دیتا؛ یہ اس library کے لیے player ہے جو پہلے سے آپ کی ملکیت میں ہو۔