SSD Nodes Learn Hosting plans →
מדריכים Matt Connorמאת Matt Connor · עודכן 2026-08-26

הקמת שרת מדיה Jellyfin על גבי VPS: מדריך מעשי

למדו איך להריץ Jellyfin ב-Docker על שרת VPS. המדריך מתמקד בפתרון בעיות הרשאות קבצים, ניהול אחסון בלוקים וההבדל הקריטי בין Direct play לקידוד מחדש בשרת ללא GPU.

מה אתם בונים

שרת מדיה Jellyfin על גבי VPS: מכולה אחת, שלושה כרכים (volumes), וכונן אחסון בלוקים (block-storage) המכיל את הסרטים והסדרות שלכם, הנגיש מכל דפדפן או אפליקציית Jellyfin. ההתקנה מבוססת על קובץ compose בן חמש-עשרה שורות. כל בעיה שעלולה להתרחש לאחר מכן נובעת משני מקורות: הרשאות קבצים שהמכולה אינה יכולה לקרוא, וניסיון לבצע קידוד מחדש (transcoding) של וידאו בשרת VPS ללא GPU, פעולה שאינה מתאימה לו. מדריך זה מקדיש את רוב תוכנו לשני נושאים אלו, שכן שם מתרכזות רוב פניות התמיכה.

Jellyfin הוא תוכנה חופשית ובקוד פתוח מלא, ללא חשבונות משתמש, ללא תכונות בתשלום, וללא איסוף נתונים (telemetry); זו הסיבה שהוא מופיע כמעט בכל רשימה של דברים שכדאי לארח באופן עצמי בשנת 2026. הוא מנגן מדיה שבבעלותכם. הוא אינו מפיץ תוכן, ומדריך זה אינו עוסק בהשגת תוכן כלשהו.

המציאות של קידוד מחדש (transcoding), לפני שתשכרו שרת

קראו זאת תחילה, שכן הדבר משנה את מה שתבחרו לרכוש. שרת מדיה מבצע אחת משתי פעולות בעת לחיצה על "נגן". Direct play מזרים את הקובץ כפי שהוא: ה-VPS קורא בתים מהדיסק ומעביר אותם ברשת, פעולה שכמעט אינה צורכת CPU. Transcoding מקודד מחדש את הווידאו בזמן אמת – רזולוציה חדשה, codec חדש או הטמעת כתוביות – וזו עבודה שצורכת משאבי CPU משמעותיים.

ב-VPS טיפוסי אין GPU. לכן, כל פעולת transcoding רצה על ה-CPU באמצעות libx264/libx265, וקידוד תוכנה הוא פעולה יקרה. פעולת transcoding אחת של 1080p H.264 יכולה להעמיס על כמה vCPUs משותפים; transcoding של 4K או HEVC לרוב אינו עומד בקצב של זמן אמת, מה שגורם לעצירות בנגינה ולטעינה אינסופית. קידוד חומרה (Hardware transcoding), המאפשר הוזלת עלויות במחשב ביתי עם Intel iGPU או כרטיס Nvidia, פשוט אינו זמין עבורכם אלא אם הספק שלכם משכיר שרתי GPU.

לפיכך, האסטרטגיה ב-VPS היא: הימנעו מ-transcoding. שמרו את הספרייה שלכם בפורמטים שהלקוחות שלכם מנגנים באופן טבעי: וידאו H.264, אודיו AAC או AC3, בתוך מכולת (container) מסוג MP4 או MKV. בחרו אפליקציות לקוח שמבצעות Direct play: האפליקציות הרשמיות של Jellyfin ל-Android TV, ל-iOS ול-Roku, וכן Infuse, Kodi, ו-Jellyfin Media Player למחשב. אם תעשו זאת, ה-VPS לעולם לא יפעיל את ffmpeg, ושרת צנוע עם 2 vCPU יוכל להזרים לכמה אנשים בו-זמנית. אם תתכננו להסתמך על transcoding, תזדקקו לשרת גדול ויקר הרבה יותר, וגם אז, 4K הוא הימור לא בטוח.

