1 pontos por GN⁺ 3 시간 전 | 1 comentários | Compartilhar no WhatsApp
  • O Immich v3.0.0 é o próximo grande lançamento após meses de trabalho, incluindo edição não destrutiva no mobile, prévia de workflows, melhorias no backup em segundo plano, verificação de integridade e prévia de transcodificação de vídeo em tempo real
  • Esta versão traz Breaking changes, mas boa parte delas são mudanças em endpoints da API do Immich, afetando principalmente ferramentas de terceiros integradas à API do Immich; a maioria dos usuários pode atualizar da mesma forma de antes
  • Para fazer o upgrade, altere IMMICH_VERSION de v2 para v3 no .env e depois execute docker compose pull && docker compose up -d; o v3.0.0 descontinua o suporte a pgvecto.rs, então ambientes anteriores ao v1.133.0 precisam migrar para o VectorChord
  • O app mobile adota o mesmo modelo de edição não destrutiva da web e melhora o backup em segundo plano no Android com um agendador de tarefas periódicas; no iOS, sincronização e upload passam a rodar em paralelo dentro do curto tempo de execução em segundo plano
  • A transcodificação de vídeo em tempo real ainda é um recurso experimental e, no momento, só foi implementada no app web; como o app mobile ainda está em desenvolvimento, não é recomendado apagar manualmente os arquivos de transcodificação offline existentes

Atualizações e mudanças de compatibilidade

  • O Immich v3.0.0 foi anunciado como a próxima versão principal e inclui várias Breaking changes
  • Muitas dessas Breaking changes são atualizações de endpoints da API, então afetam principalmente ferramentas de terceiros integradas à API do Immich
  • A maioria dos usuários pode atualizar da mesma forma de antes
  • O guia completo de migração é fornecido em um link separado no anúncio da release
  • O v3.0.0 descontinua o suporte a pgvecto.rs
  • Procedimento de atualização:
    • No arquivo .env, altere IMMICH_VERSION=v2 para IMMICH_VERSION=v3
    • Execute docker compose pull && docker compose up -d

Release candidate e canal de notificações

  • O v3.0.0 é a primeira release do Immich a usar release candidate
  • Uma release candidate é uma pré-release testada, mas ainda não oficial, usada para encontrar e corrigir bugs restantes antes da versão final
  • Se quiser receber notificações de release candidates dentro do Immich, em Admin settings > Version check você pode mudar o canal de release de Stable para Release candidate

Melhorias em edição mobile e backup

  • A edição não destrutiva no mobile dá continuidade ao recurso de edição de imagem adicionado primeiro à web na v2.5.0
  • O editor mobile anterior usava um sistema separado que criava um novo asset em vez de modificar a foto no local
  • O editor mobile do v3.0.0 oferece os mesmos recursos da versão web e permite cortar, girar e ajustar imagens sem mexer no arquivo original
  • Como a edição é não destrutiva, ela pode ser alterada novamente ou desfeita depois, e você pode editar no mobile e continuar os ajustes na web
  • Alguns recursos presentes na implementação anterior de edição mobile foram removidos
    • alteração de cor da foto
    • edição de Live Photo
    • edição de asset local
  • Alguns recursos devem voltar em releases futuras
  • O backup em segundo plano no Android agora usa um agendador de tarefas periódicas para funcionar com mais confiabilidade
    • Antes, isso era limitado a fotos tiradas recentemente
    • Agora é possível enviar toda a biblioteca em segundo plano
    • A mudança se adapta melhor às restrições de execução em segundo plano do Android e lida com limpeza de tarefas, otimização de bateria e avisos de configuração de notificações
  • No iOS, a tarefa de atualização em segundo plano agora executa sincronização e upload em paralelo, para que os uploads comecem dentro do curto tempo permitido pelo sistema

