DLNA Server , kicsit jobban managelheto

Linux-haladó

Sziasztok,

 

Szuksegunk lenne egy DLNA serverre, amivel TV-kre tudunk kikuldeni videot, streameket etc...

 

Amit talaltunk elsore es tetszik az a Serviio  https://serviio.org Tudja azt, ami nekunk kell:

 

- Jogosultsag kezeles (adott megjelenito adott tartalomhoz fer hozza)

- Stream et is tamogat (m3u8 linket beszurva streamet is kirakhatunk DLNA-n keresztul)

- Megjelenito whitelist , engedelyezes utan latja egyaltalan a servert a TV

 

Ezek a legfontosabbak ami kell nekunk. A Serviio tudja ezeket mint irtam, de kellene meg legalabb 2 alternativa h legyen "valasztasi lehetoseg"

  • 1851 megtekintés

( obermotz | 2025. 03. 21., p – 11:36 )

Én itthon használok Serviio-t kb. 10-12 éve mint DLNA szervert (2 TV-t szolgál ki) és időről időre körülnézek hogy jelent-e meg valami életképes vetélytárs. Az én szubjektív szempontjaim szerint még mindig a Serviio magasan a legjobb.

en is ezt latom (sajna) most tettem egy probat a UMS el, de mar ott elverzett, hogy nem tamogat m3u8 playlist-et. 

 

Serviioval egyik "bajom" hogy nincs  a webes feluleten semmi auth... Otthon nem gaz nyilvan, ceges kornyezetben problemasabb. (lehet persze VLAN+firewall rule-al korlatozni a hozzaferest de elegge agyuval verebre az mar...)

( junior013 | 2025. 03. 21., p – 11:41 )

Legutóbbi otthoni DLNA-s próbálkozásomnál én is kizárólag a Serviio-t találtam az egyetlen értelmes választásnak, de aztán később áttértem inkább Plex-re, így egy ideje már nem néztem, akad-e jobb alternatíva.

"Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"

Plex otthon nalam is fut es szeretem , de itt nem otthoni a tema (PR videok futtatasa TV-ken, stream (Bloomberg) futtatasa)

 

Serviio fut most free ben, teszt jelleggel laborban es tetszik, semmi gondom nincs vele (kiveve a fentebb emlitett weboldal jelszomentesseget) de gondoltam azert mielott tovabb viszem a dolgot, megnezek alternativakat.

2 éve használtam PiSignage-t. volt az aulában egy nagy TV, hozzá volt egy raspberry pi. PiSignage futott rajta. mivel csak 1 példány volt, nem volt baj kezelni. feltölthettél rá képeket, videókat, beszúrhattál YT linkeket, weboldalakat, és megadhattad, hogy az adott tartalom mennyi ideig legyen látható, mi következzen utána, néma legyen-e a videó, stb. tök jó cucc. tudtál pl külön playlist-eket összedobni. pl volt egy általános, amin mentek életképek, de ha jött valami konferencia vagy hasonló, akkor váltás, és az azzal kapcsolatos tartalmak jelentek meg.

viszont ha jól értem, akkor neked olyan platform kell, ahogy több különböző helyen vannak kijelzők/tv-k, és más más tartalmat kell megjeleníteniük. erre is jó választás a PiSignage, csak akkor már fizetős. 
a dlna nem arra való, amit felsoroltál. az felolvas egy mappát, és a benne lévő tartalmakat eljuttatja azoknak, akik kérik. se felhasználó kezelés, se semmi xtra nincs benne. 

PiSignage mellet szól még, hogy központi a menedzsmentje, ami talán azért is jó, mert akkor nem kézzel kell minden tv-hez elmenni, és nyomkodni, hogy éppen mit jelenítsen meg.

Azért elvben a DLNA is fel van ám készítve rá, hogy a forrás, a lejátszó és a vezérlő 3 különböző eszköz, azaz egy külső management-el adod a parancsot, hogy melyik TV éppen milyen forrásból, mit játsszon. Csak sajnos gyakorlati rendszert valóban nem tudok mondani, ami ezt így meg is csinálja.

"Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"

kiprobaltam ezt: https://github.com/Screenly/Anthias/

 

