Muzibu Player Sistemi Analiz Raporu

19 Şubat 2026

Toplam Sorun
6
Kritik
1
İyi Olan
7
Genel Sağlık Skoru
78/100

16 saatlik çalma için orta-iyi seviyede güvenilir.

Basit Anlatım (Herkes İçin)

Sistem genel olarak stabil ve 16 saatlik arka plan çalma için uygun. En büyük risk, internet gidip geldiğinde çalmanın otomatik toparlanmasının tam garanti olmaması. Ayrıca bazı küçük bellek birikimleri uzun süreli çalışmada sistemi yavaşlatabilir. Bu iki noktaya dokunulursa kesintisiz kullanım daha güvenli hale gelir.

Neden önemli? Çünkü kafede kimse başında durmuyor; küçük bir kopma bile müziğin tamamen durmasına yol açabilir.

Teknik Detaylar (Geliştiriciler İçin)

  • HLS konfigürasyonu: `public/themes/muzibu/js/player/core/player-core.js:308-374`
  • HlsPool: `public/themes/muzibu/js/player/core/player-core.js:376-512`
  • createHlsBlobUrl: `public/themes/muzibu/js/player/core/player-core.js:166-241`
  • Queue refill + network guard: `public/themes/muzibu/js/player/core/player-core.js:7469-7578`
  • Background playback + online/offline: `public/themes/muzibu/js/player/core/player-core.js:7584-7608`
  • Debug panel cihaz/bağlantı: `public/themes/muzibu/js/player/features/performance-debug.js:345-354` ve `2232-2251`

Değişiklik Doğrulama

Değişiklik Beklenen Bulgu Durum
enableWorker: true HLS decode worker ile `HLS_SHARED_CONFIG.enableWorker = true` ✅ Doğru
ontimeupdate throttle 250ms (6 yer) Her handler başında 250ms throttle Satırlar ~2602, ~2942, ~4025, ~4208, ~5232, ~5443 ✅ Doğru
Progress interval 100ms → 250ms setInterval(..., 250) Satırlar ~2314, ~5771, ~5829 ✅ Doğru
Blob URL variant absolutization Adım 3.5 + double query guard `createHlsBlobUrl` içinde adım 3.5 mevcut ✅ Doğru
Network offline/online recovery Offline guard + online refill `_networkOffline` guard + offline/online listener’ları mevcut ✅ Doğru
Cihaz/bağlantı debug paneli captureFullState + updatePanel bölümü `device{}` snapshot + “📱 Cihaz & Bağlantı” bölümü var ✅ Doğru

Sorun Kartları

🔴 KRİTİK • public/themes/muzibu/js/player/core/player-core.js:7584-7608, 7469
Offline → Online sonrası aktif HLS toparlanmıyor
Ne oluyor? Online event’inde yalnızca `checkAndRefillQueue()` çağrılıyor. HLS.js veya audio element stall durumunda kalırsa otomatik yeniden başlatma yok.
16 saatte etkisi? Kafe Wi‑Fi kısa süreli kopup geldiğinde müzik sessiz kalabilir; kullanıcı yoksa saatlerce fark edilmeyebilir.
Düzeltme önerisi
window.addEventListener('online', () => {
  this._networkOffline = false;
  setTimeout(() => {
    this.checkAndRefillQueue();
    const audio = this.getActiveHlsAudio?.();
    if (this.hls && audio && audio.paused) {
      this.hls.startLoad(-1);
      try { this.hls.recoverMediaError(); } catch (e) {}
      audio.play().catch(() => {});
    }
  }, 1000);
});
🟡 ORTA • public/themes/muzibu/js/player/core/player-core.js:5652-5662, 6906-6913, 7071-7087
streamUrlCache yönetimi parçalı, limit/TTL tutarsız
Ne oluyor? `addToStreamCache()` LRU+TTL uyguluyor ama birçok yerde doğrudan `streamUrlCache.set()` kullanılıyor. Böylece 30’luk limit ve 5dk TTL her zaman uygulanmıyor.
16 saatte etkisi? Uzun seanslarda Map büyüyebilir, GC artar; düşük RAM cihazlarda takılma hissedilebilir.
Düzeltme önerisi
// Doğrudan set yerine merkezi helper
this.addToStreamCache(songId, {
  stream_url: data.stream_url,
  stream_type: data.stream_type,
  fallback_url: data.fallback_url,
  preview_duration: data.preview_duration,
  cached_at: Date.now()
});
🟡 ORTA • public/themes/muzibu/js/player/core/player-core.js:6871-6938
preloadedSongs Set’inde sınır/TTL yok
Ne oluyor? Hover preload sırasında `preloadedSongs` sürekli büyüyor, sadece oturum terminate olunca temizleniyor.
16 saatte etkisi? Müşteri paneli açık kalırsa Set büyüyebilir ve gereksiz bellek tutabilir.
Düzeltme önerisi
// Basit sınır önerisi
if (this.preloadedSongs.size > 200) {
  this.preloadedSongs = new Set(Array.from(this.preloadedSongs).slice(-100));
}
🟡 ORTA • public/themes/muzibu/js/player/features/buffer-monitor.js:146-195, speed-tester.js:83-115
Buffer sırasında otomatik hız testi ek yük oluşturuyor
Ne oluyor? Buffer tespiti sonrası 10MB indirme başlatılıyor. Zayıf Wi‑Fi’da bu test, mevcut stream ile yarışabilir.
16 saatte etkisi? Tam da takılma anında ek bant genişliği tüketimi, takılmayı uzatabilir.
Düzeltme önerisi
// Buffer toparlandıktan sonra çalıştır
setTimeout(() => {
  if (!document.hidden) MuzibuSpeedTester.runTest(TRIGGERS.AUTO_BUFFERING);
}, 15000);
🟢 DÜŞÜK • public/themes/muzibu/js/player/core/player-core.js:249-258, performance-debug.js:342
activeBlobUrls debug panelinde görünmüyor
Ne oluyor? `activeBlobUrls` local scope’ta; debug panel `window.activeBlobUrls` bekliyor.
16 saatte etkisi? Doğrudan ses kesmez; ancak teşhis ekranında yanlış metrik görülür.
Düzeltme önerisi
// Core içinde bir kez
window.activeBlobUrls = activeBlobUrls;
🟢 DÜŞÜK • public/themes/muzibu/js/player/core/player-core.js:2602, 2942, 4025, 4208, 5232, 5443
ontimeupdate throttle global paylaşılmış
Ne oluyor? Tüm handler’lar aynı `self._lastTimeupdateProcess` değerini kullanıyor. İki audio aynı anda güncelleme gönderirse biri bloklanabilir.
16 saatte etkisi? Nadiren preload/crossfade tetikleme gecikebilir.
Düzeltme önerisi
const now = performance.now();
if (now - (audio._lastTimeupdate || 0) < 250) return;
audio._lastTimeupdate = now;

