Atualizações

O HolyArrs avisa quando sai uma versão nova e nunca instala por conta própria. Você baixa a imagem nova quando for melhor para você.

Ver se saiu uma versão nova

1. Abra a página Status (http://your-server:6262/health).
2. Leia Updates (atualizações). Você deve ver uma destas mensagens:

Mensagem	Significado
“HolyArrs 1.2.0 is out, newer than this one.”	Atualize quando quiser
“This is the newest version.”	Nada a fazer
“No HolyArrs release is published yet.”	O feed está vazio. Não há nada errado
“The last check did not work: …”	O feed não foi alcançado, muitas vezes por falta de internet
“The update check is off: …”	Desativada nas Configurações

3. Para verificar agora, clique em Check now (verificar agora) ou em Check again (verificar de novo). É preciso ter a permissão Change settings (alterar configurações).

Uma versão mais nova também aparece como aviso de saúde. Uma verificação que falhou aparece só em Updates.

Atualizar

1. Baixe a imagem nova e reinicie: docker compose pull, depois docker compose up -d.
2. O HolyArrs inicia. Se a versão nova muda o jeito de guardar os dados, o HolyArrs faz um backup primeiro e depois atualiza os dados. Você deve ver o app abrir na versão nova.

Dica

Um passo da atualização que falha é desfeito, e o HolyArrs para em uma página que diz o que aconteceu. Seus dados de antes da atualização ficam guardados como backup.

Voltar para a versão anterior

O HolyArrs não consegue trocar a própria imagem, então você executa a imagem anterior e o HolyArrs recupera os dados anteriores.

Cuidado

Tudo o que mudou depois da atualização, como títulos novos, configurações e histórico, não está no backup feito antes da atualização.

1. Mude a tag da imagem no seu arquivo compose (ou no docker run) para a anterior, por exemplo holyarrs/holyarrs:<older version>.
2. Execute docker compose up -d.
3. Se a atualização não mudou os dados, a versão anterior inicia. Pronto.
4. Se mudou, a versão anterior mostra uma página no lugar do app. Clique em Put back the data from before the update (recuperar os dados de antes da atualização).
5. Digite o código de uso único. Encontre o código com docker logs <container>; procure por “one-time code”.
6. O HolyArrs verifica o backup, coloca o backup no lugar e para. Você deve ver o container iniciar de novo com esses dados por causa da política de reinício. Se não houver uma, inicie o container você mesmo.

Sem a página: docker exec <container> /holyarrs restore --pre-update, depois docker restart <container>. Sem Docker: pare o HolyArrs, execute holyarrs restore --pre-update e inicie de novo.

Nada é excluído. Os dados mais novos vão para backups/before-restore-<time>/, então dá para desfazer. Ao voltar mais de uma versão, o HolyArrs usa o backup de antes da atualização mais recente que essa versão consegue ler.

Opções

Todas ficam em Settings > Health checks (Configurações > Verificações de saúde). As três últimas ficam na parte avançada do cartão.

Configuração	Padrão	Mude quando
Check for a newer HolyArrs (verificar se há um HolyArrs mais novo)	Ativada	Você não quer nenhuma requisição para fora
Check for updates every (verificar atualizações a cada)	dia	Você quer menos verificações: 3, 7, 14 ou 30 dias
Release feed (feed de versões)	Vazio (versões do HolyArrs)	Você hospeda seu próprio feed
Feed may be on the local network (o feed pode estar na rede local)	Desativada	Seu feed está na sua própria rede
Include test versions (like 1.2.0-rc1) (incluir versões de teste, como 1.2.0-rc1)	Desativada	Você quer avisos sobre versões de teste

Se não funcionar

Sintoma: “The last check did not work.” Causa: o servidor está sem internet, ou seu próprio feed está na rede local. Solução: verifique o acesso à internet ou ative Feed may be on the local network.

Sintoma: o feed de versões não salva. Causa: o endereço tem um nome, uma senha, ?query ou #fragment, ou não começa com http:// ou https://. Solução: remova essas partes.

Sintoma: a atualização parou por falta de espaço em disco. Causa: não há espaço para a cópia e a atualização. Solução: libere espaço onde fica a pasta de configuração e inicie de novo.

Sintoma: a página de voltar recusa seu código. Causa: um código antigo, ou 10 códigos errados desde o último início. Solução: copie o código da linha mais recente do log. Depois de 10 tentativas erradas, reinicie o container e use o código novo.

Recursos retidos

Alguns recursos vêm desativados por padrão nesta versão. Ative por sua conta e risco. Enquanto um recurso está retido, as páginas e os itens de menu dele ficam ocultos, as rotas de API dele respondem “not found” e as tarefas dele não são executadas. Os dados que você salvou para ele continuam lá.

Para ativar um recurso, adicione a chave dele a HOLYARRS_FLAGS, separada por vírgulas, e reinicie o container:

environment:
  HOLYARRS_FLAGS: "subtitle_sites,alert_channels_more"

Remova o nome e reinicie para desativar. As configurações ocultas voltam quando você ativa o recurso de novo.

Chave	Recurso
plex_watchlists	As watchlists do Plex viram pedidos
row_title_stats	Estatísticas dos títulos das fileiras do Explorar em Appearance (aparência)
trakt_lists	Chave do Trakt, listas do Trakt e avaliações do Trakt. As listas do TMDB continuam ativas
alert_channels_more	Alertas por Telegram, ntfy, Gotify, Pushover e webhook. Discord e e-mail continuam ativos
subtitle_sites	Sites de legendas e busca de legendas. Seu idioma de legendas continua ativo
emby_signin	Entrar com o Emby. A atualização da biblioteca do Emby continua funcionando
go_back	O painel Go back (voltar) na página Status. Os passos em Voltar funcionam sem ele

Nada mudou depois de adicionar uma chave? Confira a escrita (minúsculas, sublinhados) e reinicie o container, não só a página.

Para especialistas

O que a verificação envia

Uma requisição para api.github.com pedindo a versão mais nova, só com User-Agent: HolyArrs/<version>. Sem conta, chave ou lista de mídia. Com a verificação desativada, nenhuma requisição.

A última resposta fica salva, então um reinício não verifica antes da hora. Uma verificação espera no máximo 15 s, lê no máximo 512 KB e segue no máximo 3 redirecionamentos, sem nunca trocar entre http e https. O link das notas da versão só aparece quando aponta para as páginas de versões do HolyArrs no GitHub; fora isso, a versão aparece como texto simples.

Release feed aceita uma resposta de versão no estilo do GitHub, uma lista de versões, qualquer JSON com version, ou texto simples com a versão. Endereços de metadados de nuvem são sempre recusados. Uma versão de teste conta como mais antiga que a versão normal.

O backup antes de uma atualização

Antes de mudar os dados guardados, o HolyArrs:

1. Verifica se há espaço para uma cópia e para a atualização. Se não houver, nada muda. Pule essa verificação com HOLYARRS_SKIP_SPACE_CHECK=yes.
2. Copia cada banco de dados para backups, verifica a cópia e grava um arquivo sha256 ao lado. Depois de 3 cópias que falharam, nada muda.
3. Executa cada passo da atualização separadamente e verifica o passo. Um passo que falha é desfeito; os passos concluídos ficam. Inicie a mesma versão de novo para continuar do passo que falhou, com a mesma cópia.

Depois do primeiro início bem-sucedido, a cópia vira holyarrs-backup-pre-update-<time>.zip, com uma descrição como “before updating from 1.1.0 to 1.2.0”. Ela aparece em Settings > Backups e em holyarrs restore --list. Os 3 mais novos são mantidos; o agendamento de backups nunca remove esses arquivos. Uma instalação nova ou uma atualização que não mexe nos dados não cria nenhum.

Relacionados

• Backups
• Verificações de saúde
• Partes e modo de segurança