Újdonságok

2.0.9 - 2026-08-23

A frissítési értesítő a saját nyelvén nyitja meg az oldalait

Mi: A frissítési értesítőben található Újdonságok és Letöltés hivatkozások mostantól a MusicBee saját nyelvén nyitják meg a bővítmény oldalait, nem pedig angolul.

Miért: Ez a két hivatkozás négy nyelvre – angolra, franciára, spanyolra vagy németre – szűkítette a nyelvet, mielőtt elküldte volna a weboldalra, így mindenki más az angol oldalt kapta, még akkor is, ha létezett fordítás. Mostantól változatlanul továbbítják a MusicBee nyelvét, és hagyják, hogy a weboldal döntsön, mit szolgáljon ki, amit a mellettük lévő Súgó gomb mindig is tett.

2.0.8 - 2026-08-22

A beépülő modul mostantól helyesen mutatkozik be az alkalmazásoknak és eszközöknek, amelyek felfedezik azt a hálózatán, és az Eszközprofilok beállításai ismét egy vonalba kerültek.

Eszközei a megfelelő gyártót, modellt és verziót mutatják

Mi: Amikor egy vezérlőalkalmazás, telefon vagy TV megtalálja a MusicBee-t a hálózatán, mostantól ezt a beépülő modult a yaiol által készítettként mutatja be, a beépülő modul saját oldalára mutat, szerverként, lejátszóként és rendererként is leírja, és a ténylegesen telepített verziót jelenti.

Miért: Minden UPnP eszköz bejelenti, ki készítette és mi az, és a vezérlőalkalmazások ezt mutatják az eszköz identitásaként. Ez a beépülő modul még mindig az eredeti beépülő modul adatait jelentette be, amelyből elágazott: egy másik szerző nevét, a MusicBee weboldalát a sajátja helyett, és egy "1.0"-ra rögzített modellszámot az első kiadás óta. Telefonjáról nem lehetett megmondani, melyik beépülő modullal beszél, nemhogy melyik verziójával. Ezek az adatok mostantól magából a beépülő modulból származnak, így az eszköz mellett megjelenő verzió minden frissítéssel helyes marad.

Az Eszközprofilok beállításai ismét egy vonalba kerültek

Mi: Az Eszközprofilok lapon a címkék és a hozzájuk tartozó mezők egy bal oldali éllel rendelkeznek és egyenletes távolságra helyezkednek el, a mintavételi frekvencia tartomány pedig egyetlen sorban olvasható.

Miért: A mezők idővel szétcsúsztak, ahogy opciók kerültek a lapra, és a mintavételi frekvencia tartomány "tól" címkéje a mellette lévő mező tetején landolt – olvasható volt, ha tudta, mit mond, de zavaró volt az első alkalommal, amikor ránézett.

2.0.7 - 2026-08-08

A nagyobb zeneszámok megtartják a címüket és a pozíciócsúszkájukat

Mi: egy telefonról küldött nagyobb zeneszám – egy hosszú FLAC, egy nagy felbontású vagy DSD fájl – most már a megfelelő címét mutatja, és mozgatható rajta, akárcsak egy kisebb. Korábban némelyikük hálózaton keresztül játszott le, webcímmel a cím helyett, és egy csúszkával, ami nem csinált semmit.

Miért: a beépülő modul megvárja a helyi másolatát, mielőtt elindulna, de korábban előre eldöntötte, hogy érdemes-e várni egy fájlra, a mérete alapján. Ez valójában a hálózat sebességére vonatkozó találgatás volt, amit nem tudhat: egy 65 MB-os zeneszámot túl nagynak ítéltek, majd egy másodperccel később befejeződött a letöltés – kényelmesen azon a várakozási időn belül, amit már feladott. Most egyszerűen figyeli a letöltést. Amíg még érkezik, a beépülő modul tovább vár, bármeddig is tart; csak akkor adja fel, ha az átvitel valóban megakad, amit most gyorsabban észrevesz, mint a régi fix késleltetés.

2.0.6 - 2026-08-03

A telefonról küldött albumok mostantól szünet nélkül, folyamatosan játszódnak le a számok között, és az internetes rádiót rádióként ismeri fel az alkalmazás, ahelyett, hogy szokatlanul hosszú dalként kezelné.

Az albumok szünet nélkül játszódnak le

Mi: Amikor egy teljes albumot küld a telefonjáról, a MusicBee mostantól szünet nélkül, folyamatosan játssza le a számokat egymás után – így az élő felvételek, DJ szettek és folyamatos klasszikus művek egyben maradnak.

Miért: A szabvány lehetővé teszi, hogy egy vezérlő alkalmazás azt mondja, "ez következik", ami lehetővé teszi a zökkenőmentes átmenetet. Ezt az utasítást korábban egyáltalán nem fogadta el az alkalmazás, így nem volt hová tennie a következő számot, és úgy jelentette be, mintha az aktuális lenne – ez okozta az előző kiadásban javított albumproblémát. Mostantól megfelelően elfogadja: a következő számot már akkor letölti, amikor az aktuális még játszik, és a MusicBee saját lejátszója átlépi a határt.

Az internetes rádiót rádióként ismeri fel az alkalmazás

Mi: A MusicBee-nek küldött élő adás streamként játszódik le, és soha nem töltődik le.

Miért: Egy adás letöltése értelmetlen – nincs vége, és nincs min átugrani –, de a beépülő modul korábban nem tudta megkülönböztetni egy zenei fájltól, ezért elkezdte letölteni, és leállt, amint a letöltés meghaladott egy fix méretet. A vezérlő alkalmazás megmondja, melyiket küldi a kettő közül, és ezt mostantól közvetlenül olvassa be az alkalmazás. Nincs beállítás, nincs találgatás.

A hosszú, nagy felbontású számok megtartják a másolatukat

Mi: A DSD fájlok és a hosszú, 24 bites felvételek mostantól ugyanúgy mozgathatók, mint bármely más szám.

Miért: Ezeket a fenti méretkorlát fogta meg – egy 20 perces nagy felbontású tétel vagy egy 10 perces DSD szám is meghaladta azt –, így a másolatukat elvetették, és a pozíciócsúszka leállt a működéssel pontosan annál az anyagnál, amelyet a legvalószínűbb, hogy érdemes áttekinteni. Mivel a rádió megfelelően azonosítva van, nincs szükség méretkorlátra.

2.0.5 - 2026-08-03

Két javítás a MusicBee telefonról történő vezérléséhez: a hangerő mostantól ugyanazt jelenti mindkét végponton, és egy teljes album lejátszása az első szám után is működik.

A telefonod hangereje megegyezik a MusicBee hangerejével

Mi: a telefonod hangerejének maximumra állítása mostantól eléri a maximumot a MusicBee-ben, és a MusicBee saját beállítása is helyesen olvasható vissza a telefonon.

Miért: a beépülő modul soha nem mondta meg a vezérlő alkalmazásnak, hogy mi a legmagasabb hangerő, így minden alkalmazásnak találgatnia kellett. Az egyik 69-re állította be, ami azt jelentette, hogy a 100%-a csak a MusicBee 69%-át érte el, míg a MusicBee 100%-a 144%-ként jött vissza a telefonon – és a telefon hangerőgombjai soha nem érték el teljesen a maximumot. A renderelő most egyértelműen megadja a tartományt, így mindkét végpont ugyanarról a skáláról beszél.

Egy album lejátszása megtartja a címeit és a pozíciócsúszkáját

Mi: egy telefonról küldött album minden száma mostantól a megfelelő címét mutatja, és át lehet rajta lépni, nem csak az elsőn.

Miért: egy vezérlő alkalmazás a jelenlegi szám után egy másodperc töredékével jelenti be a következő számot, és ez a bejelentés törölte a lejátszásra váró számhoz letöltött másolatot – így a legtöbb szám csendesen visszatért a hálózaton keresztüli lejátszáshoz, ami elveszíti mind a címet, mind az ugrálás lehetőségét. Több szám másolata most egymás mellett van tárolva, így egy bejelentés már nem törölheti az éppen használtat.

2.0.4 - 2026-08-02

A telefonról vagy más szerverről a MusicBee-be küldött zene most már valódi zeneszámként viselkedik: mozoghat benne, és azonnal megjeleníti a megfelelő címét. Plusz egy javítás a hi-fi streamerekhez, amelyek egy kombinált eszközként mutatkoznak be.

Mozgás egy máshonnan küldött zeneszámban

Mi: a pozíciócsúszka húzása most már működik a telefonról, NAS-ról vagy más médiaszerverről küldött zeneszámoknál. Ennek lehetővé tétele érdekében a MusicBee letölti a zeneszám egy másolatát egy ideiglenes mappába, miközben elkezdi lejátszani, és azt a másolatot játssza le. Ez körülbelül egy másodpercet vesz igénybe egy otthoni hálózaton, a másolat törlődik, amint egy másik zeneszámot küld, és minden maradék törlődik, amikor a MusicBee legközelebb elindul.

Miért: a MusicBee el tud indítani és le tud állítani valamit, amit a hálózaton keresztül hallgat, de nem tud benne mozogni – így a csúszka úgy tűnt, hogy ugrik, majd azonnal visszacsúszott oda, ahol volt, magyarázat nélkül. Egy közönséges fájl lejátszása a saját lemezén teljesen megszünteti a korlátozást, ahelyett, hogy megkerülné azt.

Helyes cím és hossz az első hangtól kezdve

Mi: egy olyan alkalmazás által küldött zeneszám, amely nem ad a fájljainak közönséges fájlkiterjesztést, most már azonnal megjeleníti a valódi címét és hosszát, amint elindul, ahelyett, hogy hosszú webcímként jelenne meg.

Miért: a MusicBee a fájlkiterjesztés alapján azonosítja a zeneszámot – és megtalálja a címkéit –, és egyes lejátszók egyáltalán nem adnak ki kiterjesztés nélküli címeket. A helyi másolat mindig a megfelelőt tartalmazza, így a zeneszám felismerésre kerül, bármit is nevezzen a küldő alkalmazás.

Egy ugrás, amit nem lehet megtenni, most már jelzi

Mi: ha a renderelő valóban nem tud a kért pontra lépni, a vezérlő alkalmazás értesítést kap, és jelenti azt.

Miért: korábban ettől függetlenül „kész” választ adott, így a csúszka egy másodperccel később visszacsúszott, anélkül, hogy bármi magyarázatot adott volna. Egy őszinte elutasítás könnyebben kezelhető, mint egy csendes.

A kombinált hi-fi streamerek helyesen olvashatók

Mi: amikor a MusicBee egy olyan eszközre játszik le, amely egy kombinált egységként mutatkozik be – egy Marantz vagy Denon streamer, ahol a lejátszó egy gyártói burkolatban található egy médiaszerver mellett –, a beépülő modul most már a lejátszó saját adatait olvassa be a médiaszerver adatai helyett.

Miért: korábban a készülék rossz felét kérdezte meg, hogy milyen audioformátumokat tud kezelni, nem kapott használható választ, és ellenőrzés nélkül folytatta – pontosan az a hardver, ahol a formátumkezelésnek a leginkább helyesnek kell lennie. Egy eszköz modellleírása most már figyelembe veszi az eszközprofilhoz való illesztéskor is; korábban rossz helyről olvasták be és elvetették.

2.0.3 - 2026-08-02

A „lejátszás ide” szerepkör felnő: a MusicBee-nek mostantól olyan zenét is lehet küldeni, ami még nincs a könyvtárában – egy fájlt a telefonjáról, egy NAS-ról, egy másik szerverről – ahelyett, hogy csak a már birtokában lévő számokat játszaná le.

Zenék lejátszása a telefonról, nem csak a saját könyvtárból

Mi: amikor egy vezérlő alkalmazást, például a Symfoniumot vagy a BubbleUPnP-t használja zene küldésére a MusicBee-nek, a számnak már nem kell a MusicBee saját könyvtárából származnia. Egy fájl, ami magán a telefonon, egy NAS-on vagy egy másik médiaszerveren van tárolva, mostantól lejátszható. A cím és a hossz az alkalmazásból származik, amelyik elküldte, így a szám megfelelően jelenik meg, annak ellenére, hogy a MusicBee még soha nem látta a fájlt.

Miért: a „lejátszás ide” szerepkör arra az esetre épült, amikor a telefonjáról böngészi ennek a PC-nek a könyvtárát, és megérint egy dalt – a szám már a PC-n volt, így a MusicBee egyszerűen lejátszotta a saját fájlját. Bármi, ami máshonnan érkezett, csendben el lett dobva, ami a funkciót hasznavehetetlenné tette a zene telefonról a jó hangszórókra való küldésének ugyanolyan természetes esetében.

Egy lejátszhatatlan szám jelzi, hogy nem játszható le

Mi: ha a renderelő valóban nem tudja lejátszani, amit küldtek neki, mostantól visszajelzi ezt az alkalmazásnak, amelyik elküldte.

Miért: korábban mindenre azt válaszolta, hogy „megkaptam”, így a vezérlő alkalmazás folytatta és megnyomta a lejátszást. Mivel semmi sem volt ténylegesen betöltve, a MusicBee újraindította azt a számot, ami korábbról maradt – és ha az a fájl eltűnt, panaszkodott, hogy annak forrása nem található. A hiba egy nem kapcsolódó számot nevezett meg, és sehol sem mutatott a valódi problémára.

Egy új szám küldése szüneteltetett állapotban mostantól lejátsza azt a számot

Mi: ha a MusicBee szüneteltetve van, és a vezérlő alkalmazása valami újat küld neki, az új szám elindul.

Miért: a folytatás elsőbbséget élvezett a betöltéssel szemben, így a szüneteltetett szám onnan folytatódott, ahol abbahagyta, és az éppen kiválasztott szám szó nélkül el lett dobva.

2.0.2 - 2026-08-01

A keresés a fő téma: most már előadó szerint is működik, a megfelelő találatokat adja vissza, és gyorsan működik nagy könyvtár esetén is. Emellett új módszerrel célozhatja meg a vezérlőalkalmazás véletlenszerű lejátszását, és javítva lett három gomb, amelyek korábban sehová sem vezettek.

Az előadó szerinti keresés ténylegesen működik

Mi: az előadó szerinti keresés a vezérlőalkalmazásból most már az adott előadó zenéit adja vissza. A keresés mind a szám előadóját, mind az album albumelőadóját figyelembe veszi, így egy válogatás akkor is megtalálható, ha az előadó nevét vagy az album címét írja be.