Prévia de workflows

  • Workflows é o primeiro recurso em prévia para automatizar o comportamento da biblioteca
  • É possível criar automações conectando gatilhos, filtros e ações em um construtor de arrastar e soltar
  • O recurso pode ser acessado em Utilities > Workflows na web
  • Você pode criar um novo workflow vazio ou explorar templates prontos
  • O editor oferece Visual editor e JSON editor
    • O Visual editor é adequado para montar workflows
    • O JSON editor é adequado para compartilhar ou receber o conteúdo de workflows com outras pessoas
  • Cada workflow é composto por um trigger e uma série de steps
    • O trigger é o ponto de entrada do workflow; quando ele ocorre, as etapas são avaliadas
    • Os steps incluem Filters, que representam condições, e Actions, que representam efeitos
  • Há duas formas de compartilhamento: texto e JSON
    • Texto é adequado para compartilhar em fóruns ou fazer demonstrações
    • JSON é adequado para reproduzir com precisão a configuração do workflow
  • Novas ideias de triggers e actions estão recebendo feedback em uma discussion thread separada

Navegação da biblioteca e verificação de integridade

  • A página Recently Added foi adicionada à web e ao mobile
    • Agora é possível ver a biblioteca com base no momento em que os assets foram adicionados ao Immich, e não quando foram capturados
    • Isso facilita encontrar o que acabou de entrar ao explorar lotes recém-importados
    • Na web ela fica na aba Explore; no mobile, na aba Search
  • A página de manutenção ganhou integrity reports
    • O Immich escaneia diretórios no sistema de arquivos e compara com as informações armazenadas no banco de dados
    • Se houver arquivos em diretórios que o Immich não conhece, eles são marcados como untracked
    • Se o banco de dados tiver uma referência, mas o arquivo não existir naquele local, ele será marcado como missing
    • Se o checksum do arquivo em disco for diferente do checksum salvo pelo Immich, ele será marcado como checksum mismatch
  • Divergências de checksum normalmente podem vir de corrupção de arquivo, mas também podem ser resultado de renomeações incorretas
  • É possível configurar quando e por quanto tempo a tarefa de verificação de integridade deve rodar toda noite

Vídeo e reprodução de mídia

  • O app mobile ganhou o recurso Slideshow, permitindo reproduzir automaticamente fotos e vídeos na tela como na web
  • HLS e transcodificação de vídeo em tempo real foram adicionados como recurso em prévia
    • Vídeos podem ser convertidos enquanto são reproduzidos, sem criar transcodificações offline antecipadamente
    • Há suporte para troca de qualidade manual e automática
    • A transcodificação pode usar o melhor codec suportado pelo cliente
    • Desativar a transcodificação offline pode reduzir o uso de armazenamento
  • Também foram listados itens ainda não implementados
    • HDR para clientes compatíveis
    • remuxing sem transcodificar o original quando a largura de banda permitir
  • A transcodificação em tempo real é experimental e seu comportamento pode mudar entre versões
  • No momento, ela só foi implementada no app web, e a implementação no app mobile ainda está em andamento
  • A ativação pode ser feita nas video transcoding settings
  • Ativar a transcodificação em tempo real não afeta diretamente a transcodificação offline; para desligar a transcodificação offline, também é preciso ajustar a transcode policy
  • Assets importados antes da v3 precisam ter Metadata Extraction executado novamente no painel de tarefas para serem reprocessados
  • O servidor precisa ser forte o suficiente para lidar com a transcodificação em tempo real, e aceleração por hardware é recomendada, mas não obrigatória
  • O app web ganhou um novo player de vídeo customizado, alinhado ao design do Immich
    • Ele oferece os mesmos controles e layout em todos os dispositivos
    • Traz recursos básicos como alteração da velocidade de reprodução
    • Também pode resolver no iOS o problema de os controles do sistema ficarem escondidos atrás da barra de navegação do Immich

Android, OCR, compartilhamento e fluxo de álbuns

  • No Android, agora é possível usar o Immich como um app de galeria/visualizador de imagens
    • Ao tocar em uma foto ou vídeo em outro app e escolher o Immich, o arquivo abre diretamente no visualizador de assets
    • Há opções para compartilhar o arquivo ou enviá-lo para a biblioteca
    • A forma de reconhecer arquivos que já estão na biblioteca deve melhorar no futuro
  • O visualizador de assets no mobile ganhou um toggle de OCR para destacar texto reconhecido em fotos
    • É possível selecionar e copiar texto da imagem
  • No app mobile, agora é possível enviar fotos locais diretamente para álbuns
    • Também é possível adicionar direto ao álbum pela asset bottom sheet
    • Isso reduz o atrito do fluxo em que antes era preciso fazer upload primeiro e organizar depois
  • Ao compartilhar pelo mobile, é possível escolher o tamanho da imagem antes do envio
    • Isso ajuda a manter arquivos menores para apps de mensagens
    • Se necessário, também é possível compartilhar em qualidade total
    • O comportamento padrão pode ser alterado em App Settings > Preferences
    • Também é possível manter o botão de compartilhamento pressionado para escolher opções na hora
  • O desempenho da navegação na timeline foi melhorado para meses com muitos assets, reduzindo situações em que a aba do navegador trava

