Emby és Jellyfin párhuzamos futtatása Synology DS220+ NAS-on – csomagként, Container nélkül

Az otthoni médiaszerver-építésnél gyakori kérdés, hogy lehet-e egyszerre több szervert futtatni ugyanazon NAS-on – például Emby-t és Jellyfin-t párhuzamosan.
Ebben a bejegyzésben azt mutatom be, hogyan néz ki a gyakorlatban a két „csomagos” (nem Dockeres) telepítés és használat Synology DS220+ NAS-on, DSM 7 alatt, és miért ütközünk bele elég hamar a portok és a csomagrendszer korlátaiba.


Kiindulási környezet

  • NAS: Synology DS220+
  • DSM: 7.x
  • Emby Server: Synology Csomagkezelési Központból telepített, nem Dockeres csomag
  • Jellyfin: szintén csomagként szeretnénk telepíteni (teszt célból, Container nélkül)
  • Cél: Emby és Jellyfin párhuzamos futtatása ugyanazon NAS-on, anélkül, hogy Docker/Container Managerre támaszkodnánk.

Fontos kiindulási pont: mind az Emby, mind a Jellyfin történetileg ugyanazt a portpárt használja alapértelmezésként:

  • HTTP: 8096
  • HTTPS: 8920

Már ebből sejthető, hogy ugyanazon hoston a párhuzamos futtatás portütközéshez vezet, ha nem választunk szét portokat.


Emby konfiguráció – system.xml és portok

Synology DSM 7 alatt az Emby Server adatkönyvtára csomagos telepítésnél a következő helyen található:

bash/volume1/@appdata/EmbyServer

Itt a config könyvtárban találjuk a központi konfigurációs fájlt:

bash/volume1/@appdata/EmbyServer/config/system.xml

SSH-n rootként bejelentkezve:

bashcd /volume1/@appdata/EmbyServer/config
ls -l

system.xml ebben a környezetben többek között a portbeállításokat is tartalmazza. Egy tipikus részlet így néz ki:

xml<?xml version="1.0"?>
<ServerConfiguration xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <EnableUPnP>true</EnableUPnP>
  <PublicPort>8096</PublicPort>
  <PublicHttpsPort>8920</PublicHttpsPort>
  <HttpServerPortNumber>8096</HttpServerPortNumber>
  <HttpsPortNumber>8920</HttpsPortNumber>
  <EnableHttps>false</EnableHttps>
  <!-- ... további beállítások ... -->
</ServerConfiguration>

Ha az Emby portját át akarjuk állítani (például 8099-re), akkor nano-val (vi mellőzésével) egyszerűen szerkeszthetjük:

bashnano /volume1/@appdata/EmbyServer/config/system.xml

És módosítjuk:

xml  <PublicPort>8099</PublicPort>
  <PublicHttpsPort>8922</PublicHttpsPort>
  <HttpServerPortNumber>8099</HttpServerPortNumber>
  <HttpsPortNumber>8922</HttpsPortNumber>

Mentés (Ctrl+O, Enter) és kilépés (Ctrl+X) után az Emby csomagot újra kell indítani DSM-ben:

  • Csomagkezelési központ → Emby Server → Leállítás → Indítás

Vagy SSH-n:

bashsynoservice --restart pkgctl-EmbyServer

Ezután az Emby az új porton érhető el:

texthttp://NAS_IP:8099

Látszólag ezzel megoldottuk, hogy Emby ne a klasszikus 8096-os porton fusson. A probléma viszont DSM-nél mélyebben gyökerezik.


Miért ütközik mégis Jellyfin és Emby csomagként?

A Jellyfin – történetileg Emby fork – alapértelmezésként ugyanazt a portpárt használja (8096/8920).
Ha Jellyfin-t is Synology csomagként próbáljuk telepíteni DSM 7 alatt, a telepítő nem csak azt nézi, hogy a port ténylegesen foglalt-e futó processz által, hanem azt is, hogy a csomagrendszer metadata szerint a port adott csomaghoz tartozik-e.