Miért: az előadó szerinti keresést korábban tévesen úgy értelmezték, hogy "adj meg mindent ebből a típusból" – az beírt előadó nevét figyelmen kívül hagyták, és a teljes könyvtár visszatért, így egy olyan keresés, amelynek néhány száz számot kellett volna találnia, több tízezret adott vissza. Ha csak a két előadó mező egyikét egyeztetné, az csendesen elveszítené a találatok felét, ezért mindkettőt ellenőrizzük.

A keresési eredmények oldal helyesen lapozható

Mi: a hosszú keresési eredmények listáján való görgetés most már végigviszi az oldalakon. Minden oldal, amire görget, az az oldal, amit megkap.

Miért: a szerver korábban minden kérésre az első néhány találattal válaszolt, miközben a teljes találatszámot jelentette, így egy további találatokra görgető alkalmazás ugyanazokat az elemeket kapta, és soha nem érte el a végét.

A keresés sokkal gyorsabb nagy könyvtár esetén

Mi: a keresés most egyetlen lekérdezést futtat a teljes eredményhalmazra, és csak annak az oldalnak a címkéit olvassa be, amit éppen néz.

Miért: korábban minden oldal újra lefuttatta a lekérdezést a könyvtár ellen, majd betöltötte az összes találat – több ezer – címkéit, hogy egy tucatot mutasson. Egy nagy gyűjtemény esetén ez minden görgetést megakasztott. Az eredmények a könyvtár frissítésekor is törlődnek, így egy szerkesztés soha nem kerül elavultan kiszolgálásra.

Célozza meg a véletlenszerű lejátszást egy szűrővel

Mi: egy új Véletlenszerű lejátszás innen beállítás a Könyvtárbeállítások lapon. Hagyja Minden zene beállításon, és a vezérlőalkalmazás Véletlenszerű számok / Véletlenszerű albumok mappái a korábbiak szerint viselkednek; válasszon ki egyet a MusicBee szűrői közül, és minden véletlenszerű kérés ehelyett abból a szűrőből fog meríteni. A rejtett szűrők is felajánlásra kerülnek.

Miért: egy véletlenszerű lejátszás mappa "mindent" kér, és ez az egyetlen kérés, amely nem tartalmaz semmilyen utalást arra, hogy mit értett – így mindig a teljes könyvtárból merített, beszélt szóval és mindennel együtt. Itt mondhatja meg, hogy mit jelent a "minden". Ha egy véletlenszerű lejátszás mappát egy szűrő belülről nyit meg az eszközön, az továbbra is azt a szűrőt fogja véletlenszerűen lejátszani: a böngészés közben hozott választás felülírja a beállítást.

A Súgó, a GitHub és a frissítésellenőrzés valós oldalakra vezet

Mi: a beállítások párbeszédpanelen található Súgó és GitHub gombok, valamint az új verzió automatikus ellenőrzése most már megnyitják az általuk megnevezett oldalakat.

Miért: mindhárom a beépülő modul nevének rövidített formájából épült fel, amelyen soha nem létezett oldal, így mindegyik csendesen meghiúsult – a gombok látszólag semmit sem tettek, és a frissítésellenőrzés soha nem jelentett semmit, függetlenül attól, hogy mennyi ideje jelent meg egy új verzió.

2.0.1 - 2026-07-26

A lejátszás és böngészés számos hibajavítása, a podcastokra és a lejátszást és keverést vezérlő vezérlőalkalmazásokra (például BubbleUPnP) összpontosítva.

A podcastok szünet nélkül indulnak el

Mi: egy letöltött podcast epizód mostantól előre megadja a valós hosszát és fájlméretét, közvetlenül a lemezen lévő fájlból a média metaadataiba kerülve.

Miért: megadott időtartam nélkül egy olyan vezérlő, mint a BubbleUPnP, minden lejátszás gombnyomásra újra átvizsgálja az egész hangfolyamot, csak azért, hogy kiderítse, milyen hosszú az epizód – így a lejátszás csak észrevehető szünet után indult el. Mivel a hossz most már hirdetve van, tisztán indul.

A podcastok megjelennek, ha előadó szerint böngészik

Mi: egy podcast műsorneve mostantól előadóként van iktatva – tükrözve az Előadó és Albumelőadó mezőkbe (és azok rendezési változataiba), pontosan úgy, ahogy már kitölti az Album mezőt.

Miért: egy böngészési útvonal, amely előadó mező szerint csoportosít, korábban minden podcast előadóját üresnek találta, és egy üres szinten zsákutcába futott. A műsor önmagának előadóként való kezelése – összhangban az albumként való kezelésével – azt jelenti, hogy ezek az útvonalak most már az epizódokhoz vezetnek a semmi helyett.

A „Legutóbb lejátszott” és a casting közvetlenül újraindítás után működik

Mi: egy podcast, hangoskönyv, beérkező üzenetek vagy rádiós szám közvetlen lejátszása – anélkül, hogy először rákeresnénk, ahogy a BubbleUPnP „Legutóbb lejátszott” listája és a cast célok teszik – már nem hibásodik meg. A beépülő modul mostantól igény szerint betölti a számot, amikor azt az azonosítója alapján kérik.

Miért: ezek a listák közvetlenül a MusicBee újraindítása után kérik a számot, mielőtt bármit is böngésztek volna, így a beépülő modul soha nem látta az azonosítót, és „Rossz azonosító” választ adott. Mostantól kényszerítetten betölti a releváns forrásokat az első közvetlen kérésre, és megtalálja a számot.

A „Véletlen számok” és a „Véletlen albumok” eredményeket adnak vissza

Mi: a BubbleUPnP „Véletlen számok” és „Véletlen albumok” keverési mappái, amelyek a teljes könyvtár véletlenszerű szeletét kérik, most már kitöltve térnek vissza.

Miért: ezek olyan keresések, amelyekhez nincs egyező cím, és a beépülő modul korábban egy üres belső listából válaszolt rájuk, így mindig semmit sem mutattak. Mostantól – helyesen lapozva – ugyanarról az igény szerinti lekérdezési útvonalról szolgálják ki őket, amelyet a böngészés többi része is használ.

Az üres címkével rendelkező albumok felsorolják a számaikat

Mi: egy olyan album megnyitása, amelyet üres érték alapján csoportosítottak – például beérkező üzenetek, amelyek nem tartalmaznak évet – mostantól megjeleníti a számait.

Miért: az album számait összegyűjtő egyezés az „ez a címke üres” kifejezést „nincs egyezés”-ként kezelte, így bármely üres mezőből képzett album semmit sem böngészett. Egy üres csoportérték mostantól helyesen egyezik a vele azonos számokkal.

2.0.0 - 2026-07-22

Ez a MusicBee UPnP beépülő modul nyílt forráskódú yaiol elágazásának első nyilvános kiadása. Két részből áll: minden, ami új ebben az elágazásban, majd az eredeti beépülő modul javításai és fejlesztései. Minden elem megtartja a projekt belső funkciókatalógusának Mi / Miért formáját, így minden változás mögötti indoklás is megjelenik az oldalon, nem csak maga a változás.

Újdonságok ebben az elágazásban

MediaRenderer - lejátszás MusicBee-re

N01 - MusicBee mint lejátszási cél

Mi: normális esetben ez a beépülő modul egyirányú: egy telefon vagy más eszköz böngészi a MusicBee könyvtárát és lejátssza a zenét saját magán. Ez a funkció hozzáadja az ellenkező irányt - lehetővé teszi, hogy a MusicBee legyen a lejátszó. A telefonon lévő vezérlő alkalmazásból (például BubbleUPnP) kiválaszthatja az asztali MusicBee-t lejátszási célként, majd onnan vezérelheti: lejátszás, szünet, leállítás, előre-hátra ugrás, ugrás egy pontra a számban, hangerő módosítása vagy némítás.

Miért: a telefonját távirányítóvá alakítja a már a számítógépén lévő zenékhez. Üljön le a kanapéra, böngéssze a könyvtárát a telefonján, koppintson egy számra, és az a számítógépéhez csatlakoztatott hangszórókból szólal meg - teljes vezérléssel onnan, ahol ül. Az eredeti beépülő modul soha nem szállította ezt működő funkcióként.

Bekapcsolás: alapértelmezetten ki van kapcsolva, mert bekapcsolása lehetővé teszi, hogy bármi az otthoni hálózatán elindítsa a lejátszást a számítógépén. A beállítások párbeszédpanel Általános lapján található jelölőnégyzet bejelölésével engedélyezheti. A beépülő modul három szerepkörének mindegyike saját jelölőnégyzettel rendelkezik ott - könyvtáram megosztása (Szerver), engedélyezze másoknak, hogy nekem játsszanak (Renderelő), és lejátszás más eszközökre (Vezérlőpont) - és a párbeszédpanel csak azokat a beállítási lapokat mutatja, amelyekre az engedélyezett szerepköröknek ténylegesen szükségük van, így soha nem szembesül olyan opciókkal, amelyek nem vonatkoznak Önre.

Gépek megkülönböztetése: a renderelőnek bármilyen nevet adhat (alapértelmezetten "MusicBee (yaiol)"). Ez a név jelenik meg a telefonján a lejátszási célok listájában, így ha több számítógépen is fut a MusicBee, meg tudja különböztetni, melyik melyik. A névváltoztatás azonnal életbe lép, újraindítás nélkül.

A lehető legjobb hangzás, amikor saját magának játszik le: amikor a telefonjáról böngészi a MusicBee saját könyvtárát, és egy számot visszaküld ugyanarra a MusicBee-re, a beépülő modul felismeri, hogy a saját fájljai közül kell lejátszania egyet, és egyszerűen közvetlenül a lemezről játssza le. Az eredmény pontos és azonnali - bit-tökéletes, a MusicBee saját hangszínszabályzójával és hangerő-kiegyenlítésével alkalmazva - ahelyett, hogy értelmetlenül a hálózatra, majd egyből vissza küldené a hangot.

Privát futtatás: a három szerepkör egymástól függetlenül működik, így bekapcsolhatja a renderelőt, miközben a könyvtármegosztást kikapcsolva hagyja. Ebben a "csak renderelő" beállításban a könyvtára teljesen rejtve marad a hálózat elől - csak a lejátszási cél kerül bejelentésre - és a MusicBee soha nem fogja felajánlani, hogy saját magának játsszon le.

Lejátszási viselkedés

N02 - 5.1 FLAC nem automatikusan lekeverve

Mi: a MediaServerDevice.GetEncodedFile csatornaszám-korlátja If StereoOnly OrElse Not isPcmData Then channelCount = 2 volt. A Not isPcmData záradék minden nem-PCM átkódolást (FLAC, MP3, AAC, Ogg) csendesen sztereóvá lekevert, függetlenül a forrás csatornaszámától, így az 5.1-képes renderelők nem működtek, ha a forrás 5.1 FLAC volt. Most a második záradék kizárja a FLAC-ot: Not isPcmData AndAlso encoder.Codec <> FileCodec.Flac. A FLAC 5.1 átmegy; az MP3/AAC/Ogg továbbra is sztereóra kényszerül, mert a MusicBee parancssori kódolói ezekhez a formátumokhoz 2 csatornás bemenetet várnak.

Miért: az 5.1 FLAC forrás FLAC kimenetre történő átkódolásának lényege a többcsatornás keverés megőrzése. A csendes lekeverés a FLAC átkódolási opciót használhatatlanná tette a térhatású hallgatáshoz. Az N02-vel a helyes dolgot teszi.

Architektúra

A strukturális változás, amely lehetővé teszi az elágazás életképességét egy nagy könyvtárban - hiányzik az eredeti beépülő modulból.

N03 - Lusta (igény szerinti) böngészési fa

Mi: az eredeti beépülő modul a teljes böngészési fát a MusicBee indításakor építette fel - minden szám felsorolása, teljes Library_GetFileTags fájlonként, a teljes tároló hierarchia összeállítása - mielőtt megnyitotta a HTTP portot. Egy valódi könyvtárban (50k+ szám, 5400 podcast epizód, több száz állomás) ez percekig tartó hidegindítást jelent, és a fa örökké a RAM-ban marad, beleértve azokat az ágakat is, amelyeket egyetlen kliens sem nyit meg. Ez az elágazás semmit sem épít előre: a gyökér egy L:-előtaggal ellátott helyőrzőt tesz közzé végpontonként (L:music, L:podcast, L:filter:…); minden szintet csak akkor számít ki, amikor egy kliens beleböngész (LazyBrowse → EnsureLazyEndpointInMemory → szintenkénti gyorsítótárak), és a könyvtárváltozási értesítések törlik a gyorsítótárakat (SetLibraryDirty).

Miért: a hidegindítás lényegében azonnali - a HTTP port nyitva van, mire a MusicBee befejezi a beépülő modul inicializálását - és a memória arányos marad a böngészett tartalommal, nem a könyvtár méretével. Kompromisszum: az első böngészés egy végpontba megfizeti a betöltési költségét; az újbóli belépés gyorsítótárazva van a következő könyvtárváltozásig. Ez az alapja mindennek, ami ezen múlik. Teljes jegyzetek: FIXES.md.

Hálózat és robusztusság

A HTTP szerver kötési útvonalának megerősítése. Az eredeti beépülő modul csendesen leáll, ha a portja nem elérhető.

N04 - Öngyógyító HTTP portkötés

Mi: a beépülő modul HTTP szervere már nem áll le, ha a konfigurált portja nem elérhető. Három kapcsolódó változás:

Automatikus visszaesés kötési hiba esetén. A HttpServer.Start megpróbálja a konfigurált portot, és SocketException esetén akár 20 portot is felfelé szkennel az első szabad portért. A ténylegesen kötött port egy új Plugin.boundServerPort mezőben kerül rögzítésre, és minden, ami a szervert hirdeti - SSDP LOCATION URL-ek (NOTIFY + M-SEARCH válasz), az eszköz URL-je (PrimaryHostUrl), a router port-forward, és az SSDP/vezérlőpont önszűrők - mostantól a boundServerPort értéket olvassa a Settings.ServerPort helyett. Az UPnP kliensek az SSDP-n keresztül fedezik fel a valódi portot, így a mozgatott port átlátszó a renderelők számára.
Felhasználói értesítés. Ha visszaesés történik (a mentett port nem az, ami használatban van), egy lokalizált MessageBox (WarnPortInUse) tájékoztatja a felhasználót, hogy melyik port szolgálja ki valójában, és hogy az eszközök továbbra is megtalálják - mert a beépülő modul fej nélküli módban fut, és egy párbeszédpanelen belüli üzenetet csak az látna, aki már gyanított valamilyen problémát.
Újraindítási helyreállítás. A RestartServer (a beállítások mentési újraindítási útvonala) korábban vakon dereferálta a Plugin.controller / Plugin.server objektumokat. Ha a kezdeti Initialise kivételt dobott, mielőtt létrehozta volna őket (pontosan ezt okozta egy sikertelen kötés), a következő beállításmentés NullReferenceException-t eredményezett - egy félig halott beépülő modult hagyva. Mostantól újra létrehozza és elindítja őket, ha Nothing, így egy működő port mentése újraéleszti a beépülő modult teljes MusicBee újraindítás nélkül.