Principais grupos de mudanças

  • As Breaking changes incluem migração de class-validator para zod, remoção de replace asset, remoção do endpoint antigo de sincronização da timeline, fim do suporte a pgvecto.rs e mudanças na estrutura de respostas de erro
  • Entre as mudanças deprecated, está a descontinuação gradual de rotas PUT em favor de PATCH
  • Nos itens de segurança, há uma correção para fazer fotos de perfil passarem pelo thumbnail pipeline
  • Entre as adições de recursos estão edição mobile, Android periodic work manager task, player de vídeo web customizado, página de recently added assets, workflows & plugins, transcodificação HLS em tempo real, OCR no mobile e tarefa de verificação de integridade
  • As correções de bugs incluem normalização de e-mail no OAuth, limpeza de nomes de arquivos antes de adicioná-los ao zip, prevenção de exposição de assets bloqueados a parceiros, correção de criação não autorizada de faces e prevenção de falta de memória em uploads via CLI

Limitações e respostas confirmadas na discussão

  • Para quem vai do v2.0.1 ao v3.0.0, foi informado que não há instruções especiais adicionais e que basta seguir o procedimento de atualização das release notes
  • Casos em que álbuns sumiram após a atualização mobile pareceram ser um bug de migração no lado mobile, que pode ser resolvido saindo da conta e entrando de novo ou atualizando o servidor para a v3
  • Sobre restaurar backups do iPhone e baixar novamente para o aparelho as fotos que já estão no servidor, o app mobile ainda não tem opção de bulk download, apenas download individual
  • Sobre apagar vídeos já transcodificados após ativar transcodificação em tempo real, a resposta foi que o app mobile ainda não suporta esse recurso, então os vídeos transcodificados existentes ainda são necessários e a exclusão manual não é recomendada
  • Foi respondido que não há planos para converter fotos HEIC para JPG sob demanda, e que as miniaturas geradas atualmente são JPEG/WEBP, portanto compatíveis com todos os navegadores e clientes
  • A melhoria no backup em segundo plano no Android não é uma mudança para resolver imagens grandes acima de 100MB nem limitações do Cloudflare, mas sim para fazer tarefas em segundo plano rodarem com mais frequência de forma periódica
  • Na transcodificação em tempo real, o codec é escolhido pelo cliente, não pelo servidor; se o servidor anunciar variantes AV1, clientes capazes de decodificar AV1 podem optar por elas
    • Há planos para adicionar uma configuração que permita escolher quais codecs e resoluções o servidor vai anunciar
  • Melhorias em casting estão na lista de tarefas, e foi respondido que será necessário reescrever toda a parte de cast e também adicionar transcodificação em tempo real
  • Um usuário que relatou o erro No vector extension found. Available extensions: vchord, vector após o upgrade informou depois que conseguiu resolver
  • Sobre a nova verificação de divergência de checksum, um usuário comentou que quem editou imagens enviadas fora do Immich no passado pode ver centenas de checksum mismatch, e que seria útil uma função para recalcular checksums e resolver isso
  • Em relação à migração para o VectorChord, foi comentado que usuários anteriores à v1.102 podem ter perdido a mudança opt-in de DB_DATA_LOCATION, então seria útil haver um aviso se isso for detectado

Apoio e produtos

  • Junto com o lançamento do v3.0.0, também foram apresentados novos produtos do Immich
    • roupas infantis
    • roupas com o logo do Immich em bordado colorido completo
    • página de produtos: https://immich.store
  • É possível apoiar o projeto comprando uma product key ou produtos

