راهاندازی Jellyfin روی VPS با داکر و فضای ابری
اجرای Jellyfin در Docker روی VPS با دیسک بلوکی: راهنمای کامل مجوزهای فایل، تفاوت Direct Play با CPU transcoding و دسترسی امن از راه دور بدون GPU.
آنچه میسازید
یک سرور رسانه Jellyfin روی یک VPS: یک کانتینر، سه Volume، و یک دیسک ذخیرهسازی بلوکی که فیلمها و سریالهایتان را نگه میدارد و از هر مرورگر یا اپلیکیشن Jellyfin قابل دسترسی است. نصب، یک فایل Compose پانزده خطی است. هر مشکلی که بعداً پیش بیاید از دو جا ناشی میشود: مجوزهای فایلی که کانتینر نمیتواند بخواند، و درخواست ترنسکد ویدیو از یک VPS بدون GPU که اصولاً نباید چنین کاری بکند. این راهنما بیشتر حجم خود را به این دو موضوع اختصاص میدهد، چون محل اصلی تیکتهای پشتیبانی همانجاست.
Jellyfin رایگان و کاملاً متنباز است، بدون حساب کاربری، بدون قابلیتهای پولی، و بدون تلهمتری؛ به همین دلیل تقریباً در هر فهرستی از چیزهایی که در 2026 ارزش سلفهاست کردن دارند قرار میگیرد. این نرمافزار رسانههایی را پخش میکند که مالک آن هستید. هیچ محتوایی ارائه نمیدهد، و این راهنما هم دربارهٔ تهیهٔ محتوا نیست.
واقعیت ترنسکدینگ، پیش از آنکه چیزی اجاره کنید
این بخش را اول بخوانید، چون چیزی که میخرید را تغییر میدهد. یک سرور مدیا وقتی دکمهٔ پخش را میزنید یکی از دو کار را انجام میدهد. پخش مستقیم فایل را همانطور که هست استریم میکند: VPS بایتها را از روی دیسک میخواند و روی شبکه میفرستد، که تقریباً هیچ CPUای مصرف نمیکند. ترنسکدینگ ویدئو را در لحظه بازکد میکند، رزولوشن جدید، کدک جدید، یا زیرنویسهای سوختهشده، و این کار خالصاً CPU است.
یک VPS معمولی GPU ندارد. بنابراین هر ترنسکد روی CPU با libx264/libx265 اجرا میشود، و کدگذاری نرمافزاری پرهزینه است. یک ترنسکد تکی 1080p H.264 میتواند چندین vCPU اشتراکی را اشباع کند؛ یک ترنسکد 4K یا HEVC معمولاً اصلاً نمیتواند با زمان واقعی همگام بماند، در نتیجه پخش متوقف میشود و بینهایت بافر میکند. ترنسکدینگ سختافزاری، همان چیزی که روی یک باکس خانگی با iGPU اینتل یا کارت Nvidia ارزان تمام میشود، برای شما بهسادگی در دسترس نیست مگر آنکه ارائهدهندهتان نمونههای GPU اجاره دهد.
بنابراین کل استراتژی روی یک VPS این است: از ترنسکدینگ پرهیز کنید. کتابخانهٔ خود را در کدکهایی نگه دارید که کلاینتهایتان بهطور بومی پخش میکنند، ویدئوی H.264، صدای AAC یا AC3، در کانتینر MP4 یا MKV، و اپهای کلاینتی را انتخاب کنید که پخش مستقیم انجام میدهند: اپهای بومی Jellyfin برای Android TV، iOS و Roku، بههمراه Infuse، Kodi، و Jellyfin Media Player دسکتاپ. این کار را بکنید و VPS هرگز ffmpeg را لمس نمیکند، و یک باکس سادهٔ 2 vCPU همزمان برای چند نفر استریم میکند. اگر برای ترنسکدینگ برنامهریزی کنید، به یک باکس بسیار بزرگتر و گرانتر نیاز دارید، و حتی آن وقت هم 4K شرط بدی است.
محاسبهٔ پهنای باند را هم انجام دهید، چون غافلگیری دیگر همین است. پخش مستقیم فایل را با نرخ بیت خودش میفرستد. یک فایل فشردهٔ 1080p بین 8-12 Mbps کار میکند؛ یک ریموکس Blu-ray 1080p بین 20-30 Mbps؛ 4K HDR بین 40-80 Mbps. سه نفر که فایلهای 10 Mbps را پخش مستقیم میکنند یعنی 30 Mbps آپلود پیوسته از VPS شما. دو عدد را در طرح خود بررسی کنید: سرعت پورت (آیا میتواند 30 Mbps آپاستریم بفرستد؟) و سقف ترنسفر ماهانه. یک فیلم دو ساعتهٔ 10 Mbps حدود 9 گیگابایت خروجی دارد، بنابراین سهمیهٔ حجمی 1 ترابایت در ماه اندکی بیش از صد فیلم از این دست در ماه میشود، یعنی سه یا چهار فیلم در روز، و یک خانواده که 4K تماشا میکند، با نرخ بیت چهار تا هشت برابر، آن را بسیار سریعتر خالی میکند.
پیشنیازها
- یک سرور مجازی KVM تازه با اوبونتو 24.04، دسترسی ریشه یا سودو، و داکر بههمراه افزونهٔ کامپوز نصبشده.
- یک حجم ذخیرهسازی بلوکی برای رسانهها، با اندازهای متناسب با کتابخانهٔ شما (راهنمای اندازهگیری در ادامه آمده است). دیسک ریشهٔ کوچکی که همراه سرور مجازی ارائه میشود، محل قرارگیری فیلمهای شما نیست.
- یک نام دامنه اگر به دسترسی عمومی با HTTPS نیاز دارید، یا یک شبکهٔ خصوصی مجازی وایرگارد روی همان سرور مجازی اگر ترجیح میدهید کل مجموعه را خصوصی نگه دارید.
- رسانههایی که قانوناً مجاز به پخش آنها هستید، ریپهای شخصی خودتان، ضبطهای خودتان، فایلهایی که مالک آنها هستید.
ابتدا فضای ذخیرهسازی بلوکی را متصل کنید
حجم را در پنل ارائهدهنده خود متصل کنید، سپس آن را پیدا کرده و متصل نمایید. نام دستگاه را از lsblk دریافت کنید، چیزی شبیه به /dev/sdb یا /dev/vdb خواهد بود، هرگز دیسک ریشه نیست.
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 متصل کنید، نه با /dev/sdb، زیرا حروف دستگاه در طول راهاندازی مجدد جابهجا میشوند و ممکن است در نهایت دیسک اشتباهی را فرمت یا متصل کنید. یک خط به /etc/fstab اضافه کنید:
UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx /mnt/media ext4 defaults,nofail 0 2sudo mount -a
df -h /mnt/medianofail اهمیت دارد: بدون آن، اگر حجم بلوکی جدا شود، سرور از راهاندازی خودداری کرده و به یک پوسته اضطراری سقوط میکند. بزرگترین اشتباه در اینجا اجرای mkfs.ext4 روی حجمی است که از قبل داده دارد، آن را پاک میکند. فقط حجمهای جدید را فرمت کنید؛ اگر دیسک از قبل کتابخانه شما را دارد، مستقیماً به خط fstab بروید.
رسانهها را به شکلی که جلیفین انتظار دارد مرتب کنید
جلیفین فراداده را بر اساس نام پوشهها و فایلها تطبیق میدهد. اگر چیدمان اشتباه باشد، فیلمها بدون عنوان و پوستر وارد میشوند، یا یک اپیزود با سریال اشتباهی تطبیق داده میشود. دقیقاً سه قانون وجود دارد: هر فیلم در پوشهٔ Name (Year) خودش با نام فایلی یکسان قرار میگیرد؛ پوشههای فصل با 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 به متغیرهای محیطی PUID/PGID توجهی نمیکند؛ این متغیرها متعلق به ایمیج LinuxServer.io (lscr.io/linuxserver/jellyfin) هستند. در ایمیج رسمی، شما کاربر را با کلید user: در فایل compose کنترل میکنید و اگر آن را حذف کنید، کانتینر بهعنوان root اجرا میشود. صرفنظر از اینکه از کدام استفاده میکنید، قانون یکسان است: uid/gid که کانتینر با آن اجرا میشود باید بتواند تمام دایرکتوریهای رسانه را بخواند و در آنها پیمایش کند.
ما با uid/gid برابر 1000 اجرا میکنیم که اولین کاربر غیر root روی یک سیستم اوبونتو پیشفرض است. مالکیت را تأیید و تنظیم کنید:
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دایرکتوریها به بیت execute (x در 755) نیاز دارند، نه فقط خواندن؛ بدون آن، کانتینر نمیتواند وارد پوشه شود، حتی اگر بتواند نام آن را فهرست کند. دامی که کل کتابخانه را خالی میکند، والد است: اگر uid کانتینر نتواند خود mount را پیمایش کند، هرگز به /media/Movies یا /media/Shows نمیرسد و تمام کتابخانهها بهیکباره خالی میمانند و Access to the path ... is denied در لاگ ثبت میشود. هر پوشه رسانهای که قابل خواندن نباشد، ثبت و رد میشود؛ بنابراین یک دسته فایل که بهعنوان root کپی شدهاند، بیصدا از کتابخانه ناپدید میشوند. به همین دلیل است که ما بهصورت بازگشتی chown میکنیم و بیت execute را روی تمام دایرکتوریها تنظیم میکنیم، بهجای اینکه فقط یک پوشه را درست کنیم.
فایل 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" همان چیزی است که واقعاً مجوزهای فایل را تنظیم میکند و با مالکیت بالا مطابقت دارد. /config کل سرور، حسابها، کتابخانهها، فراداده و وضعیت تماشا را نگه میدارد، بنابراین باید قابل نوشتن باشد و همان چیزی است که از آن پشتیبان میگیرید. /cache فضای کاری موقتی و دورریختنی است. محل نصب رسانه :ro (فقط خواندنی) است و این عمدی است: Jellyfin بهطور پیشفرض آثار هنری و فراداده را در /config ذخیره میکند، بنابراین هرگز نیازی به نوشتن در کتابخانه شما ندارد و حالت فقط خواندنی از فایلهای شما در برابر حذف تصادفی یا یک افزونه بد محافظت میکند. پورت به 127.0.0.1 متصل شده است و این هم عمدی است، ورود تحت وب Jellyfin HTTP ساده است، بنابراین ما هرگز 8096 را در اینترنت عمومی منتشر نمیکنیم. JELLYFIN_PublishedServerUrl آدرسی است که سرور برای کشف خودکار محلی اعلام میکند، یک پیام همهپخشی UDP در شبکه محلی، بنابراین کلاینتهای سراسر اینترنت هرگز آن را نمیبینند و به سادگی از آدرسی که در برنامه تایپ میکنید استفاده میکنند. آن را روی آدرسی تنظیم کنید که باید به کلاینتها اعلام شود و انتظار داشته باشید که آن آدرس را بهصورت دستی در دستگاههای راه دور وارد کنید.
آن را از دایرکتوری compose بالا بیاورید:
docker compose up -d
docker logs -f jellyfinاولین اجرا: ویزارد راهاندازی و کتابخانههای شما
از آنجا که پورت به localhost متصل است، به جای باز کردن یک حفره در فایروال، از طریق یک تونل SSH از لپتاپ خود به ویزارد دسترسی پیدا کنید:
ssh -L 8096:127.0.0.1:8096 you@your-vps-ipاکنون به http://localhost:8096 مراجعه کنید. ویزارد شما را ابتدا از طریق انتخاب زبان و سپس ایجاد یک کاربر مدیر با یک رمز عبور قوی راهنمایی میکند؛ این حساب، سرور شماست، بنابراین از یک رمز عبور یکبارمصرف استفاده نکنید. اولین کتابخانه خود را اضافه کنید: نوع محتوا را فیلمها انتخاب کنید، آن را به /media/Movies (مسیر داخل کانتینر، نه مسیر میزبان) هدایت کنید و این کار را با مجموعههای تلویزیونی در /media/Shows تکرار کنید. کار را تمام کنید تا Jellyfin شروع به اسکن کند. نتیجه صحیح این است که برای یک کتابخانه کوچک، ظرف یکی دو دقیقه پوسترها و عنوانها ظاهر شوند. بعداً میتوانید از طریق داشبورد → کتابخانهها کتابخانه اضافه یا ویرایش کنید و با اسکن همه کتابخانهها یک بازخوانی اجباری انجام دهید.
اگر به هر نوع ترنسکدینگی متکی هستید، به داشبورد → پخش → ترنسکدینگ بروید و مسیر موقت ترنسکد را روی /cache/transcodes تنظیم کنید تا فعالیت سنگین روی ولوم کش انجام شود و /config متورم نشود. شتابدهی سختافزاری را روی هیچکدام رها کنید؛ هیچ GPUای برای شتابدهی وجود ندارد.
دسترسی از راه دور: پروکسی معکوس TLS، یا نگهداشتن آن در VPN
شما دو راه امن برای دسترسی به Jellyfin از بیرون دارید، و یک راه ناامن که باید از آن اجتناب کنید. راه ناامن، انتشار مستقیم پورت 8096 به اینترنت است: ورود به سیستم به صورت متن شفاف منتقل میشود و پورت ظرف چند ساعت مورد حمله brute-force قرار میگیرد.
گزینه A، پروکسی معکوس TLS. Jellyfin را روی یک زیردامنه پشت Traefik با TLS خودکار برای اپهای Docker شما، یا پشت nginx با یک گواهی Let's Encrypt صادر شده توسط Certbot قرار دهید. Jellyfin برای بهروزرسانیهای بلادرنگ از WebSocket استفاده میکند، بنابراین پروکسی باید هدرهای ارتقا را ارسال کند. Traefik این کار را به طور خودکار انجام میدهد؛ nginx نیاز دارد که این هدرها صریحاً نوشته شوند، و نیاز به HTTP/1.1 به سمت upstream دارد وگرنه ارتقا هرگز اتفاق نمیافتد:
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 را برای کند کردن تلاشهای brute-force علیه ورود اضافه کنید. هنگامی که سرور عمومی شد، Uptime Kuma را به URL اشاره دهید تا قبل از بینندگان خود از قطعی مطلع شوید.
گزینه B، آن را خصوصی روی VPN نگه دارید. به هیچ وجه 8096 را منتشر نکنید؛ فقط از طریق یک تونل WireGuard که روی همان ماشین خاتمه مییابد به Jellyfin دسترسی پیدا کنید. برای یک خانواده، این سادهترین انتخاب امن است، بدون گواهی، بدون مواجهه عمومی، بدون سطح حمله brute-force. کانتینر را به آدرس تونل یا localhost متصل کرده و از طریق VPN متصل شوید. برای خود تونل، راهاندازی VPN با WireGuard برای یک VPS خصوصی را ببینید.
اندازهگیری فضای ذخیرهسازی و پشتیبانگیری
بر اساس کیفیت بودجهبندی کنید، نه تعداد فایل. فیلمهای فشرده 1080p هر کدام 4 تا 15 گیگابایت حجم دارند؛ یک ریموکس 1080p بین 20 تا 40 گیگابایت؛ یک فصل سریال 1080p بین 15 تا 40 گیگابایت؛ هر فیلم 4K بین 40 تا 100 گیگابایت. یک کتابخانه شامل چند صد فیلم بههمراه چند سریال به یک حجم 2 تا 4 ترابایتی نیاز دارد و تأمین بیش از حد حجم بلاک در ابتدا ارزانتر از جابجایی بعدی آن است.
/config کل وضعیت سرور است، بنابراین تنها چیزی است که باید از آن پشتیبان تهیه کنید. از آن اسنپشات بگیرید یا سرویس را متوقف کرده و فشردهسازی کنید و نسخه پشتیبان را خارج از سرور نگه دارید:
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 انجام میشوند؛ برچسب :10 که در بالا آمده در محدوده نسخه اصلی 10.x باقی میماند، بنابراین انتقال به نسخه اصلی بعدی نیازمند ویرایش عمدی برچسب است. پیش از انجام این کار، یادداشتهای انتشار Jellyfin را مرور کنید، زیرا انتقال طرحواره کتابخانه در نسخههای اصلی اتفاق میافتد.
حالتهای خرابی، همراه با پیامهایی که خواهید دید
کتابخانه پس از اسکن خالی است. گزارش در داشبورد → گزارشها (یا ~/jellyfin/config/log/log_*.log) نشان میدهد:
System.UnauthorizedAccessException: Access to the path '/media/Movies' is denied.uid کانتینر نمیتواند آن مسیر را بخواند. علت: مالکیت رسانه با root یا uidای غیر از مقدار user: شماست، یک دایرکتوری بیت اجرایی خود را از دست داده است، یا خود نقطهٔ اتصال والد توسط آن uid قابل پیمایش نیست. راه حل: chown -R 1000:1000 /mnt/media, دایرکتوریها 755, فایلها 644, سپس اسکن مجدد.
پخش، CPU را اشباع میکند و بافر رخ میدهد. docker stats jellyfin مصرف CPU را نزدیک 100% ضربدر تعداد هستهها نشان میدهد، و داشبورد → پخش نشست را به صورت Transcode با سرعتی زیر 1.0x فهرست میکند. کلاینت در حال پخش مستقیم نیست، بنابراین VPS با سرعتی کمتر از زمان واقعی در حال ترانکدینگ CPU است و عقب میماند. علت: کدک یا کانتینر پشتیبانینشده، رندر داخلی زیرنویس، یا tone-mapping برای HDR. راه حل: به یک کلاینت با پخش مستقیم تغییر دهید، منابع را با H.264/AAC نگه دارید، از زیرنویسهای متنی (SRT) به جای زیرنویسهای تصویری (PGS/VOBSUB) که رندر داخلی را اجباری میکنند استفاده کنید، و 4K HDR را کاملاً از دستگاهی که فقط CPU دارد دور نگه دارید.
"هیچ جریان سازگاری در دسترس نیست." پیام کامل معمولاً این است: "این کلاینت با رسانه سازگار نیست و سرور نیز قالب رسانهٔ سازگاری ارسال نمیکند." کلاینت منبع را رد کرده و ترانکدینگ جانشین نیز نتوانسته شروع شود. علت: یک دستور ffmpeg خراب، یک فایل خواندهنشدنی، یا نمایهٔ کاربر که تبدیل ویدئو را مسدود کرده است. راه حل: خط ffmpeg را در داشبورد → گزارشها بخوانید، تأیید کنید که فایل اصلاً پخش میشود، در صورت وابستگی به ترانکدینگ مجوزهای پخش کاربر را بررسی کنید، و برای رد کردن ایرادهای کدک مرورگر، یک کلاینت دوم را امتحان کنید.
فیلمها پوستر ندارند یا پوستر اشتباهی دارند. فراداده تطابق پیدا نکرد. علت: فیلمی که در پوشهٔ Name (Year) خودش نیست، پوشهٔ فصل با نام S01 به جای Season 01, اپیزودها با قالب S01E01 نیستند، یا سال انتشار وجود ندارد. راه حل: نامها را مطابق چیدمان بالا تغییر دهید، سپس بازخوانی فراداده → جایگزینی همه، یا از شناسایی روی یک آیتم تکی برای تثبیت ورودی صحیح TMDB/TVDB استفاده کنید.
FAQ
آیا یک VPS میتواند بدون GPU ویدیو را ترنسکد کند؟
بله، اما فقط روی CPU و این کار پرهزینه است. یک ترنسکد نرمافزاری 1080p میتواند چندین vCPU را اشباع کند و 4K یا HEVC معمولاً نمیتوانند با زمان واقعی همگام شوند، بنابراین پخش بافر میشود. بهترین راهکار، اجتناب از ترنسکد است: کتابخانه خود را با فرمت H.264/AAC نگه دارید و از برنامههای کلاینتی استفاده کنید که پخش مستقیم انجام میدهند، در این صورت VPS فقط بایتها را استریم میکند. فقط در صورتی که واقعاً به ترنسکد در لحظه نیاز دارید، یک نمونه GPU اجاره کنید.
چرا کتابخانه Jellyfin من پس از اسکن خالی است؟
تقریباً همیشه مشکل از مجوزهاست. ایمیج رسمی jellyfin/jellyfin با user: که شما تنظیم میکنید (یا root) اجرا میشود و اگر فایلها توسط آن uid قابل خواندن نباشند، لاگهای اسکن Access to the path ... is denied را نشان میدهند و از آنها رد میشوند. مالکیت را با chown -R 1000:1000 /mnt/media اصلاح کنید، به دایرکتوریها بیت اجرا بدهید (755) و دوباره اسکن کنید. والد را هم بررسی کنید، زیرا اگر uid کانتینر نتواند از خود /mnt/media عبور کند، هرگز به پوشههای کتابخانه نمیرسد و همه چیز خالی میماند. دومین علت رایج، چیدمان پوشهای است که با آنچه Jellyfin انتظار دارد مطابقت ندارد.
چگونه از راه دور و به صورت امن به Jellyfin دسترسی پیدا کنم؟
دو گزینه خوب وجود دارد. آن را پشت یک پروکسی معکوس TLS روی یک زیردامنه قرار دهید تا ورود و استریم رمزنگاری شوند و fail2ban را اضافه کنید. هرگز پورت 8096 را مستقیماً در معرض اینترنت قرار ندهید، زیرا رمز عبور شما را به صورت متن ساده ارسال میکند. یا آن را کاملاً خصوصی نگه دارید و فقط از طریق VPN به آن دسترسی پیدا کنید، که سادهترین انتخاب امن برای یک خانه است. آدرس عمومی را مستقیماً به برنامهها بدهید؛ کشف خودکار یک پخش شبکه محلی است، بنابراین به کلاینتهایی که از طریق اینترنت وارد میشوند نمیرسد.
یک VPS برای Jellyfin چقدر دیسک و پهنای باند نیاز دارد؟
فضای دیسک به کیفیت بستگی دارد: برای هر فیلم 1080p فشرده 4-15 گیگابایت، برای هر ریموکس 20-40 گیگابایت و برای 4K حدود 40-100 گیگابایت در نظر بگیرید، بنابراین بیشتر کتابخانهها به یک حجم بلوک 2-4 ترابایتی نیاز دارند. پهنای باند با نرخ بیت پخش مستقیم تعیین میشود، 8-12 مگابیت بر ثانیه برای هر استریم 1080p و برای 4K بسیار بیشتر. بنابراین تأیید کنید که سرعت پورت شما تعداد بینندگان همزمان را پشتیبانی میکند و سقف انتقال ماهانه را زیر نظر داشته باشید. اگر قصد ترنسکد دارید، ظرفیت CPU اضافی در نظر بگیرید؛ اگر قصد پخش مستقیم دارید، پهنای باند را بر هستههای CPU اولویت دهید.
آیا اجرای Jellyfin روی VPS قانونی است؟
خود Jellyfin یک نرمافزار رایگان و متنباز است و اجرای آن کاملاً قانونی است. آنچه اهمیت دارد محتواست: فقط رسانههایی را استریم کنید که مالک آن هستید یا مجوز نگهداری آن را دارید، مانند ریپهای دیسک خودتان، ضبطها یا فایلهایی که حق استفاده از آنها را دارید. Jellyfin هیچ رسانهای ارائه نمیدهد و هیچ راهی برای به دست آوردن آن فراهم نمیکند؛ این یک پخشکننده برای کتابخانهای است که شما از قبل مالک آن هستید.