Nem rossz, sajna kozponti managementje nincs, de van jol dokumentalt API-ja, szoval lehet a fejlesztoinkel megiratok ra egy UI-t a letezo belso webes APP-unkba. 

 

Persze ehhez kell Pi, viszont stabilabbnak, meg jobban managelhetonek tunik, mint egy DLNA server. Koszi a tippet.

Már vagy 30 év számítógép van a hátam mögött (beleszámoltam a csüffögő fogalmatlan gyerekkori éveket is), de enduserként a Kodi amit tavaly ősszel próbáltam ki életemben először, hát hogy is mondjam: tele van antipattern faszságokkal. Tudod, mikor egy átlag ITfogalmatlanoknak készült videólejátszó első használatakor olyan faszságokba futsz bele, amiket nem tudsz hova tenni főállású IT-sként sem. Én vagyok balfasz h. nem működik nekem ez meg az? Vagy pont olyankor csatlakoztam be a Kodi lifecycle-be, amikor az éppen a 20 éves mélyponton van valamilyen belső devekoper war miatt?

Szabadidőmben (ami alig van ugye) túrtam a wiki-jét, ami mint minden OSS, televan 10-15 éves elavult infóval. Bármi kérdesedre sehol nem fogsz választ találni a wiki-ben, muszáj mindenért topic-ot nyitni a fórumban (mert az is 1 rendezetlen szemétgyűjtő). Ahol az elitista fasz developer-ek emeletes lóról küldenek el a francba, hiába te csak 1 laikus hülyeként egy valid kérdést tettél fel.

( ricsip v | 2025. 03. 22., szo – 06:38 )

Szerkesztve: 2025. 03. 22., szo – 06:41

Erre én is felíratkozok, kíváncsi lennék mire jutsz.

Én ezt a low-priority "DLNA VPN-en keresztül több helyszínen 1 forrás videós szerverről" hobbi projectet feladtam sok év üresjárat után (se időm, se energiám nem volt a sok SEO-fertőzött szemét világában megtalálni azt az 1 eldugott blog-ot, ami szépen végigvezetett volna a megoldáson)

( enpassant v | 2025. 03. 22., szo – 09:17 )

Én otthon eddig főként minidlna-t használtam. Ebből is látszik, hogy nincsenek nagy igényeim ;-)

Ránézek majd a Serviio-ra, köszi!

Ez így szerintem nem igaz. Adott egy médiatár, aminek egyes elemeit valamilyen szisztéma szerint szeretnéd elérhetővé tenni a DLNA kliensek részére. Ennek semmi köze a hálózati réteghez, ezt ott, szerver szinten kell szabályozni (hogy ki mihez férhet hozzá). A nyitó kérdésben legalábbis ez szerepelt: "Jogosultsag kezeles (adott megjelenito adott tartalomhoz fer hozza)"

itt nem arrol van szo hogy X es Y eszkoz elerje a dlna servert, de Z ne. Sokkal inkabb "mit erjen el dlna serveren" jogosultsag kezeles kell: X-nek a A mappahoz kell jon, Y-nek meg a B mappahoz. ennek kezelese nem a wifi feladata, foleg hogy lehet olyan eszkoz ami kabellel csatlakozik.

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Ok, akkor félreértettem. Egyébként ez nagyon nem szokványos funkció, a biztonságosságát nem venném készpénznek, érzékeny adatokat nem osztanék ki vele:

"A DLNA szerver alapvetően egy egyszerű médiaszerver, amely hálózaton keresztül elérhetővé teszi a rajta tárolt tartalmakat DLNA-képes eszközök számára (pl. okos TV-k, médialejátszók).

Jogosultságkezelés DLNA-nál

A DLNA protokoll önmagában nem tartalmaz fejlett jogosultságkezelést, mert az alapvetően egy nyílt megosztási protokoll. Azonban egyes DLNA szerver szoftverek rendelkeznek hozzáférési szabályokkal, például:

1. IP- vagy MAC-cím alapú korlátozás

  • Egyes szerverek (pl. Serviio, Twonky, Universal Media Server) lehetővé teszik, hogy csak bizonyos eszközök férjenek hozzá a tartalmakhoz.
  • Ezt fehérlista (allowlist) vagy feketelista (denylist) segítségével lehet beállítani.

