6.4 KiB
6.4 KiB
TODO — Brasiliana → S3
Só o que está aberto. O que foi concluído, com os achados e o histórico das sessões, está em
tasks/done/; a última versão completa deste arquivo, com os achados 2.15–2.28 e 3.1–3.5 citados abaixo, édone/TODO-2026-09-30.md. Plano, estado e descrição NOBRADE:PLANO.md. Scripts e estado empipeline/.
Pendente
Acervo no bucket
- Rebaixar os 69 itens sem preservação (achados 2.25–2.27): a origem responde HTTP 500 ao bitstream; todos têm miniatura. Quando a origem se recuperar, basta um
FALTA3.retomar()/F5.iniciar()na aba do navegador (o que já baixou fica marcado embras_faltantes_v3). Lista emerrors.md. - 30 arquivos
extra_seqNapagados pelosubidor.pyantigo (achado 2.19): os 8 itens principais já têm preservação de novo, mas estes 30 extras (vários TIFF) não aparecem no ledger. Lista com URL empipeline/apagados-pelo-subidor-antigo.jsonl. Precisa da aba do navegador. subidor.pyantigo: aposentar ou corrigir a regra de assinatura antes de qualquer uso futuro — do jeito que está, apaga TIFF. O que roda hoje é osubidor-paralelo.py.- 30 objetos
(N)com tamanho diferente do gêmeo (achado 2.20) — conferência individual, não dá pra automatizar com segurança. - 43 objetos
(N)que são o único arquivo do item (achado 2.20) — renomear tirando o sufixo, pra o nome não mentir sobre haver um original ao lado. - Baixar os 348 legados recuperáveis pelo endereço novo (achado 2.28) — atualizar antes o
baixador.pyparahttps://objdigital.bn.br/objdigital2/acervo_digital/. - Decidir o que fazer com as 66 páginas HTML de visualizador (25 já em
legado/+ 41 no endereço novo; achado 2.28): apagar do bucket e do ledger (não são imagem), ou montar a imagem a partir dos tiles Deep Zoom quando o objdigital voltar. Todos os 25 itens já têm preservação. - Confirmar no bucket que a contagem de itens/checksums bate com os itens reais esperados.
- Reconciliar 13.058 vs 13.060 — o MANIFEST fala em 13.058 itens reais, o
catalogo.jsonltem 13.060 handles distintos. Diferença de 2 nunca explicada. - Crawl da Fase 1 pode ter mais buracos (achado 2.10 do PLANO.md): 2 itens reais (
1799,4798) só foram achados porque o WordPress os citava. Não existe verificação exaustiva de quebrowse?type=titlepegou 100% de cada comunidade. dc.rightsausente em 5.833 itens (44,7%) — característica real da fonte, não bug. Só precisa ficar documentado no MANIFEST final.
Mural
.gitdorafapolo/xyzestá em 2,5 GB e cada publicação do atlas.webpsoma ~51 MB permanentes (binário não faz delta). Se o atlas for republicado com frequência, tirar os.webpdo git — LFS, ou servir do próprio bucket. (Publicar sóindex.html+atlas-map.json, como em 30/09, não pesa.)- Encolher o
atlas-map.jsoncom dicionário (achado 3.2) — hoje 10,4 MB com os campos NOBRADE. Só vale se oJSON.parseno celular virar problema medido.
Notas técnicas úteis pra retomar
- Downloads automáticos do Chrome exigem permissão manual em
chrome://settings/content/automaticDownloads(site adicionado:https://brasilianafotografica.bn.gov.br) — já concedida, vale pra novos scripts também, não só o original. BRAS,BAIXA,BAIXA_THUMB,BAIXA_EXTRA— todos nowindowda mesma aba, mesmo IndexedDB (bras). Todos sobrevivem a fechar/reabrir a aba (dado fica salvo), mas o loop para e precisa recolar o script certo pra retomar.- Regerar as miniaturas derivadas (tudo reconstruível, nada precisa ser
guardado): no finland,
apt install libvips-tools parallel+ s5cmd; pra cada chave deitens/*/preservacao/*,s5cmd catnum tmp evipsthumbnail "$TMP" --size 256 --output "$OUT[Q=80,strip]", comparallel -j 10. ~640 thumbs/min, tráfego intra-Hetzner (bucket éhel1, o finland também) — não passa pelo link de casa. O que ainda está só em~/Downloadssai mais barato derivado localmente commagick: mandar os 71 GB pro finland custaria os mesmos dias do upload pendente. - Cuidado ao parsear
s5cmd ls: nomes de arquivo do acervo têm espaço duplo (48094 Álbum 311 - ...jpg).awk '{$1="";$2="";$3=""; print}' recolapsa esses espaços e produz chaves que não existem — 31 downloads falharam assim antes de eu perceber. Usesed -E 's|^[0-9/]+ +[0-9:]+ +[0-9]+ ||'`, que preserva o resto literal. sqlite3desta máquina tem.sqlitercforçando modo box: qualquer script que leia a saída precisa desqlite3 -init /dev/null -noheader -separator $'\t', senão vem borda de tabela no lugar dos dados (me custou um diff inteiro de falso positivo).until ! pgrep -f X; do sleep; donenunca termina: a linha de comando do próprio loop contémX, então opgrep -fse acha e a condição nunca vira falsa. Um loop desses ficou girando horas depois do trabalho acabar (12/09, morto à mão). Esperar por PID (while kill -0 $PID) ou usarpgrep -f '[t]humb-local'para o padrão não casar consigo mesmo.- Parar processo lançado em background: SIGTERM, não SIGINT. Processo
iniciado com
&num shell não interativo herda o SIGINT ignorado (osubidor.pyficou 60 s vivo depois dokill -INT). Com SIGTERM, oaws s3 cpfilho termina órfão, o que é inofensivo: sem linha no ledger e sem apagar o local, o próximo uploader sobe de novo a mesma chave. - Upload de casa: 69 Mbps (
networkQuality -s, 12/09); download 312 Mbps. - Assinaturas aceitas como imagem (
subidor-paralelo.py): JPEGFFD8, PNG, TIFFII*\0/MM\0*, GIF, JP2, BMPBM, WebP. Content-Type sai do conteúdo, não da extensão (TIFF chega com nome.jpg). vipsthumbnail --outputé relativo à pasta do arquivo de entrada, não ao diretório corrente:vipsthumbnail tmp/x.img --output out/y.webptenta gravar emtmp/out/y.webpe falha. Usar caminho absoluto na saída. (Custou uma miniatura "refeita" que não foi refeita, em 13/09.)- Scripts-fonte em
pipeline/:coletor.js/coletor-resume.js(metadados),baixador-navegador.js(preservação, todos os itens),baixador-thumb.js(miniaturas),baixador-extras.js(2a+ imagem de itens multi-bitstream),reparo-multibitstream.js(enumera bitstreams reais de um item).