Miért: a kiváltó ok egy valós felhasználói eset volt. A régi alapértelmezett 49382 port a Windows dinamikus tartományában (49152-65535) található, ahol a Hyper-V/WSL2/Docker/WinNAT nagy blokkokat foglal le, amelyek minden rendszerindításkor eltolódnak - így a kötés WSAEACCES ("hozzáférés megtagadva") hibával meghiúsult egy olyan gépen, ahol hónapokig működött. Az alapértelmezett érték szabad portra történő módosítása ezután ütközött a Serviio-val (egy külön DLNA szerverrel, amely már az új porton volt), WSAEADDRINUSE hibával meghiúsulva. Minden hiba elnyelődött az Initialise függvényben, csendesen halottá téve a beépülő modult, majd NRE-t okozva a következő beállításmentéskor. Az N04 után egy portütközés öngyógyul - a szerver a következő szabad porton tovább fut, a felhasználó értesítést kap, és a kliensek újra felfedezik - ahelyett, hogy az egész beépülő modult leállítaná.

Megvalósítás:

Az alapértelmezett port 49382 → 9779-re került (a dinamikus tartomány alatt, így a Windows soha nem foglalja le automatikusan; nem ismert médiaszerver alapértelmezett). Mindhárom ServerPort deklarációban + a beállítások elemzési hibájának visszaesésében.
Plugin.boundServerPort (új megosztott mező) tárolja az élő figyelő portot; az activeServerPort marad a konfigurált pillanatkép, így a "Újraindítás szükséges" jelvény logikája nem tévesen aktiválódik visszaesés esetén.
HttpServer.PortScanRange = 20; a szkennelés az első sikeres TcpListener.Start() hívásnál leáll, és csak akkor dobja az utolsó kivételt, ha minden próbálkozás sikertelen.
Új EN erőforráskulcs WarnPortInUse (a fordítások a közzétételi időpont lokalizációs lépését követik).

N05 - SSDP bejelentések a multicast csoporton keresztül (VPN / pont-pont)

Mi: az SSDP bejelentések az UPnP multicast csoportnak (239.255.255.250) kerülnek elküldésre IP broadcast cím helyett. A "nem fér hozzá egy eldobott objektumhoz" ártalmatlan hibaüzenet, amely akkor jelentkezik, amikor egy SSDP keresési válasz versenyez egy szerver újraindításával, szintén elnyomásra kerül.

Miért: pont-pont / VPN hálózati adaptereken az IP broadcast nem alkalmazható - a régi broadcast küldés "érvénytelen argumentum" hibával meghiúsult, és a bejelentések elmaradtak, így a beépülő modul láthatatlan volt az ezeken a linkeken lévő kliensek számára. A megfelelő multicast csoportnak történő bejelentés pontosan ezeken az adaptereken javítja a felfedezést.

Könyvtár navigáció

Ezek ebben az elágazásban kerültek szállításra, és nem szerepelnek az eredeti beépülő modulban. Valódi UPnP kliensekből böngészve a beépülő modul saját kimenetét.

N06 - Szűrő alapú könyvtár expozíció

Mi: a MusicBee szűrőfülei (a felhasználó MusicBee mappájában lévő .xautopf fájlok) UPnP gyökérkonténerekké válnak a beépülő modul könyvtárában. Minden szűrő számai ezután böngészhetők egy AlbumArtistSort → Album → Tracks hierarchiában.

Miért: a kurált MusicBee szűrőkkel rendelkező felhasználók (pl. "5 csillagos számok", "Nemrég hozzáadottak", "Klasszikus → Barokk") elvárják, hogy megtalálják őket, amikor egy UPnP kliensből böngészik a beépülő modult. Az eredeti beépülő modul csak a nyers könyvtárfát tette közzé.

N07 - `SortAlbumArtist` mező bekötése

Mi: a beépülő modul mostantól olvassa a MusicBee MetaDataType 165 (Sort Album Artist) mezőjét, és azt használja az előadók csoportosítására/rendezésére a böngészési nézetekben.

Miért: a hi-fi böngészők és az audiofilek rendezési előadóneveket ("Beethoven, Ludwig van" a "Ludwig van Beethoven" helyett) használnak a könyvtárak rendszerezésére. Standard elvárás a komoly hallgatók számára. Hiányzik mindkét upstreamből.

N08 - Többértékű AlbumArtist kezelés

Mi: ha egy album AlbumArtist mezője több előadót tartalmaz "; " elválasztóval (pl. "yaiol; Ars Ricercata"), a szám mostantól minden előadó alatt megjelenik a böngészési nézetekben, nem pedig egyetlen Frankenstein előadó alatt, amely kombinálja a neveket.

Miért: a kollaboratív albumoknak és válogatásoknak minden közreműködő alatt meg kell jelenniük. Enélkül az album megtalálásához vezető keresési útvonalak fele hibás.

N09 - Albumkonténer borító (`upnp:albumArtURI`)

Mi: a DIDL Browse válaszokban az albumkonténer csomópontok mostantól tartalmaznak egy upnp:albumArtURI elemet, amely az album borítójára mutat.

Miért: enélkül egy UPnP kliens böngészési nézetében minden album egy általános ikont mutatna az album borítója helyett. Vizuális jel a navigációhoz; minden modern hi-fi böngésző elvárja.

N10 - Számok sorrendje a szűrőalbumokon belül

Mi: a szűrővel közzétett albumon belüli számok mostantól lemezszám, majd számszám szerint vannak rendezve.

Miért: standard albumsorrend. Explicit rendezés nélkül a számok abban a sorrendben jöttek vissza, ahogyan a szűrő éppen visszaadta őket - általában véletlenszerűnek tűntek.

N11 - Lejátszási lista mappa fa javítása

Mi: a LoadLibraryPlaylists függvény (eredetileg Steven Mayall, ~2014) nem tudott belépni az újonnan létrehozott lejátszási lista mappákba. Minden mappa első lejátszási listája, plusz az esetleges almappák, a gyökérszinten árván maradtak.

Miért: tizenegy éve jelen van az eredeti beépülő modulban. Látható volt 30 másodpercen belül a BubbleUPnP megnyitása és a Lejátszási listákra kattintás után. Javítva a yaiolban az újonnan létrehozott mappákba való helyes rekurzióval a fa felépítése során.

N12 - XML-ben illegális vezérlőkarakterek szanálása

Mi: bármely olyan szám, amely C0 vezérlőkaraktert tartalmazó címkét tartalmazott (pl. 0x19 egy rossz kódolási lépésből - UTF-8 → Latin-1 → vissza, 0x99 levágása 0x19-re), az egész Browse válasz Action Failed hibával meghiúsult, amint a rossz szám bekerült egy lapozott kötegbe.

Miért: az XML 1.0 tiltja a legtöbb C0 vezérlőkaraktert, és az XmlWriter kivételt dob, ha ilyet kell írnia. Jelen volt az eredeti beépülő modulban. Javítva az érvénytelen karakterek eltávolításával minden Library_GetFileTags kilépési ponton keresztül az XmlConvert.IsXmlChar segítségével.

N13 - Rádiólista determinisztikus a lapozott böngészés során

Mi: a Rádió konténer böngészése a generikus fájllista ágba esett, amely minden híváskor meghívta a files.Sort(AlbumFileComparer) függvényt. A rádióbejegyzések üres Album/Lemez/Szám címkékkel rendelkeznek, így minden összehasonlítás 0-t adott vissza - a List(Of T).Sort instabil, minden meghíváskor más sorrendet produkálva. Az UPnP vezérlőpontok lapoznak (a BubbleUPnP 0..15-öt, majd 16..végét kéri le); a két hívás között a lista átrendeződött, így egyes állomások mindkét oldalon megjelentek (duplikátumok), mások pedig egyikben sem (hiányzóak) - minden frissítéskor véletlenszerűnek tűnt.

Miért: jelen volt az eredeti beépülő modulban (szerzője soha nem böngészett rádiót UPnP-n keresztül). Itt javítva egy dedikált ContainerCategory.Radio ággal a Browse függvényben, hívásonkénti rendezés nélkül; a radioFiles egyszer, betöltéskor rendeződik Cím szerint (stabil). A lapozott böngészés most determinisztikus sorrendet lát; az 1. és 2. oldal diszjunkt.

N14 - UPnP keresés albumosztályú lekérdezések albumkonténereket adnak vissza

Mi: az UPnP keresés albumosztályú lekérdezésekre (upnp:class = "object.container.album.musicAlbum", pl. a BubbleUPnP "Véletlenszerű albumok") a teljes számlistát adták vissza albumkonténerek helyett, így a kliens nulla albumot mutatott. Az eredeti kezelő csak a zárójelezett kritériumokat elemezte, majd az összes számot kiadta a kért osztálytól függetlenül.

Miért: itt javítva - az albumosztályú lekérdezések mostantól különálló albumokat sorolnak fel (AlbumArtist+Album szerint csoportosítva), és mindegyiket megfelelő musicAlbum konténerként adják ki borítóképpel, a Salb<idx> virtuális-ID térben címezhetően, így a kliens belefúrhat egy eredménybe és lejátszhatja azt.

N15 - Működő, hatókör-tudatos UPnP keresés kattintással

Mi: az eredeti nem hirdetett keresési képességeket (GetSearchCapabilities üreset adott vissza), így a kliensek még keresést sem voltak hajlandóak küldeni; a régi háttérrendszer pedig a musicFiles fájlból olvasott, amely a lusta fa korszakában tartósan üres volt. Ez az elágazás hirdeti a valódi kereshető tulajdonságokat, implementálja a számok-cím-szerinti és albumok-cím-szerinti keresést a lusta könyvtár ellen (HandleLazySearch), hatókörbe helyezi a lekérdezést a kliens aktuális ágára, ha valódi konténerazonosító kerül elküldésre (egyébként L:music-ra helyettesít, így a felső sávos keresések nem húzzák be a podcast/rádió/hangoskönyv zajt), és az album eredményeket kattinthatóvá teszi szintetikus Ssrch_alb_* azonosítókon keresztül, amelyeket egy Browse korai ág visszafordít az album számaira. (Az albumosztályú eredmények konténerként való megjelenítése az N14.)

Miért: a BubbleUPnP keresése a "A könyvtár nem támogatja a keresést" üzenetről hasznos, hatókörbe helyezett, lejátszható eredmények visszaadására váltott. Teljes tervezés + elutasított megközelítések: SEARCH.md.

N16 - UPnP gyorsítótár érvénytelenítése (`SystemUpdateID`)

Mi: az eredeti állandó SystemUpdateID=0 értéket adott vissza - az UPnP ContentDirectory gyorsítótár-érvénytelenítési szerződését -, így a specifikációnak megfelelő kliensek (BubbleUPnP) soha nem változónak tekintették a könyvtárat: elavult böngészési eredmények, 404-es miniatűrök URL-séma változás után, és a "kétszer indítsa újra a MusicBee-t a változások megtekintéséhez" tánc. Ez az elágazás a SystemUpdateID-t epoch-másodpercekből inicializálja betöltéskor (így minden újraindítás szigorúan megelőzi az előzőt), és minden könyvtárváltozás és beállításmódosítás esetén növeli (SetLibraryDirty / ResetCache → BumpSystemUpdateId).

Miért: a kliensek megbízhatóan felveszik a szerkesztéseket, új fájlokat és beállításváltozásokat a következő böngészésükkor. Ismert korlát: az előfizetett kliensek nem kapják meg aktívan az új értéket GENA-n keresztül (jövőbeli feladatként parkoltatva); továbbra is látják a következő böngészésükkor.

N17 - Podcast előfizetés borítója

Mi: a podcast csempék nem mutattak képeket - minden /PodcastThumbnail/ kérés 404-es hibát adott. Két egymásra rakott hiba: a feloldási lánc soha nem ellenőrizte a MusicBee tényleges borítókép gyorsítótárát (%LocalAppData%\MusicBee\InternalCache\Subscriptions\<name>.jpg, ahonnan az asztali felhasználói felület betölt), és a HTTP réteg unescape+kisbetűsítése a feed-URL útvonalkulcsot az utolsó útvonalszegmenséig elrontotta. Ez az elágazás a borítóképeket az MB InternalCache-ből oldja fel, és a kereséseket egy URL-biztos slugon keresztül irányítja, amely sértetlenül túléli a HTTP réteget (PodcastSlug / podcastSubIdBySlug).

Miért: az előfizetés borítója mostantól megjelenik a böngészési nézetekben (mind a 22 korábban 404-es hibát adó kérés feloldódik).

N18 - Hierarchikus (elválasztott) címkeböngészés

Mi: bármely mező megjelölhető hierarchikusnak a Könyvtárbeállítások lapon, és adható neki egy egykarakteres elválasztó (egy mezőválasztó + elválasztó doboz hozzáadás/eltávolítás funkcióval, amely a beépülő modul beállításaiban marad). Ha a Csoportosítás értéke / és egy érték, mint Jazz/Cool Jazz, akkor az Jazz › Cool Jazz néven böngészhető egyetlen lapos bejegyzés helyett. Azok a számok, amelyek pontosan egy ágon vannak címkézve (csak Jazz), saját [Jazz] csomópontot kapnak, így semmi sem marad rejtve, egyetlen gyermekkel rendelkező ág önmagában összeomlik, és a ; elutasításra kerül elválasztóként, mert az a MusicBee saját többértékű elválasztója.