2. Mappa vagy fájl szintű hozzáférés-szabályozás

  • Bizonyos szerverek (pl. Plex, Emby) lehetőséget adnak rá, hogy felhasználói fiókokhoz rendeljenek jogosultságokat, így:
    • Egyes felhasználók csak bizonyos könyvtárakat látnak
    • Mások csak adott eszközökről férhetnek hozzá

3. Jelszavas védelem (nem szabványos DLNA funkció)

  • A legtöbb klasszikus DLNA szerver nem támogatja a jelszavas védelmet, de az olyan fejlettebb médiaszerverek, mint a Plex, Jellyfin vagy Emby, igen. Ezek DLNA-t is tudnak streamelni, de a teljes médiaszerverük támogat felhasználói bejelentkezést és jogosultságkezelést.

Hogyan lehet biztonságosabbá tenni egy DLNA szervert?

  1. Kapcsolja be a MAC- vagy IP-cím alapú szűrést, ha a szerver támogatja.
  2. Ne osszon meg érzékeny tartalmakat nyílt DLNA szerveren.
  3. Használjon fejlettebb médiaszervert (Plex, Emby, Jellyfin), ha felhasználói jogosultságokat akar kezelni.
  4. DLNA-t korlátozza helyi hálózatra, és ne tegye elérhetővé interneten keresztül."

"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

DLNA-t korlátozza helyi hálózatra, és ne tegye elérhetővé interneten keresztül."

Dlna nem eleve multicast alapú? Azaz LAN-os környezetben NAT-on keresztül vagy akár csak másik LAN subnet-be nem is routolható át KÖNNYEN, mert a discovery eleve lokális multicast címeken megy?

Technikailag nincs olyan, hogy LAN, az egy technikus terminus a nem-routeolható szegmens(ek)ből álló alhálózat(ok)ra. De ha a DLNA servered közvetlen az internetkábelra van kötve, akkor ő bizony oda fogja kiküldeni a multicast csomagokat, neki aztán mindegy, UTP kábel ez is, az is. Aztán ha valaki befogja, akkor kommunikálni fog vele. Nyilván sok múlik a szolgáltató routingján, mennyire van felkészülve az ilyen idióta végpontokra, lehet kiszűri, lehet nem. Pont ezért van ott a figyelmeztetés.

Aztán a discovery is egy érdekes fogalom. Oké, hogy ő multicast hirdeti magát, de a kliensek becsatlakozása már sima IP-port alapon megy, ha valaki _véletlenül_ kitalálja, hogy azon az IP-n van egy DLNA szerver, anélkül is beköszönhet, hogy elolvasta volna a röplapokat a multicastról. És hát vannak ilyen eszközök, mint az nmap, amikkel azért lehet növelni ennek a véletlennek esélyét. Ha magában a szerverben van valami protokoll-szintű sérülékenység, akkor az így simán kihasználható.

De persze, ez csak elmélet. Nem olvastam a DLNA protokoll RFC-jét, bár meglepne, ha magában a protokollban lenne erre védelem.

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

Ezen azért majd gondolkozz el.

Azaz, MiniDLNA-ból relatív könnyedén lehet több példányt futtatni - ehhez fontos, hogy a példány saját konfigurációval (UUID-del, porttal, PID-fájllal, stb.) rendelkezzen - és értelemszerűen amelyik kijelző tud ehhez a példányhoz csatlakozni - ami a port alapján már könnyen tűzfalazható - az annak a konfigurációját látja. Ahogy írja is a fickó, az N. dnarab MiniDLNA példány N. db. TV-csatornaként funkcionál. Ha az adott csatornán nincs számára érdekes (mert nem látja), akkor ennyi. És ha értelmes nevet állít be az ember az egyes példányoknak, akkor elég egyértelmű, hogy miért oda kell kapcsolódni. Ráadásul a MiniDLNA sok bekonfigurált könyvtár tartalmát tudja ömlesztve odaadni a kliensnek, azaz lehet olyan mappa, amibe a mindenkinek látszó anyagok kerülnek, és olyan, amibe csak az adott kliens számára elérhető privát anyagok kerülnek, és ezek tetszőleges kombinációját fel tudja nyalni. Így akár olyan is lehet, hogy A, B és C mind látja a közöset, látja a privát anyagait, de A és B lát még ezen kívül e 2 számára engedélyezett harmadik féle fájlkupacot is - és ezek mindegyike besorolható, hogy kép, hang vagy videó - ha egyes kliensek esetén erre is szükség van.

tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

Írna valaki ezekről (akár csak 1 konkrétról, de összehasonlítós többszereplősnek jobban örülnék) egy részletes, alapos, műszakilag kivesézett blogposztot, meghívnám érte 1 sörre a sysadmin day-en.

 

Egye fene, 2 sör. Viccen kívül, 2 sör egy jó alapos összehasonlító blogposztért (DLNA szerver oldal érdekel, de ha van kliens része is, akkor jöhet az is):

Windows Network streaming, Minidlna, Plex, Kodi, Serviio,  Jellyfin, Emby, meg ami még a piacon említésre méltó

Nem, én arra gondolok amit a kamu-AI ma még nem tud, csak az ember: ÚJ tartalmat előállítani, ami konkrétan leírva eddig még sehol nem volt. Hanem azt egy embernek kell konkrézan kipróbálnia, kitesztelnie, tapasztalatait megosztania, szubjektív véleményt alkotni, szubjektív sorrendet felállítani. Ha ezeket korábban ebben a konkrét kontextusban nem írta még le senki egy publikusan hozzáférhető weboldalon, a kamu-AI nem tudja ezt előkotorni és összerakni neked a lopott 10000 TB-nyi adatbázisából.

A sörös ajánlat nem arra vonatkozott, hogy írj egy 3-3 soros (nem sörös ;) bullshit-et mindegyikről.

Hanem inkább ilyesmire vonatkozott: húzd fel mindegyiket egy tesztkörnyezetben (lehetbugyanabban is, demonstrálandó h. megférnek egymás mellett is multicast összeakadás nélkül), wireshark-old le milyen forgalmat csinál a discovery, a konkrét média stream, átmegy-e másik routolt subnet-be/VLAN-ba, IGMP snooping melyiket hogyan cseszi szét, melyiknél van szerver-oldali transcode, milyen kodekeket ismer, milyen konténerformátumokat kezel, belső-külső felíratokkal hogy áll, NAT-on hogy megy ki-be, melyik telefonál haza a gyártónak, ha a világ másik felén akarok nézni telefonon filmet a gyűjteményemből: a vendor szervere fogja átjátszani a tartalmat? Nekem kell haza-VPN-znem? Vagy elég csak 1 portforward az otthoni rúteren?

A szubjektív értékelés opcionális. Ha a konkrétumok kiderülnek, akkor mindenki az egyéni szempontrendszere szerint tudja osztályozni melyik versenyző mire jó, miben erős és miben gyenge.

Amiket felsoroltam szempontok, egy hálózati műsorszóró termék (kliens/szerver) esetében SZERINTEM adják magukat. Ennél egy RFP csak részletesebbeket kérdezne, volt már balszerencsém az elmúlt 20 évben pár ilyenhez. Akkor -megoldásszálító csapat részeként- nyilván idegesítőnek és feleslegesnek éreztem ezt a fajta szőrszálhasogatást és részletekbe menő vallatást a megrendelő részéről. Viszont mai fejjel -megrendelőként- már nyilván megértem h. a sok kreatív és tróger gyártói trükközést csak ilyen szőrszálhasogató kérdezősködéssel és mindenbe részleteibe belemenő vizsgálattal tudja csak kivédeni a fizető vendég.

 

Teljesen más téma: divat még manapság is RFP-t írattatni a pályázókkal nagy megrendelőként IT-jellegű projectekhez? Vagy már a megrendelők is rájöttek h. a kötelező házifeladat írattatást a pályázók masszívan beleárazzák az ajánlataikba, és így végsősoron nem kap a megrendelő ingyenmunkás piac-körképet ennek köszönhetően.