בצעו גם את חישוב רוחב הפס, משום שזו הפתעה נוספת. בניגון ישיר, הקובץ נשלח בקצב הסיביות המקורי שלו. קובץ 1080p דחוס צורך 8-12 Mbps; remux של Blu-ray ברזולוציית 1080p צורך 20-30 Mbps; ו־4K HDR צורך 40-80 Mbps. שלושה משתמשים שמנגנים ישירות קבצים בקצב של 10 Mbps צורכים מה־VPS שלכם 30 Mbps של תעבורת העלאה רציפה. בדקו שני נתונים בחבילה שלכם: מהירות הפורט, כלומר האם הוא מסוגל להעביר 30 Mbps בתעבורת העלאה, ומכסת התעבורה החודשית. סרט באורך שעתיים בקצב של 10 Mbps מייצר כ־9 GB של תעבורה יוצאת. לכן מכסה מדודה של 1 TB לחודש מספיקה לקצת יותר ממאה סרטים כאלה בחודש, כלומר שלושה או ארבעה סרטים ביום. משק בית שצופה ב־4K, בקצב סיביות הגבוה פי ארבעה עד פי שמונה, ימצה את המכסה במהירות רבה יותר. יש לכלול באותו תקציב גם כל תעבורה אחרת שיוצאת מאותו שרת, כולל ממסר RustDesk באירוח עצמי, שמעביר הפעלה מלאה של שולחן עבודה מרוחק בכל פעם ששני עמיתים אינם יכולים להתחבר ישירות.

דרישות קדם

  • שרת VPS מסוג KVM עם Ubuntu 24.04, גישת root או sudo, וכן Docker עם תוסף Compose מותקנים.
  • כונן אחסון בלוקים (block-storage) עבור המדיה, בגודל המתאים לספרייה שלכם (ראו פירוט גדלים בהמשך). כונן ה-root הקטן שמגיע עם ה-VPS אינו המקום לאחסון סרטים.
  • שם מתחם (domain name) אם ברצונכם בגישת HTTPS ציבורית, או WireGuard VPN על אותו ה-VPS אם אתם מעדיפים לשמור על המערכת כולה פרטית.
  • מדיה שיש לכם זכות חוקית להזרים, כגון עותקים אישיים, הקלטות שלכם או קבצים שבבעלותכם.

עגנו תחילה את האחסון הבלוקי (Block Storage)

חברו את ה-volume בלוח הבקרה של ספק הענן, ולאחר מכן אתרו אותו ועגנו אותו. מצאו את שם ההתקן באמצעות lsblk; הוא ייראה בדומה ל-/dev/sdb או /dev/vdb, ולעולם לא יהיה זה כונן ה-root.

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, כיוון שאותיות ההתקן משתנות לאחר אתחול (reboot) וייתכן שתפרמטו או תעגנו את הכונן הלא נכון. הוסיפו שורה אחת ל-/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 ינותק, השרת יסרב לעלות ויעבור למצב emergency shell. הטעות הנפוצה ביותר כאן היא הרצת mkfs.ext4 על volume שכבר מכיל נתונים, שכן פעולה זו מוחקת אותם. פרמטו רק כוננים חדשים; אם על הדיסק כבר קיימת ספריית הנתונים שלכם, דלגו ישירות לשורת ה-fstab.

סידור המדיה לפי הדרישות של Jellyfin

Jellyfin מבצע התאמת מטא-דאטה לפי שמות תיקיות וקבצים. סידור שגוי יגרום לכך שסרטים יופיעו כקבצים ללא שם וללא פוסטר, או שפרק יזוהה כשייך לסדרה הלא נכונה. ישנם שלושה כללים מדויקים: כל סרט חייב להימצא בתיקייה משלו בשם 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) בשמות הסרטים אינו קישוט, הוא נועד להבדיל בין גרסאות מחודשות (remakes) כדי שהמערכת תזהה את הכותר הנכון. שמרו על Movies ו-Shows כתיקיות נפרדות ברמה העליונה, כיוון שכל אחת מהן הופכת לספריית Jellyfin עם סוג תוכן ספציפי, וערבוב ביניהן מבלבל את ספק המטא-דאטה. Jellyfin יאנדקס בשמחה גם תיקייה שלישית של תמונות, אך החוויה תהיה דלה בהשוואה לשרת תמונות ייעודי. אם האלבומים שלכם חשובים לכם, הקצו להם שרת נפרד שמריץ את PhotoPrism או Immich והשאירו את השרת הזה לסרטים ולסדרות טלוויזיה.

הרשאות: הסיבה הנפוצה ביותר לספריות ריקות

זוהי אי-הבנה שגורמת לאנשים לבזבז ערב שלם. התמונה הרשמית jellyfin/jellyfin אינה מכבדת את משתני הסביבה PUID/PGID; אלו שייכים לתמונה של LinuxServer.io (lscr.io/linuxserver/jellyfin). בתמונה הרשמית אתם שולטים במשתמש באמצעות המפתח user: ב-compose, ואם תשמיטו אותו, המכולה תרוץ כ-root. לא משנה באיזו תמונה תבחרו, הכלל נשאר זהה: ה-uid/gid שבו המכולה רצה חייב להיות בעל הרשאות קריאה ומעבר (traverse) בכל תיקיית מדיה.

