Os ficheiros temporários de transcodificação continuam a ocupar a unidade do sistema: como impedir isso

Pare a carga de transcodificação ativa, verifique onde são escritos os segmentos temporários e, em seguida, imponha a limpeza e desloque o caminho para longe da unidade do sistema.

Um servidor multimédia pode armazenar segmentos HLS, transmissões remuxadas, resultados da incorporação de legendas e ficheiros de sessões incompletas na sua cache predefinida ou diretório da aplicação, mesmo quando a biblioteca de origem está num grande conjunto de armazenamento. A unidade do sistema fica cheia quando esses ficheiros não são eliminados suficientemente depressa, o diretório de transcodificação está incorretamente associado ou permanecem sessões abandonadas depois de terminar a reprodução. Diagnostique o diretório e a sessão reais antes de eliminar ficheiros ou relocalizar a cache.

Localize o Diretório de Transcodificação Ativo e as Sessões Maiores

Inicie uma transcodificação controlada e observe qual diretório aumenta. Registe a definição da aplicação, o caminho do contentor, a montagem associada no anfitrião, o sistema de ficheiros, o espaço disponível, a contagem de ficheiros e os maiores subdiretórios de sessões.

O Jellyfin disponibiliza uma localização gravável separada para ficheiros temporários de transcodificação, confirmando que o caminho de transcodificação é distinto do caminho da biblioteca multimédia permanente e dos metadados. A definição relevante é o caminho temporário de transcodificação.

Se a aplicação apresentar um caminho, mas a unidade do anfitrião ficar cheia noutro local, inspecione as montagens efetivas do Docker e a camada gravável. Uma montagem associada em falta pode fazer com que o contentor escreva ficheiros temporários no sistema de ficheiros do contentor suportado pelo sistema, em vez de utilizar o volume de cache pretendido.

Pare o Processo Gerador Antes da Limpeza de Emergência

Identifique as sessões de reprodução ativas e pare apenas as transcodificações associadas aos ficheiros que estão a crescer rapidamente. Guarde o registo mais recente do FFmpeg, o título de origem, o cliente, a taxa de bits de saída, as legendas e a hora de início antes de recuperar espaço.

Já aconteceu anteriormente que ficheiros de transcodificação antigos permanecessem depois de terminar a reprodução e fizessem com que o disco ficasse cheio até o servidor deixar de conseguir iniciar. Um problema do Jellyfin documenta um filme que continuava a ocupar a pasta temporária de transcodificação horas depois de o utilizador parar de ver o conteúdo.

Não remova ficheiros pertencentes a uma sessão ativa enquanto o FFmpeg ainda estiver a escrevê-los. Pare a sessão ou o servidor de forma limpa, confirme que os ficheiros já não estão abertos e, em seguida, remova apenas os resultados temporários confirmados, em vez de eliminar toda a cache ou a base de dados da aplicação.

Ative a Eliminação de Segmentos para Sessões de Streaming Longas

Verifique se o servidor elimina os segmentos HLS transferidos durante a reprodução. Sem a eliminação de segmentos, um filme longo ou uma transmissão em direto pode exigir espaço em disco suficiente para manter todo o resultado gerado.

O Jellyfin descreve a eliminação de segmentos como a remoção dos segmentos antigos depois de o cliente os transferir, para que o servidor não tenha de armazenar o ficheiro transcodificado completo. A opção existe especificamente para impedir o armazenamento da transmissão completa.

Ative-a para um cliente de teste e monitorize a reprodução, a procura e a retoma. Mantenha-a desativada apenas quando um problema reproduzível do cliente exigir a retenção de segmentos e compense com um volume de transcodificação dedicado maior e uma limpeza de sessões mais rigorosa.

Featured

ZimaCube 2 NAS Pessoal Cloud para Casa

ZimaCube2

$799.00 - $2,499.00

Buy Now

Mova o Caminho de Transcodificação para um Volume Rápido Dedicado

Escolha um SSD, uma cache NVMe ou um sistema de ficheiros temporário com capacidade suficiente, separado da raiz do sistema operativo. O destino deve suportar escritas concorrentes e ter capacidade suficiente para as piores sessões de transcodificação esperadas.

Os utilizadores que colocam as transcodificações em discos RAM pequenos já solicitaram um limite de cache, porque o diretório pode continuar a crescer até esgotar o dispositivo temporário. O limite da falha é uma cache de transcodificação sem limite, independentemente de o dispositivo subjacente ser RAM ou SSD.

Pare o servidor, crie o novo diretório com a propriedade correta para o serviço, associe-o explicitamente ao contentor e atualize a definição da aplicação para o caminho visível no contentor. Execute uma transcodificação e confirme que a unidade do sistema do anfitrião já não aumenta.

Encontre Sessões Antigas e Falhas de Limpeza

Compare os diretórios de sessões temporárias com os IDs das sessões de reprodução ativas e os processos do FFmpeg. Os ficheiros sem uma sessão correspondente, sem um processo aberto e com datas de modificação antigas são candidatos à limpeza suportada.

Não presuma que uma tarefa genérica de limpeza da cache remove todos os artefactos de transcodificação. O relatório anterior do Jellyfin concluiu que a tarefa normal da cache não removeu o ficheiro de transcodificação antigo; por isso, a verificação real consiste em confirmar se a limpeza específica da sessão foi concluída.

Reveja o registo do servidor em torno de desligamentos do cliente, reinícios do contentor, falhas, perdas de rede e terminações forçadas de processos. Corrija a condição que impede o servidor de receber um evento de paragem limpo, em vez de depender de um script de eliminação diário como único mecanismo de controlo.

Meça a Ocupação de Transcodificação Concorrente no Pior Caso

Execute uma transcodificação remota representativa e meça os bytes temporários por minuto. Repita o teste com incorporação de legendas, mapeamento de tons HDR e a taxa de bits de saída máxima suportada; depois, multiplique pelo número previsto de sessões concorrentes e pela duração retida.

Uma unidade do sistema cheia pode afetar o servidor multimédia para além da reprodução. Um caso de suporte do Jellyfin indicou que as transcodificações que enchiam a unidade podiam estar relacionadas com a impossibilidade de a interface Web voltar a ligar-se, mostrando que o esgotamento do volume do sistema afeta a disponibilidade da aplicação.

Reserve espaço livre para o sistema operativo, registos, bases de dados, atualizações de pacotes e metadados do Docker. O volume de transcodificação deve falhar de forma independente, sem impedir o arranque do servidor ou a abertura da aplicação multimédia.

Verifique a Limpeza e Adicione Alertas de Capacidade

Teste o início da reprodução, a procura, a pausa, a desligação do cliente, o reinício do servidor e as sessões simultâneas. Confirme que os ficheiros ativos crescem apenas no caminho de transcodificação dedicado e diminuem depois de terminarem as sessões.

O guia da ZimaSpace sobre como criar um servidor multimédia doméstico apresenta o percurso de validação mais abrangente para separar o armazenamento de origem das cargas de trabalho da aplicação e temporárias.

A reparação está concluída quando já não permanecem sessões antigas, a eliminação de segmentos funciona nos clientes suportados, a unidade do sistema mantém uma reserva segura e os alertas são acionados antes de o volume de transcodificação dedicado ou o sistema de ficheiros raiz atingir o respetivo limite de capacidade.