1 comentários

 
GN⁺ 3 시간 전
Opiniões no Hacker News
  • Dou uma aula gratuita de desenvolvimento de software para alunos de graduação, e fiquei muito empolgado ao ver que um trabalho feito como atividade da disciplina apareceu em um projeto real
    Fico orgulhoso porque a primeira correção de bug listada foi a última das três pull requests que esse aluno teve mergeadas no Immich durante o curso

  • Como há muita discussão sobre criptografia nos comentários, vou compartilhar minha configuração. Há cerca de um ano e meio venho rodando o Immich para família e amigos em um servidor de leilão da Hetzner
    A comunidade da Hetzner tem uma documentação oficial de criptografia completa de disco: https://community.hetzner.com/tutorials/install-debian-with-...
    Uso SSL gratuito com Letsencrypt, e o Immich pode ser facilmente colocado atrás de um proxy Nginx que cuida do SSL
    Com backups automáticos via cron salvando todos os dados do Immich em um NAS local criptografado, a configuração fica confiável, com criptografia em trânsito e em repouso. Até agora, a manutenção foi exatamente zero
    No nível de IP, descarto tráfego de fora de 3 regiões, o que deixa tudo mais seguro, e também dá para adicionar um WAF ao proxy Nginx
    Considero até mais seguro que Google/iCloud porque o vetor de ataque de “funcionários da empresa” é muito menor. Há casos documentados de o Google examinar fotos e até fazer denúncias falsas à polícia: https://www.eff.org/deeplinks/2022/08/googles-scans-private-...
    Claro que, em tese, um funcionário da Hetzner poderia ter acesso físico ao servidor e extrair chaves de criptografia da RAM ou roubar chaves com um servidor SSH falso, mas isso é um ataque muito mais complexo, ainda não documentado, e com risco de ser detectado

    • A configuração mencionada não é criptografia de ponta a ponta. Criptografia de ponta a ponta é criptografia entre clientes, de modo que o servidor deve lidar apenas com bits criptografados
      Essa configuração usa criptografia em trânsito e criptografia em repouso. Para grandes provedores de nuvem, a criptografia em repouso pode ser relativamente menos importante, já que eles provavelmente gerenciam o ciclo de vida dos discos melhor que a maioria das empresas ou indivíduos
      É baixa a probabilidade de alguém invadir fisicamente um datacenter ou obter um drive recondicionado que não tenha sido devidamente tratado ou apagado
      Também é difícil afirmar que isso seja necessariamente mais seguro do que um provedor gerenciado. Você provavelmente não é engenheiro de segurança e tem muito menos recursos para proteger o servidor
      Isso impede que Google/iCloud façam scraping dos seus dados, mas não significa que a Hetzner não consiga acessá-los. A Hetzner controla o hipervisor superior e o plano de controle que gerenciam o servidor/VM, então não dá para saber quais recursos estão implementados
      A maior parte do que agências de inteligência conseguem fazer não vazou nem foi documentada publicamente
    • Isso não é criptografia de ponta a ponta. No momento em que o disco é montado no host, ele é descriptografado e fica utilizável, então não há nada impedindo você ou a Hetzner de acessar os dados da família
      Em uma criptografia de ponta a ponta de verdade, todos os dados do disco teriam de ser criptografados nos clientes usados pela família, e ao vasculhar o volume do disco só se veria texto cifrado
    • Acho que criptografia de ponta a ponta é indispensável para uma galeria de fotos. É uma forma de se proteger contra erros de configuração do servidor, vulnerabilidades futuras e software sem patches
    • Fiquei curioso para saber quanto armazenamento você usa na Hetzner e quanto paga
  • É um software realmente incrível e está no mesmo nível do Google Photos. Desde que comecei meu homelab, venho usando por alguns meses atrás do Tailscale e não tive nenhum problema
    Na verdade, foi ter batido no limite de 100 GB de armazenamento do Google Photos e migrado para o Immich que me fez começar com self-hosting, e o processo foi muito divertido
    É difícil acreditar que um produto self-hosted com esse nível de polimento seja gratuito. Pelo mesmo motivo, também aplaudo muito o HomeAssistant, PiHole, paperless-ngx, Dawarich e inúmeros outros projetos
    Parabéns e obrigado à equipe por ajudar a organizar memórias pessoais

    • Se você gosta do projeto, seria bom comprar uma licença. Ele é gratuito, mas dá para usar uma fração muito pequena do valor economizado para comprar uma licença
    • Hoje acho que é melhor que o Google Photos. A equipe é realmente excelente, e é surpreendente que o app que considero o melhor app de fotos de uso geral seja open source
  • Há muitos comentários dizendo que isso não tem criptografia de ponta a ponta, mas, sinceramente, não entendo por que seria necessária
    Digamos que um ladrão invada sua casa e roube seu homelab. Como não há criptografia de ponta a ponta, ele pode ver as fotos da sua falecida avó — que tragédia!
    O cenário mais provável é seu celular dar problema. Sem criptografia de ponta a ponta, se você perder a chave, não perde também as últimas lembranças da sua avó; basta copiar os arquivos .jpg para um novo dispositivo

    • Permite hospedar uma instância para família ou amigos
      Mas fico em dúvida sobre o compromisso de acessibilidade que a criptografia de ponta a ponta impõe a usuários comuns. Nesse caso, se você perder ou esquecer a chave ou a senha, perde todas as fotos muito importantes, o que é bem grave
      Google Photos e iPhotos dão às pessoas a sensação de que suas fotos estão seguras
      Também fica mais fácil hospedar uma instância em nuvem do Immich sem criptografar o sistema de arquivos do servidor remoto/VPS. Especialmente ao alugar servidor de um pequeno fornecedor, sempre fico cauteloso sobre quanto dá para confiar nos controles de acesso dos funcionários
      Sei que, com acesso físico, algum nível de confiança é inevitável, mas também importa como os discos são tratados durante a manutenção
    • Vejo o ponto central da criptografia de ponta a ponta como impedir que o provedor de nuvem veja os dados, mesmo quando ele hospeda tudo. É parecido com a Proton Drive dizer que não sabe quais arquivos você tem
      Com isso, recursos como busca semântica, reconhecimento facial, transcodificação de vídeo e geração de miniaturas teriam de ir para o cliente
      O Immich parte do pressuposto de que você confia que o servidor pode acessar as fotos. Em self-hosting, a estrutura é sempre essa
      Como a maioria dos usuários também dá esse tipo de confiança ao Google e à Apple, acho razoável
    • Não dá para simplesmente considerar que todas as fotos não são sensíveis
      Com uma verdadeira arquitetura de criptografia de ponta a ponta, acho que seria possível usar armazenamento em nuvem, hospedagem gerenciada e backups offsite com mais flexibilidade
    • No Immich, não acho que a camada de aplicação seja a camada certa para criptografia. Eu simplesmente criptografo o disco inteiro do servidor
      Em self-hosting, não há necessidade de impedir que o operador acesse os arquivos
    • Concordo. Antigamente, guardávamos álbuns de fotos no armário; se a casa pegasse fogo, eles queimavam, se a caldeira quebrasse, ficavam encharcados, e às vezes até eram roubados
      Agora podemos guardá-los digitalmente e fazer backup fora de casa. Para o Immich, esse nível de mudança já é suficiente
      Criptografar tudo completamente acabaria convidando ainda mais problemas
  • Ao mudar do iOS para o GrapheneOS, decidi fazer self-hosting das fotos e também avaliei o Immich, mas escolhi o Ente por causa da criptografia
    O Ente Photos é muito polido e tem qualidade comparável ao Apple Photos
    Gosto do fato de que, em vez de abrir só o cliente, como muitos projetos com criptografia de ponta a ponta, eles também mantêm o servidor aberto e possibilitam self-hosting
    Também gosto de poder compartilhar álbuns para que qualquer pessoa contribua sem conta, e do recurso que permite bloquear o celular para mostrar apenas fotos selecionadas quando você o entrega a outra pessoa

    • Tenho dificuldade em concordar com a frase “o Ente Photos é muito polido e tem qualidade comparável ao Apple Photos”
      Em self-hosting, ele nem consegue fazer upload de fotos de forma estável. Já fiquei dias sem conseguir enviar nada, e não havia informações de diagnóstico, então precisei compilar e depurar eu mesmo
      Mantive o app em primeiro plano, plugado no carregador por horas, e desativei tanto upload de vídeos quanto recursos de machine learning para focar só nas fotos, mas mesmo assim aconteceu
      No lado do servidor está tudo bem, e o upload pela web funciona sem problemas; só o app não funciona. Ainda não encontrei a causa
    • Para quem estiver curioso: “Ente Photos é um serviço pago, mas oferece 10 GB de armazenamento gratuito. Você também pode replicar esse repositório e fazer self-hosting”
      Ou seja, as duas formas são possíveis
      https://github.com/ente/ente
    • Ente Auth também é excelente. Porque funciona em qualquer dispositivo, inclusive justamente naquele que você está tentando acessar
      Talvez isso enfraqueça o propósito da autenticação em duas etapas, mas às vezes não me importo muito
    • Comecei a usar o Ente porque queria criar links de upload de fotos por evento. Digo aos amigos “se tirarem fotos ou vídeos hoje à noite, subam por esta URL”, e simplesmente funciona
      Não precisa de app, é muito simples e bem barato. Depois disso, passei a usar também o serviço de backup/arquivamento de fotos
      Virei fã porque o serviço é exatamente o que parece ser
  • O Immich é uma escolha natural demais para substituir Apple Photos ou Google Photos. Usado com uma VPN como Tailscale, dá para trocar quase sem mudar nada

    • É bom notar que migrar do Immich de volta para iCloud/Google não é uma área com a qual o Immich se preocupa. Não há “baixar tudo” em lugar nenhum, e a melhor forma é entrar no servidor e pegar os arquivos originais
      https://github.com/immich-app/immich/discussions/14365
    • Fico curioso se deixar o Immich público tem efeitos colaterais. Acho que muita gente superestima os riscos
      Basta atualizar regularmente, seguir regras simples e configurar algo como CrowdSec
      Sei que usar uma ferramenta como Tailscale é mais simples, mas hoje em dia vejo uma tendência de nem considerar outras opções
    • Uso photoprism e fico me perguntando se devo migrar
    • É uma pena; se suportasse álbuns aninhados ou álbuns dentro de pastas, poderia substituir facilmente o Lightroom Cloud
      Minhas fotos são organizadas como events -> year/month - holiday -> (album_1, ...), home town -> year -> (album_1, ...)
      Fotos podem estar em vários álbuns, há versões editadas, e também preciso acompanhar e filtrar estados de selecionada/rejeitada
      O único motivo pelo qual ainda não migrei para o Immich é que estou tendo dificuldade para mapear de forma elegante meu modo de organizar fotos para o modelo do Immich. Todas as tentativas até agora ficaram difíceis de usar
    • Fico curioso se há efeitos colaterais em deixar o celular conectado à VPN Tailscale o dia inteiro
  • Há algo que me incomoda ainda mais do que a ausência de criptografia de ponta a ponta. Eles não facilitaram a importação de outros serviços como Google Photos ou iCloud, e acho que isso deveria ser prioridade
    O Immich depende do projeto immich-go, que tem muitos bugs e está praticamente abandonado
    O próprio app iOS também pode ser usado para sincronizar a galeria do iCloud, mas falha ao enviar Live Motion Photos por causa de um bug aberto há cerca de 2 anos
    Cerca de 9000 fotos que exportei para o Immich são Live Photos corrompidas ou importadas pela metade, e não tenho tempo para corrigir isso
    Não consigo entender o fato de isso não ser prioridade. É o tipo de recurso que deveria passar pelos testes A/B mais rigorosos
    Se não dá para confiar que as memórias importadas não foram estragadas, não sei qual é o sentido do OCR

    • Em open source, muitas vezes os desenvolvedores voluntários se concentram no que é divertido ou no que resolve os próprios problemas
      Não parece que lidar com a exportação meio quebrada do Google Photos seja divertido para alguém e, depois que você passa uma vez pela dor da importação, aquela coceira a ser coçada também desaparece
    • O senso de direito adquirido que aparece aqui é surpreendente
    • Em uma situação parecida, na semana passada migrei 12 mil fotos/vídeos do Google Takeout para o Immich
      Configurei o Immich com Ceph como backend e, com o immich-go, migrei todos os metadados e álbuns
      Tive que ajustar um pouco as opções de paralelização, mas fora isso foi muito fácil
    • Não seria porque esses serviços são caixas-pretas fechadas e não permitem acesso adequado, exceto por métodos bem indiretos?
  • Há muitas coisas em que você passa um tempão configurando, usa uma vez e nunca mais usa; e há muitas outras que são fáceis de configurar e trazem pequenos benefícios todos os dias
    O Immich levou bastante tempo para configurar e eu o uso muito raramente, mas é um software que, toda vez que uso uma vez por ano, me faz pensar que valeu muito a pena ter instalado

    • No meu caso, a configuração não levou tanto tempo assim, e gastei algum tempo em upgrades fazendo ajustes manuais por causa de mudanças que quebravam algo de vez em quando, mas não foi frequente
      Uso toda semana e ele simplesmente funciona bem, então é ótimo
    • Queria que minha experiência tivesse sido assim. Usei com Proxmox LXC e, depois de 2 meses organizando tudo, tive corrupção de dados e não tive energia para depurar até o fim
      Pelo que lembro, pode ter tido relação com uma migração de versão principal. Depois disso perdi o entusiasmo por essa stack
      Os upgrades não eram tão tranquilos quanto eu gostaria, e imagino que hoje ainda não seja muito diferente
      Eu só queria organizar as pastas fora de um sistema de biblioteca idiota, mas na época o Immich também não combinava bem com esse modo de uso
  • Estou curioso para saber se a sincronização de fotos no iOS melhorou. Tenho 20 mil fotos no celular e, na última vez que tentei, o armazenamento do telefone encheu com os originais; mesmo deixando o celular na mesma rede local por vários dias, desbloqueado, com o app do Immich aberto em primeiro plano, não terminou
    Sei que estavam trabalhando nisso, mas não acompanhei. Queria saber se agora funciona melhor e se vale a pena tentar de novo

    • As notas de versão dizem o seguinte
      “No iOS, a tarefa de atualização em segundo plano agora executa sincronização e upload em paralelo, então o upload de fato começa dentro da curta janela de tempo permitida pelo iOS”
      Mas não sei se isso corrige esse problema
    • Em fevereiro, sincronizei cerca de 9000 fotos do celular e foi bem tranquilo. Terminou em cerca de 10 horas
      Não lembro se os originais foram baixados nem se foram removidos automaticamente depois, mas o processo todo pareceu fluido
    • Uploads de arquivos grandes não podem ser retomados. Se você tiver vídeos com bitrate e resolução razoáveis, precisa conseguir enviar o arquivo inteiro em uma única sessão
      O iOS não facilita isso com uploads em segundo plano. Deixei o app aberto durante a noite e consegui enviar tudo
    • É bem provável que seja mais um problema do iOS do que do Immich. A Apple não vê com bons olhos apps que facilitem sair do iCloud
  • Fico me perguntando se “enviar assets diretamente para álbuns no app móvel” corrige este problema: https://github.com/immich-app/immich/discussions/12748
    Para mim é um problema bem grande, porque quero que vários dispositivos e várias pessoas juntem fotos de gatos em um único álbum
    Atualmente preciso montar algo assim. Sincronizo as fotos com Syncthing para /mnt/Syncthing/a1/cats/, /mnt/Syncthing/a2/cats/, /mnt/Syncthing/b/cats/ no servidor homelab que hospeda o Immich
    Um job cron faz cópias por hardlink das fotos para a pasta /mnt/immich/ext-lib/cats/, montada como volume de biblioteca externa somente leitura
    Outro job cron executa o script https://github.com/Salvoxia/immich-folder-album-creator, que cria álbuns automaticamente a partir da estrutura de pastas da biblioteca externa
    Por fim, rodo um job cron para limpar da pasta do Syncthing fotos com mais de 1 ano, para liberar espaço no celular. O conjunto tem cerca de 1 TB, então há alguns problemas
    Ainda assim, parabéns pelo lançamento 3.0. Só é um pouco frustrante porque descobri este programa há apenas um mês e só estabilizei minha configuração self-hosted há uma semana