אנחנו נריץ את המכולה כ-uid/gid 1000, המשתמש הראשון שאינו root במערכת Ubuntu סטנדרטית. ודאו מהו ה-uid שלכם והגדירו בעלות:

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 הוא מרחב עבודה זמני. ה-mount של המדיה הוא :ro (לקריאה בלבד) במכוון: Jellyfin שומר כברירת מחדל עטיפות ומטא-דאטה תחת /config, כך שהוא לעולם אינו צריך לכתוב לספרייה שלך, והגדרת קריאה בלבד מגינה על הקבצים שלך ממחיקה בשוגג או מתוסף פגום. הפורט קשור ל-127.0.0.1 בכוונה, שכן ממשק הכניסה של Jellyfin הוא HTTP רגיל, ולכן לעולם אין לחשוף את 8096 לאינטרנט הציבורי. JELLYFIN_PublishedServerUrl הוא הכתובת שהשרת מפרסם עבור גילוי אוטומטי מקומי, שידור UDP ברשת ה-LAN, כך שלקוחות מחוץ לרשת לעולם לא יראו אותו וישתמשו פשוט בכתובת ה-URL שתקליד באפליקציה. הגדר זאת לכתובת שהלקוחות אמורים לקבל, וצפה להזין את ה-URL הזה ידנית במכשירים מרוחקים.

העלה את השירות מתוך ספריית ה-compose:

docker compose up -d
docker logs -f jellyfin

הרצה ראשונה: אשף ההגדרה וספריות המדיה שלכם

מכיוון שהפורט מאוגד ל-localhost, גשו לאשף דרך מנהרת SSH מהמחשב הנייד שלכם במקום לפתוח חור ב-firewall:

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

כעת נווטו אל http://localhost:8096. האשף ינחה אתכם בבחירת שפה, ולאחר מכן ביצירת משתמש מנהל (admin) עם סיסמה חזקה; חשבון זה הוא השרת שלכם, לכן אל תשתמשו בסיסמה זמנית. הוסיפו את הספרייה הראשונה שלכם: בחרו בסוג התוכן Movies, הצביעו על /media/Movies (הנתיב בתוך המכולה, לא הנתיב במארח), וחזרו על הפעולה עבור Shows ב-/media/Shows. סיימו את התהליך, ו-Jellyfin יתחיל בסריקה. תוצאה תקינה תציג פוסטרים וכותרות שמתמלאים תוך דקה או שתיים עבור ספרייה קטנה. ניתן להוסיף או לערוך ספריות מאוחר יותר תחת Dashboard → Libraries, ולבצע סריקה מאולצת באמצעות Scan All Libraries.

אם אתם מסתמכים על קידוד מחדש (transcoding) כלשהו, פתחו את Dashboard → Playback → Transcoding והגדירו את נתיב ה-temp לקידוד ל-/cache/transcodes, כך שהתעבורה תתבצע על כרך ה-cache במקום לנפח את /config. השאירו את האצת החומרה על None, שכן אין GPU לביצוע האצה.

גישה מרחוק: Reverse proxy עם TLS, או שמירה על VPN

ישנן שתי דרכים מאובטחות לגשת ל-Jellyfin מחוץ לרשת, ודרך אחת לא מאובטחת שיש להימנע ממנה. הדרך הלא מאובטחת היא חשיפת פורט 8096 ישירות לאינטרנט: פרטי ההתחברות עוברים בטקסט גלוי, והפורט יהיה נתון לניסיונות brute-force בתוך שעות.

אפשרות א', Reverse proxy עם TLS. הציבו את Jellyfin תחת תת-דומיין מאחורי Traefik עם TLS אוטומטי ליישומי Docker שלכם, או מאחורי nginx עם תעודת Let's Encrypt שהונפקה על ידי Certbot. Jellyfin משתמש ב-WebSockets לעדכונים בזמן אמת, לכן ה-proxy חייב להעביר את ה-upgrade headers. Traefik מבצע זאת אוטומטית; ב-nginx יש להגדיר זאת במפורש, ויש להשתמש ב-HTTP/1.1 מול ה-upstream, אחרת ה-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:// כדי שזיהוי אוטומטי מקומי יפרסם את ה-URL הנכון, אפליקציות מרוחקות ישתמשו בכתובת שתספקו להן, והוסיפו fail2ban כדי להאט ניסיונות brute-force כנגד דף ההתחברות. ברגע שהשרת חשוף לציבור, כוונו את Uptime Kuma ל-URL כדי שתקבלו התראה על השבתה לפני המשתמשים שלכם.

