{
  "versao": "8.86",
  "publicado_em": "2026-09-11",
  "novidades": "8.86 — Arquivos: ocultos ON/OFF, pasta do usuário REAL e menu \"Pastas\" nas duas colunas\n\n- Botão \"Ocultos: OFF/ON\" no alto do painel de arquivos. Por padrão os arquivos e pastas ocultos\n  não aparecem (nem os do técnico nem os da máquina); ligue para ver.\n- Corrigido no Windows com serviço: \"Pasta do usuário\" mostrava o perfil do SISTEMA (o agente roda\n  como SYSTEM). Agora mostra a pasta do usuário que está logado, de verdade.\n- Menu \"Pastas\" em cada coluna: Pasta do usuário, Área de trabalho, Documentos, Imagens, Downloads,\n  Vídeos e as unidades — com um clique, nos dois lados. As pastas são as reais do sistema (inclusive\n  Área de trabalho/Documentos redirecionados para o OneDrive; no Linux, os nomes em português).\n\n8.85 — Menu Atalhos (tecla Win, Win+Shift+S…) + acentos no Linux\n\n- Novo botão ATALHOS na barra da sessão: Win+R, Win+E, Win+D, Win+I, Win+L, Win+Shift+S\n  (recorte de tela), Alt+F4, Alt+Tab, PrintScreen e Ctrl+Shift+Esc. São as combinações que o\n  teclado do técnico não consegue mandar (a tecla Win, e Alt+F4/Alt+Tab que o Windows do\n  próprio técnico captura). Também \"Win preso\": a próxima tecla digitada vai com Win.\n- Corrigido no Linux (Rocky): letras acentuadas (ã, é, ê, õ, à, ü…) eram descartadas pelo GNOME\n  porque não têm tecla própria no layout. Agora vão como no teclado físico: tecla morta + letra.\n  Provado na bancada: \"a~bãçéÊõÇãox\" chegou exato.\n\n8.84 — Teclado do técnico: setas, foco na imagem, Ctrl+C/Ctrl+X, Shift/Ctrl no Linux\n\n- Corrigido: as SETAS do teclado nunca saíam do técnico (nem para Windows nem para Linux).\n- Corrigido: a primeira seta, Tab ou Escape tirava o foco da imagem e daí nenhuma tecla ia\n  mais para a máquina até clicar de novo (era o \"apagar não funciona\"). Agora, com a imagem em\n  foco, essas teclas são da máquina.\n- Corrigido: Ctrl+C e Ctrl+X não chegavam à máquina (copiar/recortar dentro da máquina).\n- Linux (Rocky): Shift+clique e Ctrl+clique passam a funcionar (Shift/Control/Alt por nome).\n- Provado na bancada: Backspace, Delete, Home, End e setas chegam certos ao Rocky.\n\n8.83 — Arquivos: cópia em streaming (memória e barra reais) + prioridade automática à cópia\n\n- Transferência em STREAMING nos dois sentidos: o arquivo é lido do disco no ritmo da rede,\n  em lotes, e não mais inteiro na memória. Um arquivo de vários GB não estoura mais a memória\n  do técnico nem da máquina atendida. A barra de progresso mostra o que realmente foi enviado\n  (antes corria a 100% em segundos e ficava parada) e cancelar para na hora.\n- Na máquina atendida o download passou a ir por um correio próprio: mouse e teclado não\n  ficam mais esperando atrás dos pedaços do arquivo.\n- PRIORIDADE AUTOMÁTICA à cópia: enquanto houver transferência em andamento, o vídeo cai\n  sozinho ao mínimo (1 quadro/s no Windows; no Linux pausa e retoma no próximo quadro-chave)\n  e a cópia fica com toda a banda. Ao terminar, o vídeo volta ao automático. Sem botão.\n- Se a conexão cair no meio de uma cópia, as transferências ficam marcadas como interrompidas.\n\n8.82 — Linux: rolagem do mouse invertida no client Rocky (técnico Windows)\n\n- Corrigido: ao atender uma máquina Linux (Rocky), a roda do mouse rolava ao contrário\n  (girar para baixo subia a página). O client Linux mandava o eixo vertical com o sinal\n  trocado; Windows×Windows já estava certo e continua igual.\n\n8.81 — Windows: o serviço voltava sem ninguém atender (correção urgente da 8.80)\n\n- Corrigido: no Windows, com a janela do FlyRemote aberta (ela reabre sozinha após cada\n  atualização), o serviço achava que \"já tinha agente\" e nunca subia o atendimento. Na 8.80\n  a máquina ficava com o serviço rodando e invisível para o técnico. Agora o serviço pergunta\n  à porta local se há alguém atendendo, e não mais ao nome do programa.\n- Essa mesma confusão é a raiz do \"às vezes o FlyRemote não sobe junto com o Windows e só\n  volta depois de um login por Terminal Service\". Teste após atualizar.\n- Técnico: ao cair a sessão da conta, o formulário volta com e-mail E senha preenchidos.\n\n8.80 — Fim das máquinas \"fantasma\" e da intermitência com o serviço instalado (caso MC-BACKUP)\n\n- Corrigido: com o serviço instalado, se ele parava por alguns segundos (atualização, religamento),\n  a janela do usuário assumia o atendimento com uma identidade NOVA e prendia a porta do serviço.\n  Resultado: equipamentos \"BACKUP\" repetidos no painel sem conta nenhuma, e a máquina de verdade\n  ora conectava, ora não. Agora, com o serviço instalado, a janela só espelha e espera ele voltar.\n- Remover o serviço devolve a identidade da máquina ao usuário: ela continua com o MESMO ID.\n- A máquina reafirma as contas em TODO início, mesmo sem conta guardada: excluída no painel\n  (Equipamentos) ou tirada da lista do técnico, ela reaparece sozinha ao reiniciar.\n- Painel (VPS): tela Equipamentos com caixa de seleção por linha, \"selecionar todos os visíveis\"\n  e botão \"Excluir selecionados\" com confirmação.\n\n8.79 — Máquina tirada da lista do técnico volta sozinha ao reiniciar\n\n- Corrigido: uma máquina removida da lista do técnico (lixeira) não voltava mais, nem\n  reiniciando, mesmo com a conta guardada nela. O servidor continuava listando o acesso\n  removido como se estivesse ativo, e a máquina achava que estava tudo certo.\n- Agora a máquina reafirma as contas sempre que QUALQUER conta guardada nela some da lista\n  do servidor (e não só quando a lista vem vazia). A conta guardada na máquina é a autorização.\n- Servidor: a lista de contas que a máquina consulta ao subir não mostra mais vínculo removido.\n\n8.78 — Arquivos: fim do travamento na transferência + confirmação ao desconectar\n\n- Corrigido um travamento: em certas conexões a transferência (e a navegação) podia parar sem\n  andar para nenhum lado. Agora o envio nunca fica preso.\n- Ao clicar em Desconectar com uma transferência em andamento, o programa pergunta antes de\n  encerrar, em vez de cortar a transferência sem avisar.\n- A lista de transferências mostra TODOS os itens copiados, com rolagem e um contador\n  (concluídos/total). Ao fechar o painel, a lista é limpa.\n\n8.77 — Arquivos: destino atualiza mais rápido ao terminar a cópia\n\n- Ao terminar de enviar ou baixar, a lista do lado de destino se atualiza quase na hora, sem a\n  demora que havia. No envio ainda há uma pequena espera da resposta da máquina remota, que é o\n  tempo normal de ida e volta pela rede.\n\n8.76 — Arquivos: barra de progresso do ENVIO agora anda de verdade\n\n- Ao enviar um arquivo para a máquina remota, a barra de porcentagem passa a andar acompanhando o\n  envio real pela rede, em vez de pular direto para o fim. O envio também deixa de disputar a\n  conexão de forma abrupta, ficando mais suave.\n- O download já mostrava o progresso; agora o envio também.\n\n8.75 — Arquivos: barra de progresso e atualização do destino durante a cópia\n\n- Corrigido: durante uma cópia, a barra de progresso não andava e o destino só atualizava depois.\n  A causa era a tela não se redesenhar enquanto o vídeo ficava parado por causa da transferência.\n  Agora, com o painel de arquivos aberto, a barra corre em tempo real e o arquivo copiado aparece\n  no destino assim que termina.\n\n8.74 — Arquivos: navegação remota, seleção destacada e atualização ao terminar\n\n- Corrigido: ao clicar numa pasta da máquina remota (Downloads, Documentos…), o conteúdo dela\n  não abria. Agora abre e mostra os arquivos de dentro.\n- O item selecionado fica com um fundo laranja suave, para ficar claro o que está escolhido.\n- Ao terminar uma cópia, o lado de destino se atualiza sozinho: o arquivo ou pasta que chegou\n  aparece na hora, sem precisar entrar e sair da pasta.\n\n- Corrigido: ao clicar numa pasta da máquina remota (por exemplo Downloads ou Documentos), o\n  conteúdo dela não abria. Agora abre e mostra os arquivos de dentro.\n- Um item selecionado (marcado) fica com um fundo laranja suave, para ficar claro o que está\n  escolhido antes de enviar, baixar ou excluir.\n\n8.73 — Arquivos: seleção por caixas, botões no meio e pastas inteiras (como na versão 7)\n\n- Agora dá para MARCAR vários arquivos e pastas (caixas de seleção) dos dois lados, com \"Marcar\n  todos\" e a lixeira para excluir os marcados.\n- Os botões de transferência ficam no MEIO, entre os dois lados: \"Enviar\" (seu → remoto) e\n  \"Baixar\" (remoto → seu), com a opção \"Sobrescrever\".\n- Enviar e baixar PASTAS inteiras, com suas subpastas e arquivos.\n- Ícones corrigidos: pastas e setas agora são desenhados (antes apareciam como quadradinhos).\n\n8.72 — Transferência de arquivos de volta (dois sentidos), como na versão 7\n\n- O técnico tem de novo o painel de arquivos, com o botão \"Arquivos\" na barra durante a sessão.\n- São dois lados: a sua máquina à esquerda e a máquina remota à direita. Você navega as duas pastas,\n  baixa um arquivo da máquina remota para a sua pasta, e envia um arquivo seu para a pasta remota,\n  com barra de progresso.\n- O motor de transferência já existia na versão 8; esta versão traz a tela que faltava.\n\n8.71 — Performance: quadro de vídeo entregue à interface sem disputa de trava\n\n- Do lado do técnico, o quadro decodificado passa a ser entregue à interface por troca de\n  buffers em vez de cópia sob trava. A thread que decodifica e a que desenha deixam de esperar\n  uma pela outra durante a entrega de cada quadro, o que ajuda a manter a taxa de quadros.\n- A imagem é idêntica; é só o caminho interno.\n\n8.70 — Performance: detecção de congestionamento no envio agora funciona\n\n- A máquina passa a medir corretamente quando o envio de vídeo está sendo segurado pela rede\n  (canal de saída cheio). Antes esse sinal ficava sempre em zero, então metade do controle de\n  ritmo não reagia a congestionamento no lado do envio. Agora, quando a rede segura, a máquina\n  reduz a taxa mais cedo, evitando acúmulo e engasgos.\n- Em rede folgada nada muda: o sinal fica em zero, como antes.\n\n8.69 — Performance: cursor remoto mais leve na máquina\n\n- A máquina só refaz o desenho do cursor quando a forma dele muda de verdade (seta, mãozinha,\n  texto), em vez de refazer o trabalho quinze vezes por segundo o tempo todo. Alivia o uso de\n  processador na máquina atendida, sem mudar o que o técnico vê.\n\n8.68 — Performance: captura de tela mais leve (sem trabalho desperdiçado)\n\n- A montagem de cada quadro capturado deixa de zerar uma área de memória grande que era, em\n  seguida, inteiramente sobrescrita. Em telas grandes isso alivia o custo por quadro e ajuda a\n  manter a taxa de quadros no caminho por software.\n- Mesmo alívio na redução de tamanho da imagem.\n- Nada muda na imagem; é só eficiência.\n\n8.67 — Limpeza interna (sem mudança de comportamento)\n\n- Remoção de código que não era mais usado e correção de comentários e do mapa de arquivos\n  desatualizados. Nada muda no funcionamento; é organização para facilitar a manutenção.\n\n8.66 — Robustez: reconexão e transferência não travam mais o processamento\n\n- Na reconexão, a espera pelo encerramento do vídeo anterior deixa de bloquear o processamento\n  interno do aplicativo. Isso torna a reconexão mais fluida em máquinas ocupadas.\n- Durante uma transferência de arquivo, a gravação em disco deixa de disputar espaço com o\n  processamento de mouse e teclado.\n- Nada muda no que você vê; é robustez interna.\n\n8.65 — Registro de diagnóstico mais eficiente e confiável\n\n- O arquivo de registro passa a ficar aberto, em vez de ser aberto e fechado a cada linha.\n  Isso importa quando o vídeo está com dificuldade: antes, cada quadro recusado gerava uma\n  escrita em disco no pior momento.\n- A mensagem de \"aguardando quadro-chave\" é registrada uma vez por episódio, não a cada quadro.\n- Nada muda no que o programa faz; é só o diagnóstico ficando mais leve e sem perder linhas.\n\n8.64 — Robustez de rede: conexão com teto de tempo e limites protegidos\n\n- Se o servidor de sinalização estiver inacessível por uma porta filtrada (firewall corporativo\n  que descarta em silêncio), o aplicativo desiste em 20 segundos e passa a tentar de novo, em vez\n  de ficar \"conectando…\" por vários minutos.\n- Protegido contra um valor inválido de taxa de quadros vindo da rede, que poderia derrubar a\n  captura.\n- Windows: corrigido um acúmulo lento de recursos no serviço que reinicia o atendimento muitas\n  vezes ao longo de dias ligado.\n\n8.63 — Robustez: sem vazamento de recursos e falhas que antes sumiam em silêncio\n\n- Corrigido um acúmulo de trabalho em segundo plano: a cada reconexão, a máquina criava uma\n  rotina extra do cursor que nunca terminava. Agora é uma só por sessão, encerrada ao desconectar.\n- Se a máquina não conseguir gravar sua identidade em disco (pasta sem permissão, disco cheio),\n  isso passa a ser registrado, em vez de sumir — era a causa de uma máquina reaparecer como\n  se fosse outra para o técnico.\n- Falhas inesperadas do serviço que atende em segundo plano passam a ser registradas (antes só\n  a janela registrava).\n- Ajuste interno na deteção da faixa de cor do vídeo, para evitar uma condição de corrida\n  durante reconexões rápidas.\n\n8.62 — Segurança: credencial do relay temporária e identidade da máquina protegida\n\n- A senha do relay (usado quando a conexão direta não é possível) não fica mais embutida no\n  programa. Agora o aplicativo pede uma credencial temporária ao servidor a cada conexão. Se\n  algum dia precisar trocar essa credencial, isso é feito no servidor, sem publicar versão nova.\n- No Windows, os arquivos de identidade da máquina (o identificador e o token) passam a ser\n  legíveis só pelo sistema e por administradores, não por qualquer usuário da máquina.\n- Compatível com as versões anteriores: quem está na 8.61 ou antes continua conectando\n  normalmente pelo relay antigo.\n\n8.61 — Segurança do acesso: só o servidor decide o vínculo; a máquina pergunta antes de liberar\n\n- Corrigida uma brecha no acesso: era possível, por uma mensagem forjada, entrar numa máquina\n  como se a conta fosse vinculada, sem senha. Agora quem decide se uma conta é vinculada é\n  SEMPRE o servidor; a mensagem de conexão não carrega mais essa afirmação.\n- Quando alguém pede acesso a esta máquina sem senha e sem vínculo, a máquina não libera mais\n  sozinha: mostra \"Fulano quer acessar esta máquina\" com os botões Permitir e Negar. Sem\n  ninguém na tela (serviço em segundo plano), o pedido é negado.\n- flyremote --atualizar (linha de comando) não reabre mais a janela ao terminar; só o botão\n  Atualizar da interface reabre o aplicativo.\n\n8.60 — Segurança: senha fora do registro; login guardado protegido; codificação na tela\n\n- A senha de acesso desta máquina não vai mais para o arquivo de registro (nem para o\n  diagnóstico enviado ao servidor). O registro só diz que a senha foi trocada.\n- O e-mail e a senha guardados do técnico (\"lembrar\") deixam de ficar em texto claro no\n  disco: agora vão ofuscados, com uma chave própria da instalação. Um arquivo antigo é\n  convertido na primeira abertura. O botão \"Limpar e-mail e senha guardados\" apaga também\n  o arquivo que versões anteriores deixavam.\n- Tela do Cliente: com o serviço atendendo em segundo plano, a linha CODIFICAÇÃO mostrava\n  \"—\". Agora mostra a codificação que o serviço está usando (ex.: \"Placa (VA-API) · pelo\n  serviço\").\n- Primeira versão que passa pelo portão de publicação (bancada/portao.sh): testes,\n  clippy, serviço, canal local, conexão com conta sem vínculo, Windows, atualização\n  no Debian e no Rocky, registro sem senha.\n\n8.59 — Correção: a \"Nova senha\" passa a valer de verdade\n\n- Ao clicar em \"Nova senha\" no modo Cliente, a tela mostrava o número novo, mas a\n  máquina continuava aceitando só a senha antiga: o técnico digitava o número que o\n  cliente ditava e recebia \"senha errada\". Corrigido: a senha conferida na conexão é\n  sempre a que está na tela (vale também para a senha pedida pela janela quando o\n  serviço atende em segundo plano).\n- Achado na revisão completa do código de 09/09; nada mais muda nesta versão.\n\n8.58 — Atualização automática no Debian e Ubuntu\n\n- O botão \"Atualizar\" agora funciona também no Debian e no Ubuntu: baixa o pacote\n  .deb e instala pelo apt (o sistema pede a senha uma vez). No Rocky continua pelo\n  RPM, como antes.\n- Se o serviço estiver instalado, ele é religado com a versão nova ao terminar.\n- Novo no Linux: flyremote --atualizar atualiza pela linha de comando, sem janela\n  (útil por SSH ou em máquinas administradas).\n- O pacote .deb passa a depender do curl (é com ele que o app baixa a atualização).\n\n8.57 — Serviço no Linux (Rocky, Debian e Ubuntu), como já existia no Windows\n\n- Ferramentas ganhou o botão \"Instalar o serviço\" também no Linux. Com ele, a\n  máquina passa a atender assim que o usuário entra na sessão, sem precisar abrir\n  o programa, e continua atendendo com a janela fechada; se o atendimento cair, o\n  sistema religa sozinho em 3 segundos.\n- É um serviço do próprio usuário (systemd --user), então não pede senha de\n  administrador para instalar nem para remover. A janela aberta por cima mostra o\n  ID e a senha do serviço (\"Atendida pelo serviço em segundo plano\"), igual ao\n  Windows.\n- Também pela linha de comando: flyremote --instalar-servico / --desinstalar-servico.\n- Ao atualizar pelo botão, o serviço é religado com a versão nova.\n- Limite: no Linux o serviço ainda não atende na tela de login (o GNOME só libera a\n  tela depois que alguém entra). No Windows continua igual (tela de login, UAC,\n  Ctrl+Alt+Del).\n\n8.56 — Feed de atualização na raiz de download.flyremote.com.br\n\n- As versões antigas (linhas 3 a 7) foram descontinuadas e apagadas do servidor\n  de download. Só a versão 8 existe, e o feed passou para a raiz:\n  https://download.flyremote.com.br/versao.json (exe, RPM, binário Linux e .deb).\n- O caminho antigo /flyremote8/ continua respondendo com os mesmos arquivos,\n  então as instalações 8.x anteriores seguem se atualizando normalmente.\n- Nada muda no funcionamento do app.\n\n8.55 — Pacote .deb para Debian e Ubuntu\n\n- Além do RPM (Rocky/Fedora), o feed passa a ter o .deb: flyremote_<versão>_amd64.deb,\n  para Debian 12 e 13, Ubuntu 22.04 e 24.04. Instalação: baixe e rode\n  \"sudo apt install ./flyremote_8.55.0_amd64.deb\" (as dependências vêm sozinhas).\n- Compilado dentro de um Debian 12 (glibc 2.35 exigida), com o mesmo layout do RPM:\n  /opt/flyremote/flyremote, atalho no menu, ícone, buffer UDP de 8 MB no sysctl.\n- Provado instalando em Debian 12, Debian 13 e Ubuntu 24.04 limpos, e rodando a janela\n  a partir de um container Debian 13.\n- Ainda não há atualização automática no Debian (só no Rocky pelo RPM): atualize\n  reinstalando o .deb novo. Fica para a próxima.\n\n8.54 — Ícones do botão Atualizar e do modal de conexão desenhados\n\n- A seta do botão verde \"Atualizar\" e a marca de \"feito\" das fases do modal\n  de conexão eram caracteres de texto que a fonte do app não tem e apareciam\n  como caixinha. Agora são desenhados a traço, como os outros ícones do app.\n\n8.53 — Modal de conexão no técnico: fases e a primeira imagem com bytes reais\n\n- Ao clicar em Conectar, uma caixa centralizada mostra as fases: pedindo\n  acesso, pedido entregue, a máquina respondeu, conexão estabelecida em N ms,\n  e a chegada da primeira imagem com KB recebidos, total, percentual e\n  velocidade (kbit/s) — medidos nos pacotes que chegam de verdade.\n- A máquina passa a avisar o tamanho de cada quadro-chave que manda; é esse o\n  total da barra. Máquinas antigas não avisam: a barra anda sem percentual.\n- Rápido = a caixa pisca e some na primeira imagem. Lento = depois de 2 s\n  abaixo de 1,5 Mbit/s aparece em laranja \"os dados estão chegando devagar —\n  a internet da máquina pode estar lenta\". Diagnóstico na hora.\n- O registro do técnico anota \"primeira imagem: X KB em Y ms (Z kbit/s)\".\n- Na reconexão automática a caixa diz \"Reconectando (tentativa N)\".\n\n8.52 — Regra de firewall do serviço Windows só para UDP\n\n- O serviço criava duas regras de entrada no firewall do Windows, UDP e TCP,\n  para o programa em qualquer porta. O túnel só usa UDP (o TURN por TCP é\n  saída), então a regra TCP não servia a nada e deixava o programa liberado\n  para uma porta TCP que ele nem escuta.\n- Agora só a regra UDP existe. Ao subir, o serviço apaga a regra TCP antiga\n  e garante a UDP — máquinas já instaladas ficam certas sem reinstalar.\n- Nada muda no funcionamento: a conexão continua fechando pela VPS e o\n  túnel continua o mesmo.\n\n8.51 — Texto \"cortado\" no técnico Windows ao ver o cliente Rocky\n\n- O cliente Rocky manda sempre a tela nativa (3440×1440); no técnico ela é\n  encolhida para caber na área da janela. O filtro Nearest (8.37/8.38, que\n  deixa o texto nítido em tamanho 1:1) pulava linhas inteiras ao encolher,\n  e o texto aparecia riscado/cortado.\n- Agora o técnico escolhe por quadro: área igual ao quadro (1:1) continua\n  Nearest, nítida; qualquer encolhimento usa Linear, sem pular linhas.\n  Windows×Windows não muda (a máquina já codifica no tamanho da janela = 1:1).\n- O registro anota a troca: \"[visor] amostragem: 1:1 nítida\" ou \"escalada\n  suave (quadro AxB → área CxD px)\".\n\n8.50 — Janela do técnico no Windows encaixa nos cantos como as outras\n\n- No Windows, ao conectar, a janela agora fica MAXIMIZADA em vez de tela\n  cheia. Em tela cheia o Windows tira da janela os estilos de mover e\n  encaixar (Aero Snap): ela parecia \"fixa\" e não se ajustava ao arrastar\n  para o canto. Maximizada, restaura e encaixa como qualquer janela.\n- F11 continua alternando a tela cheia de verdade; ao desconectar a janela\n  volta ao tamanho normal e centralizada.\n- No Rocky Linux nada muda (o GNOME já movia e encaixava em tela cheia).\n\n8.49 — Registro do técnico deixa de ser cego à sinalização\n\n- O registro do técnico (monitor-janela.log) agora anota quando a ligação\n  com o servidor cai (\"[sinal] caiu: … — religa em N s\"), quando religa\n  (\"[sinal] ligado ao Phoenix\") e quando o túnel entra em \"religando\".\n- Antes isso só aparecia na barra da janela; numa queda real de internet\n  não dava para saber, pelo registro, se foi o servidor, o túnel ou a\n  máquina — a máquina já anotava, o técnico não.\n- Junto com a 8.48 (\"túnel de pé em N ms\", tentativas, \"reconectado na\n  tentativa N\"), os dois registros contam a mesma história com os tempos.\n\n8.48 — Reconexão automática do técnico depois de uma queda\n\n- Caiu a internet ou a máquina sumiu? O técnico agora desiste do túnel caído\n  em 3 s (antes esperava o WebRTC declarar falha, 25 s) e tenta de novo\n  sozinho: em 2, 4, 8, 15 e 30 s, por até 5 minutos, mostrando \"reconectando\n  (tentativa N)\". Botão \"Parar de tentar\" no cartão do técnico.\n- Só reconecta quando o fim foi QUEDA (túnel caiu, não subiu, máquina não\n  respondeu, sinalização caiu). Nunca quando alguém decidiu: você encerrou, a\n  máquina encerrou, senha errada, sem vínculo, ocupada.\n- Respeita o limite do servidor (5 pedidos/min com senha): \"muitas\n  tentativas\" espera 61 s.\n- O registro do técnico passa a anotar \"túnel de pé em N ms\", a queda, cada\n  tentativa e \"reconectado na tentativa N — X s depois da queda\".\n- Bancada: máquina some sem avisar → técnico encerra por queda em 8,4 s\n  (5 s do ICE + 3 s); com a 8.47 a máquina aceita o pedido novo na hora.\n\n8.47 — Máquina recomeça na hora quando o mesmo técnico pede de novo\n\n- Técnico que caiu (rede, app fechado à força) e volta a pedir acesso: a\n  máquina agora larga a sessão velha e abre a nova imediatamente. Antes o\n  pedido era engolido como \"pedido de quadro-chave\" (túnel ainda parecia de\n  pé) ou respondido com a oferta VELHA a um peer novo (\"invalid … from\n  stable\"), e a máquina ficava presa até o túnel expirar (20–30 s).\n- Regra: pedido do mesmo técnico com túnel caído, ou já respondido e não\n  subido, ou conectado há mais de 3 s = sessão nova. Repetição legítima em\n  voo (nos 3 s iniciais) continua sendo tratada como antes.\n- Corrigido defeito latente: o evento \"Closed\" do túnel velho derrubava a\n  sessão nova quando a máquina trocava de sessão no mesmo passo (canal de\n  eventos agora é por sessão).\n- Bancada: técnico some sem avisar e volta → túnel novo de pé em ~0,1 s.\n\n8.46 — Fim da \"sessão zumbi\" no técnico (derrubava a conexão nova)\n\n- Causa achada nos registros de 08/09: ao clicar Conectar/Desconectar, o laço\n  da sessão anterior continuava vivo por até minutos (cada envio esperava 5 s\n  pela via de um túnel já morto) e, ao acordar, mandava \"encerrar\" à máquina —\n  derrubando a sessão NOVA do mesmo técnico (\"o técnico encerrou\" sem clique).\n- Agora os envios do técnico saem por um carteiro próprio (em ordem), o laço\n  nunca fica cego, e Encerrar sai na hora. Um túnel já acabado recusa o envio\n  de imediato em vez de esperar 5 s (vale para as duas pontas).\n- O visor só abre a sessão nova depois que a anterior confirma o fim (≤1,5 s).\n- Bancada: fim com 8 envios na fila e túnel morto em 0,5 ms (antes ≥ 40 s);\n  reconectar por cima sem a sessão nova cair.\n\n8.45 — Cliente Rocky: imagem instantânea no connect, sem depender do mouse\n\n- Antes, com o cliente no Rocky Linux e a tela parada, o técnico ficava sem\n  imagem até alguém mexer o mouse na máquina cliente. Motivo: o Mutter só\n  entrega um quadro novo quando a tela muda (\"dano\"), então nada era enviado.\n- Agora a captura reemite o último quadro sozinho a cada 100 ms\n  (keepalive do pipewiresrc). Ao clicar em Conectar, a transmissão começa\n  na hora e o stream fica contínuo — independente de mexer o mouse.\n- Isso também acaba com a sensação de \"travado\": o VA-API passa a receber\n  quadros continuamente em vez de só nos momentos de movimento.\n\n8.44 — Cor convertida na PLACA (GPU), não mais na CPU\n\n- O técnico Windows agora recebe o vídeo em NV12 cru e converte a cor\n  (YUV → RGB) dentro do shader da placa, na GPU. Antes essa conta rodava\n  na CPU e travava o desenho quando o cliente é o Rocky em Full HD/nativo.\n- Resultado: técnico Windows → cliente Rocky ficou fluido, sem perder cor\n  nem nitidez (a conta é a mesma, só mudou de lugar).\n- A cópia da imagem para a placa caiu pela metade (NV12 ~1,5 byte/pixel\n  contra 4 do RGBA).\n- Windows × Windows não muda: mesma cor BT.601 de sempre.\n\n8.43 (diagnostico de cor + reconexao): acrescenta no registro do tecnico a faixa de cor que ele detectou do fluxo do cliente Rocky (CHEIA BT.709 = certo, ou limitada BT.601 = o motivo da cor errada), para eu confirmar onde esta o problema da cor. Sem mudanca de comportamento; a proxima versao traz a correcao definitiva com base nisso.\n\n8.42 (cliente Rocky -> tecnico Windows): agora IGUAL a versao de teste. Quatro correcoes juntas: (1) COR FIEL — o tecnico agora LE a faixa de cor do proprio video (como fazia o GStreamer do teste) e converte em BT.709 faixa cheia quando o cliente e Rocky; antes convertia sempre em BT.601 fixo e a cor saia errada. Medido no decodificador real do tecnico: as 7 cores batem. (2) RECONEXAO RAPIDA — quadro-chave a cada 2 s (era a cada 34 s), entao ao reconectar a imagem volta na hora. (3) QUALIDADE — perfil H.264 'high' (CABAC), texto limpo sem os artefatos do 'baseline'. (4) FLUIDEZ — 30 quadros/s no nativo, que o decodificador do tecnico acompanha. O Windows x Windows continua BT.601 (o tecnico so muda a cor se detectar faixa cheia no fluxo) e so herda o filtro de nitidez.\n\n8.41 (cliente Rocky -> tecnico Windows): QUALIDADE de imagem MUITO melhor, sem os artefatos ('sujeira') ao redor do texto. Causa dos artefatos: o video estava em perfil H.264 'baseline', que nao tem a compressao boa (CABAC) e estraga texto. Agora vai em perfil 'high' (CABAC + transform 8x8), que comprime texto com muito mais qualidade pela mesma banda. Confirmei medindo no PROPRIO decodificador da placa do tecnico (Media Foundation/DXVA): decodifica high em 32 ms/quadro (baseline dava 30), ou seja, custa quase o mesmo e cabe folgado nos 30 quadros/s. Resultado: imagem limpa e nitida, cor certa (BT.601), fluida a 30 q/s no nativo. OBS: exige decodificacao por placa no tecnico (todas as maquinas modernas tem). Windows x Windows nao muda.\n\n8.40 (cliente Rocky -> tecnico Windows): equilibrio entre QUALIDADE e FLUIDEZ. A 8.39 (fator 20) era fluida mas a imagem ficava pobre; o fator 16 (mais qualidade) sozinho afogava o decodificador do tecnico no NATIVO. Solucao: baixei a taxa para 30 quadros/s (era 48) e voltei ao fator 16. Menos quadros para decodificar libera o decodificador do tecnico para desenhar cada quadro com qualidade alta, e 30 q/s continua fluido para acesso remoto. Resultado: imagem nitida e com qualidade, e fluida. Cor em BT.601 (certa) e texto nitido (filtro vizinho mais proximo) mantidos. Windows x Windows nao muda.\n\n8.39 (cliente Rocky -> tecnico Windows): a 8.38 acertou a COR (BT.601, se aproximou do certo) mas ficou LENTA — o fator de qualidade 16 gerava bits demais para o decodificador do tecnico acompanhar no NATIVO em tempo real. Voltei ao fator 20 (o mesmo da 8.36, que era fluida), mantendo a cor certa (BT.601 faixa limitada) e o texto NITIDO (filtro vizinho mais proximo). Agora: fluido de novo, cor certa e texto nitido. Windows x Windows nao muda.\n\n8.38 (corrige a 8.37 no caminho cliente Rocky -> tecnico Windows): a 8.37 tinha quebrado a cor (absurda), a fluidez e a reconexao. Causa: eu tinha forcado faixa de cor CHEIA BT.709 e conversao por OpenGL, que funcionavam no projeto de teste porque LA o tecnico usa outro renderizador (GStreamer) que le a faixa do proprio video. No FlyRemote o tecnico decodifica por Media Foundation com matriz FIXA BT.601 faixa limitada, entao a faixa cheia era lida errado; e o OpenGL travava a reconexao. Correcao: o Rocky agora manda exatamente BT.601 faixa limitada (o mesmo que o cliente Windows manda, o que o decodificador espera) — cor certa; conversao de volta ao caminho estavel (sem OpenGL) — fluidez e reconexao de novo boas. Fica a melhoria que porta bem: qualidade um pouco maior (qpi 16) e o texto NITIDO no tecnico (filtro 'vizinho mais proximo' no lugar do linear, que borrava). Windows x Windows: so herda o filtro de nitidez, que so melhora; o resto nao mudou.\n\n8.37 (cliente Linux/Rocky + tecnico): QUALIDADE DE IMAGEM e COR portadas da versao de teste que ficou nitida e fiel. So no caminho cliente Rocky -> tecnico Windows; o Windows x Windows (tecnico Win x cliente Win) NAO mudou nada. Tres melhorias: (1) a conversao de cor no Rocky agora e por OpenGL na placa (GPU) — cor FIEL, sem o desvio alaranjado que o conversor VA-API dava no vermelho; (2) faixa de cor CHEIA (BT.709): preto real, branco 255, brilho de verdade, fim do acinzentado; (3) o tecnico desenha a imagem com filtro 'vizinho mais proximo' no lugar do linear — texto NITIDO, sem o borrao que o filtro linear causava ao ajustar a imagem a janela. O Rocky codifica no NATIVO (sem reduzir a tela) com qualidade alta (qvbr fator 16) e teto de 50 Mbit, que a rede local entrega inteiro e a internet limita sozinha. Testado na bancada: 159/159 quadros, zero recusados, imagem nitida e cor fiel.\n\n8.36 (cliente Linux/Rocky): o codificador da placa agora usa AS MESMAS REGRAS do Windows — qualidade maxima e mais fluido. Antes o Rocky estava preso em valores fixos (30 quadros/s, 25 Mbit CBR, quadro-chave a cada 2 s) enquanto o Windows como maquina usava taxa por QUALIDADE, quadro-chave raro e ate 60 quadros/s. Igualado: (1) rate-control=qvbr — qualidade definida (fator 20) com teto de banda de 40 Mbit, o equivalente ao modo Qualidade 85 do Windows, no lugar do CBR travado em 25; (2) quadro-chave RARO (a cada ~21 s no lugar de 2 s) — na rede local nao se perde pacote e o quadro-chave periodico so travava; (3) ate 48 quadros/s (era 30) — o teto realista que o decodificador do tecnico acompanha sem formar fila; (4) target-usage=1, a preferencia por qualidade da placa. Provado na bancada local sob movimento pesado: 47 quadros/s, 42 Mbit, zero recusados, texto nitido. No Windows como maquina nada muda.\n\n8.35 (tunel, as duas pontas): FIM DA PERDA DE PACOTES na chegada ao tecnico. Todo socket UDP do video agora nasce com buffer de 8 MB (recepcao e envio). O padrao do Windows e 64 KB: um quadro H.264 de 25 Mbit a 30 quadros/s chega numa rajada grande e estourava o buffer — o tecnico marcava 'perdidos' todo segundo e a imagem TRAVAVA, mesmo com a rede (cabo gigabit) sem perder nada. Com o buffer grande a rajada cabe e o tecnico recebe o quadro inteiro. No Linux o instalador tambem sobe o teto do sistema (net.core.rmem_max/wmem_max) para o socket poder pedir os 8 MB. Vale para os dois sentidos (Windows->Rocky e Rocky->Windows). Atualize as DUAS pontas.\n\n8.34 (cliente Linux/Rocky): IMAGEM NITIDA na placa (VA-API) — fim do borrao. Causa achada medindo na bancada local (sem rede, sem Windows): a captura do PipeWire nao informava uma taxa de quadros FIXA ao codificador, e ele repartia os 25 Mbit numa taxa irreal (~150 quadros/s) — cada quadro saia com ~165 kbit, total ~5 Mbit, texto ilegivel. Agora o cano fixa 30 quadros/s antes do codificador: 25 Mbit reais (CBR, o mesmo padrao do Windows) e o texto do terminal legivel no quadro salvo. Alem disso, as DUAS pontas passam a registrar as medidas deste sentido no log (a maquina Linux: quadros/s, kbit/s, chaves e o que o tecnico mede; o tecnico: recebe, descomprime, idade, perdidos e se decodifica por GPU ou software). No Windows como maquina nada muda.\n\n8.33 (cliente Linux/Rocky): RECONEXAO usa a PLACA (VA-API) em toda conexao. Antes, ao sair e entrar de novo, a 2a conexao caia para o codificador por software ('nao entregou quadro em 8 s'): o gst-launch da conexao anterior ainda segurava o no do PipeWire e a sessao do Mutter, e a captura nova nao recebia quadro. Agora a maquina ESPERA o video da conexao anterior terminar de verdade (ate 1,5 s) antes de abrir o novo. Prova isolada: bancada_reconecta (duas sessoes seguidas, sem tecnico/rede) diz qual codificador cada uma usou. No Windows nada muda.\n\n8.32 (tecnico Windows): DECODIFICACAO POR HARDWARE (GPU/DXVA). O tecnico agora descomprime o video na PLACA (Media Foundation), com reserva por software se a placa nao der. E o que permite qualidade alta (QP baixo) no NATIVO sem afogar o tecnico: a placa decodifica em tempo ~constante, enquanto o software estourava com quadros grandes. Ha um INDICADOR na barra de cima da sessao: 'decodifica: GPU (placa)' ou 'Software'. Testado isolado: decodifica 150/150 quadros no nativo 3440x1440, imagem correta. A maquina Linux codifica na placa (VA-API) no nativo com QP 16. No Windows->Windows nada muda.\n\n8.31 (cliente Linux/Rocky): qualidade NITIDA no NATIVO, sem reduzir a tela. A placa (VA-API) agora codifica com BITRATE CONTROLADO (CBR), o MESMO padrao do Windows (que usa taxa controlada ate 40 Mbit) — antes eu usei CQP (taxa ilimitada, o quadro-chave gigante TRAVAVA o tecnico) e depois VCM (matava a banda, ficava ilegivel). Agora o quadro fica limitado E a banda e alta: no proprio tecnico Windows, medido no nativo 3440x1440, deu ~30 quadros/s, latencia ~9 ms, zero travas. Resultado: nitido (da para ler texto), fluido e sem repique — e a tela NAO e mais reduzida. No Windows nada muda.\n\n8.30 (cliente Linux/Rocky): SOLUCAO do travamento/qualidade do VA-API, detectada medindo no proprio tecnico Windows. Tres causas resolvidas: (1) o quadro no NATIVO (3440x1440) era grande demais e o tecnico nao decodificava a tempo (travava) — agora a placa codifica REDUZIDO (ate 1920), que o tecnico decodifica a ~3 ms sem travar; (2) o bitrate era ILIMITADO (CQP) e sob conteudo pesado explodia e afogava a rede — agora usa VCM (modo videoconferencia) com teto, entao o fluxo NUNCA colapsa (testado ate com ruido total: 40 q/s, idade 3 ms, 0 perdidos); (3) o mouse volta a mapear certo (area = resolucao do monitor). A placa segue matando o 'repique'. Se nao houver placa, cai para software. No Windows nada muda.\n\n8.29 (cliente Linux/Rocky): torna a PLACA (VA-API) confiavel. Medido: sob movimento, a captura do GNOME/Wayland entrega ~32 quadros/s quando o encoder e a GPU, contra ~18 no software — e e o encoder lento do software que causa o acumulo e o 'repique' (vai-e-volta ao parar de arrastar). Ficou provado que o VAS-API decodifica perfeito e da latencia de ~6 ms. Nesta versao: (1) o arranque da placa tem mais tempo (8 s) e, se falhar, o registro passa a DIZER o motivo do gst (antes ficava mudo); (2) o software de reserva nao oscila mais de resolucao (causava saltos). Requisito da placa: driver de midia Intel/AMD. No Windows nada muda.\n\n8.28 (cliente Linux/Rocky): a captura passa a usar a PLACA DE VIDEO (VA-API) quando ela existe — e e isso que MATA o 'repique' ao arrastar janela. O software codificava quase no tamanho nativo e nao acompanhava o movimento (medido: ~25 quadros/s a 3440 de largura), entao os quadros represavam e a janela 'ia e voltava' ao parar. A GPU codifica o nativo em tempo real, sem esse atraso. O mouse ja funciona no VA-API (a resolucao e lida do proprio fluxo). Se a placa nao existe ou nao sobe, cai para software AGORA com resolucao ADAPTATIVA: nitido com a tela parada, mais leve durante o movimento, para nao repicar. Requisito da placa: driver de midia da Intel/AMD instalado (senao, software). No Windows nada muda.\n\n8.27 (Windows): DOIS consertos importantes. (1) LOGIN: o serviço so reata sessao ao console (tscon) quando ha um TECNICO conectado. Antes ele fazia isso a cada 30s mesmo ocioso e, se voce estava digitando a senha na tela de login (console ainda sem usuario), ele podia trazer uma sessao RDP desconectada por cima do seu login e quebrar o carregamento do perfil ('nao foi possivel carregar o perfil de usuario'). Agora um login normal nunca e tocado. (2) ASSINATURA: o certificado do editor foi refeito do jeito correto (uma CA raiz + um certificado-filho de code-signing) — antes a assinatura nao era valida no Windows (erro de restricao basica). Agora, com a instalacao do servico instalando a CA, o Windows valida a assinatura (verificado: 'Assinatura verificada'), o que remove o 'editor desconhecido' e reduz o falso positivo de antivirus. No Linux nada muda.\n\n8.26 (Windows): o programa volta a ser ASSINADO digitalmente (editor 'FacilRapido Tecnologia'), e a INSTALACAO DO SERVICO agora instala esse certificado como confiavel na maquina (armazens Root e TrustedPublisher). Com isso o Windows reconhece o editor — some o aviso de 'editor desconhecido' e do SmartScreen — e cai muito o falso positivo de antivirus COMPORTAMENTAL sobre o arquivo de atualizacao (ex.: o PDM:Trojan.Win32.Generic da Kaspersky), que era disparado justamente por ser um .exe baixado SEM assinatura. Se o antivirus insistir no comportamento do updater, marque o FlyRemote como aplicativo confiavel nele. No Linux nada muda.\n\n8.25 (cliente Linux): conserta o 'repique/retrocede' que aparecia SO no tecnico e a queda de qualidade da 8.24 — os dois eram culpa de uma mudanca minha na 8.24. Aquela versao, para nao 'andar depois de parar', descartava quadros DEPOIS de codificados; mas o H.264 e diferencial (cada quadro depende do anterior), entao pular um quebrava a cadeia e o tecnico mostrava imagem velha/embolada (o 'retrocede'). Agora o video foi reconstruido do jeito certo: a captura so guarda o quadro MAIS NOVO e a codificacao pega sempre esse — quadros antigos sao descartados ANTES de virar H.264, onde e seguro. Assim a imagem nunca corrompe, o arrasto para na hora, E a nitidez volta ao normal (acabou o limite de 1600 da 8.24; volta a codificar no tamanho da janela do tecnico). Validado localmente: 0 quadros recusados pelo decodificador. No Windows nada muda.\n\n8.24 (cliente Linux): acaba com o 'repique' ao arrastar janela. Em telas grandes (por exemplo um monitor ultrawide 3440x1440) o software estava codificando quase na resolucao nativa e nao acompanhava o movimento — os quadros represavam e a janela continuava andando depois de voce parar. Agora o caminho por software tem um TETO de resolucao (ate 1600 de largura; o tecnico amplia de volta), entao a codificacao acompanha a captura folgado. E na saida para a rede, se na hora de enviar ja existe um quadro MAIS NOVO esperando, o antigo e descartado (a duracao vai para o novo) — nunca um quadro-chave, do qual o decodificador depende. Assim o tecnico ve sempre o quadro atual, sem aquela fila de quadros velhos escoando. Resultado: o arrasto de janela para na hora. No Windows nada muda.\n\n8.23 (cliente Linux): muito mais LEVE e FLUIDO. Agora a maquina Linux reduz a resolucao para o tamanho da janela do tecnico (como no Windows), o que derruba a latencia — o arrasto de janela para na hora, sem aquele 'continua andando depois de parar'. A codificacao por software (OpenH264) passa a ser o padrao, confiavel (mouse, teclado e recuperacao de quadro-chave). A placa (VA-API) fica como experimental (so com a variavel FLY8_GPU=1) ate ganhar pedido de quadro-chave sob demanda. No Windows nada muda.\n\n8.22 (cliente Linux): conserta o RECONECTAR sem controle — ao reconectar rapido, o fio de video antigo zerava o controle do novo; agora so limpa se ainda for a propria sessao. O encerramento pela placa (VA-API) ficou imediato (antes se arrastava). E o cartao da maquina no Linux passa a mostrar se esta na Placa (VA-API) ou por Software. No Windows nada muda.\n\n8.21 (TESTE do cliente Linux): agora o Rocky/Linux tambem pode ser MAQUINA (ser acessado), nao so tecnico. Ele captura a tela pelo GNOME (Wayland) e aceita mouse e teclado do tecnico. A codificacao segue uma ESCADA: usa a PLACA de video (VA-API) quando ela esta disponivel, senao cai para software automaticamente. No Windows nada muda. Obs: no Linux a maquina precisa estar com o programa aberto e alguem logado na sessao grafica (servico/tela de login vem depois). Para a placa entrar, e preciso o driver de midia da Intel/AMD instalado; sem ele, funciona por software.\n\n8.20: ao desconectar, a maquina agora LIBERA A PLACA DE VIDEO por completo. Antes o codificador de hardware ficava com a sessao de codificacao aberta e a GPU seguia ocupada (medido: ~12% travados numa GPU pequena, ~41% numa maior) mesmo sem ninguem conectado. Agora o uso de GPU volta a 0% assim que o tecnico desconecta. O encerramento da captura ficou documentado no codigo (leve, sem travar).\n\n8.19: na sessao do tecnico ha um botao Ctrl+Alt+Del para enviar a combinacao para a maquina remota (util no Windows Server, na tela de login e para abrir o Gerenciador de Tarefas). So funciona com o servico instalado na maquina, que e quem o Windows deixa injetar essa combinacao.\n\n8.18: versao de teste da atualizacao do Linux (confirma o conserto da 8.17). Se apos atualizar o canto mostrar v8.18, o Rocky esta atualizando certo.\n\n8.17: conserta a atualizacao no Rocky/Linux que baixava, reabria e continuava na versao antiga. O pacote RPM estava levando um binario defasado (a versao dentro do programa nao acompanhava a etiqueta do pacote), entao ele reinstalava e reoferecia a atualizacao num laco. Agora o empacotamento recompila e confere a versao antes de publicar.\n\n8.16: a lixeira de EXCLUIR agora aparece tambem nas maquinas RECENTES (aquelas em que voce ja entrou, guardadas so neste computador). Antes elas tinham um icone de chave diferente e gerava confusao. Agora e um botao so de excluir para tudo: nas da conta ele desvincula (com confirmacao); nas recentes ele tira da lista deste computador.\n\n8.15: no tecnico, botao de LIXEIRA em cada maquina da conta para EXCLUIR (desvincular) ela da sua lista, com uma confirmacao antes. Nao apaga a maquina em si nem o programa dela — so tira da sua lista; da pra vincular de novo depois.\n\n8.14: em Ferramentas ha um botao Verificar atualizacao para checar na hora se saiu versao nova (antes so checava ao abrir e a cada 30 min). Se ja estiver na ultima, ele avisa; se houver nova, aparece o botao Atualizar.\n\n8.13: no tecnico, botao de LAPIS em cada maquina da conta para RENOMEAR. O nome novo e salvo no servidor (Phoenix), entao vale para todos: ao conectar de outro computador, a lista ja mostra o nome atualizado. O servidor nao deixa duas maquinas da mesma conta com o mesmo nome.\n\n8.12: conserta a IDENTIDADE da maquina ao instalar o servico no Windows. Em maquinas que vinham de uma versao antiga (a identidade morava na pasta do usuario), o servico rodando como SYSTEM nao enxergava essa pasta e gerava um device_id NOVO — a maquina aparecia como OUTRA no tecnico e a antiga ficava offline. Agora a instalacao copia a identidade da pasta do usuario para a pasta do sistema antes de o servico subir, entao a maquina continua com o mesmo ID.\n\n8.11: versao de TESTE da atualizacao automatica. Se voce esta lendo isto pelo botao Atualizar e, depois de atualizar, o canto da tela mostra v8.11 e este aviso sumiu, entao a atualizacao esta funcionando de ponta a ponta.\n\n8.10: o FlyRemote agora AVISA quando ha versao nova. Ele le o feed da VPS de tempos em tempos e, quando sai uma versao mais nova, mostra um botao verde \"Atualizar\" na barra de cima; em Ferramentas aparecem as novidades e o botao Atualizar. No Rocky, Atualizar baixa o RPM e instala com a janela de senha do sistema, depois reabre o app. No Windows, baixa o programa novo, pede a permissao de administrador, troca o programa no mesmo lugar (mesmo com o servico rodando) e reabre. Tambem foi consertada a troca do binario quando o servico estava ativo (antes dava \"arquivo em uso\" porque o Windows religava o servico no meio da troca).\n\n8.9: o nome do servico do Windows agora e SEMPRE \"FlyRemote\", sem numero de versao. Antes era \"FlyRemote8\" (o 8 era a linha, nao a versao) - nao mudava entre 8.6/8.7/8.8, mas para nao restar duvida foi fixado em \"FlyRemote\". Ao instalar, qualquer servico de nome antigo (FlyRemote8) e removido, entao fica UM so. Atualizar passou a ser so trocar o programa no mesmo lugar mantendo o mesmo servico (a copia agora espera o arquivo liberar, sem falhar quando o servico anterior ainda esta soltando o binario).\n\n8.8: corrige o SERVICO do Windows que nao iniciava depois de reiniciar o computador. Causa: ao reinstalar/atualizar o servico, uma marca do Windows para apagar o programa no proximo boot (deixada pela remocao anterior) continuava valendo, e o Windows apagava o binario no boot - o servico entao nao encontrava o arquivo e ficava parado (evento 7000). Agora a remocao apaga o binario na hora (nao no reboot) e a instalacao limpa qualquer marca de apagar que sobrou, entao o servico volta a subir sozinho apos reiniciar.\n\n8.7: nova aba FERRAMENTAS na barra de cima (ao lado de Contas), sempre alcancavel mesmo quando o video ainda nao carregou. E dela que se instala e remove o servico do Windows (o botao saiu do modo Cliente e ganhou tela propria), com o estado real do servico (ativo, instalado mas parado, ou nao instalado) e a explicacao do que ele resolve: manter a maquina atendendo desde que liga, inclusive na TELA DE LOGIN depois de um reinicio, e permitir Ctrl+Alt+Del e a caixa de permissao de administrador (UAC) na maquina remota. O login do tecnico (e-mail e senha) agora fica guardado no Windows E no Linux, com um botao Limpar para apagar. O registro passa a anotar ONDE a maquina esta atendendo (sessao, usuario, estacao e desktop de entrada) na hora em que comeca a atender - serve para achar por que uma maquina nao mostra a tela. E ao clicar em Desconectar o registro deixa de dizer por engano que a sinalizacao caiu.\n\n8.6: SERVICO do Windows embutido no proprio programa (um binario so). No modo Cliente ha um botao Instalar servico: ele copia o FlyRemote para C:\\Program Files\\FlyRemote, registra o servico (inicia com o Windows), cria um atalho FlyRemote na area de trabalho e apaga o .exe solto. O servico mantem a maquina atendendo mesmo sem ninguem logado e, o principal, quando a conexao RDP e desconectada ele reata a sessao ao console (tscon) para a captura nao virar tela preta. Taxa da conexao agora em Mbit/s. 8.5: no Windows a janela passa a desenhar por Direct3D 12 (wgpu) em vez de OpenGL. Sem driver de video (Server 2019, maquina virtual, sessao remota) o proprio Windows fornece o WARP, desenho por software, e o programa abre; com placa usa a placa. O video do tecnico continua com uma copia por quadro. Linux segue em OpenGL. 8.4: no Windows, quando a tarefa/servico ja esta atendendo (flyremote --atender) e a pessoa abre a interface por cima, o cartao Esta maquina passa a mostrar o ID e a senha dessa instancia (canal local na porta 47613, a mesma da trava de instancia unica) e o botao de senha nova pede a senha por esse canal. Antes ficava em Preparando esta maquina sem dados. 8.3: janela menor (940x640, encolhe sozinha para caber em telas 1024x768 e na escala 1,25 do GNOME); modo Tecnico com a LISTA DE MAQUINAS como na 7 (maquinas da conta com online/offline ao vivo, em sessao, desde quando, recentes deste computador, busca, so online, atualizar; clicar conecta); codigo do visor reorganizado em arquivos por papel (tecnico_, cliente_, tela_, layout_, windows_/linux_) com LEIA-ME; RPM do Rocky com metadados AppStream (aparece em Programas para desinstalar). Ainda sem atualizacao automatica e sem servico Windows.",
  "windows": "https://download.flyremote.com.br/FlyRemote8.exe",
  "windows_tamanho": "40 MB",
  "linux": "https://download.flyremote.com.br/flyremote-8-linux",
  "linux_tamanho": "35 MB",
  "linux_rpm": "https://download.flyremote.com.br/flyremote-8.86.0.x86_64.rpm",
  "linux_deb": "https://download.flyremote.com.br/flyremote_8.86.0_amd64.deb"
}