Ez gyakorlatban azt jelenti:

  • Ha Emby csomag telepítve van, a Synology Package Center úgy tekinti, hogy 8096/8920 „Emby portok”, függetlenül attól, hogy a system.xml-ben később átállítottuk 8099/8922-re.
  • Jellyfin csomag telepítője a saját default portjai alapján ütközést lát, és blokkolja a telepítést.
  • Fordítva ugyanígy: ha Jellyfin van fenn, Emby telepítése ütközhet, még akkor is, ha Jellyfinnél már átírtuk a portokat.

A fórumokban több beszámoló van arról, hogy:

  • Emby és Jellyfin csomag egyszerre a Synology-n portütközésbe fut,
  • a telepítők nem kezelik jól azt a helyzetet, amikor a default portot utólag átírják,
  • gyakran az egyik csomag uninstallja sem takarítja ki teljesen a port-hozzárendelést, így „szellem” konfliktusok maradnak.

Kipróbált megoldási irányok (laborjelleggel)

Tesztként végig lehet próbálni a következő sorrendeket:

1. Emby → port átállítása → Jellyfin telepítés

  • Emby csomag telepítése Csomagkezelési központból
  • Emby port átállítása a system.xml-ben 8099/8922-re
  • Jellyfin csomag telepítési kísérlete

Gyakorlati tapasztalat: a Jellyfin telepítő továbbra is portütközést jelez (8096/8920), hiába fut Emby másik porton. A csomagrendszer metadata szerint a portokat továbbra is Emby birtokolja.

2. Emby uninstall → Jellyfin install → Jellyfin port átállítás → Emby reinstall

Ez egy sokat ajánlott workaround:

  1. Emby csomag eltávolítása
  2. NAS reboot
  3. Jellyfin csomag telepítése (most már nincs Emby)
  4. Jellyfin adminban a portok átállítása (pl. HTTP 8096 → 8097)
  5. Jellyfin csomag újraindítása
  6. Emby csomag újbóli telepítése

Gyakorlati tapasztalat: bizonyos DSM + csomag verzióknál még így is előfordul, hogy az Emby telepítő portütközésre hivatkozik, annak ellenére, hogy Jellyfin már más porton fut.
Ennek oka, hogy a Jellyfin csomag saját default portdeclarációja továbbra is 8096/8920, és a csomagrendszer metadata alapján mindkét csomag „azonos portkészletre” pályázik.


Portok és folyamatok ellenőrzése parancssorból

Adja magát, hogy SSH-n rootként megnézzük, ki foglalja ténylegesen a portokat:

bashnetstat -tulpn | grep 8096
netstat -tulpn | grep 8920

Vagy modern rendszer esetén:

bashss -tulpn | grep 8096
ss -tulpn | grep 8920

Tesztkörnyezetben gyakran az derül ki, hogy nincs aktív processz a kérdéses portokon, mégis a csomagtelepítő ütközést jelez.
Ez megerősíti, hogy a konfliktus nem csak runtime portfoglalásról szól, hanem a DSM csomagrendszerben tárolt port-hozzárendelésről.


DSM logok és csomag-metadata – hol érdemes keresni?

Ha mélyebben szeretnénk megvizsgálni, miért áll le egy telepítő:

  • DSM Log Center:
    • Csomagtelepítési hibaüzenetek, portkonfliktusra utaló bejegyzések.
  • Csomag metadata / konfiguráció:
    • /var/packages/EmbyServer/ és /var/packages/Jellyfin/ alatt találhatók a csomaghoz tartozó fájlok, service definíciók, esetleges portbejegyzések.
    • Egyes környezetekben supervisord/service configfájlok (*.sc vagy ini) hivatkoznak explicit 8096/8920-ra.

