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

מה אתם בונים

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

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

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

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

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

האסטרטגיה ב-VPS היא לכן: הימנעו מ-transcoding. שמרו את הספרייה שלכם ב-codecs שהלקוחות שלכם מנגנים באופן טבעי: וידאו 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 הוא הימור לא בטוח.

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

דרישות קדם

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

עגנו את האחסון הבלוקי תחילה

חברו את ה-volume בלוח הבקרה של ספק הענן שלכם, ולאחר מכן אתרו אותו ובצעו לו mount. מצאו את שם ההתקן באמצעות 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

בצעו את ה-mount לפי 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 על כונן שכבר מכיל נתונים, שכן הפעולה מוחקת אותם. פרמטו רק כוננים חדשים; אם על הכונן כבר קיימת ספריית הנתונים שלכם, דלגו ישירות לשורת ה-fstab.

סידור המדיה לפי הדרישות של 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) בשמות סרטים אינו קישוט, הוא מבדיל בין גרסאות מחודשות (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: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 הנוכחית (12.2 נכון ל-2026-10-10). user: "1000:1000" מגדיר את ה-uid/gid שבהם ירוץ תהליך ה-Jellyfin. הגדרה זו אינה משנה את הבעלות או את ההרשאות של אף קובץ, כיוון ש-Docker שומר על ה-uid/gid של המארח עבור ספריות המעוגנות (mounted), וזו הסיבה ש-chown לעיל חייב להתאים להם. /config מכיל את כל השרת, החשבונות, הספריות, המטא-דאטה ומצב הצפייה, לכן עליו להיות בעל הרשאות כתיבה והוא המידע שיש לגבות. /cache הוא מרחב עבודה זמני. העיגון של המדיה הוא :ro (לקריאה בלבד) במכוון: Jellyfin שומר כברירת מחדל עטיפות ומטא-דאטה תחת /config, כך שאין לו צורך לכתוב לספריית המדיה שלך, והגדרת קריאה בלבד מגינה על הקבצים שלך מפני מחיקה בשוגג או תוסף פגום. הפורט קשור ל-127.0.0.1 בכוונה תחילה, שכן ממשק ה-web של 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. האשף ידריך אותך בבחירת שפה, ולאחר מכן ביצירת משתמש מנהל עם סיסמה חזקה; חשבון זה הוא השרת שלך, לכן אל תשתמש בסיסמה זמנית. הוסף את הספרייה הראשונה שלך: בחר בסוג תוכן Movies, כוון אותו אל /media/Movies (הנתיב בתוך המכולה, לא הנתיב במארח), וחזור על הפעולה עבור Shows ב-/media/Shows. סיים את התהליך, ו-Jellyfin יתחיל בסריקה. תוצאה תקינה תציג פוסטרים וכותרות שמתמלאים בתוך דקה או שתיים עבור ספרייה קטנה. ניתן להוסיף או לערוך ספריות מאוחר יותר תחת Dashboard → Libraries, ולבצע סריקה מאולצת באמצעות Scan All Libraries. אותם פוסטרים הם גם מה שהופך ממשק חלופי לכדאי לבדיקה ברגע שהבסיס עובד, שכן Halcyon בונה מחדש את אותה ספרייה כחנות וידאו משנות ה-90 שניתן לשוטט בה מתוך הגרפיקה ש-Jellyfin כבר משך.

אם אתה מסתמך על קידוד מחדש (transcoding) כלשהו, פתח את Dashboard → Playback → Transcoding והגדר את נתיב ה-temp של ה-transcode ל-/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 כדי שתדעו על השבתה לפני המשתמשים שלכם. הגדירו את ההתראות שלו אל שרת ntfy בניהול עצמי, כך שכישלון בבדיקה יגיע כהודעת push לטלפון במקום כאימייל שתקראו רק למחרת בבוקר. חשיפת מסך התחברות לאינטרנט הציבורי היא גם הזדמנות טובה לבצע ביקורת על שאר השרת, במקום להניח שרק פורט 443 מגיב: sudo ss -tlnp מציג את כל הפורטים המאזינים ואת התהליך שמאחוריהם. אם אתם מריצים גם קוד משלכם על השרת, open-kritt סורק מאגרים והתלויות שלהם לאיתור פגיעויות; הוא מבצע ביקורת על קוד המקור, לא על פורטים מאזינים.

אפשרות ב', שמירה על פרטיות באמצעות VPN. אל תחשפו את פורט 8096 לאינטרנט הציבורי כלל; גשו ל-Jellyfin רק דרך מנהרת WireGuard שמסתיימת על אותו שרת. עבור משק בית, זוהי הבחירה המאובטחת והפשוטה ביותר: ללא תעודות, ללא חשיפה ציבורית, וללא שטח פנים ל-brute-force. ה-binding ל-localhost מקובץ ה-compose אינו מספיק כאן כשלעצמו, כיוון שפורט שמפורסם ב-127.0.0.1 נגיש רק מה-VPS עצמו, ולא מעמיתים ב-VPN. פרסמו אותו על כתובת המנהרה של השרת במקום זאת (למשל "10.8.0.1:8096:8096", באמצעות כתובת ה-IP של שרת ה-WireGuard שלכם), או השאירו localhost והציבו לפניו proxy המאזין על כתובת המנהרה, ולאחר מכן התחברו דרך ה-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; התג :12 לעיל נשאר בתוך סדרת 12.x, לכן מעבר לגרסה ראשית הבאה הוא שינוי תג מכוון. עברו על הערות השחרור של Jellyfin לפני שתבצעו זאת, כיוון ששינויים במבנה בסיס הנתונים של הספרייה מתרחשים בגרסאות ראשיות. Jellyfin הסירה את הקידומת "10." ממספרי הגרסאות שלה החל מ-12.0 (ספטמבר 2026): 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, והוא דורש סריקת ספרייה מלאה לאחר מכן, פעולה שלוקחת זמן רב מהרגיל. תג נעול בצירוף תיקיית מצב מגובה הם המתכון המלא לכל מכולה שפועלת באופן קבוע, וזהו אותו דפוס העומד מאחורי שמירה על הזיכרון ולוחות הזמנים של סוכן אירוח עצמי לאורך אתחולים.

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

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

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

ה־uid של המכולה אינו מורשה לקרוא את הנתיב. הסיבה: הבעלות על המדיה היא של root או של uid שונה מהערך שהגדרת ב-user:, או שחסרה הרשאת הרצה (execute bit) על תיקייה, או שהנתיב עצמו אינו נגיש ל־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), או ביצוע tone-mapping ל-HDR. הפתרון: עברו ללקוח התומך ב-direct-play, שמרו על קובצי המקור בפורמט H.264/AAC, השתמשו בכתוביות טקסט (SRT) במקום בכתוביות תמונה (PGS/VOBSUB) שרוב לקוחות 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 שגויה, קובץ פגום, או הגדרות משתמש החוסמות המרת וידאו. הפתרון: קראו את שורת ה-ffmpeg ב-Dashboard → Logs, ודאו שהקובץ תקין, בדקו את הרשאות הניגון של המשתמש אם אתם מסתמכים על טרנסקודינג, ונסו לקוח אחר כדי לשלול בעיות תאימות של הדפדפן.

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