A szubjektív értékelés opcionális. Ha a konkrétumok kiderülnek, akkor mindenki az egyéni szempontrendszere szerint tudja osztályozni melyik versenyző mire jó, miben erős és miben gyenge.

Igen, de ezt mondom, hogy tulajdonképpen van neked szempontrendszered, amire kíváncsi vagy. Ha összeraksz egy normális promptot, amiben leírod explicit, hogy téged mi érdekel, megkéred, hogy kukázzon össze a netről forrásokat való élet beli példákra, keressen screenshotot, akármi, akkor reális esély van arra, hogy összerakaja neked. Arra is, hogy ha megkéred, hogy figyu, rakjál össze nekem konfigot meg docker composet meg mittomén mit tesztkörnyezet felhúzásához.

esetében SZERINTEM adják magukat

Ja, de valójában egy elég vastag része egy egyszeri usert egyáltalán nem biztos hogy érdekel. Általában a legtöbb azért ilyen viszonylag genericcel kezdi, mert a legtöbbször azzal kezdődik. Aztán ha faggatod tovább, kierül, hogy milyen mélyre lehet vele menni, mielőtt loopol és habosít, vagy egyértelműen képzeleg. Tapasztalataim szerint van, amiben elég mélyre, és van amiben rohadtul nem.

Viszont ha két sörért még a szempontrendszeren való gondolkozást is meg akarod spórolni, hát arra valóban nem jó. Mert akkor nem azt várod tőle, hogy újat alkosson, hanem azt, hogy gondolatolvasson. Pedig nem vagy nő :D

Nem árajánlatot adtam fizetős munkára vazze...

Van itt hup-on aki lebloggolja egy több hónapos elektronikai kütyü összerakását, vagy nyáktervezést stb  fotókkal illusztrálva. Csak úgy, hobbiból, ingyen.

Ezért sem fizetett pl. nekem senki 1 sört sem: https://hup.hu/node/160279

A sörös ajánlat nem arra vonatkozott, hogy írj egy 3-3 soros (nem sörös ;) bullshit-et mindegyikről.

Hanem inkább ilyesmire vonatkozott: húzd fel mindegyiket egy tesztkörnyezetben...

Ha mindegyikért fizetsz 3 sört (normális cseh, nem valami lábmosóvíz penny pils), fontolóra veszem! 😉

Tv vásárlás előtt állok, és a jól bevált házi fájl és letöltő szerver összeállításom is döglődik! Megszolgálta! Raspberry Pi2 v1.1 egy 1TB-os leselejtezett laptop vinyóval... 😁

( Vamp | 2025. 03. 27., cs – 16:18 )

Szerkesztve: 2025. 03. 27., cs – 16:20

Gondoltam leirom, mi lett a dolog vege :)

 

A fejlesztesi osztalynak megmutatva igazabol arra jutottak, hogy Node&React alapon (ahogy amugy a sajat belsos progink is fut) megirjak az egeszet. Supportalni fog Pdf-et, image-et, videot, stream-et (m3u8) mindent ami kell. A megjelenito egy bongeszot kiosk modba futtato Pi vagy x86-os gep lesz. More or less mar kesz is van, megneztem, nice lesz :) Szoval reszemrol a tema lezarva :)

Csodás szopásoknak néztek elébe, de hajrá!

(imádom ezt a "van rá piaci termék, ingyen is, de oldjuk meg házon belül" attitűdöt, persze, olcsóbb megoldani, aztán majd amikor jönnek ki sorra a mindenféle hibák, vagy lecserélik a tévéket és kellene még két protokollt támogatni, akkor jön a tátogás, hogy dehát erre nincs épp idő/pénz/ember, mert a hosszútávú karbantartást nem számolta bele senki. Az implementálás minőségéről meg ne is beszéljünk, tisztelet a kivételnek, ezek mindig valami érdekes módon értelmezett megoldások szoktak lenni. Elnézést, ha túlságosan cinikus vagyok, de nagyon sok ilyet láttam már, és kevés jót ezekből.)

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