Miért: a felhasználó által már egyetlen mezőbe kódolt mély címke-taxonómiák (műfaji fák, hangulati hierarchiák, "Klasszikus/Barokk/Concerto") végre úgy böngészhetők, mint a címke által leírt fa, ahelyett, hogy egy lapos, perjelekkel elválasztott karakterláncok falát kellene végigolvasnia a felhasználónak.

N19 - Egyetlen gyökérútvonal, csoportosító mezővel címkézve

Mi: egyetlen böngészési útvonal a gyökérnél a csoportosító mezőjével (pl. "Műfaj") van címkézve, nem pedig a teljes rövid útvonalával, ami megegyezik azzal, ahogyan az egyesített első mezőcsoportok elnevezésre kerülnek.

Miért: a böngészési fa konzisztensen olvasható - egy elnevezési szabály, függetlenül attól, hogy egy gyökérbejegyzés önállóan áll, vagy egyesült a testvérekkel (N20) - ahelyett, hogy egy magányos gyökérbejegyzés részletes belső útvonalat mutatna, miközben a szomszédjai tiszta mezőnevet mutatnak.

N20 - Első mezőn osztozó böngészési útvonalak egyesítése

Mi: két böngészési útvonal, amelyek ugyanazon az első mezőn osztoznak - "Műfaj / Albumelőadó rendezése" és "Műfaj / Podcast személyek" - egyetlen Műfaj gyökérmappába omlanak össze, amely először a műfaji értékeket sorolja fel, majd két nézetre oszlik, ahelyett, hogy két majdnem azonos "Műfaj / ..." bejegyzés lenne egymás mellett a gyökérnél.

Miért: egy felhasználó, akinek több kapcsolódó nézete volt egy közös mező alá ágyazva, azt látta, hogy a gyökér tele van majdnem azonos felső szintű bejegyzésekkel. Az egyesítés olvashatóvá teszi a gyökeret, és a kapcsolódó nézeteket oda csoportosítja, ahová tartoznak - a közös mezőjük alá.

N21 - Kategória-típusú böngészési útvonalak (Standard / Rádió / Podcast)

Mi: minden böngészési útvonal kategória szerint van típusozva - Standard, Rádió vagy Podcast. A sablonlista ebbe a három szakaszba van csoportosítva, minden sablon mezőválasztója csak azokat a mezőket kínálja, amelyeket az adott kategória adatai ténylegesen szolgáltatni tudnak, és egy sablon csak a Nézet fában lévő megfelelő csomópontokra alkalmazható (az inkompatibilis csomópontok szürkén jelennek meg és nem jelölhetők be). A fenntartott Rádió és Podcast sablonok nem törölhetők, így a kategória szakaszuk soha nem tűnik el.

Miért: a típusozás nélkül a felhasználó olyan elrendezést hozhatna létre, amely csendesen üresen jelenik meg - egy rádióállomásnak nincs "albuma", egy podcast epizódnak nincs "albumelőadója" - és csak úgy fedezné fel, hogy egy UPnP kliensből egy halott mappába böngészik. A mezőmenü és az alkalmazási célok korlátozása a kategória valós adataira megakadályozza az üres elrendezések létrehozását.

N22 - Podcastok csoportosítása megjelenési év szerint

Mi: minden podcast epizód megjelenési dátuma beolvasásra kerül, így egy évszintű podcast böngészési útvonal az epizódokat év szerint csoportosítja, ahelyett, hogy egyetlen "Ismeretlen" alá omlana össze.

Miért: a nagy podcast előfizetések év szerint navigálhatóvá válnak, mint a könyvtár többi része, ahelyett, hogy minden epizód egyetlen dátum nélküli halomba kerülne, mert a beépülő modul soha nem nézte meg az epizódonkénti megjelenési dátumot.

N23 - Egyetlen eredményt adó csoportosítási szintek összevonása

Mi: egyetlen értékre feloldódó csoportosítási szint - egy lemeztípus szint, amely csak "LP"-t mutat egy olyan előadó számára, aki csak LP-ket készített, vagy egy betűszint egyetlen betűvel - automatikusan átugrásra kerül, egyenesen a tartalmába juttatva a felhasználót.

Miért: egy olyan mappán keresztül böngészni, amely pontosan egy mappát tartalmaz, tiszta súrlódás. Az egyetlen választási szint összevonása eltávolítja a holt kattintást anélkül, hogy megváltoztatná, amit a felhasználó elérhet.

N24 - Év csoportosítás/keresés a MusicBee dátummezője alapján

Mi: az év feltétel már nem kérdezi le a MusicBee teljes dátum "Év" mezőjét egy puszta négyjegyű értékkel, és a keménykódolt évmező aliasozás megszűnt, így minden csoportosítási mező mostantól általánosan feloldódik az útvonaldefinícióból.

Miért: azoknál a könyvtáraknál, amelyek Év címkéje teljes dátumot tartalmaz, az év szerinti csoportosítás vagy keresés korábban semmit sem adott vissza - a négyjegyű lekérdezés soha nem egyezett a teljes dátum mezővel. A megfelelő mező lekérdezése újra megtalálja a számokat az év szerinti csoportosítás és keresés során.

N25 - Külön "Év" és "Év (éééé)" csoportosítási mezők

Mi: az album csoportosítási és böngészési útvonalak mostantól a MusicBee saját év mezőit is közzéteszik - Év (a teljes dátum címke) és Év (éééé) (csak a négyjegyű év) - így a felhasználó választhatja bármelyiket, amikor album csoportosítást vagy böngészési útvonalat definiál.

Miért: a két mező különböző dolgokat jelent a MusicBee-ben, és összevonásuk elvesztette ezt a különbséget. Mindkettő megjelenítése lehetővé teszi a felhasználó számára, hogy egy év összes kiadását összegyűjtse (éééé) vagy megtartsa a pontos dátum szerinti sorrendet (teljes Év címke), ahogyan azt szándékozza.

N32 - Rögzített szűrők és lejátszási listák típus szerint csoportosítva a gyökérnél

Mi: egy rögzített szűrő mostantól közvetlenül a Szűrők mappa alatt jelenik meg a böngészési gyökérnél, és egy rögzített lejátszási lista közvetlenül a Lejátszási listák mappa alatt, ahelyett, hogy az összes rögzített elem egy csomóba gyűlne a gyökér végén. Minden rögzített parancsikon a saját típusával együtt helyezkedik el.

Miért: ahogy a felhasználó több parancsikont rögzít, a vegyes szűrők és lejátszási listák egyetlen, utolsó csomója nehezebben áttekinthetővé válik, és minden parancsikont elválaszt attól a mappától, amelyhez tartozik. A rögzített elemek saját kategóriájuk alá csoportosítása olvashatóvá teszi a gyökeret, és minden parancsikont a hozzá tartozó dolgok mellé helyezi.

Beállítások párbeszédpanel és csomagolás

N26 - Szakaszolt beállítások párbeszédpanel

Mi: a Beállítások oldal bal oldali navigációs elrendezést kapott szakaszokkal: Általános / Lejátszás / Könyvtár / Eszközprofilok / Diagnosztika.

Miért: az eredeti egyetlen hosszú, lapos lista volt minden beállításról - rendben volt a fejlesztőnek, aki építette, de zavaró volt mindenki másnak. A szakaszolás csoportosítja a kapcsolódó opciókat, és a párbeszédpanelt modernebb alkalmazásbeállításokhoz hasonlóvá teszi.

Összeállítás + beépülő modul átnevezése (nincs F-azonosító - csomagolási megjegyzés)

Mi: a lefordított DLL neve mb_UPnP_yaiol.dll, és a beépülő modul "MusicBee UPnP (yaiol)" néven jelenti magát. Különbözik az eredeti mb_Upnp.dll-től.

Miért: a felhasználók telepíthetik a yaiol-t az eredeti beépülő modul mellé, és összehasonlíthatják a viselkedést egymás mellett.

Jelvényrendszer - futásidejű állapot megjelenítése (az F40 mögötti mechanizmus)

Mi: egy általános felhasználói felületi minta a fontos futásidejű feltételek látható, színes jelvényekként való megjelenítésére a Beállítások párbeszédpanelen. Jelenlegi példák:

⚠ Max Conn (N04) - akkor aktiválódik, ha a maximális kapcsolatok korlátja legalább egyszer elérte a MusicBee indítása óta. Ragaszkodó munkamenet jelző Plugin.MaxConnectionsHit. Beállítva a WaitOnSendBarrier függvényben, ha nincs szabad hely.
⚠ Újraindítás szükséges - akkor aktiválódik, ha egy mentett beállítás MusicBee újraindítást igényel az érvényesüléshez. Ragaszkodó munkamenet jelző Plugin.RestartRequired. Beállítva a párbeszédpanel Mentés kezelőjében, ha az új tartósított érték eltér a futásidejű pillanatképtől (Plugin.activeMaxConnections, Plugin.activeServerPort, Plugin.activeIpAddress). Az újraindítást igénylő beállítások azokra korlátozódnak, amelyek valóban nem tudnak hot-reload-ot - HTTP szerver kötési paraméterek és a SemaphoreSlim, amely egyszer az Initialise-ben épül fel.

Miért: a beépülő modul naplófájlja rendben van a technikai felhasználók hibakereséséhez, de egy nem technikai felhasználó, aki "az eszköz rosszul szól" vagy "a lejátszás lassú" problémával szembesül, soha nem fogja megnyitni a Diagnosztika → Napló megtekintése menüpontot. A jelvények rögzítik azokat az eseteket, amikor a felhasználónak tudnia kell, hogy valami történt, és megjelenítik azt a következő alkalommal, amikor megnyitja a beépülő modult - felfedezhető anélkül, hogy bármit is olvasna.

Jövőbeli felhasználásra újrahasználható:

Profil eltérés észlelve (az eszköz felhasználói ügynöke soha nem egyezett egyetlen profillal sem, visszaesett a Generikusra).
NextURI visszalépés aktiválódott (F13 - a résmentes lejátszás letiltva a munkamenetre egy hibás eszközön).
Könyvtár szkennelés sikertelen / részleges.
Renderelő kapcsolat elveszett a munkamenet közepén.
Bármely más feltétel, ahol "egyszer megtörtént, a felhasználónak tudnia kell" jobb, mint "csendesen naplózva 1000 másik sor között".

Megvalósítási konvenciók:

A jelvénycímkék a párbeszédpanel szintjén élnek (nem bármely panelen belül), így láthatók, függetlenül attól, hogy a felhasználó melyik szakaszon van.
Az alsó sor mentén helyezkednek el a Mentés/Mégse gombok közelében (jelenlegi: y=410 vízszintesen egymásra rakva).
Minden jelvénynek van egy megfelelő ragaszkodó munkamenet jelzője a Plugin osztályban, amely Igazra vált, amikor a feltétel bekövetkezik, és csak a MusicBee újraindításakor áll vissza.
Erőforrások: <Feltétel>Jelvény (címkeszöveg, ⚠ előtaggal) + <Feltétel>JelvényTipp (eszköztipp, amely elmagyarázza az okot + a megoldást).
A "mentett beállítás újraindítást igényel" jelvényekhez készítsen futásidejű pillanatképet a Plugin.Initialise() függvényben, és hasonlítsa össze a Settings.* értékekkel a Settings.SaveSettings() után a párbeszédpanel Mentés kezelőjében.

N27 - A Mégse gomb elveti az útvonal-/sablonmódosításokat

Mi: a beállítások párbeszédpanelen az útvonalakon és sablonokon végrehajtott szerkesztések mostantól elvetésre kerülnek, amikor a felhasználó a Mégse gombra kattint, ahelyett, hogy csendesen alkalmazva maradnának, és minden, a munkamenet során eltávolított fenntartott sablon újra létrehozásra kerül. (A sablonok egyébként élőben mentődnek, ahogy szerkesztik őket - nincs külön Mentés gomb az Útvonalak lapon.)

Miért: a Mégse gombnak azt kellene jelentenie, hogy mégse. Korábban egy felhasználó, aki útvonal-/sablonmódosításokkal kísérletezett, és visszavonta azokat, azt tapasztalta, hogy a változtatások már véglegesítve vannak, és nincs mód azok visszavonására, kivéve, ha mindegyiket kézzel újra megteszi.

N28 - Szó szerinti ampersandok a mezőválasztó menüben

Mi: egy olyan mező, amelynek neve "&" karaktert tartalmaz - pl. "Hangulat & Kontextus" - szó szerint jeleníti meg az ampersandot a mezőválasztó menüben, ahelyett, hogy Alt-mnemonic előtagként elnyelné.

Miért: az ampersandot tartalmazó mezőnevek hibásan jelentek meg (a karakter eltűnt, és a következő betű gyorsítóvá vált), ami megnehezítette a menübejegyzés felismerését.

N29 - Stabil, fordítatlan beállítások ablak címe

Mi: a beállítások ablak címe rögzítve van a "MusicBee UPnP Plugin" márkanevű karakterlánchoz, és már nem változik az interfész nyelvével; a nyelvenkénti DialogTitle karakterlánc minden lokalizációs csomagból el lett távolítva.

Miért: egy ablakcím, amely nyelvenként változott, egy fordítható felület volt, haszon nélkül - a cím egy márkajelzés. A rögzítése stabil és konzisztens marad mindenhol.

Lokalizáció

Az eredeti beépülő modul csak angol nyelvű. Ez az elágazás teljesen lokalizálható - minden felhasználó felé irányuló karakterlánc egy erőforráscsomagon keresztül áramlik, és a beépülő modul automatikusan felismeri a MusicBee saját felhasználói felületének nyelvét.

N30 - Többnyelvű felhasználói felület (fordítások függőben)

Mi: a lokalizációs mechanizmus teljes és szállítva van. A Localisation.vb beolvassa a MusicBee kiválasztott nyelvét a MusicBee3Settings.ini fájlból (<SystemLanguage> endonim) és alkalmazza a megfelelő .NET kultúrát a szálra, így a My.Resources.Resources.* a lokalizált karakterláncot adja vissza. Minden felhasználó felé irányuló címke/gomb/üzenet egy erőforráskulcshoz van bekötve (tervezői vezérlők az ApplyDesignerExtras + sync-en-locale.js segítségével; futásidejű karakterláncok, mint a WarnPortInUse kézzel hozzáadva). Ami nem készült el még, az a tényleges fordítás: csak az angol forráscsomag (Resources.resx) létezik - a többi nyelvhez tartozó műholdas csomagok egyetlen kötegelt lépésben készülnek el, amikor a beépülő modul funkcionálisan teljes (a részleges fordítás, miközben a karakterláncok még változnak, felesleges erőfeszítés).

