¿Por qué se dispara el trabajo en segundo plano de Immich después de cambiar una biblioteca?
El trabajo en segundo plano de Immich puede dispararse después de un cambio en una biblioteca porque un evento de un sistema de archivos o de una biblioteca puede ramificarse en tareas de escaneo, metadatos, derivados e indexación.
La distinción importante es entre una oleada limitada de reprocesamiento esperado y un trabajo que revisita repetidamente los recursos sin que haya un cambio correspondiente. Mover una carpeta, volver a escanear una biblioteca externa, descubrir archivos nuevos o un comportamiento específico de una versión pueden producir gráficos similares de CPU y colas, por lo que el evento de la biblioteca debe vincularse con las tareas exactas que creó.
Un escaneo de biblioteca es una etapa de descubrimiento, no toda la carga de trabajo
Primero, un escaneo reconcilia lo que Immich puede ver en el disco con lo que ya conoce de la biblioteca. Descubrir un recurso nuevo o modificado puede hacer que los resultados posteriores queden obsoletos o falten, lo que crea trabajo adicional después de que el propio escaneo parece haber terminado.
Un informe de un usuario en escaneos de biblioteca superpuestos describe una cola de escaneo que terminó mientras las colas de miniaturas, reconocimiento facial y otras seguían muy llenas. El mecanismo útil es la ramificación: una breve fase de descubrimiento puede crear una cola de procesamiento mucho más larga.
Lee las colas en orden de dependencia. Si la cola de la biblioteca llega a cero mientras las colas de trabajo derivado siguen avanzando, es posible que el servidor simplemente esté consumiendo tareas producidas por el escaneo ya completado. Llamar a todo el periodo «un escaneo repetido» oculta qué etapa está utilizando realmente los recursos.
Los cambios de ruta pueden parecer trabajo con recursos nuevos
Las bibliotecas externas son especialmente sensibles a la identidad del sistema de archivos y a los cambios de ruta. Cuando se reorganizan los archivos, la aplicación puede necesitar reconciliar sus nuevas ubicaciones con el estado almacenado de los recursos. Dependiendo del comportamiento de la versión y del tipo de biblioteca, esto puede activar más trabajo del que sugeriría la cantidad de fotos realmente nuevas.
Una discusión de 2026 sobre archivos externos movidos documenta un caso en el que las rutas reorganizadas se trataron como recursos nuevos y provocaron que se volvieran a generar miniaturas, análisis de ML y procesamiento de vídeos. Es un informe sobre una limitación conocida, no una promesa de que todos los movimientos de carpetas se comporten de forma idéntica.
Esto explica por qué reorganizar una biblioteca puede ser mucho más costoso que añadir la misma cantidad de fotos nuevas. Sin embargo, si las rutas y el contenido de los archivos no han cambiado, la regeneración completa repetida apunta a otra condición y debe investigarse en lugar de aceptarse como un comportamiento normal en segundo plano.
Las colas posteriores pueden crecer mientras el trabajo se completa
El número de tareas en espera no tiene por qué disminuir de forma monótona. Cuando termina una tarea, puede hacer que un recurso sea apto para otra tarea o añadir más tareas a una etapa posterior. Durante una reconciliación grande, por tanto, el servidor puede mostrar progreso activo y, al mismo tiempo, una cola posterior en crecimiento.
La discusión sobre una cola de miniaturas señala que pueden aparecer nuevas tareas de miniaturas a medida que se completa otro procesamiento. También ilustra un límite importante: errores históricos y rutas de importación mal configuradas pueden crear bucles anómalos, por lo que una cola en crecimiento debe interpretarse teniendo en cuenta la versión y las rutas.
Usa los contadores de trabajo completado y comprueba algunos resultados recientes, no solo el número de tareas en espera. Si aparecen miniaturas, aumentan las tareas completadas y, con el tiempo, el ritmo de finalización supera al de nuevas llegadas, la cola se está vaciando aunque alcance su máximo después de que haya terminado el escaneo original de la biblioteca.
Un pico es anómalo cuando no hay ningún cambio que lo explique
La carga esperada en segundo plano debe poder atribuirse a un evento definido: recursos nuevos, una actualización de metadatos, un cambio de ruta, un cambio de modelo o una acción explícita de regeneración. La explicación pierde fuerza cuando los mismos recursos antiguos se programan repetidamente sin que haya cambiado la configuración ni el contenido.
Un informe reciente en el que un escaneo afectó a otras bibliotecas pareció regenerar trabajo en varias bibliotecas externas y muestra por qué el alcance es importante. Considera informes como este evidencia limitada a una versión para compararla con tus propios registros, no como un comportamiento básico de Immich.
El mecanismo tampoco explica un equipo que sigue ocupado mucho después de que las colas pertinentes se hayan vaciado. En ese caso, comprueba el mantenimiento de la base de datos, las copias de seguridad, otro contenedor, la actividad del sistema de archivos o un proceso bloqueado. Un cambio en una biblioteca no debe convertirse en una explicación general para una carga sostenida no relacionada.
Relaciona el cambio con un mapa de tareas anterior y posterior
Antes de realizar un cambio controlado en la biblioteca, registra el número de recursos, los recuentos de tareas en espera y activas de los trabajos principales, el uso de CPU, la latencia del almacenamiento y la hora del último escaneo completado. Añade o mueve un pequeño grupo conocido, repite la misma observación y anota exactamente qué colas crecen y con qué rapidez se vacían.
Usa la explicación de ZimaSpace sobre la ruta de datos de Immich para asignar cada pico al descubrimiento, el procesamiento, la base de datos o el almacenamiento, en lugar de tratar toda la actividad en segundo plano como una sola categoría.
Acepta el pico cuando el trabajo generado sea proporcional al cambio controlado, aparezcan los resultados, los fallos se mantengan limitados y las colas regresen hacia el nivel habitual. Investiga más cuando se regeneren repetidamente recursos sin cambios, el alcance supere a la biblioteca editada o las mismas tareas fallen sin avanzar.
Productos recomendados
Centro de Tecnología e IA
Más para leer
Los modelos abiertos están alcanzando a la IA de vanguardia: ¿será 2026 el año en que la IA local alcance un nivel suficientemente bueno?
Los modelos abiertos están alcanzando un nivel suficiente para más cargas de trabajo de IA local, mientras que los modelos de vanguardia en la...
NVIDIA PAIR convierte tu red doméstica en un clúster local de IA—¿todavía necesitas un gran servidor con GPU?
NVIDIA PAIR distribuye las solicitudes de IA local entre varios PC, haciendo que la capacidad de cómputo sea más flexible, mientras un servidor doméstico...
¿Por qué Immich se siente más rápido en una red LAN que mediante conexiones remotas?
Las solicitudes en la LAN suelen seguir una ruta más corta y con menor latencia. El acceso remoto añade limitaciones de capacidad de la...