Alapvetően egyetértek, de abból, hogy "már nagyjából kész is van" én arra tippelnék, hogy valójában összeglueztak a meglevő keretrendszerrel vmi authentikált panelt, ami valami standard webrtc-t csomagol. Úgy akár még szoftver oldalról kb használható is maradhat, mert gyakorlatilag csak ragacs kód. A súlyos szopás faktor hosszú távon ebben a "valami pi" lesz inkább :)

Azert itt nem errol van szo egeszen... A rendszer jelenleg is rendelkezik egy tobb eve hasznalt "kiosk" modu megjelenito modullal, amivel kulonfele tartalmakat (szunetrend, ceges hatekonysag, baleset mentes napok szama, etc) jelenitunk meg monitorokon. Ennek egy kibovitese lesz a videos tartalom. 

Ezert van az, hogy mar "majdnem" kesz is van, hiszen a nagyja mar eddig is letezett.

( ozs v | 2025. 03. 28., p – 17:42 )

Szerkesztve: 2025. 03. 28., p – 17:43

Többször elolvastam a kívánalmakat, illetve az adott válaszokat. Jelentem, nekem is lesz kipróbálni valóm. Egyik-másik felkeltette az érdeklődésem. :)

Azt nem olvastam a kritériumok között, hogy csak ingyenes megoldást keresnél.

Ha van rá (jó nagy) keret -- ami nyilván nincs --, akkor ajánlom figyelmedbe a BrightSign megoldásait. Ez pont azt tudja -- és még sokkal többet --, amire nektek szükségetek van. Cserébe viszont elég vastag lesz a kiállított számla. Úgyhogy ez nagy negatívum a részére. :(

Hátha van olyan hely, ahol épp leszerelik őket, s kedvezményesen lehet szert tenni rájuk. ;)

Nincs közöm a céghez, csak az előző melóhelyemen üzemeltettünk jópárat, s az árától eltekintve egész jó tapasztalataink voltak vele.

Lehet, hogy kívül szőke vagyok, de belül sötét, oké?!

( BaT | 2025. 03. 28., p – 20:42 )

Szerkesztve: 2025. 03. 28., p – 20:43

Gerbera-val szemeztem korábban, de még nem próbáltam. Tud streamet és van benne kliens konfiguráció, bár nem kimondottan jogosultságkezelésre, de talán így megoldható:

<clients enabled="yes">
    <!-- 1. kliens IP alapján -->
    <client ip="192.168.1.100" group="client1"/>

    <!-- 2. kliens UserAgent alapján -->
    <client userAgent="SomeTVManufacturerAndModel/123" group="client2"/>

    <!-- Alapértelmezett csoport, minden tartalmat elrejt -->
    <group name="default">
        <hide location="/media/library/path"/>
    </group>

    <!-- 1. kliens csoportja, 2. kliens tartalmát elrejti -->
    <group name="client1">
        <hide location="/media/library/path/client2"/>
    </group>

    <!-- 2. kliens csoportja, 1. kliens tartalmát elrejti -->
    <group name="client2">
        <hide location="/media/library/path/client1"/>
    </group>
</clients>

( kris | 2025. 03. 29., szo – 00:29 )

Ha közvetlenül az UPnP képes TV-kre akar valaki tartalmat renderelni, ahhoz nem kell feltétlenül DLNA szerver, teljesen simán lehet mindenféle lejátszandót (UPnP media renderer-t) "etetni" egy UPnP controller segítségével bármilyen http-n elérhető tartalommal---amire aztán lehet mindenféle fancy hozzáféréskezelést tenni. Ami szivatás és elég macerássá teszi az UPnP-t az a multicast. 

Szerintem reális a célszoftver írása (vagyis UPnP controller), nem olyan bonyolult és mondjuk nem egy HTTP szinten egységes implementációkkal rendelkező valami, de azért egészen jól kompatibilisek az eszközök, pl. python-ban nem egy űrtechnika összedobni valamit. Csak az a fránya multicast ne lenne a device discovery-hez---ha fix eszközökkel dolgozik az ember, akkor megúszható, mert a tényleges device control meg a tartalmak letöltése már unicast-on megy.