Célnyelvek (a MusicBee által kínált készlet, 1:1-ben egyezik az endonymToCulture függvénnyel, így a beépülő modul automatikusan követi a MusicBee nyelvét):


Arab (`ar`)	Cseh (`cs`)	Német (`de`)	Görög (`el`)
Spanyol (`es`)	Francia (`fr`)	Magyar (`hu`)	Olasz (`it`)
Koreai (`ko`)	Holland (`nl`)	Norvég (`nb`)	Lengyel (`pl`)
Portugál BR (`pt-BR`)	Portugál PT (`pt-PT`)	Svéd (`sv`)	Török (`tr`)
Ukrán (`uk`)	Orosz (`ru`)	Japán (`ja`)	Egyszerűsített kínai (`zh-CN`)
Hagyományos kínai (`zh-TW`)	Angol (`en`, forrás)

Változatpolitika (a munkaterület lokalizációs szabálya szerint): a PT és ZH külön csomagokra vannak osztva, mert a szókincs/írásmód valóban eltér (pt-BR/pt-PT, zh-CN/zh-TW). Az EN egyetlen csomag - a MusicBee "English(US)" (en-US) a .NET kultúraláncán keresztül visszaesik az en-re, így nem készül külön US csomag. Az ES és FR szintén egyetlen lokalizációjú.

Miért: egy UPnP beépülő modul beállításai ("ne használjon nyers PCM-et", "kényszerítse a little-endian PCM-et", port-visszaesési figyelmeztetések) elég rejtélyesek az anyanyelven is. A MusicBee saját felhasználói felületének nyelvének követése - ahelyett, hogy angolra kényszerítené - a különbség egy olyan eszköz között, amelyet egy nem angol anyanyelvű felhasználó konfigurálni tud, és egy olyan között, amelyet nem. Egyik upstream sem próbálkozott ezzel.

N31 - A súgó link a teljes felület nyelvén nyílik meg

Mi: a súgó link megnyitása a beépülő modulból tiszteletben tartja a felhasználó teljes felületének nyelvét (pl. pt-BR, zh-CN) az alapnyelvre való összeomlás helyett, és tisztább frissítésellenőrző azonosítót küld.

Miért: egy regionális változatban (brazíliai portugál, egyszerűsített kínai) futó MusicBee felhasználó az alapnyelvű súgóoldalra került. A teljes kultúra átvitele a pontosan használt nyelvű súgóoldalra juttatja őket.

Javítások és fejlesztések az eredeti beépülő modulon

Core protokoll és lejátszás

F01 - Frissített alapértelmezett DLNA eszközprofilok

Mi: friss alapértelmezett profilokat szállít a PlayStation 4, Xbox 360/One és a modern BubbleUPnP számára, olyan képességjelzőkkel (mintavételezési sebességek, bitmélységek, kodekek), amelyek tükrözik, hogy ezek az eszközök ma valójában mit támogatnak.

Miért: az eredeti beépülő modul alapértelmezett beállításai 2014 körül megfagytak. A PS4/Xbox/BubbleUPnP azóta hi-res audio támogatást kapott. A dobozból kivéve egy új telepítés a legjobb minőségben játszik ezeken az eszközökön anélkül, hogy a felhasználónak hozzá kellene nyúlnia az eszközprofil beállításaihoz.

F02 - `MediaRenderer:3` hirdető vezérlőeszközök

Mi: a beépülő modul lekérdezi egy renderelő UPnP szolgáltatásleírását, hogy eldöntse, a MusicBee képes-e vezérelni azt. Az eredeti csak a urn:schemas-upnp-org:device:MediaRenderer:1 értékre illeszkedett. A modern eszközök :2 vagy :3 értékeket hirdetnek. Az F02 szélesíti az illesztést.

Miért: enélkül a legújabb Sonos / WiiM / Eversolo egységek egyszerűen nem jelennek meg célként a MusicBee "Lejátszás ide" eszközlistájában - annak ellenére, hogy ugyanazt a protokollt beszélik. Egyetlen karakterlánc-előtag illesztési javítás feloldja a teljes modern eszközgenerációt.

F03 - "Nyers adatfolyam kényszerítése" profilonkénti opció (alapértelmezetten BE)

Mi: ha be van jelölve, a beépülő modul az eredeti fájlbájtokat küldi az eszközre átkódolás, DSP, ReplayGain feldolgozás nélkül. Csak a felhasználó által kiválasztott nyers fájl, bájt-bájtonként (HTTP keretezés kivételével).

Miért: a fórumok tanúsága szerint ez a legnagyobb lejátszási minőségbeli nyereség. A hi-fi felhasználók, akik drága renderelőket vásárolnak, kifejezetten bit-tökéletes kimenetet akarnak; bármilyen DSP beavatkozás meghiúsítja a célt. Alapértelmezetten BE, mert a legtöbb modern eszköz kezeli bármilyen kodeket, amit a felhasználó rájuk dobott, és a ReplayGain/EQ-nak opt-in-nek kell lennie. Profilonként állítható, így megtarthatja az átkódolást egy régi Xbox számára, miközben natív adatfolyamot küld egy hi-fi DAC-nak.

F04 - "Átkódolás kényszerítése" profilonként

Mi: profilonkénti felülbírálás, amely minden adatfolyamot ezen az eszközön keresztül kényszerít az átkódolóba, függetlenül a natív kodek támogatásától. Az F03 (Nyers adatfolyam kényszerítése) inverze. Kölcsönösen kizárja egymást az F03-mal - a felhasználói felület automatikusan kikapcsolja a másikat, ha az egyik be van kapcsolva.

Miért: egyetlen globális kapcsoló ellentmondásos lenne a profilonkénti Nyers adatfolyam kényszerítése (F03) funkcióval. Valós eset: A eszköz egy hi-fi DAC, amely bit-tökéletes natív adatfolyamokat szeretne; B eszköz egy régi AV vevő, amely FLAC-on megfullad. Globális kapcsolóval a felhasználónak választania kell - a másik eszköz rovására. Profilonként mindkét eszköz a helyes választ kapja.

Megvalósítás:

StreamingProfile.ForceTranscoding As Boolean = False.
A perzisztencia séma v9-re emelkedett. A v9 előtti fájlok egyszer betöltik a régi globális értéket, és átmásolják azt az összes profilba, megőrizve a régi viselkedést a frissítés során.
Felhasználói felület: eltávolítva a Diagnosztika panelről, hozzáadva az Eszközprofilok szakaszhoz a ForceNativeStream mellé. Kétirányú kölcsönös kizárási kezelők (CheckedChanged mindegyiken leiratkozik a másikról, mielőtt átbillentené, hogy elkerülje a végtelen ciklust).
Döntési hely: Settings.ForceTranscoding → streamingProfile.ForceTranscoding a WriteAudioFileDIDL függvényben.

F05 - "Little-endian PCM kényszerítése" profilonként

Mi: a PCM adatfolyamok (L16/L24 mime típusok) specifikáció szerint big-endianek. Egyes eszközök tévesen little-endiant várnak, és fehér zajt játszanak le, ha megfelelő big-endian adatokat kapnak. Az F05 profilonként váltja a bájt sorrendet.

Miért: enélkül bizonyos eszközök statikus falat adnak ki. A tünet drámai, és az ok láthatatlan a PCM kódolás ismerete nélkül - a kapcsoló lehetőséget ad a felhasználóknak egy találgatásos javításra.

F06 - "Ne használjon nyers PCM-et" profilonként

Mi: amikor az eszköz azt állítja, hogy támogatja a nyers PCM-et, a beépülő modul azt használja. Egyes eszközök hazudnak - elfogadják a SOAP kézfogást, de elrontják a tényleges nyers PCM adatokat, miközben megfelelően kezelik a WAVE konténerbe csomagolt PCM-et. Az F06 kényszeríti a PCM-over-Wave-et, függetlenül attól, hogy az eszköz mit hirdet.

Miért: bizonyos Marantz modellek kifejezetten - nyers PCM-et hirdetnek, de csak a WAVE működik. Enélkül a nyers PCM adatfolyamok torzultan jönnek ki, hibaüzenet nélkül.

F07 - "Tartalom hossza" profilonként

Mi: milyen értéket küldjön a HTTP Content-Length fejlécben. Négy lehetőség:

Alapértelmezett - tényleges bájtmennyiség, ha ismert, kihagyja, ha ismeretlen.
Nincs - soha ne küldje el a fejlécet (csak chunked encoding).
Csak PCM - csak nyers PCM esetén küldje el; minden másnál hagyja ki.
Rögzített - küldje el a UInt32.MaxValue - 8192 értéket (egy jelző "hatalmas ismeretlen hosszúságra").

Miért: az UPnP/DLNA eszközök vadul eltérnek abban, hogyan reagálnak a Content-Length-re. Egyeseknek pontos számra van szükségük, mások utálják az adatfolyamokon, egyeseknek egy jelző "nagyon nagy" értékre van szükségük a pufferelés fenntartásához. Ezt később kiterjesztették a csak PCM-ről minden kimeneti formátumra, mert ugyanezek a problémák jelentkeztek az átkódolt MP3/AAC adatfolyamokban is.

F08 - "Ne törölje a NextURI-t" profilonként

Mi: normális esetben a beépülő modul törli az eszköz sorban álló NextURI-jét, amikor a sor kiürül (üres URL-lel küld SetNextAVTransportURI-t). Egyes eszközök (különösen a Denon) az üres NextURI-t "állítson le mindent" értelmezik, és azonnal leállítják a lejátszást. Az F08 megakadályozza, hogy a beépülő modul valaha is törölje azt.

Miért: enélkül a Denon tulajdonosok azt tapasztalják, hogy az eszköz megszakítja a számot a közepén, amikor a sor kiürül. Az F08 bejelölésével az eszköz a régi NextURI-t a memóriában tartja (ártalmatlan - csak felülíródik, amikor legközelebb valami sorba kerül).

F09 - FLAC mint átkódolási kimeneti formátum

Mi: az Eszközprofilok átkódolási formátum legördülő menüje mostantól a FLAC-ot is kínálja a PCM 16/24, MP3, AAC, Ogg mellett. A kiválasztása a BASS kódolót a MusicBee standard FLAC konvertálási parancssorán keresztül irányítja (ugyanaz a mechanizmus, amit az MP3/AAC/Ogg már használ).

Miért: azoknál az eszközöknél, amelyek jól kezelik a FLAC-ot, de nem tudják dekódolni a forrás kodeket (pl. egy Eversolo, amely a MusicBee WMA könyvtárát FLAC-ra konvertálva kapja), ez megőrzi a veszteségmentes minőséget, ahol az MP3/AAC eldobná az audio adatokat. Feloldja az N02-t (5.1 lekeverés vezérlése), amelyet veszteségmentes átkódolási opció nélkül nem lehetett kezelni.

Megvalósítás: egy soros kiegészítés az Encoder.StartEncode Select Case Codec blokkjához - a FLAC csatlakozik az MP3/AAC/Ogg-hoz a parancssori vezérelt ágban. A felhasználói felület legördülő menüje "FLAC"-ot kap 6. opcióként. A SettingsDialog betöltési/mentési leképezése kiterjed a FileCodec.Flac ↔ SelectedIndex = 5 felismerésére. A Mime, DLNA típus és kódolási funkció már be volt kötve az ItemManager.GetMimes / GetDlnaType / GetEncodeFeature függvényekben korábbi munkákból (F21, F26).

Résmentes (SetNextAVTransportURI)

F10 - SetNextAVTransportURI / NextURI core

Mi: valódi résmentes lejátszás. Amikor az eszköz a UPnP szolgáltatásleírásában hirdeti a SetNextAVTransportURI támogatását, a beépülő modul előre sorba állítja a következő számot az eszközön, mielőtt az aktuális szám véget ér. Az eszköz belsőleg átvált, hallható rés nélkül a számok között - amit egy CD-lejátszón hall. Ez nem a "folyamatos adatfolyam" hack (amely mindent egy hosszú adatfolyamba fűz össze, és elveszíti a számonkénti metaadatokat).

Miért: a zászlóshajó Tier-2 funkció. A folyamatos élő előadásként rögzített albumok (élő felvételek, klasszikus tételek, DJ szettek) rosszul szólnak, ha fél másodperces csend van a számok között. Ennek megfelelő megoldása egy zászlóshajó funkció, amely most ebben az elágazásban található.

Megjegyzések: a sorba állított hangot a beépülő modul HTTP szervere szolgálja ki streamHandle=0 (könyvtár-lekérdezési mód) használatával, ami azt jelenti, hogy a MusicBee audio motorja nem vesz részt a sorba állított számban. Kompromisszum: a ReplayGain/DSP/EQ effektek nem vonatkoznak a következő számra. Elfogadható, ha a "nyers adatfolyam kényszerítése" be van kapcsolva (az alapértelmezett).

F11 - "NextURI támogatás letiltása" profilonként

Mi: még ha egy eszköz hirdeti is a SetNextAVTransportURI funkciót, ez a jelölőnégyzet arra kényszeríti a beépülő modult, hogy figyelmen kívül hagyja ezt a hirdetést, és visszaessen az egy-szám-egyszerre lejátszásra.

Miért: egyes eszközök hirdetik a NextURI-t, de hibás implementációval rendelkeznek (összeomlások, félátmenetek, lefagyások). Ahelyett, hogy minden egyes hibás eszközt visszafejtenénk, a felhasználó kap egy "csak kapcsolja ki itt" kapcsolót.

F12 - NextURI életciklus a most játszott listán

Mi: amikor a MusicBee NowPlayingListChanged eseményt vált ki, a beépülő modul újraértékeli, hogy mit kell sorba állítani a résmentes átmenethez. Lekérdezi a MusicBee-től az új "következő" számot a NowPlayingList_GetNextIndex(1) + NowPlayingList_GetListFileUrl segítségével, összehasonlítja az eszközön jelenleg sorban állóval (az új nextPlaySourceUrl mezőn keresztül követve), és újra sorba állítja, ha megváltozott (vagy törli a sort, ha a MusicBee azt mondja, hogy nincs következő szám).

Miért: F12 nélkül az eszköz a régi NextURI-t játszotta tovább, amikor a felhasználó eltávolította/átrendezte a sorba állított számot. Ez történelmileg több iterációt igényelt, mert minden lista-mutáció más kezelést igényel - mi egyszerűsítettünk azáltal, hogy megbíztunk a NowPlayingList_GetNextIndex függvényben (amely már figyelembe veszi a véletlenszerű lejátszást és az összes ismétlés körbefutását), így minden változat ugyanazon az összehasonlításon keresztül fut.

