Junto al botón de subir aparece ahora el límite por archivo. No es un número
escrito a mano: se calcula como el menor entre el tope del código (500 MB) y
lo que permita el php.ini de ese servidor (upload_max_filesize y
post_max_size) — un letrero fijo mentiría si el servidor admite menos. El
pre-chequeo del navegador usa ese mismo valor, y el rechazo dice cuánto pesa
el archivo y cuál es el límite.
Dato relevante: PHP trae de fábrica 2 MB de límite de subida. Si el letrero
en producción muestra «2 MB», esa es la verdadera causa de los videos que no
entraron, y la solución es subir upload_max_filesize y post_max_size en el
php.ini del servidor.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
El reproductor no se saltaba nada: en la base solo había 2 videos. El defecto
estaba en la subida: los archivos elegidos se mandaban TODOS EN PARALELO
(inp.files.forEach), peleándose el ancho de banda de subida. Los primeros
alcanzaban a entrar y el resto moría por timeout — avisando con un toast que
desaparece en segundos y con una barra de progreso que además era la misma
para todos, pisándose entre sí. El cliente veía «subí 5», la playlist tenía 2.
Ahora los archivos van de a uno (secuencial a propósito), un fallo no frena a
los que siguen, y al terminar queda un RESUMEN FIJO: «3 de 5 agregados», con
el nombre de cada rechazado y su motivo en cristiano. Los videos de iPhone
(.mov) —causa probable del resto de los faltantes— se rechazan de inmediato
con la instrucción de convertirlos a MP4, en el navegador y en el servidor.
Y los límites de PHP (INI_SIZE, FORM_SIZE, PARTIAL) dejan de caer en «error
de subida desconocido».
Verificado además que nginx acepta cuerpos de 90 MB o más: el límite del web
server no era la causa.
scripts/test_tv_playlist.js: 11 pruebas contra el código real — nunca dos
subidas a la vez, los 5 se intentan pese a fallos, el resumen cuenta y nombra,
y los pre-chequeos rechazan sin tocar la red.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