אפשרות ב', שמירה על פרטיות באמצעות VPN. אל תחשפו את פורט 8096 כלל; גשו ל-Jellyfin רק דרך מנהרת WireGuard שמסתיימת באותו שרת. עבור משק בית, זוהי הבחירה המאובטחת והפשוטה ביותר: ללא תעודות, ללא חשיפה ציבורית, וללא שטח פנים ל-brute-force. קשרו את ה-container לכתובת המנהרה או ל-localhost והתחברו דרך ה-VPN. ראו את הגדרת WireGuard VPN עבור VPS פרטי עבור הקמת המנהרה עצמה.

תכנון נפח אחסון וגיבויים

תכננו את התקציב לפי איכות, לא לפי מספר הקבצים. סרטי 1080p דחוסים תופסים 4-15 GB כל אחד; גרסאות remux של 1080p תופסות 20-40 GB; עונה של סדרת 1080p תופסת 15-40 GB; וכל תוכן ב-4K תופס 40-100 GB לסרט. ספרייה של כמה מאות סרטים וכמה סדרות דורשת נפח של 2-4 TB, וזול יותר להקצות נפח אחסון עודף מראש מאשר לבצע הגירה מאוחרת.

/config הוא מצב השרת המלא, ולכן זהו הדבר היחיד שחובה לגבות. בצעו Snapshot או עצרו את השירות ובצעו tar לתיקייה, ושמרו את העותק מחוץ לשרת:

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

/cache ותיקיית ה-transcode הם זמניים וניתנים לשחזור. את המדיה ב-/mnt/media גבו בנפרד או קבלו את העובדה שניתן להמיר אותה מחדש; רוב המשתמשים בוחרים באפשרות השנייה בשל הנפח. שדרוגים הם docker compose pull && docker compose up -d; תגית ה-:10 לעיל נשארת בתוך גרסה ראשית 10.x, לכן מעבר לגרסה ראשית הבאה הוא שינוי תגית מכוון. עברו על הערות השחרור של Jellyfin לפני ביצוע השינוי, כיוון ששינויים בסכימת הספרייה מתרחשים בגרסאות ראשיות. תגית נעולה בצירוף תיקיית מצב מגובת הם המתכון המלא לכל מכולה שפועלת באופן קבוע, וזהו אותו דפוס העומד מאחורי שמירה על הזיכרון והלו"ז של סוכן אירוח עצמי לאחר אתחול.

מצבי כשל והודעות שגיאה נפוצות

הספרייה ריקה לאחר סריקה. הלוג בנתיב Dashboard → Logs (או ~/jellyfin/config/log/log_*.log) מציג:

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

ה־uid של המכולה אינו מורשה לקרוא את הנתיב. סיבה: המדיה בבעלות root או uid שונה מערך ה-user: שלכם, ספרייה שחסר לה bit הרצה (execute), או נקודת mount שה־uid אינו יכול לעבור דרכה. פתרון: בצעו chown -R 1000:1000 /mnt/media, הגדירו הרשאות לספריות 755 ולקבצים 644, ולאחר מכן בצעו סריקה מחדש.

הניגון צורך את כל ה-CPU וסובל מקיטועים (buffering). הפקודה docker stats jellyfin מראה ניצול CPU קרוב ל-100% כפול מספר הליבות, והלשונית Dashboard → Playback מציגה את הסשן כ-Transcode במהירות נמוכה מ-1.0x. הלקוח אינו מבצע direct-play, לכן ה-VPS מבצע transcoding ב-CPU לאט יותר מהזמן האמיתי ונוצר פיגור. סיבה: codec או container שאינם נתמכים, הטמעת כתוביות (burn-in), או מיפוי גווני HDR. פתרון: עברו ללקוח התומך ב-direct-play, שמרו על קבצי מקור בפורמט H.264/AAC, השתמשו בכתוביות טקסט (SRT) במקום כתוביות תמונה (PGS/VOBSUB) המאלצות הטמעה, והימנעו מניגון 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." הלקוח דחה את קובץ המקור וגם ה-transcode החלופי נכשל. סיבה: פקודת ffmpeg שגויה, קובץ לא קריא, או פרופיל משתמש החוסם המרת וידאו. פתרון: קראו את שורת ה-ffmpeg ב-Dashboard → Logs, ודאו שהקובץ תקין, בדקו את הרשאות הניגון של המשתמש אם אתם מסתמכים על transcoding, ונסו לקוח אחר כדי לשלול בעיות תאימות של הדפדפן.

