1. Fija la situación antes de hacer clic en relanzar
Deja de añadir trabajo y comprueba que ninguna ejecución del mismo lote siga activa. Una conexión perdida no siempre significa que el programa se haya detenido. Consulta su estado cuando siga siendo posible: lanzar una segunda copia puede producir duplicados o escribir en los mismos destinos.
Conserva el registro, la lista de archivos de entrada, los ajustes y el mensaje de error. Haz una copia de la tabla de seguimiento antes de corregirla. Guarda las salidas dudosas en una ubicación aparte, sin sobrescribir los originales ni los resultados ya aceptados. Si el destino está lleno, prepara espacio o usa otro destino después de haber identificado lo que debe conservarse.
2. Dale a cada elemento una identidad estable
Una línea debe representar una tarea esperada, por ejemplo IMG-017 asociado a catalogo/silla-frente.png. La ruta por sí sola puede volverse ambigua después de un movimiento; un nombre corto como foto.png puede existir en varias carpetas. Conserva un identificador único y la correspondencia con la entrada original.
Añade el identificador de configuración, la ruta de salida, el estado, el número de intento y un motivo corto. Este registro puede ser una tabla normal o un CSV de tu proyecto. No necesita contener las imágenes, contraseñas ni todo el registro técnico de la máquina. Una persona debe poder encontrar la entrada correcta y explicar por qué figura en la reanudación.
No modifiques el original detrás de un identificador ya aceptado. Una nueva entrada o una transformación distinta exige una nueva versión claramente anotada. De lo contrario, el mismo identificador acabaría designando dos trabajos incompatibles y el registro ya no permitiría decidir qué está terminado.
| ID | Configuración | Estado | Salida o motivo |
|---|---|---|---|
| IMG-017 | essai-02 | Aceptado | IMG-017.png abierto y comprobado |
| IMG-018 | essai-02 | Por verificar | Archivo presente, comprobación no terminada |
| IMG-019 | essai-02 | Fallo | Falta de memoria durante el procesamiento |
| IMG-020 | essai-02 | Por hacer | No se encontró ninguna salida esperada |
3. Contrasta el registro con los archivos reales
Para cada identificador previsto, busca la salida esperada. Verifica el formato, las dimensiones o el contenido necesarios para tu uso, y luego abre el archivo con la herramienta de destino. Las salidas ya aceptadas y que siguen presentes quedan fuera de la lista de reanudación. Si falta una salida mientras el registro dice «aceptado», busca primero una copia conservada antes de decidir recalcularla.
Clasifica los elementos «en curso» en el momento de la interrupción entre los que hay que verificar. Algunos pueden estar completos, otros solo parcialmente. La fecha o el tamaño del archivo son un indicio, no una validación. Un archivo adicional sin identificador conocido queda aparte hasta que encuentres su procedencia.
Para las imágenes, Pillow distingue la identificación del archivo, la lectura de sus píxeles y la verificación de su estructura. Un programa que se limita a abrir su encabezado no lo comprueba todo. Una comprobación automática puede detectar algunas corrupciones; no juzga si el texto es legible o si los colores corresponden al entregable.
4. Separa un elemento incompleto de un resultado rechazado
Una salida parcial debe rehacerse o restaurarse desde una copia completa. Una salida completa pero inaceptable exige primero entender el defecto. Volver a lanzar los mismos parámetros sobre una entrada ilegible o sobre un caso que se queda sin memoria de forma sistemática probablemente repetirá el problema. Anota la corrección antes de volver a poner ese identificador en la cola.
Mantén pocos estados: por hacer, en curso, por verificar, aceptado y fallo. El paso a «aceptado» llega después de la comprobación, no al lanzar el cálculo. Si decides excluir una entrada, añade un estado «descartado» con un motivo y el acuerdo útil para el proyecto. No debe desaparecer en silencio del total esperado.
No cuentes un nuevo intento como una nueva tarea. IMG-019 puede tener tres intentos y una sola salida retenida. Esta distinción evita confundir sesenta ejecuciones con sesenta entregables distintos.
Ejemplo: recuperar los diecinueve elementos que aún faltan
Este escenario ilustrativo trata de sesenta imágenes independientes. Tras la interrupción y la comprobación, cuarenta y una salidas están aceptadas, cuatro son parciales, seis fallaron y nueve faltan. El registro cubre bien 41 + 4 + 6 + 9 = 60 identificadores. La reanudación afecta a diecinueve elementos, siempre que se traten las causas de los seis fallos.
La persona responsable reconstruye una lista de diecinueve identificadores y luego distingue los cuatro archivos parciales, los seis errores y las nueve tareas sin salida. Retoma primero una entrada corregida y una entrada ausente. También confirma que una imagen ya aceptada no figura en la selección. Este pequeño control valida la lista antes del procesamiento restante.
Si después se aceptan dieciocho elementos adicionales y un archivo de origen sigue siendo ilegible, el balance es de cincuenta y nueve aceptados y un fallo explicado. El lote no se declara completo en sesenta. La siguiente decisión consiste en recuperar una entrada correcta o en hacer aprobar su exclusión, no en ocultar la línea.
| Estado tras el control | Número de identificadores | Procesamiento propuesto |
|---|---|---|
| Aceptado y salida recuperada | 41 | Conservar; ninguna repetición |
| Salida parcial | 4 | Guardar aparte y luego rehacer |
| Fallo identificado | 6 | Corregir la causa antes de un nuevo intento |
| Salida ausente | 9 | Retomar desde la entrada |
| Total por retomar | 19 | 4 + 6 + 9, sin duplicados |
5. Realiza la repetición en una ubicación distinta
Prepara una carpeta de repetición con solo los identificadores retenidos, o usa la selección explícita de tu programa. Revisa la lista antes de lanzar. Si la herramienta ofrece «ignorar los archivos existentes», comprueba qué significa: la existencia de un archivo parcial puede hacer que se ignore por error. El registro verificado sigue siendo tu referencia.
Haz que las nuevas salidas se generen en una carpeta distinta, con su configuración y su intento. Valídalas antes de reemplazar una versión anterior. Algunos scripts pueden sobrescribir un archivo existente sin pedir confirmación; Python lo documenta en particular para os.replace. Una convención de nombres no protege por sí sola de un reemplazo.
Si los ajustes cambian para corregir un defecto, mantén ese cambio visible. Puedes conservar salidas procedentes de dos configuraciones si cumplen los mismos criterios y si la mezcla es aceptable para el proyecto. Para una serie visualmente homogénea, compara también las nuevas salidas con las antiguas antes de reunir las carpetas.
6. Verifica el balance por identificador, no solo por cantidad
Al final, cada identificador esperado debe tener un estado explicado. Dos copias de IMG-017 no compensan la ausencia de IMG-020. Verifica la unicidad de los nombres, la correspondencia con las entradas y la configuración de las salidas retenidas. Abre los archivos rehechos y controla los puntos que motivaron su repetición.
La carpeta terminada comprende las salidas aceptadas, el registro actualizado, los ajustes y la lista de los posibles elementos descartados o aún bloqueados. Guarda este conjunto con una copia controlada. Una línea «aceptado» no sustituye ni al archivo ni a su copia de seguridad.
Este método retoma tareas independientes desde su entrada. No permite continuar automáticamente una simulación, un renderizado o un entrenamiento en la instrucción exacta de la parada. Estos trabajos requieren un estado de reanudación propio del programa. Tampoco supongas que una carpeta que quedó en un entorno alquilado se conservará después del periodo: prepara tu copia.