Ezeknek az elemzése már reverse engineering-jellegű: kideríthető, hol deklarálja a csomag a portjait, és elvileg kézzel átírható lenne – de ez már nem támogatott, könnyen törékeny megoldás, és DSM frissítésnél, csomag update-nél visszajöhet a konfliktus.


Következtetés: megvalósítható-e a párhuzamos csomagos használat?

A teszt gyakorlati eredménye:

  • Elméletben: ha az egyik rendszer default portját install után átállítjuk, és a másikat csak ezután rakjuk fel, elvileg futtatható lenne párhuzamosan Emby és Jellyfin.
  • Gyakorlatban DSM 7-en:
    • A csomagtelepítők és a Synology Package Center portlogikája miatt legalább az egyik telepítésnél portütközésbe ütközünk.
    • A rendszer a default portokra épít, és nem veszi figyelembe a később átírt configot (system.xml, Jellyfin networking UI).
    • Több uninstall/reinstall és portellenőrzés után is előfordul, hogy vagy Jellyfin, vagy Emby telepítése megakad.

Ezért a konklúzió szakmai szempontból:

  • Tiszta, támogatott megoldás DSM 7-en:
    • Emby csomagként, Jellyfin konténerben (Docker/Container Manager), vagy fordítva.
    • Vagy csak az egyik médiaszerver, a másik helyett.
  • Csomagos Emby + csomagos Jellyfin egyidejű futtatása ugyanazon NAS-on, Container nélkül:
    • Elvi szinten megpróbálható,
    • de a gyakorlatban nem tekinthető stabil, támogatott konfigurációnak, mert a DSM csomagrendszer default portokra támaszkodik és konfliktusba kerül a két csomag telepítésekor.

Ha valaki kísérletezni akar vele, érdemes dokumentáltan, mentésekkel, tesztkörnyezetben próbálkozni, és elfogadni, hogy egy DSM frissítés vagy csomag update után bármikor visszatérhetnek a port-problémák.


Mit érdemes erről hazavinni rendszergazda szemmel?

  • Synology DSM 7 alatt a csomagrendszer nem arra lett kitalálva, hogy több, azonos default portot használó médiaszervert csomagként párhuzamosan fusson.
  • A hivatalos Jellyfin útmutatók sem véletlenül tolják Container Manager irányába a DSM telepítést: ott a portkiosztás teljesen a rendszergazda kezében van, nem a csomagrendszerben bedrótozott defaultokon múlik.
  • Ha a cél megbízható, hosszú távú használat és egyszerű frissíthetőség, akkor a vegyes modell (egyik csomag, másik konténer) jelenleg pragmatikusabb, mint a tisztán csomagos „kettős” setup.

Gyakori kérdések (FAQ) – Emby + Jellyfin Synology DS220+ NAS-on

Az alábbiakban összegyűjtöttem néhány gyakori kérdést és választ az Emby és Jellyfin párhuzamos, csomagos használatával kapcsolatban Synology DS220+ NAS-on, DSM 7 alatt.


1. Miért nem elég az Emby portját átírni a system.xml-ben?

system.xml az Emby saját futási konfigurációja, amit maga az Emby szerver olvas be, és ennek alapján indul el az adott portokon.
A Synology DSM Csomagkezelési Központ viszont külön metaadatban tárolja, hogy egy csomag milyen portokat használ, és telepítéskor/ellenőrzéskor ezeket a default portokat veszi figyelembe – nem feltétlenül a később módosított configfájlt.
Ezért hiába fut Emby már 8099-es porton, a csomagrendszer szemében 8096 továbbra is „Emby port” maradhat, ami ütközhet Jellyfin default beállításaival.


2. Miért ütközik Jellyfin és Emby portszinten, ha mindkettő csomagként van telepítve?