16 Saat Senaryo Tablosu

Saat Beklenen durum Risk faktörü Güvenlik skoru
0h Queue dolu, HLS pool hazır Düşük 92
1h Preload ve crossfade stabil Düşük 90
4h Cache büyümesi başlar Orta (streamUrlCache büyümesi) 82
8h GC artışı ve küçük takılmalar Orta (preloadedSongs + cache) 78
12h Wi‑Fi kopması ihtimali artar Yüksek (offline sonrası toparlanma) 70
16h Uzun stabilite sınırı Yüksek (HLS resume + bellek) 68

Mimari Değerlendirme

Gözlem
HlsPool tasarımı (taint + release) uzun seanslar için doğru yaklaşım; destroy yerine reuse ile GC yükü düşürülmüş.
Gözlem
Queue refill, context yokken otomatik “popular” fallback oluşturuyor; 16 saat senaryosu için iyi bir emniyet şeridi.
Şüphe
HlsPool havuz boyutu sabit (2). Düşük cihaz + yoğun preload kombinasyonunda overflow sıklaşabilir.
Şüphe
createHlsBlobUrl segmentlerde token kaldırıyor. Eğer CDN token gerektirirse sessiz 403 dönebilir (şu an tasarım kararı).
Endişe
Offline sonrası HLS akışını yeniden başlatan mekanizma yok; uzun sessizlik riski var.
Endişe
Cache yönetimi tek bir yerde standart değil; uzun seanslarda bellek birikimi olasılığı var.

İyi Yapılmış Olanlar

Bu sistemi bir rakiple kıyaslasaydım, şu noktalarda öne çıkar:

  • HlsPool ile instance reuse ve taint yaklaşımı, uzun süreli stabiliteyi destekliyor.
  • Crossfade + preload zinciri, kesintisiz geçiş için iyi düşünülmüş.
  • Blob URL ile gerçek HLS URL’lerini gizleme, güvenlik/koruma tarafında artı.
  • Queue refill fallback’leri (genre/album/sector/artist/popular) iş sürekliliğini koruyor.
  • Debug panelde longtask, bellek trendi ve cihaz/bağlantı bilgisi teşhisi hızlandırıyor.
  • HLS 401/403 retry + MP3 fallback, kullanıcı tarafında akışı kurtarıyor.
  • Progress tracker 250ms’e çekilerek main thread yükü azaltılmış.

Sonraki Adım Önerileri

1. [Kritik] Hemen yapılmalı
Offline → online sonrası HLS akışını aktif biçimde toparlama (startLoad/recover/play). Neden: Kafe senaryosunda sessiz kalma riski yüksek. Etki: Müzik kesintisi oranı belirgin düşer.
2. [Önemli] Bu hafta
streamUrlCache ve preloadedSongs için merkezi limit/TTL standardı. Neden: Uzun seanslarda bellek birikimini azaltır. Etki: 8-16 saat arası stabilite artar.
3. [İyileştirme] Fırsat bulunca
Buffer sırasında otomatik hız testini geciktirme veya mini dosyaya düşürme. Neden: Takılma anında ek yükü azaltır. Etki: Zayıf Wi‑Fi’de daha yumuşak deneyim.