Yenilikler
2.0.9 - 2026-08-23
Güncelleme bildirimi sayfalarını sizin dilinizde açar
Ne: Güncelleme bildirimindeki Yenilikler ve İndir bağlantıları artık eklentinin sayfalarını İngilizce yerine MusicBee'nin kendi dilinde açar.
Neden: Bu iki bağlantı, web sitesine göndermeden önce dili dört dilden birine (İngilizce, Fransızca, İspanyolca veya Almanca) daraltıyordu, bu nedenle çevirisi mevcut olsa bile herkese İngilizce sayfa sunuluyordu. Artık MusicBee'nin dilini değiştirmeden iletiyorlar ve web sitesinin ne sunacağına karar vermesine izin veriyorlar, ki yanlarındaki Yardım düğmesi her zaman bunu yapmıştır.
2.0.8 - 2026-08-22
Eklenti artık kendisini ağınızda keşfeden uygulamalara ve cihazlara doğru şekilde tanıtıyor ve Cihaz Profilleri ayarları tekrar hizalanıyor.
Cihazlarınız doğru üreticiyi, modeli ve sürümü gösteriyor
Ne: Bir kontrol uygulaması, telefon veya TV, ağınızda MusicBee'yi bulduğunda, bu eklentiyi artık yaiol tarafından yapılmış olarak sunuyor, eklentinin kendi sitesine işaret ediyor, onu üç rolü de (sunucu, oynatıcı ve işleyici) kapsayan olarak tanımlıyor ve gerçekten yüklü olan sürümü bildiriyor.
Neden: Her UPnP cihazı kimin yaptığını ve ne olduğunu duyurur ve kontrol uygulamaları bunu cihazın kimliği olarak gösterir. Bu eklenti hala çatallandığı orijinal eklentinin ayrıntılarını duyuruyordu: başka bir yazarın adı, kendi sitesi yerine MusicBee'nin web sitesi ve ilk sürümden beri "1.0" olarak sabitlenmiş bir model numarası. Telefonunuzdan hangi eklentiyle konuştuğunuzu, bırakın hangi sürümünü, anlamanın bir yolu yoktu. Bu ayrıntılar artık eklentinin kendisinden geliyor, böylece cihazın yanında gösterilen sürüm her güncellemeyle doğru kalıyor.
Cihaz Profilleri ayarları tekrar hizalanıyor
Ne: Cihaz Profilleri sekmesinde etiketler ve kutuları tek bir sol kenarı paylaşıyor ve eşit aralıklarla duruyor, örnekleme hızı aralığı tek bir satır olarak okunuyor.
Neden: Seçenekler zamanla sekmeye eklendikçe alanlar birbirinden uzaklaşmıştı ve örnekleme hızı aralığının "ila" etiketi yanındaki kutunun üzerine oturmuştu — ne yazdığını bildiğinizde okunabilir, ilk baktığınızda şaşırtıcıydı.
2.0.7 - 2026-08-08
Daha büyük parçalar başlıklarını ve konum kaydırıcılarını korur
Ne: Bir telefondan gönderilen daha büyük bir parça — uzun bir FLAC, yüksek çözünürlüklü veya DSD dosyası — artık doğru başlığını gösteriyor ve küçük bir parça gibi hareket ettirilebiliyor. Daha önce bazıları bunun yerine ağ üzerinden oynatılıyordu, başlık yerine bir web adresi ve hiçbir işe yaramayan bir kaydırıcı ile.
Neden: Eklenti başlamadan önce yerel kopyasını bekler, ancak daha önce bir dosyanın beklemeye değer olup olmadığına boyutuna göre önceden karar verirdi. Bu, ağınızın ne kadar hızlı olduğuna dair bir tahmindi ve bunu bilmesinin bir yolu yoktu: 65 MB'lık bir parça çok büyük olarak değerlendirildi, ardından bir saniye sonra indirme tamamlandı — zaten vazgeçtiği bekleme süresi içinde rahatça. Artık sadece indirmeyi izliyor. Hala gelmekte iken eklenti beklemeye devam eder, bu ne kadar sürerse sürsün; yalnızca aktarım gerçekten durduğunda vazgeçer, ki bunu artık eski sabit gecikmeden daha hızlı fark eder.
2.0.6 - 2026-08-03
Telefondan gönderilen albümler artık parçalar arasında boşluk olmadan çalıyor ve internet radyosu, alışılmadık derecede uzun bir şarkı olarak ele alınmak yerine radyo olarak tanınıyor.
Albümler boşluksuz çalıyor
Ne: Telefonunuzdan bir albümün tamamını gönderdiğinizde, MusicBee artık bir parçadan diğerine duraksamadan geçiyor — böylece canlı kayıtlar, DJ setleri ve kesintisiz klasik eserler bir bütün olarak kalıyor.
Neden: Standart, kontrol eden bir uygulamanın "sırada ne var" demesine izin verir, bu da kesintisiz bir birleşmeyi mümkün kılar. Bu talimat hiç kabul edilmiyordu, bu yüzden uygulamanın yaklaşan parçayı koyacak bir yeri yoktu ve onu mevcut parça gibi duyuruyordu — önceki sürümde düzeltilen albüm sorununun nedeni buydu. Artık düzgün bir şekilde kabul ediliyor: mevcut parça hala çalarken bir sonraki parça getiriliyor ve MusicBee'nin kendi oynatıcısı sınırı geçiyor.
İnternet radyosu radyo olarak tanınıyor
Ne: MusicBee'ye gönderilen canlı bir istasyon akış olarak çalınır ve asla indirilmez.
Neden: Bir yayını indirmek mantıksızdır — sonu yoktur ve atlanacak bir şey yoktur — ancak eklenti daha önce bir yayını bir müzik dosyasından ayırt etmenin bir yoluna sahip değildi, bu yüzden indirmeye başlıyor ve indirme sabit bir boyutu aştığında duruyordu. Kontrol eden uygulama, hangisini gönderdiğini belirtir ve bu artık doğrudan okunur. Ayar yok, tahmin yok.
Uzun yüksek çözünürlüklü parçalar kopyalarını korur
Ne: DSD dosyaları ve uzun 24 bit kayıtlar artık diğer parçalar gibi hareket ettirilebilir.
Neden: Yukarıdaki boyut sınırlamasına takılıyorlardı — 20 dakikalık yüksek çözünürlüklü bir hareket veya 10 dakikalık bir DSD parçası bu sınırı aşıyordu — bu yüzden kopyaları terk ediliyor ve konum kaydırıcısı, en çok incelenmeye değer materyal için çalışmayı durduruyordu. Radyo düzgün bir şekilde tanımlandığında, boyut sınırlamasına gerek kalmaz.
2.0.5 - 2026-08-03
Bir telefondan MusicBee'yi kullanmak için iki düzeltme: ses seviyesi artık her iki uçta da aynı anlama geliyor ve tüm bir albümü yayınlamak ilk parçadan sonra da çalışmaya devam ediyor.
Telefonunuzdaki ses seviyesi MusicBee'deki ses seviyesiyle eşleşiyor
Ne: telefonunuzdaki ses seviyesini maksimuma getirmek artık MusicBee'de maksimuma ulaşıyor ve MusicBee'nin kendi ayarı telefonda doğru şekilde okunuyor.
Neden: eklenti, kontrol eden uygulamaya en yüksek ses seviyesinin ne olduğunu asla söylemedi, bu yüzden her uygulama tahmin etmek zorunda kaldı. Bunlardan biri 69'a karar verdi, bu da %100'ünün MusicBee'de sadece %69'a ulaştığı anlamına geliyordu, MusicBee'nin %100'ü ise telefonda %144 olarak geri döndü — ve telefonun ses düğmeleri asla tam olarak en üste ulaşamadı. Oluşturucu artık aralığı açıkça belirtiyor, böylece her iki uç da aynı ölçekten bahsediyor.
Bir albümü yayınlamak başlıklarını ve konum kaydırıcısını korur
Ne: bir telefondan gönderilen bir albümün her parçası artık sadece ilk parça değil, doğru başlığını gösteriyor ve içinde hareket ettirilebiliyor.
Neden: kontrol eden bir uygulama, mevcut parçadan saniyenin küçük bir kısmı sonra bir sonraki parçayı duyurur ve bu duyuru, çalmak üzere olan parça için getirilen kopyayı iptal ediyordu — bu yüzden çoğu parça sessizce ağ üzerinden çalmaya geri döndü, bu da hem başlığı hem de etrafta gezinme yeteneğini kaybeder. Birkaç parça için kopyalar artık yan yana tutuluyor, böylece bir duyuru artık kullanımda olanı iptal edemez.
2.0.4 - 2026-08-02
Bir telefondan veya başka bir sunucudan MusicBee'ye gönderilen müzik artık gerçek bir parça gibi davranır: içinde gezinebilirsiniz ve doğru başlığını hemen gösterir. Ayrıca, kendilerini tek bir birleşik cihaz olarak sunan hi-fi yayıncılar için bir düzeltme.
Başka bir yerden gönderilen bir parçada gezinme
Ne: konum kaydırıcısını sürüklemek artık telefonunuzdan, bir NAS'tan veya başka bir medya sunucusundan gönderilen bir parça için çalışıyor. Bunu mümkün kılmak için MusicBee, çalmaya başlarken parçanın bir kopyasını geçici bir klasöre indirir ve bu kopyayı çalar. Bir ev ağında yaklaşık bir saniye sürer, başka bir parça gönderdiğiniz anda kopya silinir ve MusicBee bir sonraki başladığında kalanlar temizlenir.
Neden: MusicBee, ağ üzerinden dinlediği bir şeyi başlatıp durdurabilir, ancak içinde gezinemez; bu nedenle kaydırıcı atlıyor ve hiçbir açıklama olmaksızın hemen geri kayıyordu. Kendi diskinizdeki sıradan bir dosyayı çalmak, bu sınırlamayı tamamen ortadan kaldırır.
İlk notadan itibaren doğru başlık ve uzunluk
Ne: dosyalarına sıradan bir dosya uzantısı vermeyen bir uygulama tarafından gönderilen bir parça, uzun bir web adresi olarak görünmek yerine, başlar başlamaz gerçek başlığını ve uzunluğunu gösterir.
Neden: MusicBee, bir parçayı - ve etiketlerini - dosya uzantısından tanımlar ve bazı oynatıcılar hiç uzantısı olmayan adresler verir. Yerel kopya her zaman doğru olanı taşır, bu nedenle parça gönderen uygulama ne ad verirse versin tanınır.
Yapılamayan bir atlama artık belirtiliyor
Ne: oluşturucu gerçekten istenen noktaya hareket edemezse, kontrol eden uygulamaya bildirilir ve uygulama bunu rapor eder.
Neden: daha önce ne olursa olsun "tamamlandı" yanıtını veriyordu, bu nedenle kaydırıcı bir saniye sonra nedenini açıklayacak hiçbir şey olmadan geri kayıyordu. Dürüst bir ret, sessiz bir redden daha kolaydır.
Birleşik hi-fi yayıncılar doğru okunuyor
Ne: MusicBee, kendisini tek bir birleşik birim olarak sunan bir cihaza (bir Marantz veya Denon yayıncısı, burada oynatıcı bir medya sunucusunun yanında bir üretici sarmalayıcısının içinde bulunur) çaldığında, eklenti artık medya sunucusunun değil, oynatıcının kendi ayrıntılarını okur.
Neden: daha önce cihazın yanlış yarısına hangi ses formatlarını işleyebileceğini soruyordu, kullanılabilir bir yanıt alamıyordu ve hiç kontrol etmeden devam ediyordu - format işlemenin en doğru olması gereken donanım tam da buydu. Bir cihazın model açıklaması da artık bir cihaz profiliyle eşleştirilirken dikkate alınıyor; yanlış yerden okunuyor ve atılıyordu.
2.0.3 - 2026-08-02
Oynatma rolü büyüyor: MusicBee artık yalnızca sahip olduğu parçalar yerine, kütüphanesinde olmayan müzikleri (telefonunuzdaki, bir NAS'taki veya başka bir sunucudaki bir dosya) alabilir.
Yalnızca kendi kütüphanenizden değil, telefonunuzdan gönderilen müziği çalın
Ne: Symfonium veya BubbleUPnP gibi bir kontrol uygulamasını kullanarak MusicBee'ye müzik gönderdiğinizde, parçanın artık MusicBee'nin kendi kütüphanesinden gelmesi gerekmiyor. Telefonun kendisinde, bir NAS'ta veya başka bir medya sunucusunda depolanan bir dosya artık çalınır. Başlık ve uzunluk, gönderen uygulamadan gelir, bu nedenle MusicBee dosyayı hiç görmemiş olsa bile parça düzgün bir şekilde görünür.
Neden: oynatma rolü, bu bilgisayarın kütüphanesine telefonunuzdan göz atıp bir şarkıya dokunduğunuz durum için oluşturulmuştu — parça zaten bilgisayardaydı, bu yüzden MusicBee kendi dosyasını çaldı. Başka bir yerden gelen her şey sessizce atılıyordu, bu da özelliği, müziği telefondan iyi hoparlörlere gönderme gibi eşit derecede doğal bir durum için işe yaramaz hale getiriyordu.
Çalınamayan bir parça bunu belirtir
Ne: eğer işleyici gönderilen şeyi gerçekten çalamıyorsa, bunu gönderen uygulamaya geri bildirir.
Neden: daha önce her şeye "aldım" diye yanıt veriyordu, bu yüzden kontrol uygulaması devam edip oynat düğmesine basıyordu. Gerçekte hiçbir şey yüklenmediği için MusicBee, daha önce kalmış olan parçayı yeniden başlatıyordu — ve eğer o dosya gitmişse, kaynağının bulunamadığından şikayet ediyordu. Hata, alakasız bir parçanın adını veriyor ve gerçek sorunun yakınında hiçbir yere işaret etmiyordu.
Duraklatılmışken yeni bir parça göndermek artık o parçayı çalar
Ne: MusicBee duraklatılmışsa ve kontrol uygulamanız ona yeni bir şey gönderirse, yeni parça başlar.
Neden: devam etme, yüklemeye göre öncelikliydi, bu yüzden duraklatılmış parça kaldığı yerden devam etti ve az önce seçtiğiniz parça tek kelime edilmeden bırakıldı.
2.0.2 - 2026-08-01
Arama teması: artık sanatçıya göre çalışıyor, doğru sonuçları döndürüyor ve büyük bir kitaplıkta hızlı. Ayrıca kontrol uygulamanızın karışık çalmasını hedeflemenin yeni bir yolu ve hiçbir yere çıkmayan üç düğme için bir düzeltme.
Sanatçıya göre arama gerçekten çalışıyor
Ne: kontrol uygulamanızdan bir sanatçıyı aramak artık o sanatçının müziğini döndürüyor. Arama hem parçanın Sanatçısı hem de albümün Albüm Sanatçısı ile eşleşir, böylece bir derleme, sanatçının adını veya albümün dosyalandığı adı yazsanız da bulunur.
Neden: bir sanatçı araması daha önce "bana bu türden her şeyi ver" olarak yanlış anlaşılıyordu — yazdığınız sanatçı atılıyordu ve tüm kitaplık geri geliyordu, bu nedenle birkaç yüz parçayla eşleşmesi gereken bir arama on binlerce parça döndürüyordu. İki sanatçı alanından yalnızca birini eşleştirmek, sonuçların yarısını sessizce kaybetmiş olurdu, bu nedenle her ikisi de kontrol edilir.
Arama sonuçları sayfası düzgün çalışıyor
Ne: uzun bir arama sonuçları listesinde gezinmek artık içinde hareket ediyor. Kaydırdığınız her sayfa, aldığınız sayfadır.
Neden: sunucu daha önce her isteği ilk birkaç sonuçla yanıtlarken tam eşleşme sayısını bildiriyordu, bu nedenle daha fazlasını arayan bir uygulama aynı öğeleri almaya devam ediyor ve asla sona ulaşamıyordu.
Büyük bir kitaplıkta arama çok daha hızlı
Ne: bir arama artık tüm sonuç kümesi için tek bir sorgu çalıştırır ve yalnızca baktığınız sayfanın etiketlerini okur.
Neden: her sayfa daha önce sorguyu kitaplığa karşı yeniden çalıştırıyor ve ardından her eşleşmenin etiketlerini — binlercesini — yükleyerek bir düzine gösteriyordu. Büyük bir koleksiyonda bu, her kaydırmayı duraklatıyordu. Sonuçlar ayrıca kitaplık yenilendiğinde de bırakılır, bu nedenle bir düzenleme asla eski olarak sunulmaz.
Karışık çalmayı bir filtreye hedefleyin
Ne: Kitaplık Seçenekleri sekmesinde yeni bir Şuradan rastgele çal ayarı. Bunu Tüm Müzik olarak bırakın ve kontrol uygulamanızın Rastgele Parçalar / Rastgele Albümler klasörleri eskisi gibi davranır; MusicBee filtrelerinizden birini seçin ve her rastgele istek bunun yerine o filtreden çekilir. Gizli filtreler de sunulur.
Neden: bir karışık çalma klasörü "her şeyden" bir dilim ister ve bu, ne demek istediğiniz hakkında hiçbir ipucu taşımayan tek istektir — bu nedenle her zaman tüm kitaplıktan, konuşma ve hepsi dahil olmak üzere çekilirdi. "Her şey"in ne anlama geldiğini burada söylersiniz. Cihazdaki bir filtrenin içinden bir karışık çalma klasörünü açmak yine de o filtreyi karıştırır: göz atarken yaptığınız bir seçim ayarı geçersiz kılar.
Yardım, GitHub ve güncelleme kontrolü gerçek sayfalara ulaşıyor
Ne: ayarlar iletişim kutusundaki Yardım ve GitHub düğmeleri ve yeni bir sürüm için otomatik kontrol, artık adını verdikleri sayfaları açar.
Neden: üçü de eklentinin adının hiçbir sayfanın var olmadığı kısaltılmış bir biçiminden oluşturulmuştu, bu nedenle her biri sessizce başarısız oldu — düğmeler hiçbir şey yapmıyor gibi görünüyordu ve güncelleme kontrolü, yeni bir sürüm ne kadar süredir çıkmış olursa olsun hiçbir şey bildirmedi.
2.0.1 - 2026-07-26
Oynatma ve göz atma düzeltmeleri turu, podcast'lere ve oynatma ile karıştırmayı sağlayan denetleyici uygulamalarına (BubbleUPnP gibi) odaklandı.
Podcast'ler duraklamadan çalmaya başlar
Ne: İndirilen bir podcast bölümü artık gerçek uzunluğunu ve dosya boyutunu doğrudan diskteki dosyadan medya meta verilerine aktararak önceden belirtiyor.
Neden: Belirtilen bir süre olmadan, BubbleUPnP gibi bir denetleyici, bölümün ne kadar uzun olduğunu anlamak için her oynat düğmesine bastığınızda tüm ses akışını yeniden tarar — bu nedenle oynatma ancak fark edilir bir duraklamadan sonra başlardı. Uzunluk artık belirtildiğinde, sorunsuz bir şekilde başlar.
Sanatçıya göre göz attığınızda podcast'ler görünür
Ne: Bir podcast'in gösteri adı artık sanatçısı olarak dosyalanıyor — tıpkı Albüm alanını doldurduğu gibi, Sanatçı ve Albüm Sanatçısı alanlarına (ve bunların sıralama varyantlarına) yansıtılıyor.
Neden: Bir sanatçı alanına göre gruplandıran bir göz atma yolu, her podcast'in sanatçısını boş bulur ve boş bir seviyede çıkmaza girerdi. Gösterinin kendisini sanatçı olarak ele almak — onu albüm olarak ele almakla tutarlı bir şekilde — bu yolların artık hiçbir şey yerine bölümlere ulaşması anlamına geliyor.
"Son Çalınanlar" ve yayınlama yeniden başlatmadan sonra doğru çalışır
Ne: Bir podcast, sesli kitap, gelen kutusu veya radyo parçasını doğrudan çalmak — önce ona göz atmadan, BubbleUPnP'nin "Son Çalınanlar" listesi ve yayın hedeflerinin yaptığı gibi — artık başarısız olmuyor. Eklenti artık kimliğine göre istendiğinde parçayı isteğe bağlı olarak yüklüyor.
Neden: Bu listeler, MusicBee yeniden başlatıldıktan hemen sonra, hiçbir şeye göz atılmadan önce bir parça ister, bu nedenle eklenti kimliği hiç görmemiş ve "Geçersiz kimlik" yanıtını vermişti. Artık bu ilk doğrudan istek üzerine ilgili kaynakları zorla yükler ve parçayı bulur.
"Rastgele Parçalar" ve "Rastgele Albümler" sonuç döndürür
Ne: BubbleUPnP'nin tüm kitaplığın rastgele bir dilimini isteyen "Rastgele Parçalar" ve "Rastgele Albümler" karıştırma klasörleri artık dolu olarak geri geliyor.
Neden: Bunlar eşleşecek bir başlığı olmayan aramalardır ve eklenti daha önce bunları boş bir dahili listeden yanıtlamıştı, bu nedenle her zaman hiçbir şey göstermezlerdi. Artık — doğru şekilde sayfalanmış olarak — göz atmanın geri kalanının kullandığı aynı isteğe bağlı sorgu yolundan sunuluyorlar.
Boş etiketli albümler parçalarını listeler
Ne: Boş bir değere göre gruplandırılmış bir albümü açmak — örneğin yıl taşımayan gelen kutusu parçaları — artık parçalarını gösteriyor.
Neden: Bir albümün parçalarını toplayan eşleşme, "bu etiket boş"u "eşleşme yok" olarak ele alıyordu, bu nedenle boş bir alandan oluşan herhangi bir albüm hiçbir şeye göz atmazdı. Boş bir grup değeri artık onu paylaşan parçalarla doğru şekilde eşleşiyor.
2.0.0 - 2026-07-22
Bu, MusicBee UPnP eklentisinin açık kaynaklı yaiol çatalının ilk genel sürümüdür. İki bölüm halinde sunulmuştur: bu çatala yeni eklenen her şey, ardından orijinal eklentide yapılan düzeltmeler ve iyileştirmeler. Her öğe, projenin dahili özellik kataloğunun Ne / Neden biçimini korur, böylece her değişikliğin arkasındaki mantık, sadece değişiklik değil, sayfada yer alır.
Bu çatala yeni eklenenler
MediaRenderer - MusicBee'ye oynat
N01 - MusicBee oynatma işleyici olarak
Ne: normalde bu eklenti tek yönlü çalışır: bir telefon veya başka bir cihaz MusicBee'nin kitaplığına göz atar ve müziği kendi üzerinde çalar. Bu özellik ters yönü ekler - MusicBee'nin oynatıcı olmasını sağlar. Telefonunuzdaki bir denetleyici uygulamasından (BubbleUPnP gibi) masaüstü MusicBee'nizi çalan şey olarak seçebilir, ardından elinizden kontrol edebilirsiniz: oynat, duraklat, durdur, ileri veya geri atla, parçanın bir noktasına atla ve sesi değiştir veya sessize al.
Neden: telefonunuzu PC'nizdeki müziğin bir uzaktan kumandasına dönüştürür. Koltuğunuzda oturun, telefonunuzdaki kitaplığınıza göz atın, bir parçaya dokunun ve masaüstünüze bağlı hoparlörlerden gelir - oturduğunuz yerden tam kontrolle. Orijinal eklenti bunu çalışan bir özellik olarak hiç göndermedi.
Açma: varsayılan olarak kapalıdır, çünkü açmak, ev ağınızdaki herhangi bir şeyin PC'nizde oynatmayı başlatmasına izin verir. Bunu ayarlar iletişim kutusunun Genel sekmesindeki bir onay kutusuyla etkinleştirirsiniz. Eklentinin üç rolünün her birinin orada kendi onay kutusu vardır - kitaplığımı paylaş (Sunucu), başkalarının bana oynatmasına izin ver (İşleyici) ve diğer cihazlara oynat (Kontrol Noktası) - ve iletişim kutusu yalnızca açtığınız rollerin gerçekten ihtiyaç duyduğu ayarlar sekmelerini gösterir, bu nedenle size uygulanmayan seçeneklerle asla karşılaşmazsınız.
Makinelerinizi ayırt etme: işleyiciye istediğiniz adı verebilirsiniz ("MusicBee (yaiol)" olarak başlar). Bu ad, telefonunuzun oynatma hedefleri listesinde görünen addır, bu nedenle birden fazla PC MusicBee çalıştırıyorsa hangisinin hangisi olduğunu anlayabilirsiniz. Bir ad değişikliği, yeniden başlatmaya gerek kalmadan hemen yürürlüğe girer.
Kendi kendine oynatırken mümkün olan en iyi ses: telefonunuzdan MusicBee'nin kendi kitaplığına göz attığınızda ve bir parçayı aynı MusicBee'ye geri gönderdiğinizde, eklenti kendi dosyalarından birini çalmasının istendiğini tanır ve basitçe doğrudan diskinizden çalar. Sonuç, gereksiz yere sesi ağa ve doğrudan kendine geri itmek yerine, MusicBee'nin kendi ekolayzırı ve ses seviyesi dengelemesi uygulanmış, tam ve anında - bit-perfect'tir.
Özel olarak çalıştırma: üç rol bağımsız olarak çalışır, bu nedenle kitaplık paylaşımını kapalı bırakırken işleyiciyi açabilirsiniz. Bu "yalnızca işleyici" kurulumunda kitaplığınız ağdan tamamen gizli kalır - yalnızca oynatma hedefi duyurulur - ve MusicBee asla kendi kendine oynatmayı teklif etmez.
Oynatma davranışı
N02 - 5.1 FLAC otomatik olarak downmix edilmedi
Ne: MediaServerDevice.GetEncodedFile içindeki kanal sayısı kısıtlaması If StereoOnly OrElse Not isPcmData Then channelCount = 2 idi. Not isPcmData maddesi, kaynak kanal sayısından bağımsız olarak her PCM olmayan dönüştürmeyi (FLAC, MP3, AAC, Ogg) sessizce stereoya downmix etti, kaynak 5.1 FLAC olduğunda 5.1 özellikli işleyicileri etkisiz hale getirdi. Şimdi ikinci madde FLAC'ı hariç tutuyor: Not isPcmData AndAlso encoder.Codec <> FileCodec.Flac. FLAC 5.1 geçer; MP3/AAC/Ogg hala zorunlu stereo çünkü MusicBee'nin bu formatlar için komut satırı kodlayıcıları 2 kanallı giriş bekliyor.
Neden: 5.1 FLAC kaynağını FLAC çıktısına dönüştürmenin tüm amacı, çok kanallı miksi korumaktır. Sessiz downmix, FLAC dönüştürme seçeneğini surround dinleme için işe yaramaz hale getirdi. N02 ile doğru şeyi yapar.
Mimari
Çatalı büyük bir kitaplıkta uygulanabilir kılan yapısal değişiklik - orijinal eklentide yok.
N03 - Tembel (isteğe bağlı) göz atma ağacı
Ne: orijinal eklenti, HTTP bağlantı noktasını açmadan önce MusicBee başlangıcında tüm göz atma ağacını oluşturdu - her parçayı numaralandır, dosya başına tam Library_GetFileTags, tüm kapsayıcı hiyerarşisini birleştir. Gerçek bir kitaplıkta (50 binden fazla parça, 5400 podcast bölümü, yüzlerce istasyon) bu, dakikalarca süren soğuk başlangıçtır ve ağaç, hiçbir istemcinin asla açmadığı dallar da dahil olmak üzere sonsuza kadar RAM'de kalır. Bu çatal önceden hiçbir şey oluşturmaz: kök, uç nokta başına bir L: ön ekli yer tutucu (L:music, L:podcast, L:filter:…) gösterir; her seviye yalnızca bir istemci ona göz attığında hesaplanır (LazyBrowse → EnsureLazyEndpointInMemory → seviye başına önbellekler) ve kitaplık değişikliği bildirimleri önbellekleri temizler (SetLibraryDirty).
Neden: soğuk başlangıç esasen anında gerçekleşir - MusicBee eklenti başlatmayı bitirdiğinde HTTP bağlantı noktası açıktır - ve bellek, kitaplık boyutuna değil, göz atılanlara orantılı kalır. Takas: bir uç noktaya ilk göz atma yük maliyetini öder; yeniden giriş, bir sonraki kitaplık değişikliğine kadar önbelleğe alınır. Bu, diğer her şeyin bağlı olduğu temeldir. Tam notlar: FIXES.md.
Ağ ve sağlamlık
HTTP sunucusunun bağlama yolunu güçlendirme. Orijinal eklenti, bağlantı noktası kullanılamadığında sessizce ölür.
N04 - Kendi kendini onaran HTTP bağlantı noktası bağlama
Ne: eklentinin HTTP sunucusu, yapılandırılan bağlantı noktası kullanılamadığında artık ölmez. Üç bağlantılı değişiklik:
- Bağlama hatasında otomatik geri dönüş.
HttpServer.Startyapılandırılan bağlantı noktasını dener veSocketExceptiondurumunda ilk boş bağlantı noktasını bulmak için 20 bağlantı noktasına kadar yukarı doğru tarar. Gerçek bağlı bağlantı noktası yeni birPlugin.boundServerPortiçinde kaydedilir ve sunucuyu duyuran her şey - SSDPLOCATIONURL'leri (NOTIFY + M-SEARCH yanıtı), cihaz URL'si (PrimaryHostUrl), yönlendirici bağlantı noktası yönlendirmesi ve SSDP/kontrol noktası kendi kendine filtreleri - artıkSettings.ServerPortyerineboundServerPortokur. UPnP istemcileri SSDP aracılığıyla gerçek bağlantı noktasını keşfeder, bu nedenle taşınan bir bağlantı noktası işleyiciler için şeffaftır. - Kullanıcı bildirimi. Bir geri dönüş gerçekleştiğinde (kaydedilen bağlantı noktası kullanımda olan değilse), yerelleştirilmiş bir
MessageBox(WarnPortInUse) kullanıcıya hangi bağlantı noktasının aslında hizmet verdiğini ve cihazların onu hala bulacağını söyler - çünkü eklenti başsız çalışır ve bir iletişim kutusu içi mesajı yalnızca zaten bir sorundan şüphelenen biri görürdü. - Yeniden başlatma kurtarma.
RestartServer(ayarlar kaydetme yeniden başlatma yolu) eskidenPlugin.controller/Plugin.server'ı körü körüne referanssızlaştırırdı. BaşlangıçInitialiseonları oluşturmadan önce bir hata fırlatırsa (tam olarak başarısız bir bağlamanın neden olduğu şey), bir sonraki ayarlar kaydetme birNullReferenceExceptionile karşılaşırdı - yarı ölü bir eklenti bırakırdı. ArtıkNothingolduğunda onları yeniden oluşturur ve başlatır, böylece çalışan bir bağlantı noktasını kaydetmek, tam bir MusicBee yeniden başlatması olmadan eklentiyi canlandırır.
Neden: tetikleyici gerçek bir kullanıcı olayıydı. Eski varsayılan bağlantı noktası 49382, Windows dinamik aralığında (49152-65535) yaşar; burada Hyper-V/WSL2/Docker/WinNAT, her önyüklemede değişen büyük bloklar ayırır - bu nedenle aylarca çalıştığı bir makinede WSAEACCES ("erişim yasak") ile bağlama başarısız oldu. Varsayılanı boş bir bağlantı noktasına değiştirmek daha sonra Serviio (yeni bağlantı noktasında zaten ayrı bir DLNA sunucusu) ile çakıştı ve WSAEADDRINUSE ile başarısız oldu. Her hata Initialise içinde yutuldu, eklentiyi sessizce ölü bıraktı ve ardından bir sonraki ayarlar kaydetmede NRE'ye neden oldu. N04'ten sonra bir bağlantı noktası çakışması kendi kendini onarır - sunucu bir sonraki boş bağlantı noktasında çalışmaya devam eder, kullanıcıya bildirilir ve istemciler onu yeniden keşfeder - tüm eklentiyi çökertmek yerine.
Uygulama:
- Varsayılan bağlantı noktası
49382→9779(dinamik aralığın altında, bu nedenle Windows asla otomatik olarak ayırmaz; bilinen bir medya sunucusu varsayılanı değil) tüm üçServerPortbildiriminde + ayarlar ayrıştırma hatası geri dönüşünde taşındı. Plugin.boundServerPort(yeni paylaşılan alan) canlı dinleme bağlantı noktasını tutar;activeServerPortyapılandırılan anlık görüntüyü tutar, böylece "Yeniden Başlatma Gerekli" rozet mantığı bir geri dönüşte yanlış tetiklenmez.HttpServer.PortScanRange = 20; tarama ilk başarılıTcpListener.Start()'ta durur ve yalnızca tüm denemeler başarısız olursa son istisnayı fırlatır.- Yeni EN kaynak anahtarı
WarnPortInUse(çeviriler yayın zamanı yerel ayar geçişini takip eder).
N05 - Çok noktaya yayın grubu üzerinden SSDP duyuruları (VPN / noktadan noktaya)
Ne: SSDP duyuruları, bir IP yayın adresine değil, UPnP çok noktaya yayın grubuna (239.255.255.250) gönderilir. Bir SSDP arama yanıtı bir sunucu yeniden başlatmasıyla çakıştığında günlüğe kaydedilen zararsız "atılmış bir nesneye erişilemiyor" hatası da bastırılır.
Neden: noktadan noktaya / VPN ağ bağdaştırıcılarında, IP yayını geçerli değildir - eski yayın gönderme "geçersiz argüman" ile başarısız oldu ve duyurular kaçırıldı, bu nedenle eklenti bu bağlantılardaki istemciler için görünmezdi. Doğru çok noktaya yayın grubuna duyuru yapmak, tam olarak bu bağdaştırıcılarda keşfi düzeltir.
Kitaplık navigasyonu
Bunlar bu çatala dahil edildi ve orijinal eklentide yok. Gerçek UPnP istemcilerinden eklentinin kendi çıktısına göz atılarak elde edildi.
N06 - Filtre tabanlı kitaplık gösterimi
Ne: MusicBee'nin filtre sekmeleri (kullanıcının MusicBee klasöründeki .xautopf dosyaları) eklentinin kitaplığında UPnP kök kapsayıcıları haline gelir. Her filtrenin parçaları daha sonra AlbumArtistSort → Album → Tracks hiyerarşisinde göz atılabilir.
Neden: küratörlü MusicBee filtreleri olan kullanıcılar (örn. "5 yıldızlı parçalar", "Son eklenenler", "Klasik → Barok"), bir UPnP istemcisinden eklentiye göz atarken bunları bulmayı beklerler. Orijinal eklenti yalnızca ham kitaplık ağacını gösteriyordu.
N07 - SortAlbumArtist alanı kablolaması
Ne: eklenti artık MusicBee'nin MetaDataType 165 (Albüm Sanatçısı Sıralama) okur ve göz atma görünümlerinde sanatçıları gruplamak/sıralamak için kullanır.
Neden: hi-fi tarayıcılar ve odyofiller, kitaplıkları düzenlemek için sıralama-sanatçı adlarını ("Ludwig van Beethoven" yerine "Beethoven, Ludwig van") kullanır. Ciddi dinleyiciler için standart beklenti. Her iki yukarı akışta da eksik.
N08 - Çok değerli Albüm Sanatçısı işleme
Ne: bir albümün AlbumArtist alanı "; " ile ayrılmış birden fazla sanatçı içerdiğinde (örn. "yaiol; Ars Ricercata"), parça artık adları birleştiren tek bir Frankenstein sanatçısı altında değil, göz atma görünümlerinde her sanatçının altında görünür.
Neden: işbirlikçi albümler ve derlemeler her işbirlikçinin altında görünmelidir. Bu olmadan, albümü bulmak için arama yollarının yarısı bozuktur.
N09 - Albüm kapsayıcı resmi (upnp:albumArtURI)
Ne: DIDL Göz At yanıtlarındaki albüm kapsayıcı düğümleri artık albüm kapağını işaret eden bir upnp:albumArtURI öğesi içerir.
Neden: bu olmadan, bir UPnP istemcisinin göz atma görünümündeki her albüm, albüm kapağı yerine genel bir simge gösterir. Navigasyon için görsel ipucu; her modern hi-fi tarayıcısı tarafından beklenir.
N10 - Filtre albümleri içindeki parça sıralaması
Ne: filtreyle gösterilen bir albüm içindeki parçalar artık Disk Numarasına, ardından Parça Numarasına göre sıralanır.
Neden: standart albüm sırası. Açık sıralama olmadan, parçalar filtrenin onları döndürdüğü herhangi bir sırada geri geliyordu - genellikle rastgele görünüyordu.
N11 - Çalma listesi klasör ağacı düzeltmesi
Ne: LoadLibraryPlaylists işlevi (başlangıçta Steven Mayall tarafından, ~2014) yeni oluşturulan çalma listesi klasörlerine inemedi. Her klasördeki ilk çalma listesi, artı herhangi bir alt klasör, kök düzeyinde yetim kaldı.
Neden: orijinal eklentide on bir yıldır mevcuttu. BubbleUPnP'yi açıp Çalma Listeleri'ne tıkladıktan sonra 30 saniye içinde görünür. Ağaç oluşturma sırasında yeni oluşturulan klasörlere doğru şekilde özyinelemeli olarak inerek yaiol'da düzeltildi.
N12 - XML-yasadışı kontrol karakteri temizliği
Ne: C0 kontrol karakteri (örn. kötü bir kodlama geçişinden 0x19 - UTF-8 → Latin-1 → 0x99'u 0x19'a geri kesme) içeren bir etikete sahip herhangi bir parça, kötü parça sayfalandırılmış bir gruba girdiğinde tüm Göz At yanıtının Action Failed ile başarısız olmasına neden oldu.
Neden: XML 1.0 çoğu C0 kontrol karakterini yasaklar ve XmlWriter herhangi birini yazması istendiğinde hata fırlatır. Orijinal eklentide mevcuttu. XmlConvert.IsXmlChar aracılığıyla her Library_GetFileTags çıkış noktasında geçersiz karakterleri kaldırarak düzeltildi.
N13 - Sayfalandırılmış Göz At'ta radyo listeleme deterministik
Ne: Radyo kapsayıcısı için Göz At, her çağrıda files.Sort(AlbumFileComparer)'ı çağıran genel dosya listesi dalına düştü. Radyo girişlerinin boş Albüm/Disk/Parça etiketleri vardır, bu nedenle her karşılaştırma 0 döndürdü - List(Of T).Sort kararsızdır, her çağrıda farklı bir sıra üretir. UPnP kontrol noktaları sayfalandırır (BubbleUPnP 0..15'i sonra 16..sonu getirir); iki çağrı arasında liste yeniden düzenlendi, bu nedenle bazı istasyonlar her iki sayfada da (yinelenenler) ve bazıları hiçbirinde (eksik) göründü - her yenilemede rastgele görünüyordu.
Neden: orijinal eklentide mevcuttu (yazarı UPnP aracılığıyla radyoya asla göz atmaz). Burada Browse içinde özel bir ContainerCategory.Radio dalı ile düzeltildi, çağrı başına sıralama yok; radioFiles yükleme zamanında Başlığa göre bir kez sıralanır (kararlı). Sayfalandırılmış göz atma artık deterministik bir sıra görür; sayfa 1 ve sayfa 2 ayrık.
N14 - UPnP Arama albüm sınıfı albüm kapsayıcılarını döndürür
Ne: albüm sınıfı sorguları için UPnP Arama (upnp:class = "object.container.album.musicAlbum", örn. BubbleUPnP'nin "Rastgele Albümler") albüm kapsayıcıları yerine tam parça listesini döndürdü, bu nedenle istemci sıfır albüm gösterdi. Orijinal işleyici yalnızca parantez içindeki kriterleri ayrıştırdı, ardından istenen sınıftan bağımsız olarak tüm parçaları döktü.
Neden: burada düzeltildi - albüm sınıfı sorguları artık farklı albümleri (Albüm Sanatçısı+Albüm'e göre gruplandırılmış) numaralandırır ve her birini kapak resmiyle uygun bir musicAlbum kapsayıcısı olarak yayar, Salb<idx> sanal kimlik alanı aracılığıyla adreslenebilir, böylece istemci bir sonuca inebilir ve oynatabilir.
N15 - Tıklanabilir, kapsam duyarlı UPnP araması
Ne: orijinal hiçbir arama yeteneği duyurmadı (GetSearchCapabilities boş döndürdü), bu nedenle istemciler arama bile göndermeyi reddetti; ve eski arka uç, tembel ağaç çağında kalıcı olarak boş olan musicFiles'tan okudu. Bu çatal, gerçek aranabilir özellikleri duyurur, tembel kitaplığa karşı başlığa göre parçaları ve başlığa göre albümleri uygular (HandleLazySearch), gerçek bir kapsayıcı kimliği gönderildiğinde sorguyu istemcinin mevcut dalına sınırlar (aksi takdirde L:music yerine geçer, böylece üst çubuk aramaları podcast/radyo/sesli kitap gürültüsünü sürüklemez) ve bir Browse erken dalının albümün parçalarına geri eşlediği sentetik Ssrch_alb_* kimlikleri aracılığıyla albüm sonuçlarını tıklanabilir hale getirir. (Albüm sınıfı sonuçlarının kapsayıcı olarak parçası N14'tür.)
Neden: BubbleUPnP'deki arama, "Kitaplık aramayı desteklemiyor"dan yararlı, kapsamlı, oynatılabilir sonuçlar döndürmeye geçti. Tam tasarım + reddedilen yaklaşımlar: SEARCH.md.
N16 - UPnP önbellek geçersiz kılma (SystemUpdateID)
Ne: orijinal sabit bir SystemUpdateID=0 döndürdü - UPnP ContentDirectory önbellek geçersiz kılma sözleşmesi - bu nedenle spesifikasyona uygun istemciler (BubbleUPnP) kitaplığı asla değişmeyen olarak ele aldı: eski göz atma sonuçları, URL şeması değişikliğinden sonra 404 küçük resimler ve "değişiklikleri görmek için MusicBee'yi iki kez yeniden başlatma" dansı. Bu çatal, SystemUpdateID'yi yüklemede epoch-saniyelerden besler (böylece her yeniden başlatma kesinlikle sonuncunun önündedir) ve her kitaplık mutasyonu ve ayar değişikliğinde artırır (SetLibraryDirty / ResetCache → BumpSystemUpdateId).
Neden: istemciler bir sonraki göz atmalarında düzenlemeleri, yeni dosyaları ve ayar değişikliklerini güvenilir bir şekilde alır. Bilinen sınır: abone olan istemcilere GENA aracılığıyla yeni değer aktif olarak yeniden itilmez (gelecekteki çalışma olarak park edildi); bir sonraki göz atmalarında hala görürler.
N17 - Podcast abonelik resmi
Ne: podcast kutucukları resim göstermedi - her /PodcastThumbnail/ isteği 404 döndürdü. İki yığılmış hata: çözümleme zinciri MusicBee'nin gerçek resim önbelleğini (%LocalAppData%\MusicBee\MusicBee\InternalCache\Subscriptions\<name>.jpg, masaüstü UI'nin yüklendiği yer) asla kontrol etmedi ve HTTP katmanının unescape+küçük harf, besleme URL'si rota anahtarını son yol segmentine kadar bozdu. Bu çatal, MB'nin InternalCache'inden resmi çözer ve HTTP katmanından sağlam bir şekilde geçen URL güvenli bir slug aracılığıyla aramaları yönlendirir (PodcastSlug / podcastSubIdBySlug).
Neden: abonelik resmi artık göz atma görünümlerinde işlenir (önceden 404 olan tüm 22 istek çözülür).
N18 - Hiyerarşik (sınırlı) etiket göz atma
Ne: herhangi bir alan Kitaplık Seçenekleri sekmesinde hiyerarşik olarak işaretlenebilir ve tek karakterli bir sınırlayıcı verilebilir (ekle/kaldır ile bir alan seçici + sınırlayıcı kutusu, eklenti ayarlarında kalıcı). Gruplandırmayı / ve Jazz/Cool Jazz gibi bir değere ayarlayın, ardından tek bir düz giriş yerine Jazz › Cool Jazz olarak göz atar. Tam olarak bir dalda etiketlenmiş parçalar (sadece Jazz) kendi [Jazz] düğümünü alır, böylece hiçbir şey gizlenmez, tek bir çocuğu olan bir dal kendi kendine çöker ve ; sınırlayıcı olarak reddedilir çünkü MusicBee'nin kendi çok değerli ayırıcısıdır.
Neden: bir kullanıcının tek bir alana zaten kodladığı derin etiket taksonomileri (tür ağaçları, ruh hali hiyerarşileri, "Klasik/Barok/Konçerto") nihayet, kullanıcının baştan sona okuması gereken düz bir eğik çizgiyle ayrılmış dizeler duvarı yerine, etiketin tanımladığı ağaç olarak göz atar.
N19 - Gruplandırma alanına göre etiketlenmiş tek kök yolu
Ne: kökteki tek bir göz atma yolu, tam kısa yolu yerine gruplandırma alanına (örn. "Tür") göre etiketlenir, birleştirilmiş ilk alan gruplarının adlandırılma şekliyle eşleşir.
Neden: göz atma ağacı tutarlı bir şekilde okunur - bir kök girişinin tek başına durup durmadığı veya kardeşlerle birleştirilip birleştirilmediği (N20) tek bir adlandırma kuralı - birleştirilmiş komşuları temiz bir alan adı gösterirken, yalnız bir kök girişinin ayrıntılı bir dahili yol göstermesi yerine.
N20 - İlk alanı paylaşan göz atma yollarını birleştir
Ne: aynı ilk alanı paylaşan iki göz atma yolu - "Tür / Albüm Sanatçısı Sıralama" ve "Tür / Podcast Kişileri" - kökte yan yana iki neredeyse aynı "Tür / ..." girişi yerine, önce tür değerlerini listeleyen ve ardından iki görünüme ayrılan tek bir Tür kök klasörüne çöker.
Neden: ortak bir alan altında iç içe geçmiş birkaç ilgili görünümü olan bir kullanıcı, kökün neredeyse aynı üst düzey girişlerle dolu olduğunu gördü. Bunları birleştirmek, kökü okunabilir tutar ve ilgili görünümleri ait oldukları yere - paylaşılan alanlarının altına - gruplandırır.
N21 - Kategori türünde göz atma yolları (Standart / Radyo / Podcast)
Ne: her göz atma yolu kategoriye göre türlenir - Standart, Radyo veya Podcast. Şablon listesi bu üç bölüme ayrılır, her şablonun alan seçicisi yalnızca o kategorinin verilerinin gerçekten sağlayabileceği alanları sunar ve bir şablon yalnızca Görünüm ağacındaki eşleşen düğümlere uygulanabilir (uyumsuz düğümler grileşir ve işaretlenemez). Ayrılmış Radyo ve Podcast şablonları silinemez, bu nedenle kategori bölümleri asla kaybolmaz.
Neden: türleme olmadan bir kullanıcı sessizce boş çıkan bir düzen oluşturabilirdi - bir radyo istasyonunun "albümü" yoktur, bir podcast bölümünün "albüm sanatçısı" yoktur - ve bunu yalnızca bir UPnP istemcisinden ölü bir klasöre göz atarak keşfederdi. Alan menüsünü ve uygulama hedeflerini kategorinin gerçek verileriyle sınırlamak, boş düzenlerin oluşturulmasını engeller.
N22 - Podcast'leri yayın yılına göre gruplandır
Ne: her podcast bölümünün yayın tarihi okunur, bu nedenle Yıl seviyesi olan bir podcast göz atma yolu, bölümleri tek bir "Bilinmeyen" altında toplamak yerine yıla göre gruplandırır.
Neden: büyük podcast abonelikleri, eklenti bölüm başına yayın tarihine hiç bakmadığı için her bölümün tarihsiz bir yığına düşmesi yerine, kitaplığın geri kalanı gibi yıla göre gezilebilir hale gelir.
N23 - Tek sonuçlu gruplandırma seviyelerini daralt
Ne: tek bir değere çözülen bir gruplandırma seviyesi - yalnızca LP'ler yapan bir sanatçı için yalnızca "LP" gösteren bir Kayıt Türü seviyesi veya tek bir harf içeren bir harf seviyesi - otomatik olarak atlanır ve kullanıcıyı doğrudan içeriğine düşürür.
Neden: tam olarak bir klasör içeren bir klasöre göz atmak tamamen sürtünmedir. Tek seçenekli seviyeyi daraltmak, kullanıcının ulaşabileceği şeyi değiştirmeden ölü tıklamayı ortadan kaldırır.
N24 - MusicBee'nin tarih alanına göre yıl gruplandırma/arama
Ne: yıl koşulu artık MusicBee'nin tam tarih "Yıl" alanını çıplak dört haneli bir değerle sorgulamaz ve sabit kodlanmış yıl alanı takma adı gitti, böylece her gruplandırma alanı artık yol tanımından genel olarak çözülür.
Neden: Yıl etiketi tam bir tarih içeren kitaplıklar için, yıla göre gruplandırma veya arama daha önce hiçbir şey döndürmedi - dört haneli sorgu tam tarih alanıyla asla eşleşmedi. Doğru alanı sorgulamak, yıl gruplandırma ve aramanın parçaları tekrar bulmasını sağlar.
N25 - Ayrı "Yıl" ve "Yıl (yyyy)" gruplandırma alanları
Ne: albüm gruplandırma ve göz atma yolları artık MusicBee'nin kendi yıl alanlarının her ikisini de gösterir - Yıl (tam tarih etiketi) ve Yıl (yyyy) (sadece dört haneli yıl) - böylece kullanıcı bir albüm gruplandırması veya bir göz atma yolu tanımlarken ikisinden birini seçebilir.
Neden: iki alan MusicBee'de farklı şeyler ifade eder ve bunları birleştirmek bu ayrımı kaybetti. Her ikisini de göstermek, kullanıcının bir yılın her sürümünü bir araya getirmesine (yyyy) veya tam tarih sıralamasını (tam Yıl etiketi) korumasına olanak tanır.
N32 - Sabitlenmiş filtreler ve çalma listeleri kökte türe göre gruplandırıldı
Ne: sabitlenmiş bir filtre artık göz atma kökünde Filtreler klasörünün hemen altında ve sabitlenmiş bir çalma listesi Çalma Listeleri klasörünün hemen altında görünür, tüm sabitlemeler kökün sonunda tek bir kümede toplanmak yerine. Her sabitlenmiş kısayol kendi türüyle birlikte durur.
Neden: bir kullanıcı daha fazla kısayol sabitledikçe, karışık filtreler ve çalma listelerinden oluşan tek bir sondaki küme taranması zorlaşır ve her kısayolu ait olduğu klasörden ayırır. Sabitlenmiş öğeleri kendi kategorileri altında gruplandırmak, kökü okunabilir tutar ve her kısayolu ait olduğu şeylerin yanında tutar.
Ayarlar iletişim kutusu ve paketleme
N26 - Bölümlere ayrılmış ayarlar iletişim kutusu
Ne: Tercihler sayfası, Genel / Oynatma / Kitaplık / Cihaz Profilleri / Tanılama bölümleriyle sol gezinme düzenine sahip oldu.
Neden: orijinal, her ayarın tek, uzun, düz bir listesiydi - onu inşa eden geliştirici için iyi, diğer herkes için kafa karıştırıcı. Bölümlere ayırma, ilgili seçenekleri gruplandırır ve iletişim kutusunun modern uygulama ayarlarına daha çok benzemesini sağlar.
Derleme + eklenti yeniden adlandırma (F-id yok - paketleme notu)
Ne: derlenmiş DLL mb_UPnP_yaiol.dll olarak adlandırılır ve eklenti kendini "MusicBee UPnP (yaiol)" olarak bildirir. Orijinal mb_Upnp.dll'den farklıdır.
Neden: kullanıcılar yaiol'u orijinal eklentiyle birlikte kurabilir ve davranışı yan yana karşılaştırabilir.
Rozet sistemi - çalışma zamanı durumunu gösterme (F40'ın arkasındaki mekanizma)
Ne: önemli çalışma zamanı koşullarını Ayarlar iletişim kutusunda görünür renkli rozetler olarak göstermek için genel bir UI deseni. Mevcut örnekler:
- ⚠ Maks Bağlantı (N04) - MusicBee başladığından beri maksimum bağlantı sınırına en az bir kez ulaşıldığında tetiklenir. Yapışkan oturum bayrağı
Plugin.MaxConnectionsHit. Boş yuva olmadığındaWaitOnSendBarrieriçinde ayarlanır. - ⚠ Yeniden Başlatma Gerekli - kaydedilen bir ayarın yürürlüğe girmesi için MusicBee yeniden başlatması gerektiğinde tetiklenir. Yapışkan oturum bayrağı
Plugin.RestartRequired. Yeni kalıcı değer çalışma zamanı anlık görüntüsünden (Plugin.activeMaxConnections,Plugin.activeServerPort,Plugin.activeIpAddress) farklı olduğunda iletişim kutusunun Kaydet işleyicisinde ayarlanır. Yeniden başlatma gerektiren ayarlar, gerçekten sıcak yeniden yüklenemeyenlerle sınırlıdır - HTTP sunucusu bağlama parametreleri ve Initialise'da bir kez oluşturulan SemaphoreSlim.
Neden: eklentinin günlük dosyası teknik kullanıcılar için hata ayıklama için iyidir, ancak "cihaz yanlış ses çıkarıyor" veya "oynatma yavaş" diyen teknik olmayan bir kullanıcı asla Tanılama → Günlüğü görüntüle'yi açmaz. Rozetler, kullanıcının bir şey olduğunu bilmesi gereken durumları yakalar ve eklentiyi bir sonraki açışlarında gösterir - hiçbir şey okumadan keşfedilebilir.
Gelecek için yeniden kullanılabilir:
- Profil uyuşmazlığı algılandı (cihaz kullanıcı aracısı hiçbir profille eşleşmedi, Genel'e geri döndü).
- NextURI geri çekilmesi tetiklendi (F13 - aralıksız oynatma, sorunlu bir cihazda oturum için devre dışı bırakıldı).
- Kitaplık taraması başarısız / kısmi.
- İşleyici bağlantısı oturum ortasında kesildi.
- "Bir kez oldu, kullanıcı bilmeli"nin "1000 diğer satır arasında sessizce günlüğe kaydedildi"den daha iyi olduğu diğer herhangi bir durum.
Uygulama kuralları:
- Rozet etiketleri iletişim kutusu düzeyinde yaşar (herhangi bir panelin içinde değil), böylece kullanıcı hangi bölümde olursa olsun görünürler.
- Kaydet/İptal'in yakınındaki alt satır boyunca konumlandırılır (mevcut: y=410 yatay olarak yığılmış).
- Her rozetin, durum oluştuğunda True olan ve yalnızca MusicBee yeniden başlatıldığında sıfırlanan
Pluginiçinde karşılık gelen bir yapışkan oturum bayrağı vardır. - Kaynaklar:
<Condition>Badge(etiket metni, ⚠ ile ön ekle) +<Condition>BadgeTip(nedeni + çözümü açıklayan araç ipucu). - "Kaydedilen ayar yeniden başlatma gerektiriyor" rozetleri için,
Plugin.Initialise()'da bir çalışma zamanı anlık görüntüsü alın ve iletişim kutusu Kaydet işleyicisindeSettings.SaveSettings()'ten sonraSettings.*ile karşılaştırın.
N27 - İptal, yol/şablon düzenlemelerini atar
Ne: ayarlar iletişim kutusunda yollara ve şablonlara yapılan düzenlemeler, kullanıcı İptal'e tıkladığında sessizce uygulanmış kalmak yerine artık atılır ve oturum sırasında kaldırılan herhangi bir ayrılmış şablon yeniden oluşturulur. (Şablonlar aksi takdirde düzenlendikçe canlı olarak kaydedilir - Yollar sekmesinde ayrı bir Kaydet düğmesi yoktur.)
Neden: İptal, iptal anlamına gelmelidir. Daha önce, yol/şablon değişiklikleriyle deney yapan ve geri çekilen bir kullanıcı, değişikliklerin zaten işlendiğini ve bunları manuel olarak yeniden yapmak dışında geri almanın bir yolu olmadığını gördü.
N28 - Alan seçici menüsünde değişmez ampersanlar
Ne: adı "&" içeren bir alan - örn. "Ruh Hali & Bağlam" - ampersanı Alt-mnemonic öneki olarak yutmak yerine alan seçici menüsünde değişmez olarak işler.
Neden: ampersan içeren alan adları yanlış görüntülendi (karakter kayboldu ve bir sonraki harf bir hızlandırıcı oldu), menü girişini tanımayı zorlaştırdı.
N29 - Kararlı, çevrilmemiş ayarlar penceresi başlığı
Ne: ayarlar penceresi başlığı "MusicBee UPnP Eklentisi" marka dizesine sabitlenmiştir ve artık arayüz diliyle değişmez; dil başına DialogTitle dizesi her yerel ayar paketinden çıkarılmıştır.
Neden: dil başına kelime değişen bir pencere başlığı, hiçbir faydası olmayan çevrilebilir bir yüzeydi - başlık bir marka işaretidir. Sabitlemek, her yerde kararlı ve tutarlı kalmasını sağlar.
Yerelleştirme
Orijinal eklenti yalnızca İngilizce'dir. Bu çatal tamamen yerelleştirilebilir - her kullanıcıya yönelik dize bir kaynak paketi aracılığıyla akar ve eklenti MusicBee'nin kendi UI dilini otomatik olarak algılar.
N30 - Çok dilli UI (çeviriler beklemede)
Ne: yerelleştirme mekanizması tamamlandı ve gönderiliyor. Localisation.vb, MusicBee'nin seçilen dilini MusicBee3Settings.ini'den (<SystemLanguage> endonim) okur ve eşleşen .NET kültürünü iş parçacığına uygular, böylece My.Resources.Resources.* yerelleştirilmiş dizeyi döndürür. Her kullanıcıya yönelik etiket/düğme/mesaj bir kaynak anahtarına bağlanır (tasarımcı kontrolleri ApplyDesignerExtras + sync-en-locale.js aracılığıyla; WarnPortInUse gibi çalışma zamanı dizeleri elle eklenir). Henüz yapılmayan şey gerçek çeviridir: yalnızca İngilizce kaynak paketi (Resources.resx) mevcuttur - diğer diller için uydu paketleri, eklenti özellik açısından tamamlandığında tek bir toplu geçişte üretilir (dizeler hala değişirken parça parça çeviri çabayı boşa harcar).
Hedef diller (MusicBee'nin kendisinin sunduğu, endonymToCulture tarafından 1:1 eşleşen, böylece eklenti MusicBee'nin dilini otomatik olarak takip eder):
Arapça (ar) |
Çekçe (cs) |
Almanca (de) |
Yunanca (el) |
İspanyolca (es) |
Fransızca (fr) |
Macarca (hu) |
İtalyanca (it) |
Korece (ko) |
Hollandaca (nl) |
Norveççe (nb) |
Lehçe (pl) |
Portekizce BR (pt-BR) |
Portekizce PT (pt-PT) |
İsveççe (sv) |
Türkçe (tr) |
Ukraynaca (uk) |
Rusça (ru) |
Japonca (ja) |
Basitleştirilmiş Çince (zh-CN) |
Geleneksel Çince (zh-TW) |
İngilizce (en, kaynak) |
Varyant politikası (çalışma alanı yerel ayar kuralına göre): PT ve ZH ayrı paketlere ayrılır çünkü kelime dağarcığı/komut dosyası gerçekten farklılaşır (pt-BR/pt-PT, zh-CN/zh-TW). EN tek bir pakettir - MusicBee'nin "English(US)" (en-US) .NET'in kültür zinciri aracılığıyla en'e geri döner, bu nedenle ayrı bir US paketi üretilmez. ES ve FR da benzer şekilde tek yerel ayardır.
Neden: bir UPnP eklentisinin ayarları ("ham PCM kullanma", "küçük endian PCM'yi zorla", bağlantı noktası geri dönüş uyarıları) kişinin ana dilinde bile yeterince şifrelidir. MusicBee'nin kendi UI dilini takip etmek - İngilizce'yi zorlamak yerine - İngilizce olmayan bir kullanıcının yapılandırabileceği bir araç ile yapılandıramayacağı bir araç arasındaki farktır. Hiçbir yukarı akış bunu denemedi.
N31 - Yardım bağlantısı tam arayüz dilinde açılır
Ne: eklentiden Yardım bağlantısını açmak, temel dile çökmek yerine kullanıcının tam arayüz dilini (örn. pt-BR, zh-CN) dikkate alır ve daha net bir güncelleme kontrol tanımlayıcısı gönderir.
Neden: MusicBee'yi bölgesel bir varyantta (Brezilya Portekizcesi, Basitleştirilmiş Çince) çalıştıran bir kullanıcı, temel dilli yardım sayfasına gönderildi. Tam kültürü taşımak, onları kullandıkları tam dildeki yardım sayfasına götürür.
Orijinal eklentideki düzeltmeler ve iyileştirmeler
Çekirdek protokol ve oynatma
F01 - Güncellenmiş varsayılan DLNA cihaz profilleri
Ne: PlayStation 4, Xbox 360/One ve modern BubbleUPnP için, bu cihazların bugün gerçekten desteklediği yetenek bayraklarını (örnekleme hızları, bit derinlikleri, kodekler) yansıtan yeni varsayılan profiller gönderir.
Neden: orijinal eklentinin varsayılanları yaklaşık 2014'te donmuştu. PS4/Xbox/BubbleUPnP o zamandan beri yüksek çözünürlüklü ses desteği kazandı. Kutudan çıktığı gibi, yeni bir kurulum, kullanıcının cihaz profili ayarlarına dokunmasına gerek kalmadan bu cihazlarda sınıfının en iyisi oynatmayı sağlar.
F02 - MediaRenderer:3 duyuran kontrol cihazları
Ne: eklenti, MusicBee'nin onu sürüp süremeyeceğine karar vermek için bir işleyicinin UPnP hizmet açıklamasını araştırır. Orijinal yalnızca urn:schemas-upnp-org:device:MediaRenderer:1 ile eşleşti. Modern cihazlar :2 veya :3 duyurur. F02 eşleşmeyi genişletir.
Neden: bu olmadan, Sonos / WiiM / Eversolo'nun son birimleri, aynı protokolü konuşsalar bile MusicBee'nin "Oynat" cihaz listesinde hedef olarak görünmezler. Tek bir dize önek eşleşme düzeltmesi, tüm modern cihaz neslini açar.
F03 - "Yerel akışı zorla" profil başına seçenek (varsayılan AÇIK)
Ne: işaretlendiğinde, eklenti orijinal dosya baytlarını cihaza dönüştürme, DSP, ReplayGain işleme uygulanmadan gönderir. Kullanıcının seçtiği ham dosya, bayt bayt (HTTP çerçeveleme hariç).
Neden: forum ifadelerine göre bu, tek başına en büyük oynatma kalitesi kazancıdır. Pahalı işleyiciler satın alan hi-fi kullanıcıları açıkça bit-perfect çıktı ister; herhangi bir DSP dokunuşu amacı bozar. Varsayılan AÇIK çünkü çoğu modern cihaz kullanıcının onlara attığı her kodeği işler ve ReplayGain/EQ isteğe bağlı olmalıdır. Profil başına olduğu için eski bir Xbox için dönüştürmeyi sürdürürken hi-fi bir DAC'a yerel gönderebilirsiniz.
F04 - "Dönüştürmeyi zorla" profil başına
Ne: yerel kodek desteğinden bağımsız olarak her akışı bu cihaza dönüştürücüden geçmeye zorlayan profil başına geçersiz kılma. F03'ün tersi (Yerel Akışı Zorla). F03 ile karşılıklı olarak dışlayıcıdır - ikisinden biri açıldığında UI diğerini otomatik olarak işaretini kaldırır.
Neden: tek bir genel geçiş, profil başına Yerel Akışı Zorla (F03) ile çelişkili olurdu. Gerçek dünya durumu: cihaz A, bit-perfect yerel akışlar isteyen bir hi-fi DAC'tır; cihaz B, FLAC'ta boğulan eski bir AV alıcısıdır. Genel bir geçişle kullanıcının diğer cihaz pahasına seçim yapması gerekir. Profil başına her cihaz doğru cevabı alır.
Uygulama:
StreamingProfile.ForceTranscoding As Boolean = False.- Kalıcılık şeması v9'a yükseltildi. v9 öncesi dosyalar eski genel değeri bir kez yükler ve yükseltme boyunca eski davranışı koruyarak tüm profillere kopyalar.
- UI: Tanılama panelinden kaldırıldı, Cihaz Profilleri bölümüne Yerel Akışı Zorla'nın yanına eklendi. İki yönlü karşılıklı dışlama işleyicileri (her birinde
CheckedChanged, sonsuz döngüyü önlemek için diğerini çevirmeden önce aboneliğini iptal eder). - Karar yeri:
Settings.ForceTranscoding→streamingProfile.ForceTranscodingiçindeWriteAudioFileDIDL.
F05 - "Küçük endian PCM'yi zorla" profil başına
Ne: PCM akışları (L16/L24 mime türleri) spesifikasyona göre büyük endian'dır. Bazı cihazlar yanlışlıkla küçük endian bekler ve uygun büyük endian verileri verildiğinde beyaz gürültü çalar. F05, bayt sırasını profil başına değiştirir.
Neden: bu olmadan, belirli cihazlar bir statik duvarı çıkarır. Semptom dramatiktir ve neden PCM kodlaması bilgisi olmadan görünmezdir - geçiş, kullanıcılara bir tahmin ve kontrol düzeltmesi verir.
F06 - "Ham PCM kullanma" profil başına
Ne: cihaz ham PCM'yi desteklediğini iddia ettiğinde, eklenti bunu kullanır. Bazı cihazlar yalan söyler - SOAP el sıkışmasını kabul ederler ancak gerçek ham PCM verilerini bozar, WAVE kapsayıcısına sarılmış PCM'yi düzgün bir şekilde işlerken. F06, cihazın ne duyurduğundan bağımsız olarak PCM-over-Wave'i zorlar.
Neden: özellikle belirli Marantz modelleri - ham PCM duyururlar ancak yalnızca WAVE çalışır. Bu olmadan, ham PCM akışları bozuk çıkar, işaret edecek bir hata mesajı olmadan.
F07 - "İçerik uzunluğu" profil başına
Ne: HTTP Content-Length başlığında hangi değeri göndereceğiniz. Dört seçenek:
- Varsayılan - bilindiğinde gerçek bayt sayısı, bilinmediğinde atla.
- Yok - başlığı asla gönderme (yalnızca parçalı kodlama).
- Yalnızca PCM - yalnızca ham PCM için gönder; diğer her şey için atla.
- Sabit -
UInt32.MaxValue - 8192gönder ("çok büyük bilinmeyen uzunluk" için bir işaretçi).
Neden: UPnP/DLNA cihazları Content-Length'e nasıl tepki verdikleri konusunda büyük farklılıklar gösterir. Bazıları tam bir sayıya ihtiyaç duyar, bazıları akışlarda bundan nefret eder, bazıları arabelleğe almaya devam etmek için bir işaretçi "gerçekten büyük" değere ihtiyaç duyar. bu daha sonra yalnızca PCM'den tüm çıktı formatlarına genişletildi çünkü aynı sorunlar dönüştürülmüş MP3/AAC akışlarında da ortaya çıktı.
F08 - "NextURI'yi temizleme" profil başına
Ne: normalde eklenti, kuyruk boşaldığında cihazın kuyruğa alınmış NextURI'sini temizler (boş bir URL ile SetNextAVTransportURI göndererek). Bazı cihazlar (özellikle Denon) boş bir NextURI'yi "her şeyi durdur" olarak yorumlar ve oynatmayı hemen durdurur. F08, eklentinin onu asla temizlemesini engeller.
Neden: bu olmadan, Denon sahipleri kuyruk boşaldığında cihazın parça ortasında kesildiğini deneyimler. F08 işaretlendiğinde, cihaz eski NextURI'yi bellekte tutar (zararsızdır - bir sonraki bir şey kuyruğa alındığında üzerine yazılır).
F09 - Dönüştürme çıktı formatı olarak FLAC
Ne: Cihaz Profilleri'ndeki dönüştürme formatı açılır menüsü artık PCM 16/24, MP3, AAC, Ogg'un yanı sıra FLAC'ı da sunar. Bunu seçmek, BASS kodlayıcısını MusicBee'nin standart FLAC dönüştürme komut satırı aracılığıyla yönlendirir (MP3/AAC/Ogg'un zaten kullandığı mekanizma).
Neden: FLAC'ı iyi işleyen ancak kaynak kodeği çözemeyen cihazlar için (örn. MusicBee'nin WMA kitaplığını FLAC'a dönüştürülmüş olarak alan bir Eversolo), bu, MP3/AAC'nin ses verilerini atacağı yerlerde kayıpsız kaliteyi korur. Kayıpsız bir dönüştürme seçeneği olmadan ele alınamayan N02'yi (5.1 downmix kontrolü) engeller.
Uygulama: Encoder.StartEncode'nin Select Case Codec bloğuna tek satırlık ekleme - FLAC, komut satırı odaklı dalda MP3/AAC/Ogg'a katılır. UI açılır menüsü 6. seçenek olarak "FLAC" alır. SettingsDialog'daki yükleme/kaydetme eşlemesi FileCodec.Flac ↔ SelectedIndex = 5'i tanımak için genişler. Mime, DLNA türü ve kodlama özelliği, önceki çalışmalardan (F21, F26) ItemManager.GetMimes / GetDlnaType / GetEncodeFeature içinde zaten kablolanmıştı.
Aralıksız (SetNextAVTransportURI)
F10 - SetNextAVTransportURI / NextURI çekirdeği
Ne: gerçek aralıksız oynatma. Cihaz, UPnP hizmet açıklamasında SetNextAVTransportURI desteğini duyurduğunda, eklenti mevcut parça bitmeden önce bir sonraki parçayı cihazda önceden kuyruğa alır. Cihaz, parçalar arasında duyulabilir bir boşluk olmadan dahili olarak geçiş yapar - bir CD çalarda duyduğunuz şey. Bu, "sürekli akış" hilesi değildir (bu, her şeyi tek bir uzun akışta birleştirir ve parça başına meta verileri kaybeder).
Neden: amiral gemisi Tier-2 özelliği. Sürekli canlı performans olarak kaydedilen albümler (canlı kayıtlar, klasik hareketler, DJ setleri) parçalar arasında yarım saniyelik bir sessizlik olduğunda yanlış ses çıkarır. Bunu düzgün bir şekilde çözmek, şimdi bu çatala dahil olan amiral gemisi bir özelliktir.
Notlar: kuyruğa alınmış ses, eklentinin HTTP sunucusu aracılığıyla streamHandle=0 (kitaplık getirme modu) kullanılarak sunulur, bu da MusicBee'nin ses motorunun kuyruğa alınmış parça için döngüde olmadığı anlamına gelir. Takas: ReplayGain/DSP/EQ efektleri bir sonraki parçaya uygulanmaz. "Yerel akışı zorla" açık olduğunda (varsayılan) kabul edilebilir.
F11 - "NextURI desteğini devre dışı bırak" profil başına
Ne: bir cihaz SetNextAVTransportURI duyursa bile, bu onay kutusu eklentiyi bu duyuruyu yok saymaya ve tek seferde tek parça oynatmaya geri dönmeye zorlar.
Neden: bazı cihazlar NextURI duyurur ancak hatalı bir uygulamaya sahiptir (çökmeler, yarım geçişler, takılmalar). Her bozuk cihazı tersine mühendislik yapmak yerine, kullanıcıya "burada kapat" geçişi verilir.
F12 - Şimdi oynatılanlar listesinde NextURI yaşam döngüsü
Ne: MusicBee NowPlayingListChanged'ı tetiklediğinde, eklenti aralıksız geçiş için neyin kuyruğa alınması gerektiğini yeniden değerlendirir. MusicBee'den NowPlayingList_GetNextIndex(1) + NowPlayingList_GetListFileUrl aracılığıyla yeni "sonraki" parçayı ister, cihazda şu anda kuyruğa alınmış olanla karşılaştırır (yeni nextPlaySourceUrl alanı aracılığıyla izlenir) ve değiştiyse yeniden kuyruğa alır (veya MusicBee bir sonraki parça olmadığını söylerse kuyruğu temizler).
Neden: F12 olmadan, kullanıcı kuyruğa alınmış parçayı kaldırdığında/yeniden sıraladığında cihaz eski bir NextURI çalmaya devam etti. Bu tarihsel olarak birkaç yineleme aldı çünkü her liste mutasyonu farklı işlem gerektirir - biz NowPlayingList_GetNextIndex'e güvenerek basitleştirdik (bu zaten karıştırma ve tümünü tekrarla sarmalamayı dikkate alır), bu nedenle tüm varyantlar aynı karşılaştırma aracılığıyla yönlendirilir.
Uygulama:
- Yeni
nextPlaySourceUrlalanı, kuyruğa alınmış olanın MusicBee kitaplık URL'sini depolar (işleyici soneki olan akış URL'si bir kitaplık yoluyla karşılaştırılamaz). MediaRendererDeviceüzerinde yeniPublic Sub RefreshQueuedNextUri(). Üç sonuç: NextURI kuyruğa alınmadı → işlem yok; kuyruğa alınmış yeni "sonraki" ile eşleşiyor → işlem yok; kuyruğa alınmış farklı → yeni URL ileQueueNextçağır (veya temizlemek içinQueueNext("")- bu F08 DoNotClearNextUri'yi dikkate alır).Plugin.ReceiveNotificationaltındaNotificationType.NowPlayingListChanged'a bağlandı.
F13 - NextURI hatası geri çekilmesi
Ne: aynı cihazda 4 ardışık SetNextAVTransportURI hatasından sonra, eklenti MusicBee yeniden başlatılana kadar o cihaz için aralıksız oynatmayı devre dışı bırakır.
Neden: bir cihaz NextURI için gerçekten bozuksa (aralıklı SOAP hataları, ağ aksaklıkları), eklenti aksi takdirde her parçada yeniden denemeye devam ederdi. F13 gürültüyü durdurur ve sessizce tek seferde tek parça oynatmaya geri döner.
F14 - Tekrar modu + NextURI entegrasyonu
Ne: F14, OnAvTransportStatusCheck içindeki F15 geçiş dedektöründe ele alınan iki duruma ayrılır:
- Tümünü Tekrarla: MusicBee doğru "sarma" URL'sini (listenin sonundaki parça 1)
Plugin.QueueNext'e kendisi iletir. Özel eklenti mantığına gerek yok - cihaz ona geçiş yapar ve F15 dedektörü her zamanki gibiPlayer_PlayNextTrack'i çağırır, bu da MusicBee'nin NPL dizinini 0'a geri sarar. - Birini Tekrarla: MusicBee AYNI parça URL'sini
Plugin.QueueNext'e iletir. Cihaz ona geçiş yapar (yeni akış işleyici, aynı kaynak). F15 dedektörü şimdiPlayer_GetRepeat()'i sorgular - eğerRepeatMode.Oneise,Player_PlayNextTrackçağrısını atlayarak MusicBee'nin NPL dizinini döngüdeki parçadan ilerletmesini engeller.
Neden: Birini Tekrarla atlaması olmadan, aralıksız geçişte Player_PlayNextTrack'i çağırmak MusicBee'yi listedeki bir sonraki parçaya ilerletirdi (Birini Tekrarla yalnızca oynatıcının UI'sında parça sonu otomatik ilerleme davranışını etkiler - Sonraki Parça her zaman ileri gider), Birini Tekrarla'nın ne anlama geldiğiyle çelişirdi.
Oynatma sayısı uyarısı: Birini Tekrarla'da, oynatma sayısı artışı MusicBee 3.7.9563+'ın döngüsel oynatmayı fark etmesine bağlıdır. Eski MusicBee sürümleri aralıksız tekrarı doğru şekilde çalar ancak oynatma sayısı artışını kaçırır. Belgelenmiş; engellemiyor.
F15 - Parça geçiş algılama durum makinesi
Ne: cihaz dahili olarak mevcut parçadan NextURI'ye geçiş yaptığında, eklentinin bunu fark etmesi ve MusicBee'ye şimdi oynatılan dizinini ilerletmesini söylemesi gerekir. Aksi takdirde MusicBee hala önceki parçada olduğunu düşünür ve oynatma sayıları / UI / scrobbling senkronizasyondan sapar.
Uygulama: her durum zamanlayıcısı tikinde GetPositionInfo.TrackURI'yi yoklar. Bildirilen URI, NextURI aracılığıyla kuyruğa aldığımız URI ile eşleştiğinde, MusicBee'de Player_PlayNextTrack'i çağırırız ve suppressNextSoapCall'ı ayarlarız, böylece ortaya çıkan PlayToDevice SetAVTransportURI'yi yeniden göndermez (bu, aralıksız oynatmayı kesintiye uğratırdı).
Neden: F15 olmadan cihaz bir sonraki parçayı çalar ancak MusicBee'nin UI'si hala önceki parçada olduğunu söyler. Kafa karıştırıcı, scrobbling'i bozar, oynatma sayısı takibini bozar. Parça geçiş algılaması, her işleyici markasının URI değişikliğini ne zaman bildirdiği konusunda kendi tuhaflıkları olduğu için uzun, işleyici başına yineleme gerektirir (bazıları önce GEÇİŞ yapıyor bildirir, bazıları yeni URI ile doğrudan OYNATILIYOR'a atlar, bazıları arada kısa bir DURDURULDU durumuna sahiptir).
Notlar: ilk denememiz BubbleUPnP işleyicisinde çalışır. Cihaz başına uç durumlar B6'da kalır.
F16 - Aralıksız geçişte patlama düzeltmesi
Ne: patlama, kuyruğa alınmış parçanın kaynak formatı (örnekleme hızı / kanallar / kodek) şu anda çalınan parçadan farklı olduğunda meydana gelir ve cihazın DAC'ını geçişte yeniden kilitlemeye zorlar. F16, formatlar farklı olduğunda kuyruk zamanında tetiklenen ve her iki tarafı da adlandıran bir NextUri:FormatChange tanılama ekler - böylece patlama duyan kullanıcılar ilişkilendirebilir.
Tanılama ayrıca hafifletmeyi de işaret eder: cihaz profilinde Dönüştürmeyi Zorla'yı işaretleyin. Bu, her parçayı tek bir dönüştürme kodeği/örnekleme hızı/bit derinliğine homojenleştirir ve kaynak formatı farkını tamamen ortadan kaldırır.
Gerçek dönüştürme-eşleştirme düzeltmesi için neden ertelendi: yapısal düzeltme (kuyruğa alınmış parçayı çalınan parçanın formatına eşleşecek şekilde dönüştürme), eklentinin HTTP sunucusu URL şemasında değişiklikler gerektirir - şu anda /encode/{id}0.{ext} kuyruğa alınmış dosyayı yerel olarak sunar. F16'nın gelecekteki bir v2'si, format başına /encode/{id}0_{rate}_{depth}.{ext} rotaları ekler ve bunları kodlayıcı aracılığıyla bağlardı. Bu, Dönüştürmeyi Zorla yeterli olmadığında gerçek bir cihaz patlamayı sergilerse yapmaya değer daha büyük bir mimari değişikliktir.
Bugünkü uygulama:
lastSourceUrlalanı, şu anda çalınan kaynak URL'sini izler.QueueNext, hem mevcut hem de kuyruğa alınmış parçalar içinFilePropertyType.SampleRate/Channels/Kindokur ve uyuşmazlık durumundaNextUri:FormatChangegünlüğe kaydeder.
F17 - Arama sonrası ilerleme çubuğu yeniden senkronizasyonu
Ne: Seek() işlevi, başarılı bir Arama SOAP'ından sonra zaten GetPlayPositionInformation()'ı çağırdı, bu da "hiç yeniden senkronizasyon yok" durumunu düzeltir. F17, UPnP'nin 1 saniyelik RelTime nicelemesinden kaynaklanan kalan 1 saniyeye kadar kaymayı kapatır: cihazın bildirilen konumu kullanıcının istenen hedefinin 1 saniye içine yuvarlandığında, eklenti artık cihazın kesmesini değil, kullanıcının alt saniye hassasiyetindeki değerine güvenir. Yalnızca cihaz dramatik olarak farklı bir şey bildirdiğinde (>1s kapalı) değerini kullanırız (arama istenenden başka bir yere indi, örn. bazı kodeklerde ana kareye yapışma).
Neden: bu olmadan, cihazın "2:30" raporuna göre 2:30.500'e arama yapmak, ilerleme çubuğunun gerçekliğin ~500ms gerisinde görünmesine neden olurdu. F17'den sonra çubuk, yaygın parça içi kaydırma durumu için kullanıcının amacına uyar ve ana kareye yapışma aykırı değeri için cihazın raporuna hala saygı duyar.
F18 - Sürekli akış / NextURI kilitleme
Ne: şimdi iki kilitleme mevcut:
- Çalışma zamanı:
Settings.ContinuousOutputaçık olduğundaQueueNexterkenFalsedöndürür. Sürekli akış kendi aralıksız mekanizmasıdır (tek uzun birleştirilmiş akış); üzerineSetNextAVTransportURIgöndermek, cihazı her parçanın ayrı bir URI mi yoksa sürekli akışın bir parçası mı olduğu konusunda karıştırır. - UI: kullanıcı genel sürekli akış onay kutusunu işaretlediğinde, şu anda görüntülenen profilin
forceNativeStreamotomatik olarak işaretini kaldırır. Sürekli akış her zaman dönüştürür, bu nedenle zorunlu yerel kombinasyonda anlamsızdır.
Neden: kullanıcının iki çakışan aralıksız mekanizmayı aynı anda etkinleştirmesini engeller. F18 olmadan, cihaz hem sürekli bir akış URI'si hem de her sonraki parça için bir NextURI alırdı, işleyiciye bağlı olarak tanımsız davranışla.
F19 - Boş NextURI hataları yok sayıldı
Ne: SetNextAVTransportURI boş bir URL ile çağrıldığında (örn. listedeki son parça), bazı cihazlar bir SOAP hatası döndürür. F19 bunları sessizce yutar - günlüğe kaydedilir ancak hata olarak yayılmaz.
Neden: "sonraki parça yok" durumu normaldir, hata değildir. Bunu ölümcül olarak ele almak günlüğü kirletir ve (bazı akışlarda) yeniden deneme fırtınalarını tetikler.
Mime türleri ve DLNA meta verileri
F20 - MP3 mime → audio/mpeg
Ne: standartlara uygun MP3 mime türü audio/mpeg'dir, audio/mp3 değil. İkincisi, çoğu cihazın tolere ettiği yaygın bir yanlış adlandırmadır, ancak daha katı işleyiciler onu reddeder.
Neden: standardı takip eden daha katı cihazlarda oynatmayı sessizce düzeltir. Yaiol kod tabanı bunu zaten doğru bir şekilde içeriyordu; değişiklik gerekmedi.
F21 - Mime türü sırası: x- olmayan varyant önce
Ne: bir cihaz hem audio/flac hem de audio/x-flac duyurduğunda, eklenti x- olmayan varyantı önce döndürür. Hem standart hem de deneysel mime'lara sahip herhangi bir kodek için de aynı.
Neden: x- öneki deneysel/resmi olmayan mime'ları işaretler. Bazı işleyiciler standart formla daha iyi davranır. Küçük yeniden sıralama, gerçek dünya etkisi.
F22 - Opus mime türü desteği
Ne: Opus'u akışa uygun bir ses kodeği olarak tanır; Opus parçalarını sunarken audio/opus mime gönderir.
Neden: Opus artık yaygın (modern konuşma/müzik uzlaşma kodeği). F22 olmadan eklenti, Opus dosyalarını onları işleyen cihazlara bile akış yapmayı reddederdi.
F23 - Monkey Audio (APE) kaynak dosyası desteği
Ne: .ape dosyalarını akış/dönüştürme için geçerli bir kaynak kodeği olarak tanır.
Neden: APE, niş ama sadık bir kullanıcı tabanına sahip kayıpsız bir formattır. Eklemek az maliyetlidir ve bu kullanıcılar için kitaplığı açar.
F24 - AAC / ALAC mime geri dönüşü
Ne: bir cihaz AAC veya ALAC'ı destekliyorsa ancak bunları UPnP hizmet açıklamasında açıkça duyurmuyorsa, eklenti yine de bunları bir geri dönüş olarak sunar.
Neden: AAC'yi iyi işleyen birkaç cihaz, yetenek XML'lerinde listelemeyi unuttu. F24 olmadan eklenti denemez bile, dönüştürmeyi zorlar. F24 ile eklenti dener ve cihaz yapabiliyorsa yerel olarak işlemesine izin verir.
F25 - Yerel + kodlanmış WAV akışları için DLNA tür bayrağı
Ne: DLNA tür bayrağı (LPCM, WAVE, MP3 gibi bir profil tanımlayıcı) cihazın aldığıyla eşleşmelidir. F25, yerel akışların ve kodlanmış WAV akışlarının doğru şekilde işaretlenmesini sağlar.
Neden: yanlış eşleşen DLNA türü, bazı cihazların oynatmayı tamamen reddetmesine veya yanlış kod çözücüyü uygulamasına neden olur.
F26 - FLAC dosyaları için DLNA başlığı
Ne: FLAC akışları, başlıklarında uygun DLNA profil tanımlayıcısını alır.
Neden: bu olmadan, FLAC'ı destekleyen bazı cihazlar akışı bu şekilde tanımaz.
F27 - Meta verilerde bit hızı hesaplama düzeltmesi
Ne: sürekli akış res@bitrate, (sampleRate * channels * bitsPerSample) / 1000 olarak hesaplanıyordu - kbps, özniteliği saniye başına bayt olarak tanımlayan UPnP DIDL spesifikasyonundan ~125 faktör kadar farklı. Şimdi 1000 yerine 8'e bölünür.
Neden: cihazda yanlış bit hızı gösterimi - çoğu işleyicide kozmetik, ancak bazıları akış arabelleklerini değerden ayırır ve olduklarından ~125 kat daha küçük görünen akışlarda takılır. Sürekli olmayan kaynak dosya yolu bunu zaten doğru bir şekilde içeriyordu ((bitrate_kbps * 1000) \ 8 = bayt/sn); yalnızca sürekli akış yolu yanlıştı.
F28 - Meta veri zaman formatı düzeltmesi (Marantz)
Ne: DIDL'deki res@duration, H:MM:SS (örn. 0:03:42) olarak biçimlendirilmişti. UPnP DIDL spesifikasyonu formatı H+:MM:SS[.F+] olarak tanımlar - kesinlikle kesirli saniyeler isteğe bağlı ancak önerilir; bazı Marantz cihazları çıplak formu geçersiz olarak kabul eder ve süre gösterimlerini boş bırakır. Şimdi H:MM:SS.fff (örn. 0:03:42.000) olarak biçimlendirilmiştir.
Neden: bir markaya özgü görüntüleme sorunu; kesirli saniyelerle uyumlu ISO tarzı format, başka hiçbir cihazı etkilemeden düzeltir. Her iki DIDL yayma sitesinde de uygulandı (kaynak dosya yolu + WriteAudioFileDIDL içindeki kodlanmış akış yolu).
Aynı geçişte bonus düzeltme: pv:addedTime ve pv:lastPlayedTime, DateTime format dizelerinde HH (24 saat) yerine hh (12 saat) kullanıyordu. 13:00 ile 23:59 arasında eklenen veya çalınan herhangi bir parça, alanı gösteren cihazlarda yanlış bir saatle (örn. 17:42 → "05:42") işlenirdi. Şimdi HH kullanır.
F29 - Kodlanmış MP3 arama desteği (CBR)
Ne: dönüştürülmüş MP3 akışları artık DLNA.ORG_OP=10 (yalnızca bayt) yerine DLNA.ORG_OP=11 (hem bayt hem de zaman arama) duyurur. Daha önce dönüştürülmüş MP3'te zaman aramayı reddeden cihazlar artık ilerleme çubuklarını/arama UI'lerini normal şekilde sürebilir.
Neden: MusicBee'nin dönüştürücüsü HighQuality ön ayarında sabit bit hızlı MP3 üretir, bu nedenle bayt ↔ zaman eşlemesi doğrusaldır - cihaz, herhangi bir kodlayıcı tarafı desteği olmadan bir zaman arama isteğini bir HTTP Range bayt aramasına kendisi dönüştürebilir. OP=11 duyurmak, cihazdaki bu UI'yi açar. F29 olmadan, dönüştürülmüş bir MP3 içinde arama yapan kullanıcılar ya aramanın sessizce yok sayıldığını ya da parça başlangıcına düştüğünü gördüler.
Uygulama: ItemManager.vb içindeki GetEncodeFeature'ı, satır içi If'i okunabilir bir If/ElseIf/Else zincirine ayıracak şekilde yeniden yapılandırdı. MP3 açıkça OP=11 alır; diğer PCM olmayan kodekler OP=10'u korur. AAC/FLAC/vb. için değişiklik yok - bunlar MusicBee'nin garanti etmediği CBR-ness'in kodek özel doğrulamasına ihtiyaç duyardı.
F30 - .mpeg dosya uzantısı işlendi
Ne: .mpeg (ve daha da nadir .mpe) uzantılı dosyalar artık GetCodec içinde FileCodec.Mp3 olarak tanınır. F30'dan önce FileCodec.Unknown döndürdüler ve kitaplıktan sessizce reddedildiler / dönüştürme kaynakları olamadılar.
Neden: eski MPEG-1 Katman 3 arşivleri bazen .mp3 yerine .mpeg kullandı (spesifikasyon her ikisine de izin verir). 300 binlik bir kitaplıkta birkaç dosya "MusicBee onları gösteriyor ama eklenti göstermiyor" hissini vermek için yeterlidir - kullanıcı için kafa karıştırıcı.
Oynatma davranışı
F31 - Radyo akışları otomatik olarak sürekli modu kullanır
Ne: WriteAudioFileDIDL artık kaynak URL'nin Kind özelliğini Library_GetFileProperty aracılığıyla araştırır ve Kind'ı "Akış" ile biten herhangi bir dosyayı (MusicBee radyo için "MP3 Akışı", "İnternet Akışı" vb. bildirir) genel Settings.ContinuousOutput geçişinden bağımsız olarak sürekli olarak ele alır. Sürekli akış DIDL dalı (Başlık: "Sürekli Akış", id="continuousstream", sabit PCM/Wave çıktısı) kullanılır; cihaz tek bir sonsuz tarzı akış görür.
Neden: radyo akışlarının parça sınırları, sabit uzunluğu, arama özelliği yoktur. Onları DIDL'de ayrı dosyalar gibi ele almak, eklentinin var olmayan bayt aralıklarını ve sürelerini duyurmasına neden oldu. MusicBee bize zaten "bu bir Akış" dediğinde otomatik geçiş yapmak, kullanıcının düşünmesi gerekmeyen bir ayak tabancasını ortadan kaldırır.
Kapsam: yalnızca MusicBee oynatmayı sürdürdüğünde geçerlidir (musicBeePlayToMode). Kitaplık getirme yolu (UPnP istemcisi göz atma) değişmeden kalır - radyo URL'leri orada nadirdir ve kullanıcıya yönelik davranış açık test olmadan değişmemelidir.
F32 - Kodek duyurusu geri dönüşü
Ne: bir cihaz belirli kodekleri duyurmazsa (veya eklenti cihazın yetenek XML'ini ayrıştıramazsa), eklenti akışı hemen reddetmez. Bunun yerine, onu sunmaya çalışır ve cihazın karar vermesine izin verir.
Neden: birçok cihazın eksik veya okunaksız yetenek XML'i vardır ancak kodeği aslında iyi işler. F32, küçük bir "en iyi tahmin ve dene"yi doğrudan bir reddetme ile değiştirir.
F33 - İlerleme çubuğu senkronizasyon iyileştirmesi
Ne: anketler arası konum zaten tek bir çapa (currentPlayStartTicks) üzerinden duvar saatiyle tahmin edilir, bu nedenle ilerleme çubuğu alt saniye hızında sorunsuz bir şekilde güncellenir. Kalan titreşim kaynağı, yeni başlayan bir parça için başlangıç çapası idi: önceki kod, durum zamanlayıcısı ilk kez Oynatılıyor durumuna geçtiğini fark ettiğinde position=0 olduğunu varsayıyordu, ancak o zamana kadar cihaz 100-500ms (bir anket aralığı) çalıyor olabilirdi. MusicBee'nin ilerleme çubuğu 0'dan başlar, sonra gerçeklik yakaladığında ileri atlardı.
F33 düzeltmesi: yeni bir parçada ilk kez Oynatılıyor durumuna geçiş yaparken (currentPlayStartTimeEstimated=True), cihazın gerçek mevcut konumunu almak için GetPlayPositionInformation()'ı çağırın, ardından buna göre çapa atın. UPnP yalnızca 1 saniyelik çözünürlük bildirir, bu nedenle çapa hala nicelenmiştir, ancak 0 varsaymaktan çok daha gerçeğe yakındır.
Neden: özellikle parça değişikliğinden hemen sonra daha sorunsuz + daha doğru ilerleme gösterimi. 1 saniyelik UPnP raporlama çözünürlüğünün kendisi etrafında dolaşmanın bir yolu yok - bu spesifikasyon.
F34 - Parça değişikliğinden sonra ilerleme çubuğu titremesi
Ne: yeni bir parça için PlayToDevice çağrıldığında, eklenti currentPlayPositionMs ve currentPlayStartTicks'i SOAP-Oynat ve yeni Oynatılıyor durumunu algılayan ilk durum zamanlayıcısı anketi arasındaki ~100ms'lik pencere için önceki parça değerlerinde bırakırdı. MusicBee'nin ilerleme çubuğu kısaca önceki parçanın sonunu gösterir, sonra 0'a geri döner, sonra tırmanırdı. F34, PlayToDevice girişinde her ikisini de sıfırlar - bir parça değişikliğinin gerçekleştiğini bildiğimiz anda, herhangi bir SOAP çalışmasından önce.
Neden: hızlı atlama kullanım durumlarında (manuel sonraki veya aralıksız geçiş) görsel aksaklık. Artık MusicBee'nin Play sonrası ilk PlayPositionMs sorgusu temiz bir şekilde 0 döndürür, ardından F33'ün GetPlayPositionInformation'ı ilk durum değişikliği tikinde cihazın gerçek konumuna göre onu iyileştirir.
Uygulama: PlayToDevice'ın üst kısmında dört satır, F33'ün geçiş zamanı doğru çapalamasıyla eşleştirildi.
F35 - "Dönüştürmeyi zorla" hatası
Ne: dönüştürmeyi zorlama, belirli kombinasyonlarda dönüştürmeyi hala atlayabilirdi. F04 profil başına yeniden çalışmasından sonra, iki özel boşluk kapatıldı:
- ForceNativeStream ile öncelik. Her ikisi de True olduğunda (bir şema geçişi veya kısmi bir ayarlar dosyası aracılığıyla olabilir), ForceTranscoding artık doğrudan kazanır (
If streamingProfile.ForceTranscoding Then forceEncode = True ElseIf streamingProfile.ForceNativeStream Then forceEncode = False). UI karşılıklı dışlama, kullanıcının her ikisini de işaretlemesini engeller, ancak çalışma zamanı koruması, diskten tutarsız yüklenen herhangi bir durumu ele alır. - bypassTranscodeDecision mantığı. Daha önce:
streamingProfile.ForceNativeStream AndAlso Not Settings.ForceTranscoding. Şimdi:streamingProfile.ForceNativeStream AndAlso Not streamingProfile.ForceTranscoding- aynı öncelik kuralı ancak aynı profil başına kapsamda.
Neden: "zorla" zorla anlamına gelmelidir. Kullanıcı bir cihaz için ForceTranscoding'i açıkça etkinleştirdiyse, eklenti diğer bayrakların nasıl birleştiğinden bağımsız olarak asla sessizce yerel akışa düşmemelidir.
F36 - İşleyici kapalı istisnası
Ne: Plugin.ReceiveNotification'ı, yakalanmayan herhangi bir istisnayı MusicBee'nin bildirim pompasına geri yayılmasına izin vermek yerine günlüğe kaydeden üst düzey bir Try/Catch içine sardı.
Neden: MusicBee'den gelen bildirimler (PlayStateChanged, VolumeMuteChanged, vb.) SOAP üzerinden işleyiciyle konuşan ControlPointManager'a gönderilir. Bireysel çağrı siteleri zaten SOAP çağrılarının etrafında Try/Catch içeriyordu, ancak yeterince tuhaf bir zamanlama durumu (örn. aynı bildirim işleyicisinde iki SOAP çağrısı arasında işleyicinin ölmesi) hala kaçabilirdi. Üst düzey sarmalayıcı, kullanıcının MusicBee'den asla genel bir "TargetInvocationException" açılır penceresi görmemesi için son güvenlik ağıdır.
Uygulama: mevcut gövdeyi ReceiveNotificationInternal olarak yeniden adlandırdı ve Try { ReceiveNotificationInternal(...) } Catch { LogError(...) } yapan ince bir sarmalayıcı ReceiveNotification ekledi. ControlPointManager içindeki (her PostSoapRequest çağrısının etrafındaki) önceden var olan yöntem başına Try/Catch altyapısı kalır - F36 kemer + askıdır.
F37 - Uzun parça arama yanlış geçişi tetikler
Ne: uzun bir parça içinde arama yapmak, bazı işleyicilerde kısa bir Durduruldu→Oynatılıyor döngüsü üretebilir. Ayrımcılık olmadan, ProcessNewPlayState.Stopped bunu doğal parça sonu olarak kabul eder ve Player_PlayNextTrack'i çağırır, kullanıcı sadece kaydırmak istediğinde MusicBee'yi ilerletir. F37, Seek() içinde lastUserInitiatedSeek'i damgalar ve Durduruldu işleyicisine 5 saniyelik bir koruma ekler (mevcut lastUserInitiatedStop penceresini yansıtır).
Neden: bir arama sırasında sessizce bir sonraki parçaya atlama, kimsenin nedenini tahmin edemeyeceği hatalardan biridir - kullanıcı "garip, ileri kaydırmaya çalıştım ve şimdi bir sonraki şarkıyı çalıyor" diye düşünür. Düzeltme mekaniktir: zaten mevcut olan kullanıcı durdurma ayrımcılığıyla aynı desen.
F38 - Çökme eğilimli kodekler için geliştirilmiş arama işleme
Ne: MP3 aramada BubbleUPnP'nin çökmesi kanonik semptomdu. Denetimden sonra, mevcut yaiol arama kodu zaten doğru şeyleri yapıyor - yerel yol HTTP Range'i doğru şekilde işler (206, Content-Range, AcceptRanges), kodlanmış yol X-AvailableSeekRange duyurur ve gelen timeSeekRange.dlna.org / npt başlıklarını ayrıştırır, DLNA.ORG_OP bayrakları gerçek akış yeteneklerini yansıtır (sorunlu Platinum cihazlar için DisablePcmTimeSeek devre dışı bırakma ile). Mevcut BubbleUPnP 4.6.4'te kullanıcı tarafından test edildi: çökme gözlenmedi.
Neden: BubbleUPnP MP3-arama çökmesi yaklaşık 2024'te bildirildi ve uygulama o zamandan beri ~16 aylık düzeltmeler aldı. F29 (kodlanmış MP3 OP=11) onu yeniden ortaya çıkarabilecek yeni değişkendi; test edilen sürümlerde yapmıyor.
Bir çökme geri dönerse: düzeltme şekli, işaretlenmiş kodeklerde DLNA.ORG_OP=10 (yalnızca bayt) zorlayan profil başına "sınırlı arama" geçişi olurdu - DisablePcmTimeSeek'in PCM için zaten nasıl çalıştığını yansıtır. O zaman ekle, önleyici olarak değil.
UI ve günlük kaydı
F39 - "Ekle" düğmesi yeni profili seçer
Ne: cihaz profilleri listesinde "Ekle"ye tıklamak yeni bir profil oluşturur VE otomatik olarak seçer, böylece kullanıcı alanları hemen düzenleyebilir. Bölümlere ayrılmış iletişim kutusu yeniden düzenlememiz bunu zaten yapıyor - hem doğrudan Ekle yolu hem de şablondan yolu Me.activeStreamingProfiles.SelectedIndex = Me.activeStreamingProfiles.Items.Count - 1 ile biter. Bir kontrol, çatalımızın bunu zaten ele aldığını doğruladı - değiştirilecek bir şey yok.
Neden: küçük bir UX kağıt kesiği, burada zaten bir kağıt kesiği olmadığı ortaya çıktı.
F40 - Daha büyük maksimum bağlantılar + uyarı günlüğü
Ne: eklentinin eşzamanlı akış sınırı (Sockets_Stream_File / Sockets_Encoder_Start etrafındaki SemaphoreSlim) sabit kodlanmış 4 idi. F40, bunu Genel ayarlar sayfasında kullanıcı tarafından yapılandırılabilir hale getirir (varsayılan 16, aralık 1-256), bir isteğin bir yuva beklemesi gerektiğinde bir MaxConnections günlük satırı ekler VE MusicBee başladığından beri sınıra en az bir kez ulaşıldıysa ayarlar iletişim kutusunun sol altında kırmızı ⚠ Maks Bağlantı rozeti gösterir.
Neden: bir cihaz paralel istekler ateşlediğinde (bazı Marantz/Linn resim taramaları sırasında, BubbleUPnP'nin aktif oynatmanın yanı sıra meta veri araştırmaları), ek istekler semaforun arkasında sessizce engellendi - kullanıcı görünür bir neden olmadan "cihaz yavaş" gördü. Günlük satırı teknik hata ayıklama için iyidir ancak teknik olmayan kullanıcılar günlükleri asla okumaz. Ayarlar iletişim kutusundaki görünür rozet, sınırı aşma durumunu eklentinin tercihlerini açan herkes için keşfedilebilir hale getirir.
Uygulama:
MusicBeeUpnp.vbiçindekiWaitOnSendBarrier(logTag)içinde beklemeyi merkezileştirdi; her iki çağrı sitesi (MediaServerDevice.GetFile,Encoder.StartEncode) onu kullanır.Settings.MaxConnections, ayarlar şemasının v8'inde kalıcı hale getirildi.Plugin.MaxConnectionsHit,WaitOnSendBarrieriçinde ayarlanan yapışkan bir oturum bayrağıdır; yalnızca MusicBee yeniden başlatıldığında sıfırlanır.SettingsDialog.maxConnectionsBadge,Plugin.MaxConnectionsHitTrue olduğunda yalnızca görünen(16, 410)konumunda kırmızı kalın bir etikettir. Nedeni ve çözümü açıklayan bir araç ipucuna sahiptir.- Semafor, tür yüklemede bir kez başlatılır, bu nedenle ayarı değiştirmek bir MusicBee yeniden başlatması gerektirir (alan etiketinde belirtilmiştir).
F41 - "ReplayGain/DSP nedeniyle kodlama" günlüğü
Ne: ayrı "RG için kodlama" / "DSP için kodlama" günlük satırları yerine, F42'den gelen tek StreamDecision satırı, birikmiş nedenler olarak MB-DSP/EQ, MB-ReplayGain, Profile-DSP/EQ, Profile-ReplayGain içerir. Aynı tanılama değeri, daha az gürültü.
Neden: kullanıcılar, belirli bir parça için dönüştürmenin neden gerçekleştiğine dair tüm nedenleri tek bir günlük satırında görür, dağılmış değil. Tam ayrıntılar için F42'ye bakın.
F42 - "İşleyici kaynak kodeği desteklemiyor" günlüğü
Ne: oynatma başına cihaza "yerel KODEK" veya "dönüştürme KODEK→KODEK neden=…" diyen bir StreamDecision günlük satırı eklendi. Neden alanı, dönüştürmeyi tetikleyen her koşulu biriktirir: MB-DSP/EQ, MB-ReplayGain, Profile-DSP/EQ, Profile-ReplayGain, WebFile, VirtualFile, ForceTranscoding(global), SampleRate<min/SampleRate>max, DownmixToStereo, DeviceLacksCodec(X), BandwidthConstrained.
Neden: kullanıcılar, yerel olarak akış yapmayı bekledikleri dosyalarda beklenmedik CPU artışları nedeniyle kafaları karıştı. Parça başına bir günlük satırı, onlara dönüştürmeyi tam olarak hangi koşulun tetiklediğini söyler - ve alan DeviceLacksCodec(Flac) gösteriyorsa, cihazın protokol bilgisinin eksik olduğunu ve F32'nin geri dönüşünün devreye girmesini isteyebileceklerini hemen anlarlar.
Uygulama: karar zinciri boyunca artımlı olarak oluşturulan tek bir biriktirici dizesi; sonunda bir kez günlüğe kaydedilir. Üretimde günlük gürültüsünü önlemek için Settings.LogDebugInfo ile korunur.
F43 - SetNextAVTransport günlüğü kaynak URL'yi gösterir
Ne: QueueNext günlük girişleri artık stream=<HTTP akış URL'si>'nin yanı sıra source=<MusicBee kitaplık yolu> içerir. Aynı değişiklik başarı yoluna ve hata yoluna (QueueNext:Failed) uygulandı.
Neden: kuyruğa alınmış bir parça sorununu ayıklarken, akış URL'si (/encode/aabbccdd0.flac) kendi başına opaktır - her parça için aynıdır. Kaynak URL, MusicBee'nin kuyruğa almaya çalıştığı dosyayı tam olarak söyleyen, insan tarafından aranabilir kitaplık yoludur.
F44 - Daha iyi mime türü hata günlüğü
Ne: Activate sırasında iki yeni günlük girişi:
Activate:MimeUnverified- cihazınGetProtocolInfoyanıtındaki bozuk giriş başına tetiklenir, hangi girişin ayrıştırılamadığını adlandırır (böylece kullanıcı örn. "Marantz, bazı kodekler içinhttp-get:*::*döndürdü - yetenek doğrulanmadı, F32'nin geri dönüşü tahmin edecek" görebilir).Activate:NoSinkInfo- cihaz hiç<Sink>öğesi döndürmezse bir kez tetiklenir.SupportedMimeTypes'ın Nothing kaldığı veIsCodecSupported'ın "her şeyin çalıştığını varsay"a düştüğü anlamına gelir - daha sonra "cihaz akışı reddetti" hataları göründüğünde yararlı bağlam.
Neden: F44'ten önce bu sessiz yetenek düşüşleri, kullanıcıların parçalarının neden beklentilere aykırı olarak dönüştürüldüğünü veya cihaz tarafından reddedildiğini tahmin etmelerine neden oldu. Artık Activate: için tek bir arama, cihazın yetenek bilgisinin kullanılabilir olup olmadığını gösterir.
F45 - Daha iyi meta veri hata günlüğü
Ne: ContentDirectoryService.vb içindeki Browse istisna günlüğü, önceki yaiol çalışmasında (Alia Vox hata oturumu) ObjectID ve yığın izi ile zaten zenginleştirilmişti. F45, BrowseFlag (meta veri vs çocuklar), Filter (istemcinin hangi öznitelikleri istediği), sortCriteria ve partialResultLength (hatadan önce kaç bayt DIDL üretildiği - kötü parçanın grubun ne kadar ilerisinde olduğunu gösterir) ile daha da genişletir.
Neden: DIDL ortasında bir şeyler ters gittiğinde, kısmi uzunluk değeri, hatanın grubun ilk parçasında mı (partial=0) yoksa ortasında mı (partial=N) olduğunu söyler - grubun startingIndex'i ile birleştirildiğinde, suçlu parça dizinini tanımlayabilirsiniz. Filter ve BrowseFlag, istemcinin ne tür bir göz atma istediğini açıklar; bazen meta veri odaklı bir göz atma, aynı kimlik için bir çocuk göz atma başarılı olduğunda başarısız olur.
Ağ
F46 - Otomatik mod yalnızca gerçek ağ bağdaştırıcılarında duyurur
Ne: Otomatik arayüz modunda eklenti, her çalışan IPv4 bağdaştırıcısında kendini (SSDP) duyururdu. Bir VPN tüneli (NordLynx) veya sanal anahtar (Hyper-V / WSL / Docker) da çalıştıran bir makinede, aynı kitaplık bu bağdaştırıcıların her birinde de duyuruldu, bu nedenle yayın yaptığınız kontrol noktası sunucuyu iki veya üç kez keşfetti ve kitaplığı yinelenen kopyalar olarak listeledi. Otomatik mod artık yalnızca gerçek bir IPv4 varsayılan ağ geçidine (HasIPv4Gateway) sahip bağdaştırıcıları tutar - tünel ve sanal anahtar bağdaştırıcılarında bu yoktur - bu nedenle bunlar duyuru listesinden çıkarılır. Kullanıcı tarafından sabitlenmiş bir adres hala doğrudan kazanır (yalnızca o arayüzde duyurur) ve hiçbir bağdaştırıcı bir ağ geçidi bildirmezse seçici her bağdaştırıcıya geri döner, bu nedenle duyurulan adres listesi asla boş olmaz ve eklenti görünmez hale gelemez.
Neden: yinelenme "bir VPN'de olmak"tan kaynaklanmaz - aynı anda LAN bağdaştırıcısında ve tünel/sanal bağdaştırıcıda duyuru yapmaktan kaynaklanır, bu nedenle bir kontrol noktası aynı sunucuyu iki adreste görür. Bir tüketici VPN'i (NordVPN/NordLynx) yalnızca internete yönelik trafiği tüneller; DLNA işleyici LAN'da yaşar ve yerel alt ağ trafiği tüneli atlar, bu nedenle tünel bağdaştırıcısı hiçbir zaman bir işleyiciye ulaşmaz - onu düşürmek, çalışan bir yolu asla değil, bir hayalet kopyayı kaldırır. Ağ geçidi testi, gerçek bir LAN/Wi-Fi bağdaştırıcısını bir tünelden veya sanal anahtardan ayıran ucuz, güvenilir sinyaldir. N05'i tamamlar (bu tür bağlantılarda duyuruların nasıl gönderildiğini düzeltti - yayın yerine çok noktaya yayın); F46, hangi bağdaştırıcıların duyuru yapacağını yönetir.
Bilinen sınır: işleyicileri gerçekten tünel boyunca yaşayan bir mesh / uzaktan erişim VPN'i (Tailscale, ZeroTier, WireGuard-to-home) genellikle varsayılan ağ geçidi olmayan bir bağdaştırıcı sunar, bu nedenle Otomatik mod onu da düşürür. Bu kullanıcılar bunun yerine VPN adresini sabitler, bu da ağ geçidi filtresine göre öncelik alır.