Mindkét médiaszerver történetileg ugyanazt a portpárt használja: HTTP 8096, HTTPS 8920.
Synology DSM 7 alatt, ha Jellyfin csomag telepítőt futtatunk, az ugyanazokat a default portokat deklarálja, mint az Emby csomag.
A csomagtelepítők és a DSM portellenőrzése emiatt azt látja, hogy két külön csomag ugyanarra a portkészletre pályázik – ez portütközéshez és telepítési hibához vezet, még akkor is, ha utólag átírjuk Emby vagy Jellyfin portjait a saját konfigurációjukban.


3. Ha Jellyfin portját átállítom admin felületen, miért akad el később az Emby telepítése?

Jellyfin admin felületén (Dashboard → Networking) módosítható a „Local HTTP port” és „Local HTTPS port”, és ez a futó Jellyfin szerver viselkedését befolyásolja.
A Synology csomagrendszer azonban a csomaghoz tartozó default portdeklarációt továbbra is 8096/8920-ként ismerheti, így Emby telepítője azt látja, hogy ezek a portok „Jellyfinhez” tartoznak – ezért blokkolhatja az Emby csomag telepítését portütközésre hivatkozva, függetlenül a runtime beállításoktól.
Ez tipikusan akkor jön elő, amikor Jellyfin már csomagként fenn van, és utólag próbálunk Emby-t feltenni.


4. Létezik stabil, támogatott mód arra, hogy Emby és Jellyfin párhuzamosan fusson ugyanazon Synology NAS-on?

Igen, de a gyakorlat azt mutatja, hogy DSM 7 alatt nem a „két csomag” modell az, ami stabilan működik.
A leginkább támogatott és rugalmas megoldás jelenleg:

  • az egyik médiaszerver (például Emby) csomagként fut,
  • a másik (például Jellyfin) Docker/Container Managerben, konténerként.

Így külön host portmappinget tudsz beállítani (pl. Jellyfin 8097, Emby 8099), és a csomagrendszer portlogikája nem ütközik a konténeres szolgáltatással.
Ez különösen akkor fontos, ha egy NAS-on több médiaszervert is párhuzamosan szeretnél használni (Emby, Jellyfin, Plex stb.).


5. Akkor egyáltalán nem lehet csomagos Emby + csomagos Jellyfin párost használni DSM 7-en?

Elméletben kifaragható egy olyan setup, ahol:

  • az egyik rendszert ideiglenesen eltávolítod,
  • a másikat felteszed, átállítod a portot,
  • majd visszarakod az elsőt,

de a gyakorlati tapasztalat az, hogy ez könnyen port- és csomagtelepítési hibákhoz vezet, és frissítéseknél/upgrade-eknél ismét előjönnek a problémák.
Szakmai szemmel ez a konfiguráció nem tekinthető stabil, hosszú távon karbantartható, „production-ready” megoldásnak, inkább labor-teszt jellegű kísérlet.


6. Miért ajánlja Jellyfin hivatalosan a Docker/Container Manageres telepítést Synology DSM 7-hez?

A Jellyfin DSM 7-es telepítési útmutatói egyértelműen a konténeres telepítést preferálják, mert:

  • a portkiosztást teljesen te döntöd el (host port ⇔ konténer port),
  • független a DSM csomagrendszer default portjaitól,
  • frissítéskor, rollbackkor és több médiaszerver párhuzamos futtatásakor jóval kevesebb csomagszintű ütközés van.

Konténeres Jellyfin használatával elkerülhető az a helyzet, hogy a Jellyfin és Emby csomag ugyanazokat a portokat akarja lefoglalni, és telepítéskor egymást blokkolják.


7. Összefoglalva: mit érdemes választani, ha stabil rendszer kell?

  • Ha csak egy médiaszerver kell:
    • válaszd azt (Emby, Jellyfin, Plex), amelyik neked funkcionalitásban, kliensekben és UI-ban a leginkább megfelel, és futtasd csomagként vagy konténerben, de ne keverd feleslegesen több megoldást egy NAS-on.
  • Ha kettőt szeretnél párhuzamosan:
    • a gyakorlatban jelenleg az a stabil megoldás, ha az egyik csomagként, a másik konténerben fut, külön portokon.
    • Így DSM csomagrendszer és konténeres világ szépen együtt tud élni, portütközés és telepítési konfliktus nélkül.