Megvalósítás:

Az új nextPlaySourceUrl mező tárolja a sorba állított MusicBee könyvtár URL-jét (a streamelési URL a kezelő utótaggal nem hasonlítható össze egy könyvtárútvonallal).
Az új Public Sub RefreshQueuedNextUri() a MediaRendererDevice osztályon. Három kimenet: nincs sorba állított NextURI → nincs művelet; a sorba állított egyezik az új "következővel" → nincs művelet; a sorba állított eltér → hívja a QueueNext függvényt az új URL-lel (vagy QueueNext("") a törléshez - ami tiszteletben tartja az F08 DoNotClearNextUri beállítást).
Bekötve a Plugin.ReceiveNotification függvénybe a NotificationType.NowPlayingListChanged alatt.

F13 - NextURI hiba visszalépés

Mi: 4 egymást követő SetNextAVTransportURI hiba után ugyanazon az eszközön a beépülő modul letiltja a résmentes lejátszást az adott eszközön a MusicBee újraindításáig.

Miért: ha egy eszköz valóban hibás a NextURI szempontjából (időszakos SOAP hibák, hálózati hibák), a beépülő modul egyébként minden számnál újrapróbálkozna. Az F13 leállítja a zajt, és csendesen visszaesik az egy-szám-egyszerre lejátszásra.

F14 - Ismétlési mód + NextURI integráció

Mi: az F14 két esetre oszlik, amelyeket az F15 átmenetérzékelő kezel az OnAvTransportStatusCheck függvényben:

Összes ismétlése: A MusicBee a helyes "körbefutó" URL-t (1. szám a lista végén) adja át a Plugin.QueueNext függvénynek. Nincs szükség speciális beépülő modul logikára - az eszköz átvált rá, és az F15 érzékelő meghívja a Player_PlayNextTrack függvényt a szokásos módon, ami a MusicBee NPL indexét visszaállítja 0-ra.
Egy ismétlése: A MusicBee UGYANAZT a szám URL-t adja át a Plugin.QueueNext függvénynek. Az eszköz átvált rá (új adatfolyam-azonosító, ugyanaz a forrás). Az F15 érzékelő most lekérdezi a Player_GetRepeat() függvényt - ha az RepeatMode.One, akkor átugorja a Player_PlayNextTrack hívást, így a MusicBee nem lépteti előre az NPL indexet a hurkolt számtól.

Miért: az Egy ismétlése átugrás nélkül a Player_PlayNextTrack hívása a résmentes átmenetnél előre léptetné a MusicBee-t a listában a következő számra (az Egy ismétlése csak a lejátszó felhasználói felületén lévő számvégi automatikus előrelépési viselkedést befolyásolja - a Következő szám mindig előre lép), ami ellentmondana annak, amit az Egy ismétlése jelent.

Lejátszásszám figyelmeztetés: az Egy ismétlése módban a lejátszásszám növelése attól függ, hogy a MusicBee 3.7.9563+ észreveszi-e a hurkolt lejátszást. A régebbi MusicBee verziók helyesen játsszák le a résmentes ismétlést, de kihagyják a lejátszásszám növelését. Dokumentálva; nem blokkoló.

F15 - Számátmenet-érzékelő állapotgép

Mi: amikor az eszköz belsőleg átvált az aktuális számról a NextURI-re, a beépülő modulnak észre kell vennie, és szólnia kell a MusicBee-nek, hogy léptesse előre a most játszott indexét. Ellenkező esetben a MusicBee azt hiszi, hogy még mindig az előző számon van, és a lejátszásszámok / felhasználói felület / scrobbling elcsúszik.

Megvalósítás: minden állapotidőzítő-ticknél lekérdezi a GetPositionInfo.TrackURI értéket. Amikor a jelentett URI megegyezik azzal, amit a NextURI-n keresztül sorba állítottunk, meghívjuk a Player_PlayNextTrack függvényt a MusicBee-n, és beállítjuk a suppressNextSoapCall értéket, hogy az ebből eredő PlayToDevice ne küldje újra a SetAVTransportURI parancsot (ami megszakítaná a résmentes lejátszást).

Miért: F15 nélkül az eszköz lejátssza a következő számot, de a MusicBee felhasználói felülete azt mondja, hogy még mindig az előzőn van. Zavaró, megszakítja a scrobblinget, megszakítja a lejátszásszám-követést. A számátmenet-érzékelés hosszú, renderelőnkénti iterációt igényel, mert minden renderelő márkának megvannak a maga furcsaságai abban, hogy mikor jelenti az URI változást (egyesek először a TRANSITIONING-et jelentik, mások egyből a PLAYING-re ugranak az új URI-vel, másoknak van egy rövid STOPPED állapotuk a kettő között).

Megjegyzések: az első vágásunk a BubbleUPnP renderelőn működik. Az eszközönkénti él esetek az B6-ban maradnak.

F16 - Felpattanás a résmentes átmenetnél javítás

Mi: a felpattanás akkor következik be, amikor a sorba állított szám forrásformátuma (mintavételezési sebesség / csatornák / kodek) eltér a jelenleg játszott számétól, ami arra kényszeríti az eszköz DAC-ját, hogy újra rögzítse magát az átmenetnél. Az F16 hozzáad egy NextUri:FormatChange diagnosztikát, amely sorba állításkor aktiválódik, amikor a formátumok eltérnek, megnevezve mindkét oldalt - így a felpattanásokat halló felhasználók korrelálhatnak.

A diagnosztika a megoldásra is rámutat: jelölje be a ForceTranscoding opciót az eszközprofilon. Ez homogenizálja az összes számot egyetlen átkódolási kodekre/mintavételezési sebességre/bitmélységre, teljesen kiküszöbölve a forrásformátum különbségét.

Miért halasztották el a tényleges átkódolás-egyeztetés javítását: a strukturális javítás (az átkódolt szám átkódolása a játszott szám formátumához) változtatásokat igényel a beépülő modul HTTP szerver URL sémájában - jelenleg a /encode/{id}0.{ext} natívan szolgálja ki a sorba állított fájlt. Az F16 jövőbeli v2-je formátumonkénti /encode/{id}0_{rate}_{depth}.{ext} útvonalakat adna hozzá, és bekötné őket a kódolóba. Ez egy nagyobb architekturális változás, amelyet érdemes megtenni, ha egy valódi eszköz felpattanást mutat, miután a ForceTranscoding nem elegendő.

Jelenlegi megvalósítás:

A lastSourceUrl mező követi a jelenleg játszott forrás URL-t.
A QueueNext beolvassa a FilePropertyType.SampleRate/Channels/Kind értékeket mind az aktuális, mind a sorba állított számokhoz, és NextUri:FormatChange üzenetet naplóz eltérés esetén.

F17 - Folyamatjelző sáv újraszinkronizálása keresés után

Mi: a Seek() függvény már meghívta a GetPlayPositionInformation() függvényt egy sikeres Seek SOAP után, ami javítja a "nincs újraszinkronizálás" esetet. Az F17 lezárja a fennmaradó, akár 1 másodperces eltolódást, amelyet az UPnP 1 másodperces RelTime kvantálása okoz: amikor az eszköz által jelentett pozíció a felhasználó által kért cél 1 másodpercen belüli értékére kerekedik, a beépülő modul mostantól a felhasználó al-másodperces pontosságú értékében bízik az eszköz csonkítása helyett. Csak akkor használjuk az eszköz értékét, ha az eszköz drámaian eltérő értéket jelent (>1 másodperc eltérés) (a keresés máshová érkezett, mint kérték, pl. kulcsképhez igazítás egyes kodekeknél).

Miért: enélkül a 2:30.500-ra történő keresés, az eszköz "2:30" jelentése alapján, a folyamatjelző sávot ~500ms-mal a valóság mögött mutatná. Az F17 után a sáv megegyezik a felhasználó szándékával a gyakori számon belüli görgetés esetében, és továbbra is tiszteletben tartja az eszköz jelentését a kulcsképhez igazítás kivételével.

F18 - Folyamatos adatfolyam / NextURI reteszelés

Mi: két reteszelés van érvényben:

Futásidő: a QueueNext korán False értéket ad vissza, ha a Settings.ContinuousOutput be van kapcsolva. A folyamatos adatfolyam saját résmentes mechanizmusa (egy hosszú, összefűzött adatfolyam); a SetNextAVTransportURI küldése ezen felül összezavarja az eszközt abban, hogy minden szám külön URI-e, vagy a folyamatos adatfolyam része.
Felhasználói felület: amikor a felhasználó bejelöli a globális folyamatos adatfolyam jelölőnégyzetet, a jelenleg megjelenített profil forceNativeStream automatikusan kikapcsol. A folyamatos adatfolyam mindig átkódol, így a natív kényszerítése értelmetlen kombinációban.

Miért: megakadályozza, hogy a felhasználó két ellentmondásos résmentes mechanizmust engedélyezzen egyszerre. F18 nélkül az eszköz mind folyamatos adatfolyam URI-t, mind NextURI-t kapna minden következő számhoz, meghatározatlan viselkedéssel a renderelőtől függően.

F19 - Üres NextURI hibák figyelmen kívül hagyása

Mi: amikor a SetNextAVTransportURI üres URL-lel kerül meghívásra (pl. a lista utolsó száma), egyes eszközök SOAP hibát adnak vissza. Az F19 ezeket csendesen elnyeli - naplózva, de nem terjesztve hibaként.

Miért: a "nincs következő szám" állapot normális, nem hiba. Halálosként kezelése szennyezi a naplót, és (egyes folyamatokban) újrapróbálkozási viharokat vált ki.

Mime típusok és DLNA metaadatok

F20 - MP3 mime → `audio/mpeg`

Mi: a szabványoknak megfelelő MP3 mime típus audio/mpeg, nem audio/mp3. Az utóbbi egy gyakori téves elnevezés, amit a legtöbb eszköz tolerál, de a szigorúbb renderelők elutasítják.

Miért: csendesen javítja a lejátszást a szabványt követő szigorúbb eszközökön. A yaiol kódbázisban ez már helyesen szerepelt; nincs szükség változtatásra.

F21 - Mime típus sorrend: nem `x-` változat először

Mi: amikor egy eszköz audio/flac és audio/x-flac értéket is hirdet, a beépülő modul először a nem x- változatot adja vissza. Ugyanez vonatkozik minden kodekre, amely szabványos és kísérleti mime típusokkal is rendelkezik.

Miért: az x- előtag kísérleti/nem hivatalos mime típusokat jelöl. Egyes renderelők jobban viselkednek a szabványos formával. Apró átrendezés, valós hatás.

F22 - Opus mime típus támogatás

Mi: felismeri az Opus-t mint streamelhető audio kodeket; audio/opus mime típust küld Opus számok kiszolgálásakor.

Miért: az Opus ma már elterjedt (modern beszéd/zene kompromisszumos kodek). F22 nélkül a beépülő modul megtagadná az Opus fájlok streamelését még az azokat kezelő eszközöknek is.

F23 - Monkey Audio (APE) forrásfájl támogatás

Mi: felismeri a .ape fájlokat mint érvényes forrás kodeket streameléshez/átkódoláshoz.

Miért: az APE egy veszteségmentes formátum, amelynek van egy réteg, de hűséges felhasználói bázisa. Hozzáadása kevés költséggel jár, és feloldja a könyvtárat ezeknek a felhasználóknak.

F24 - AAC / ALAC mime visszaesés

Mi: ha egy eszköz támogatja az AAC-t vagy az ALAC-ot, de nem hirdeti expliciten a UPnP szolgáltatásleírásában, a beépülő modul akkor is felajánlja őket visszaesésként.

Miért: több olyan eszköz, amely jól kezeli az AAC-t, elfelejtette felsorolni a képességei XML-jében. F24 nélkül a beépülő modul meg sem próbálná, kényszerítve az átkódolást. F24-gyel a beépülő modul megpróbálja, és hagyja, hogy az eszköz natívan kezelje, ha tudja.

F25 - DLNA típusjelző natív + kódolt WAV adatfolyamokhoz

Mi: a DLNA típusjelzőnek (egy profilazonosító, mint LPCM, WAVE, MP3) meg kell egyeznie azzal, amit az eszköz kap. Az F25 biztosítja, hogy a natív adatfolyamok és a kódolt WAV adatfolyamok helyesen legyenek jelölve.

Miért: a nem megfelelő DLNA típus miatt egyes eszközök teljesen megtagadják a lejátszást, vagy rossz dekódert alkalmaznak.

F26 - DLNA fejléc FLAC fájlokhoz

Mi: a FLAC adatfolyamok a megfelelő DLNA profilazonosítót kapják a fejléceikben.

Miért: enélkül egyes FLAC-ot támogató eszközök nem ismerik fel az adatfolyamot.

F27 - Bitráta számítás javítása a metaadatokban

Mi: a folyamatos adatfolyam res@bitrate értéke (sampleRate * channels * bitsPerSample) / 1000 - kbps - volt, ami ~125-szörös eltérést mutatott az UPnP DIDL specifikációtól, amely az attribútumot bájtok másodpercenként definiálja. Mostantól 8-cal oszt, 1000 helyett.

Miért: hibás bitráta megjelenítés az eszközön - a legtöbb renderelőn kozmetikai, de egyesek az értékből allokálnak adatfolyam-puffereket, és akadoznak azokon az adatfolyamokon, amelyek ~125-ször kisebbnek tűnnek, mint amilyenek. A nem folyamatos forrásfájl útvonalon ez már helyesen szerepelt ((bitrate_kbps * 1000) \ 8 = bájt/mp); csak a folyamatos adatfolyam útvonal volt hibás.

F28 - Metaadat időformátum javítása (Marantz)

Mi: a DIDL res@duration formátuma H:MM:SS volt (pl. 0:03:42). Az UPnP DIDL specifikáció a formátumot H+:MM:SS[.F+]-ként definiálja - szigorúan, a tört másodpercek opcionálisak, de ajánlottak; egyes Marantz eszközök az egyszerű formát érvénytelennek tekintik, és üresen hagyják a időtartam kijelzőjüket. Mostantól H:MM:SS.fff formátumban (pl. 0:03:42.000).