Létezik olyan egyszerű controller program, amiben megadod h. hol van a Dlna szerver (IP, port, protocol), folder meg azon belül fájlnév, megadsz neki egy cél IP-t (pl. egy okosTV), hogy az azon futó valamilyen media player (pl. a beépített programja?) meg elkezdi lejátszani a videót? Kétlem h. ilyen létezik, ill. h. ez így működne. A TV-nek kell szerintem kezdeményeznie a folyamatot: figyelnie a multicast IP-n elérhető DLNA szerver announcement-eket, aktívan csatlakoznia a multicast group-ba, connect-elni az unicast IP-re, lekérni a tartalmat, végül elindítani a lejátszást.

Az első felére: egyetértek, én sem tudok ilyenről (bár ez semmit nem jelent).

A második felére: nagyon nem értek veled egyet, hogy ez nem működne, mert ennek pont így kellene működnie a DLNA szabvány szerint.

Ugyebár a DLNA speckó szerint van legalább 4-féle eszköz, és a szerver (mondjuk a NAS a rajta futó MiniDLNA-val; hivatalosan DMSA - Digital Media Server Application) és a lejátszó (mondjuk a TV a beépített progijával; DMP - Digital Media Player) mellett amit leírsz az pontosan a harmadik eszköz, a vezérlő (DMC - Digital Media Controller) feladata. Csak épp nekem olyan érzésem van, hogy a negyedik fajta eszköz nem nagyon létezik, amihez a kontroller beszélhet: a Digital Media Renderer. Ezt a TV-k, okoshangszórók, okostáblák (vagy egyéb megjelenítők, hangkeltő eszközök) csinálhatnák, csak nem teszik. de ettől még létezhetNE.

Én úgy képzelem, hogy egy ideális világban pl. egy Chromecast kategóriájú eszköz és infrastrktúra akár múködhetne is pontosan így:

- van egy NAS-om amin fut a DMS

- van egy buta TV-m HDMI bemenettel.

- hozzá egy ilyen kütyú, ami DMR-ként funkcionál

- és van egy telefonos / számítógépes appom, ami pedig DMC funkciót játszik el

Így a buta TV-n látom az akármit a NAS-tól streamelve. Ha pedig a telefonról szeretnék mutogatni valamit, akkor ugyanaz az app legyen DMC mellett DMS is, és ki lehessen választani lokális médiát.

No most pl. az androidos BubbleUPNP legalábbis leírása szerint ezt pont tudja (ha jól emlékszem).

A hátulütője fentieknek, hogy nem oldja meg sok ember azon igényét, hogy ne (csak) lokális tartalmat lehessen nézni, hanem YT, vimeo, Netflix és egyéb streaming szolgáltatók anyagát is akarják látni - de ez szerintem a streaming szolgáltatók hibája, hogy nem DLNA-t használnak.

tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

Csak épp nekem olyan érzésem van, hogy a negyedik fajta eszköz nem nagyon létezik, amihez a kontroller beszélhet: a Digital Media Renderer. Ezt a TV-k, okoshangszórók, okostáblák (vagy egyéb megjelenítők, hangkeltő eszközök) csinálhatnák, csak nem teszik. de ettől még létezhetNE.

Dehogy nem, pl. az én TCL Android TV-m is hirdeti magát, pl. eezUPnP-vel tudok is rá tartalmat küldeni.

( zrubi v | 2025. 03. 31., h – 00:21 )

Ezen topik hatására - és mert épp újraépítem az itthoni NAS-t, kipróbáltam a jellyfin-t.

Eddig bőven túlszárnyalta az elvárásaimat :)

Persze, még nem volt tüzetes tesztelés, de mivel a telepítés után csak odaadtam neki az eddigi 'Movies' folert, hogy tssék, itt vannak a filmek.... Ez meg gyakorlatilag adott nekem egy - azonnal működő - házi NetFlix-et :)

Pesze, ehhez kell külön kliens, de - számomra igen meglepő módon - van hozzá még az LG TV-re is.

0 reklám, nem akar fizetős plan-ra terelni, és full open-source.

Eddig tetszik! - annyira, hogy önkéntes (rendszeres) előfizetőjük is lennék... ha megtalálnám hol és hogyan tehetem ezt meg.

zrubi.hu