לסרטים אין פוסטר או שהפוסטר שגוי. המטא-דאטה לא תאם. סיבה: סרט שאינו נמצא בתיקייה ייעודית משלו Name (Year), תיקיית עונה בשם S01 במקום Season 01, פרקים שאינם בפורמט S01E01, או חוסר בשנה. פתרון: שנו את שמות הקבצים לפי המבנה לעיל, בצעו Refresh metadata → Replace all, או השתמשו ב-Identify על פריט בודד כדי לקשר אותו לערך הנכון ב-TMDB/TVDB.

FAQ

האם ניתן לבצע קידוד וידאו (transcoding) ב-VPS ללא GPU?

כן, אך הדבר מתבצע באמצעות ה-CPU בלבד, והוא צורך משאבים רבים. קידוד תוכנה בודד של 1080p עלול להעמיס על מספר vCPUs, וקידוד 4K או HEVC לרוב לא יעמוד בקצב של זמן אמת, מה שיגרום להשהיות בנגינה. הפתרון היעיל הוא להימנע מקידוד: שמרו את הספרייה בפורמט H.264/AAC והשתמשו ביישומי קצה התומכים ב-direct-play, כך שה-VPS רק יזרים את הנתונים. שכרו שרת עם GPU רק אם אתם זקוקים באמת לקידוד בזמן אמת.

מדוע ספריית ה-Jellyfin שלי ריקה לאחר סריקה?

כמעט תמיד מדובר בבעיית הרשאות. ה-image הרשמי של jellyfin/jellyfin רץ תחת ה-user: שהגדרתם (או כ-root), ואם הקבצים אינם ניתנים לקריאה על ידי ה-uid הזה, לוג הסריקה יציג Access to the path ... is denied וידלג עליהם. תקנו את הבעלות באמצעות chown -R 1000:1000 /mnt/media, העניקו לתיקיות הרשאת הרצה (755), בצעו סריקה מחדש, ובדקו גם את תיקיית האב; אם ה-uid של ה-container לא יכול לעבור דרך /mnt/media עצמה, הוא לעולם לא יגיע לתיקיות הספרייה והתוצאה תהיה ריקה. הסיבה השנייה בשכיחותה היא מבנה תיקיות שאינו תואם את הציפיות של Jellyfin.

כיצד אוכל לגשת ל-Jellyfin מרחוק ובאופן מאובטח?

ישנן שתי אפשרויות טובות. הציבו את השירות מאחורי reverse proxy עם TLS בתוך subdomain כך שההתחברות והזרמת המדיה יוצפנו, והוסיפו fail2ban; לעולם אל תחשפו את פורט 8096 כפי שהוא, שכן הוא מעביר את הסיסמה בטקסט גלוי. לחלופין, שמרו על השירות פרטי לחלוטין וגשו אליו רק דרך VPN, שזו האפשרות הבטוחה והפשוטה ביותר לשימוש ביתי. הזינו ביישומים את הכתובת הציבורית ישירות, שכן זיהוי אוטומטי (autodiscovery) מבוסס על שידור ברשת מקומית (broadcast) ואינו מגיע ללקוחות המגיעים דרך האינטרנט.

כמה שטח דיסק ורוחב פס נדרשים ל-VPS עבור Jellyfin?

שטח הדיסק תלוי באיכות: הקצו 4-15 GB לסרט 1080p דחוס, 20-40 GB ל-remux, ו-40-100 GB ל-4K, כך שרוב הספריות ידרשו נפח אחסון של 2-4 TB. רוחב הפס נקבע לפי קצב ה-bitrate של ה-direct-play, כ-8-12 Mbps לכל זרם 1080p, והרבה יותר עבור 4K; לכן ודאו שמהירות החיבור שלכם תומכת במספר הצופים בו-זמנית ועקבו אחר מכסת התעבורה החודשית. הוסיפו משאבי CPU אם אתם מתכננים לבצע קידוד; תנו עדיפות לרוחב פס על פני ליבות אם אתם מתכננים להשתמש ב-direct-play.

האם זה חוקי להריץ Jellyfin על גבי VPS?

Jellyfin עצמה היא תוכנה חופשית בקוד פתוח והרצתה חוקית לחלוטין. מה שקובע הוא התוכן: הזרימו רק מדיה שבבעלותכם או שיש לכם רישיון להחזיק, כגון עותקים אישיים מדיסקים, הקלטות או קבצים שיש לכם זכות להשתמש בהם. Jellyfin אינה מפיצה מדיה ואינה מספקת דרך להשיג כזו; היא משמשת כנגן עבור ספרייה שכבר נמצאת בבעלותכם.