v0.9.20

Multiview (Android, iOS y tvOS)

• Botón «Multiview» en el reproductor, solo en directo. El canal que se ve
  pasa al primer cuadro de una cuadrícula de 2×2 con el mismo reproductor, sin
  volver a abrirse (MultiviewScreen.kt; IOSMultiviewView.swift, compartido
  por iOS y tvOS, con IOSPlaybackHandoff para volver a pantalla completa con
  otro cuadro).
• «+» añade un canal de la lista de zapping, empezando por el siguiente. Suena
  solo el cuadro elegido: los demás van con mute y no con aid=no, porque en
  directo volver a poner la pista deja el canal parado hasta que el audio
  alcanza al vídeo.
• Menú de cada cuadro: pantalla completa, cambiar canal, quitar. «Atrás» sale a
  pantalla completa con el cuadro elegido.
• Tope de calidad: maxVideoHeight en PlaybackPreparation.prepare (DASH, HLS
  con ClearKey y Smooth) y hlsBitrateCap para hls-bitrate de mpv cuando
  mpv ve el master entero. Los cuadros nuevos abren a ≤720p; con el cuarto,
  todos. Tests: QualityCapTests.
• Varios controladores a la vez en iOS/tvOS: la sesión de audio y el «no
  apagar la pantalla» se sueltan cuando ya no queda ninguno.
• Probado en el Chromecast con Google TV (4 canales a 720p por hardware, unos
  670 MB). iOS y tvOS compilan pero no se han probado en aparato.

Favoritos y recientes (Android, iOS y tvOS)

• Petición de un usuario. Dos grupos fijos, «★ Favoritos» y «Recientes»,
  delante de «Todos» (solo en el directo). Un canal se marca manteniéndolo
  pulsado en la rejilla (combinedClickable en Android, contextMenu en
  iOS/tvOS) o con la estrella del reproductor; las tarjetas favoritas llevan
  una estrella. Recientes: los últimos 20 canales en directo abiertos, también
  al zapear, del último hacia atrás.
• Se identifican por grupo + nombre, que sobrevive a recargar la lista (el id
  es la posición). Se guardan en cada aparato; no se sincronizan por Drive.
• Con «Favoritos» elegido, el zapping y el selector del multiview se mueven
  entre favoritos. Sin probar en aparato.

Android: el APK de la actualización ya no se queda en el aparato

• cache/update/update.apk (unos 60 MB) seguía ahí tras instalarse hasta que
  Android vaciaba la caché. AppUpdater lo borra al arrancar.

Proxies que no se quedan sin hilos

• Los accept() de los proxies DASH/HLS, el servidor de Smooth y el DNS
  bloqueaban hilos de DispatchQueue.global y del pool de Swift, que en
  Android tienen un hilo por núcleo. Con cuatro canales en el Chromecast (4
  núcleos) todo se quedaba en «Conectando…», y cambiar de canal muy seguido
  podía atascarse igual. BlockingIO (en LiveHTTPServer.swift) los saca a
  hilos propios.

Android: el renderizado por sistema ya no se cae al reabrir

• checkSystemRenderer miraba hwdec-current en cuanto había tamaño de
  vídeo, también entre un archivo y otro (cambiar de calidad), cuando mpv
  responde «no», y pasaba a vo=gpu sin motivo. Ahora mira al arrancar la
  reproducción y solo con un vídeo abierto.

«Enviar registro» llega por Telegram (Android)

• El registro se manda al desarrollador con el bot @isplayer_registry_bot
  (DiagnosticsLog.sendToDeveloper), con lo que el usuario cuente y un código
  para identificarlo. Uno por minuto como mucho. «Compartir» sigue como
  alternativa. Token y chat en Config/GoogleOAuth.local.xcconfig (fuera del
  repo); sin ellos, la app solo ofrece compartir. Sin probar el envío desde un
  aparato.