Miért: egy márkára jellemző megjelenítési probléma; a szabványos ISO-stílusú formátum tört másodpercekkel javítja anélkül, hogy bármely más eszközt érintene. Mindkét DIDL kibocsátási helyen alkalmazva (forrásfájl útvonal + kódolt adatfolyam útvonal a WriteAudioFileDIDL függvényben).

Bónusz javítás ugyanabban a lépésben: a pv:addedTime és pv:lastPlayedTime hh (12 órás óra) formátumot használt a DateTime formátumkarakterláncaiban HH (24 órás) helyett. Bármely 13:00 és 23:59 között hozzáadott vagy lejátszott szám hibás órával jelenne meg (pl. 17:42 → "05:42") azokon az eszközökön, amelyek megjelenítik a mezőt. Mostantól HH formátumot használ.

F29 - Kódolt MP3 keresés támogatása (CBR)

Mi: az átkódolt MP3 adatfolyamok mostantól DLNA.ORG_OP=11 (bájt és idő szerinti keresés is) értéket hirdetnek DLNA.ORG_OP=10 (csak bájt szerinti) helyett. Azok az eszközök, amelyek korábban megtagadták az idő szerinti keresést az átkódolt MP3-on, mostantól normálisan vezérelhetik a folyamatjelző sávjukat/keresési felhasználói felületüket.

Miért: a MusicBee átkódolója állandó bitrátájú MP3-at produkál a HighQuality előbeállítással, így a bájt ↔ idő leképezés lineáris - az eszköz maga is át tudja alakítani az idő szerinti keresési kérést HTTP Range bájt szerinti kereséssé, kódoló oldali támogatás nélkül. Az OP=11 hirdetése feloldja ezt a felhasználói felületet az eszközön. F29 nélkül az átkódolt MP3-ban kereső felhasználók keresését vagy csendesen figyelmen kívül hagyták, vagy a szám elejére kerültek.

Megvalósítás: az ItemManager.vb GetEncodeFeature függvénye átstrukturálásra került, hogy az inline If egy olvasható If/ElseIf/Else lánccá bomoljon. Az MP3 expliciten OP=11 értéket kap; más nem-PCM kodekek megtartják az OP=10 értéket. Nincs változás az AAC/FLAC/stb. esetében - ezekhez kodek-specifikus CBR-ellenőrzésre lenne szükség, amit a MusicBee nem garantál.

F30 - `.mpeg` fájlkiterjesztés kezelése

Mi: a .mpeg (és a még ritkább .mpe) kiterjesztésű fájlok mostantól FileCodec.Mp3 kódként ismerhetők fel a GetCodec függvényben. F30 előtt FileCodec.Unknown értéket adtak vissza, és csendesen elutasították őket a könyvtárból / nem lehettek átkódolási források.

Miért: a régi MPEG-1 Layer 3 archívumok néha .mpeg kiterjesztést használtak .mp3 helyett (a specifikáció mindkettőt megengedi). Néhány fájl egy 300k-s könyvtárban elég ahhoz, hogy a felhasználó azt érezze, "a MusicBee megmutatja őket, de a beépülő modul nem" - zavaró a felhasználó számára.

Lejátszási viselkedés

F31 - Rádió adatfolyamok automatikusan folyamatos módot használnak

Mi: a WriteAudioFileDIDL mostantól lekérdezi a forrás URL Kind tulajdonságát a Library_GetFileProperty segítségével, és minden olyan fájlt, amelynek Kind tulajdonsága "Stream"-re végződik (a MusicBee "MP3 Stream", "Internet Stream" stb. rádióra vonatkozóan), folyamatosként kezel, függetlenül a globális Settings.ContinuousOutput kapcsolótól. A folyamatos adatfolyam DIDL ág (Cím: "Folyamatos adatfolyam", id="continuousstream", rögzített PCM/Wave kimenet) kerül felhasználásra; az eszköz egyetlen végtelen stílusú adatfolyamot lát.

Miért: a rádió adatfolyamoknak nincsenek számlimitjei, nincs rögzített hossza, nincs keresés. Az, hogy a DIDL-ben különálló fájlokként kezeljük őket, azt okozta, hogy a beépülő modul olyan bájt tartományokat és időtartamokat hirdetett, amelyek nem léteznek. Az automatikus váltás, amikor a MusicBee már elmondta nekünk, hogy "ez egy adatfolyam", eltávolít egy olyan hibalehetőséget, amire a felhasználónak nem kellene gondolnia.

Hatókör: csak akkor érvényes, ha a MusicBee vezérli a lejátszást (musicBeePlayToMode). A könyvtár-lekérdezési útvonal (UPnP kliens böngészés) változatlan - a rádió URL-ek ritkák ott, és a felhasználó felé irányuló viselkedésnek nem szabadna megváltoznia explicit tesztelés nélkül.

F32 - Kodek-hirdetési visszaesés

Mi: ha egy eszköz nem hirdet bizonyos kodekeket (vagy a beépülő modul nem tudja elemezni az eszköz képesség XML-jét), a beépülő modul nem utasítja el azonnal az adatfolyamot. Ehelyett megpróbálja kiszolgálni, és hagyja, hogy az eszköz döntsön.

Miért: sok eszköznek hiányos vagy olvashatatlan képesség XML-je van, de valójában jól kezeli a kodeket. Az F32 egy kis "legjobb tipp és próbálkozás" lehetőséget cserél egy egyenes elutasításra.

F33 - Folyamatjelző sáv szinkronizálás javítása

Mi: a lekérdezések közötti pozíció már falórával extrapolálva van egyetlen horgonyból (currentPlayStartTicks), így a folyamatjelző sáv simán frissül al-másodperces sebességgel. A fennmaradó jitter forrása egy frissen indított szám kezdeti horgonya volt: az előző kód feltételezte, hogy a position=0 abban a pillanatban, amikor az állapotidőzítő először észlelte, hogy az állapot Playing-re váltott, de addigra az eszköz már 100-500ms-ig játszhatott (egy lekérdezési intervallum). A MusicBee folyamatjelző sávja 0-ról indulna, majd előre ugrana, amikor a valóság utolérte.

F33 javítás: amikor egy új számon először vált Playing állapotba (currentPlayStartTimeEstimated=True), hívja meg a GetPlayPositionInformation() függvényt, hogy megkapja az eszköz aktuális aktuális pozícióját, majd horgonyozzon ahhoz. Az UPnP csak 1 másodperces felbontást jelent, így a horgony továbbra is kvantált, de sokkal közelebb van az igazsághoz, mint a 0 feltételezése.

Miért: simább + pontosabb folyamatkijelzés, különösen számváltás után. Az 1 másodperces UPnP jelentési felbontás maga nem kerülhető meg - ez a specifikáció.

F34 - Folyamatjelző sáv jitter számváltás után

Mi: amikor a PlayToDevice függvényt egy új számra hívták meg, a beépülő modul korábban a currentPlayPositionMs és currentPlayStartTicks értékeket az előző szám értékein hagyta a SOAP-Play és az első állapotidőzítő lekérdezés közötti ~100ms-os ablakban, amely az új Playing állapotot észlelte. A MusicBee folyamatjelző sávja röviden az előző szám végét mutatta, majd visszaállt 0-ra, majd emelkedett. Az F34 mindkettőt nullázza a PlayToDevice belépéskor - abban a pillanatban, amikor tudjuk, hogy számváltás történik, még a SOAP munka előtt.

Miért: vizuális hiba gyors ugrásos esetekben (kézi következő vagy résmentes átmenet). Most a MusicBee első PlayPositionMs lekérdezése Play után tisztán 0-t ad vissza, majd az F33 GetPlayPositionInformation függvénye finomítja azt az eszköz tényleges pozíciójára az első állapotváltozási ticknél.

Megvalósítás: négy sor a PlayToDevice tetején, párosítva az F33 átmeneti idejű pontos horgonyzásával.

F35 - "Átkódolás kényszerítése" hiba

Mi: az átkódolás kényszerítése bizonyos kombinációkban továbbra is kihagyhatta az átkódolást. Az F04 profilonkénti átdolgozás után két specifikus rés került lezárásra:

Prioritás a ForceNativeStream-mel. Ha mindkettő True volt (ami előfordulhat séma migráció vagy részleges beállításfájl esetén), a ForceTranscoding mostantól egyértelműen nyer (If streamingProfile.ForceTranscoding Then forceEncode = True ElseIf streamingProfile.ForceNativeStream Then forceEncode = False). A felhasználói felület kölcsönös kizárása megakadályozza, hogy a felhasználó mindkettőt bejelölje, de a futásidejű védelem kezeli az összes olyan állapotot, amely inkonzisztensen töltődött be a lemezről.
bypassTranscodeDecision logika. Korábban: streamingProfile.ForceNativeStream AndAlso Not Settings.ForceTranscoding. Most: streamingProfile.ForceNativeStream AndAlso Not streamingProfile.ForceTranscoding - ugyanaz a prioritási szabály, de ugyanazon profilonkénti hatókörben.

Miért: a "kényszerítésnek" kényszerítést kell jelentenie. Ha a felhasználó expliciten engedélyezte a ForceTranscoding-ot egy eszközhöz, a beépülő modulnak soha nem szabad csendesen visszaesnie a natív streamelésre, függetlenül attól, hogy más jelzők hogyan kombinálódnak.

F36 - Renderelő-lezárt kivétel

Mi: a Plugin.ReceiveNotification függvényt egy felső szintű Try/Catch blokkba csomagoltuk, amely minden nem kezelt kivételt naplóz, ahelyett, hogy hagyná azt visszaterjedni a MusicBee értesítési pumpájába.

Miért: a MusicBee-től érkező értesítések (PlayStateChanged, VolumeMuteChanged stb.) a ControlPointManager osztályba kerülnek, amely SOAP-on keresztül kommunikál a renderelővel. Az egyes hívási helyek már rendelkeztek Try/Catch blokkokkal a SOAP hívásaik körül, de egy kellően furcsa időzítési eset (pl. a renderelő meghal két SOAP hívás között ugyanabban az értesítési kezelőben) továbbra is elszökhetett. A felső szintű burkoló a végső biztonsági háló, így a felhasználó soha nem lát egy általános "TargetInvocationException" felugró ablakot a MusicBee-től.

Megvalósítás: az existing body átnevezésre került ReceiveNotificationInternal-re, és egy vékony burkoló ReceiveNotification került hozzáadásra, amely Try { ReceiveNotificationInternal(...) } Catch { LogError(...) } műveletet végez. A ControlPointManager osztályon belüli (minden PostSoapRequest hívás körüli) meglévő metódusonkénti Try/Catch infrastruktúra megmarad - az F36 öv + nadrágtartó.

F37 - Hosszú szám keresése hamis átmenetet vált ki

Mi: egy hosszú számban való keresés rövid Stopped→Playing ciklust eredményezhet egyes renderelőkön. Megkülönböztetés nélkül a ProcessNewPlayState.Stopped ezt a szám természetes végének tekinti, és meghívja a Player_PlayNextTrack függvényt, előre léptetve a MusicBee-t, amikor a felhasználó csak görgetni akart. Az F37 a Seek() függvényben beállítja a lastUserInitiatedSeek értéket, és egy 5 másodperces védelmet ad a Stopped kezelőhöz (tükrözve a meglévő lastUserInitiatedStop ablakot).

Miért: a csendes átugrás a következő számra keresés közben egyike azoknak a hibáknak, amelyek okát senki sem tudja kitalálni - a felhasználó azt gondolja, "furcsa, megpróbáltam előre görgetni, és most a következő számot játssza". A javítás mechanikus: ugyanaz a minta, mint a már meglévő felhasználói leállítás megkülönböztetés.

F38 - Javított kereséskezelés összeomlásra hajlamos kodekeknél

Mi: a BubbleUPnP összeomlása MP3 kereséskor volt a kanonikus tünet. Auditálás után a jelenlegi yaiol keresési kódja már a helyes dolgokat teszi - a natív útvonal helyesen kezeli a HTTP Range-et (206, Content-Range, AcceptRanges), a kódolt útvonal hirdeti az X-AvailableSeekRange-et és elemzi a bejövő timeSeekRange.dlna.org / npt fejléceket, a DLNA.ORG_OP jelzők tükrözik a tényleges adatfolyam képességeit (a DisablePcmTimeSeek opt-out-tal a problémás Platinum eszközökhöz). Felhasználó által tesztelt a jelenlegi BubbleUPnP 4.6.4-en: nem észleltek összeomlásokat.

Miért: a BubbleUPnP MP3-keresési összeomlását 2024 körül jelentették, és az alkalmazás azóta ~16 hónapnyi javítást kapott. Az F29 (kódolt MP3 OP=11) volt az új változó, amely újra előhozhatta volna; a tesztelt verziókon nem.

Ha az összeomlás visszatér: a javítás egy profilonkénti "korlátozott keresés" kapcsoló lenne, amely DLNA.ORG_OP=10 (csak bájt) értéket kényszerít a jelölt kodekekre - tükrözve, ahogyan a DisablePcmTimeSeek már működik a PCM-hez. Akkor hozzáadni, nem előre.

Felhasználói felület és naplózás

F39 - "Hozzáadás" gomb kiválasztja az új profilt

Mi: az "Hozzáadás" gombra kattintva az eszközprofilok listájában új profil jön létre ÉS automatikusan kiválasztásra kerül, így a felhasználó azonnal szerkesztheti a mezőket. A szakaszolt párbeszédpanel refaktorálásunk már megteszi ezt - mind a közvetlen Hozzáadás útvonal, mind a sablonból történő útvonal azzal végződik, hogy Me.activeStreamingProfiles.SelectedIndex = Me.activeStreamingProfiles.Items.Count - 1. Egy ellenőrzés megerősítette, hogy az elágazásunk már kezeli ezt - nincs mit változtatni.

Miért: apró UX papírvágás, ami itt már nem is volt papírvágás.

F40 - Nagyobb maximális kapcsolatok + figyelmeztető napló

Mi: a beépülő modul egyidejű adatfolyam korlátja (SemaphoreSlim a Sockets_Stream_File / Sockets_Encoder_Start körül) keménykódolt 4 volt. Az F40 felhasználó által konfigurálhatóvá teszi az Általános beállítások oldalon (alapértelmezett 16, tartomány 1-256), hozzáad egy MaxConnections naplóbejegyzést, amikor egy kérésnek várnia kell egy helyre, ÉS megjelenít egy piros ⚠ Max Conn jelvényt a beállítások párbeszédpanel bal alsó sarkában, ha a korlátot legalább egyszer elérte a MusicBee indítása óta.