🙂

UPDATE!!! Sikerült feltenni 🙂

Haladó rész: Emby metaadat-hekkelés rövid időre, Jellyfin csomag telepítéséhez

Az alap bejegyzésben arra jutottunk, hogy DSM 7 alatt a csomagos Emby és csomagos Jellyfin párhuzamos használata portszinten problémás, mert mindkettő 8096/8920 portpárra épít, és a csomagtelepítők, illetve a DSM Csomagkezelési Központ ezeket ütközésként kezeli.
A gyakorlatban viszont egy rövid idejű, célzott metaadat-hekkeléssel elértük, hogy Jellyfin csomag fel tudjon települni Emby mellé – Container használata nélkül.

Ez a szekció labor jellegű, haladó rendszergazdai lépéseket tartalmaz, és nem tekinthető hivatalosan támogatott módszernek. Production NAS-on csak tudatosan, mentésekkel és dokumentálással érdemes alkalmazni.


Cél

  • Emby már csomagként telepítve DSM 7 alatt.
  • Emby runtime portjai átállítva 8099/8922-re (system.xml alapján).
  • Jellyfin csomagot szeretnénk telepíteni Csomagkezelési Központból úgy, hogy ne lásson portütközést 8096/8920 miatt.

Ehhez elérjük, hogy DSM minden szinten azt „higgye”, Emby 8099/8922 portokat használ, ne a klasszikus 8096/8920-at – legalább addig, amíg a Jellyfin telepítés átmegy.


1. Emby runtime portjainak átállítása (system.xml)

Ez az „alap” lépés, amit már korábban részletesen leírtunk:

bashnano /volume1/@appdata/EmbyServer/config/system.xml

Portok módosítása:

xml  <PublicPort>8099</PublicPort>
  <PublicHttpsPort>8922</PublicHttpsPort>
  <HttpServerPortNumber>8099</HttpServerPortNumber>
  <HttpsPortNumber>8922</HttpsPortNumber>

Mentés után Emby restart:

bashsynoservice --restart pkgctl-EmbyServer

Ettől kezdve maga az Emby szerver ténylegesen 8099/8922-n figyel.


2. DSM „meta” és service portok felderítése

SSH-n rootként ellenőriztük, hol fordul elő még 8096/8920 Embyhez kötve:

bashgrep -R "8096" /var/packages/EmbyServer /usr/local/etc/services.d 2>/dev/null
grep -R "8920" /var/packages/EmbyServer /usr/local/etc/services.d 2>/dev/null

Releváns találatok:

text/var/packages/EmbyServer/INFO:adminport="8096"
/var/packages/EmbyServer/target/EmbyServer.sc:src.ports="8096,8920/tcp"
/var/packages/EmbyServer/target/EmbyServer.sc:dst.ports="8096,8920/tcp"
/usr/local/etc/services.d/EmbyServer.sc:src.ports="8096,8920/tcp"
/usr/local/etc/services.d/EmbyServer.sc:dst.ports="8096,8920/tcp"

A többi találat (bináris DLL-ek, hwdata PCI IDs) nem kapcsolódik hálózati portokhoz, azokat nem módosítjuk.


3. Emby csomagmeta és service portok átírása 8099/8922-re

3.1. INFO – adminport

bashnano /var/packages/EmbyServer/INFO

Eredeti sor:

textadminport="8096"

Módosítva:

textadminport="8099"

Ez azt mondja a DSM-nek, hogy az Emby „admin portja” 8099 legyen, ne 8096.

3.2. EmbyServer.sc – target service

bashnano /var/packages/EmbyServer/target/EmbyServer.sc

Eredeti sorok:

textsrc.ports="8096,8920/tcp"
dst.ports="8096,8920/tcp"

Módosítva:

textsrc.ports="8099,8922/tcp"
dst.ports="8099,8922/tcp"

3.3. EmbyServer.sc – global service definíció

bashnano /usr/local/etc/services.d/EmbyServer.sc

Eredeti sorok:

textsrc.ports="8096,8920/tcp"
dst.ports="8096,8920/tcp"

Módosítva:

textsrc.ports="8099,8922/tcp"
dst.ports="8099,8922/tcp"

Ezekkel a módosításokkal:

  • Emby saját configja (system.xml)
  • DSM csomagmeta (INFO)
  • Emby target service definíció (target/EmbyServer.sc)
  • DSM service definíció (/usr/local/etc/services.d/EmbyServer.sc)

mind ugyanarra az új portkészletre (8099/8922) mutat.


4. Emby leállítása / NAS újraindítása

A konfiguráció és metaadat módosítása után:

bashsynoservice --stop pkgctl-EmbyServer
reboot

A NAS újraindítása biztosítja, hogy DSM az új portinformációkat töltse be.


5. Jellyfin csomag telepítése

Újraindítás után:

  • DSM → Csomagkezelési központ → Jellyfin → Telepítés

A portütközés-probléma itt oldódott meg: mivel Emby minden szinten 8099/8922 portokra lett átállítva, Jellyfin csomag telepítője már nem lát 8096/8920-on Embyhez kötött csomagot, így átengedi a telepítést.

Kimenet: Jellyfin csomag sikeresen feltelepült Emby jelenléte mellett, Container használata nélkül.


6. Jellyfin portok átírása (hogy később se ütközzön)

Telepítés után Jellyfin elindítása és admin felület elérése:

texthttp://NAS_IP:8096

Admin → Dashboard → Networking (vagy Advanced → Networking):

  • Local HTTP port: 8096 → pl. 8097 vagy 9096
  • Local HTTPS port: 8920 → pl. 9097 (ha használod)

Mentés, Jellyfin csomag restart.

Ettől kezdve Jellyfin stabilan az új portokon fut, függetlenül az Emby konfigurációjától.


7. Mi lesz Embyvel a Jellyfin telepítés után?

Miután Jellyfin portjait átállítottuk, és Jellyfin stabilan új portokon fut:

  • Emby maradhat 8099/8922-n – ez a legbiztonságosabb, mert így fizikailag sem „néz rá” Jellyfin portjaira.
  • Elméletben Embyt vissza lehetne állítani 8096/8920-ra is, de akkor ismét oda kell figyelni, hogy Jellyfin ne használja ugyanazokat a portokat.

A DSM oldali metaadat-módosítások (INFO, EmbyServer.sc) frissítésnél visszaállhatnak gyári értékre, ezért hosszú távon nem célszerű „végleges megoldásként” tekinteni rájuk – ebben a tesztben kifejezetten arra szolgáltak, hogy Jellyfin csomag telepítése átmenjen.


Mit bizonyít ez a lab teszt?

  • Megmutatja, hogy technikai szinten DSM 7-en is összehozható csomagos Emby + csomagos Jellyfin párhuzamosan ugyanazon NAS-on, ha:
    • Emby portjait minden szinten átírjuk (runtime + meta + service),
    • Jellyfin feltelepül default portokon,
    • majd Jellyfin portjait átállítjuk saját, ütközésmentes értékekre.
  • Egyben azt is jelzi, hogy ez a megoldás:
    • nem hivatalosan támogatott,
    • DSM frissítések és csomagfrissítések érinthetik,
    • csak tapasztalt rendszergazdának ajánlott, labor környezetben.

Így a blog eredeti következtetése (hogy production környezetben Emby csomag + Jellyfin konténer kombináció stabilabb, mint két csomag egymás mellett) továbbra is érvényes, de most van hozzá egy dokumentált „proof-of-concept” lab szekció, hogy megfelelő hekkeléssel csomagos Emby + csomagos Jellyfin is összehozható.