Miért: amikor egy eszköz párhuzamos kéréseket indít (egyes Marantz/Linn a borítókép-keresések során, a BubbleUPnP metaadat-lekérdezései aktív lejátszás mellett), további kérések csendesen blokkolódtak a szemafor mögött - a felhasználó "lassú eszköz" üzenetet látott látható ok nélkül. A naplóbejegyzés jó a technikai hibakereséshez, de a nem technikai felhasználók soha nem olvassák a naplókat. A beállítások párbeszédpanelen látható jelvény felfedezhetővé teszi a korlát elérésének állapotát bárki számára, aki megnyitja a beépülő modul beállításait.

Megvalósítás:

A várakozás központosítva a WaitOnSendBarrier(logTag) függvényben a MusicBeeUpnp.vb fájlban; mindkét hívási hely (MediaServerDevice.GetFile, Encoder.StartEncode) használja.
A Settings.MaxConnections a beállítási séma v8-ban marad.
A Plugin.MaxConnectionsHit egy ragaszkodó munkamenet jelző, amelyet a WaitOnSendBarrier függvényben állítanak be; csak a MusicBee újraindításakor áll vissza.
A SettingsDialog.maxConnectionsBadge egy piros, félkövér címke a (16, 410) pozíción, amely csak akkor jelenik meg, ha a Plugin.MaxConnectionsHit True. Van egy eszköztippje, amely elmagyarázza az okot és a megoldást.
A szemafor egyszer inicializálódik típusbetöltéskor, így a beállítás megváltoztatása MusicBee újraindítást igényel (a mező címkéjében megjegyezve).

F41 - Napló "átkódolás ReplayGain/DSP miatt"

Mi: a külön "átkódolás RG-hez" / "átkódolás DSP-hez" naplóbejegyzések helyett az F42-ből származó egyetlen StreamDecision sor tartalmazza az MB-DSP/EQ, MB-ReplayGain, Profile-DSP/EQ, Profile-ReplayGain értékeket mint felhalmozott okokat. Ugyanaz a diagnosztikai érték, kevesebb zaj.

Miért: a felhasználók egy naplósoron látják az átkódolás összes okát egy adott számhoz, nem szétszórva. Lásd az F42-t a teljes részletekért.

F42 - Napló "a renderelő nem támogatja a forrás kodeket"

Mi: hozzáadott egy StreamDecision naplóbejegyzést minden lejátszási célú számhoz, amely azt mondja, hogy "natív KODEK" vagy "átkódolás KODEK→KODEK ok=…". Az ok mező felhalmozza az átkódolást kiváltó összes feltételt: MB-DSP/EQ, MB-ReplayGain, Profile-DSP/EQ, Profile-ReplayGain, WebFile, VirtualFile, ForceTranscoding(global), SampleRate<min/SampleRate>max, DownmixToStereo, DeviceLacksCodec(X), BandwidthConstrained.

Miért: a felhasználók zavarban voltak a váratlan CPU-tüskék miatt olyan fájlokon, amelyeket natívan streamelni vártak. Egy naplósor számonként pontosan megmondja nekik, melyik feltétel okozta az átkódolást - és ha a mező DeviceLacksCodec(Flac)-ot mutat, azonnal tudják, hogy az eszköz protokollinformációja hiányos volt, és esetleg az F32 visszaesését szeretnék, hogy beinduljon.

Megvalósítás: egyetlen akkumulátor karakterlánc, amelyet fokozatosan építenek fel a döntési láncban; egyszer naplózva a végén. A Settings.LogDebugInfo beállításhoz kötve, hogy elkerüljék a naplózási zajt a gyártásban.

F43 - A SetNextAVTransport napló a forrás URL-t mutatja

Mi: a QueueNext naplóbejegyzések mostantól tartalmazzák a source=<MusicBee könyvtár útvonal> értéket a stream=<HTTP streamelési URL> mellett. Ugyanez a változás vonatkozik a sikeres és a sikertelen útvonalra is (QueueNext:Failed).

Miért: egy sorba állított szám hibakeresésekor a streamelési URL (/encode/aabbccdd0.flac) önmagában átláthatatlan - minden számra ugyanaz. A forrás URL az ember által kereshető könyvtárútvonal, amely pontosan megmondja, melyik fájlt próbálta a MusicBee sorba állítani.

F44 - Jobb mime-típus hiba naplózás

Mi: két új naplóbejegyzés az Activate során:

Activate:MimeUnverified - minden hibás bejegyzésnél aktiválódik az eszköz GetProtocolInfo válaszában, megnevezve, melyik bejegyzést nem lehetett elemezni (így a felhasználó láthatja pl. "a Marantz http-get:*::* értéket adott vissza valamilyen kodekhez - a képesség ellenőrizetlen, az F32 visszaesése találgatni fog").
Activate:NoSinkInfo - egyszer aktiválódik, ha az eszköz egyáltalán nem adott vissza <Sink> elemet. Ez azt jelenti, hogy a SupportedMimeTypes Nothing marad, és az IsCodecSupported "feltételezzük, hogy minden működik" állapotba kerül - hasznos kontextus, amikor később "az eszköz megtagadta az adatfolyamot" hibák jelennek meg.

Miért: F44 előtt ezek a csendes képesség-visszaesések a felhasználókat találgatásra késztették, hogy miért kódolták át a számaikat az elvárásokkal ellentétben, vagy miért utasította el őket az eszköz. Most egyetlen Activate: keresés megmutatja, hogy az eszköz képességinformációja használható volt-e.

F45 - Jobb metaadat hiba naplózás

Mi: a Browse kivétel napló a ContentDirectoryService.vb fájlban már gazdagodott a korábbi yaiol munkában (az Alia Vox hiba munkamenet) az ObjectID és a veremkövetéssel. Az F45 tovább bővíti a BrowseFlag (metaadat vs. gyermekek), Filter (mely attribútumokat kérte a kliens), sortCriteria és partialResultLength (hány bájt DIDL készült a hiba előtt - rámutat, hogy a rossz szám mennyire van a kötegben).

Miért: ha valami elromlik a DIDL közepén, a részleges hosszúság érték megmondja, hogy a hiba a köteg első számánál történt-e (partial=0) vagy félúton (partial=N) - a köteg startingIndex értékével kombinálva azonosíthatja a hibás szám indexét. A Filter és a BrowseFlag elmagyarázza, milyen típusú böngészést akart a kliens; néha egy csak metaadat böngészés meghiúsul, ahol ugyanazon azonosítóhoz tartozó gyermek böngészés sikeres.

Hálózat

F46 - Automatikus mód csak valós hálózati adaptereken hirdet

Mi: Automatikus interfész módban a beépülő modul korábban minden működőképes IPv4 adapteren bejelentette magát (SSDP). Egy olyan gépen, amely VPN alagutat (NordLynx) vagy virtuális kapcsolót (Hyper-V / WSL / Docker) is futtat, ugyanazt a könyvtárat ezeken az adaptereken is bejelentették, így a vezérlőpont, ahonnan sugárzott, kétszer vagy háromszor is felfedezte a szervert, és a könyvtárat duplikált másolatokként listázta. Az automatikus mód mostantól csak azokat az adaptereket tartja meg, amelyeknek van valós IPv4 alapértelmezett átjárója (HasIPv4Gateway) - amivel az alagút és a virtuális kapcsoló adapterek nem rendelkeznek -, így ezek kimaradnak a bejelentési listából. A felhasználó által rögzített cím továbbra is egyértelműen nyer (csak azon az interfészen hirdet), és ha egyetlen adapter sem jelent átjárót, a választó visszaesik minden adapterre, így a hirdetett címek listája soha nem üres, és a beépülő modul nem válhat láthatatlanná.

Miért: a duplikációt nem az "VPN-en lenni" okozza - hanem az, hogy egyszerre hirdet a LAN adapteren és az alagút/virtuális adapteren, így egy vezérlőpont ugyanazt a szervert két címen látja. Egy fogyasztói VPN (NordVPN/NordLynx) csak az internetre irányuló forgalmat alagutazza; a DLNA renderelő a LAN-on él, és a helyi alhálózati forgalom megkerüli az alagutat, így az alagút adapter soha nem éri el a renderelőt - eldobása eltávolít egy fantom másolatot, soha nem egy működő útvonalat. Az átjáró teszt az olcsó, megbízható jel, amely elválasztja a valós LAN/Wi-Fi adaptert egy alagúttól vagy virtuális kapcsolótól. Kiegészíti az N05-öt (amely javította, hogyan küldik a bejelentéseket ilyen linkeken - multicast broadcast helyett); az F46 szabályozza, mely adaptereken történik egyáltalán bejelentés.

Ismert korlát: egy mesh / távoli hozzáférésű VPN (Tailscale, ZeroTier, WireGuard-to-home), amelynek renderelői valóban az alagúton keresztül élnek, általában olyan adaptert mutat, amelynek nincs alapértelmezett átjárója, így az automatikus mód azt is eldobja. Ezek a felhasználók ehelyett a VPN címet rögzítik, amely elsőbbséget élvez az átjáró szűrővel szemben.

Újdonságok

2.0.9 - 2026-08-23

A frissítési értesítő a saját nyelvén nyitja meg az oldalait

2.0.8 - 2026-08-22

Eszközei a megfelelő gyártót, modellt és verziót mutatják

Az Eszközprofilok beállításai ismét egy vonalba kerültek

2.0.7 - 2026-08-08

A nagyobb zeneszámok megtartják a címüket és a pozíciócsúszkájukat

2.0.6 - 2026-08-03

Az albumok szünet nélkül játszódnak le

Az internetes rádiót rádióként ismeri fel az alkalmazás

A hosszú, nagy felbontású számok megtartják a másolatukat

2.0.5 - 2026-08-03

A telefonod hangereje megegyezik a MusicBee hangerejével

Egy album lejátszása megtartja a címeit és a pozíciócsúszkáját

2.0.4 - 2026-08-02

Mozgás egy máshonnan küldött zeneszámban

Helyes cím és hossz az első hangtól kezdve

Egy ugrás, amit nem lehet megtenni, most már jelzi

A kombinált hi-fi streamerek helyesen olvashatók

2.0.3 - 2026-08-02

Zenék lejátszása a telefonról, nem csak a saját könyvtárból

Egy lejátszhatatlan szám jelzi, hogy nem játszható le

Egy új szám küldése szüneteltetett állapotban mostantól lejátsza azt a számot

2.0.2 - 2026-08-01

Az előadó szerinti keresés ténylegesen működik

A keresési eredmények oldal helyesen lapozható

A keresés sokkal gyorsabb nagy könyvtár esetén

Célozza meg a véletlenszerű lejátszást egy szűrővel

A Súgó, a GitHub és a frissítésellenőrzés valós oldalakra vezet

2.0.1 - 2026-07-26

A podcastok szünet nélkül indulnak el

A podcastok megjelennek, ha előadó szerint böngészik

A „Legutóbb lejátszott” és a casting közvetlenül újraindítás után működik

A „Véletlen számok” és a „Véletlen albumok” eredményeket adnak vissza

Az üres címkével rendelkező albumok felsorolják a számaikat

2.0.0 - 2026-07-22

Újdonságok ebben az elágazásban

MediaRenderer - lejátszás MusicBee-re

N01 - MusicBee mint lejátszási cél

Lejátszási viselkedés

N02 - 5.1 FLAC nem automatikusan lekeverve

Architektúra

N03 - Lusta (igény szerinti) böngészési fa

Hálózat és robusztusság

N04 - Öngyógyító HTTP portkötés

N05 - SSDP bejelentések a multicast csoporton keresztül (VPN / pont-pont)

Könyvtár navigáció

N06 - Szűrő alapú könyvtár expozíció

N07 - SortAlbumArtist mező bekötése

N08 - Többértékű AlbumArtist kezelés

N09 - Albumkonténer borító (upnp:albumArtURI)

N10 - Számok sorrendje a szűrőalbumokon belül

N11 - Lejátszási lista mappa fa javítása

N12 - XML-ben illegális vezérlőkarakterek szanálása

N13 - Rádiólista determinisztikus a lapozott böngészés során

N14 - UPnP keresés albumosztályú lekérdezések albumkonténereket adnak vissza

N15 - Működő, hatókör-tudatos UPnP keresés kattintással

N16 - UPnP gyorsítótár érvénytelenítése (SystemUpdateID)

N17 - Podcast előfizetés borítója

N18 - Hierarchikus (elválasztott) címkeböngészés

N19 - Egyetlen gyökérútvonal, csoportosító mezővel címkézve

N20 - Első mezőn osztozó böngészési útvonalak egyesítése

N21 - Kategória-típusú böngészési útvonalak (Standard / Rádió / Podcast)

N22 - Podcastok csoportosítása megjelenési év szerint

N23 - Egyetlen eredményt adó csoportosítási szintek összevonása

N24 - Év csoportosítás/keresés a MusicBee dátummezője alapján

N25 - Külön "Év" és "Év (éééé)" csoportosítási mezők

N32 - Rögzített szűrők és lejátszási listák típus szerint csoportosítva a gyökérnél

Beállítások párbeszédpanel és csomagolás

N26 - Szakaszolt beállítások párbeszédpanel

Összeállítás + beépülő modul átnevezése (nincs F-azonosító - csomagolási megjegyzés)

Jelvényrendszer - futásidejű állapot megjelenítése (az F40 mögötti mechanizmus)

N27 - A Mégse gomb elveti az útvonal-/sablonmódosításokat

N28 - Szó szerinti ampersandok a mezőválasztó menüben

N29 - Stabil, fordítatlan beállítások ablak címe

Lokalizáció

N30 - Többnyelvű felhasználói felület (fordítások függőben)

N31 - A súgó link a teljes felület nyelvén nyílik meg

Javítások és fejlesztések az eredeti beépülő modulon

N07 - `SortAlbumArtist` mező bekötése

N09 - Albumkonténer borító (`upnp:albumArtURI`)

N16 - UPnP gyorsítótár érvénytelenítése (`SystemUpdateID`)

F02 - `MediaRenderer:3` hirdető vezérlőeszközök

F20 - MP3 mime → `audio/mpeg`

F21 - Mime típus sorrend: nem `x-` változat először

F30 - `.mpeg` fájlkiterjesztés kezelése