재시작 후 Jellyfin 재생이 중단되는 이유는 무엇인가요?

재시작 전에는 Jellyfin이 정상 작동했지만 이후 재생이 중단된다면, 라이브러리를 변경하기 전에 부팅 과정에서 다시 활성화되어야 했던 종속 항목을 확인하세요.

재시작으로 인해 마운트 시점, 컨테이너 장치 매핑, 권한, DNS 또는 서비스를 사용할 수 있게 되는 순서가 달라질 수 있습니다. Jellyfin 프로세스가 정상이라고 해서 미디어 경로 또는 GPU를 사용할 수 있다는 뜻은 아닙니다. 부팅 후 환경을 정상 작동하던 기준 상태와 비교하고, 처음 누락된 종속 항목부터 복구하세요.

미디어 마운트가 실제로 마운트되었는지 확인

일반적으로 NAS나 디스크가 차지하는 디렉터리가 존재하더라도 해당 저장 장치가 마운트되지 않았을 수 있습니다. 이 경우 Jellyfin은 빈 로컬 경로를 보게 되어, 명확한 마운트 오류 대신 미디어가 없다고 보고할 수 있습니다.

서비스 시작 전 마운트 확인을 수행하면 애플리케이션이 빈 마운트 지점에 파일을 쓰거나 해당 위치를 스캔하는 것을 방지할 수 있습니다.

`findmnt` 또는 플랫폼에 해당하는 명령으로 파일 시스템의 식별 정보를 확인한 다음, Jellyfin 서비스 사용자로 알려진 미디어 파일을 읽어 보세요. 의도한 저장 장치가 준비되기 전에는 다시 스캔하지 마세요.

런타임이 다시 시작된 후 앱 데이터 소유권 확인

컨테이너를 다시 만들거나 호스트를 변경하면 영구 구성에 액세스하는 숫자형 사용자가 달라질 수 있습니다. 읽기 권한만으로는 충분하지 않습니다. Jellyfin은 데이터베이스와 구성 상태도 업데이트해야 하기 때문입니다.

UID 및 GID 매핑이 바인드 마운트 전체의 파일 시스템 소유권과 일치하면 컨테이너화된 서비스를 예측 가능한 상태로 유지할 수 있습니다.

서비스 ID로 앱 데이터 상위 디렉터리에 임시 파일을 만들고 삭제하는 테스트를 실행하세요. 영구 앱 데이터 경로는 런타임을 교체한 후에도 재귀적인 소유권 복구 없이 유지되어야 합니다.

하드웨어 장치가 다시 나타났는지 확인

재부팅 전 iGPU를 사용하던 트랜스코딩이 `/dev/dri` 또는 다른 가속기 매핑이 누락되면 CPU로 전환되거나 실패할 수 있습니다. Direct Play는 여전히 작동할 수 있어 문제가 미디어에만 있는 것처럼 보일 수 있습니다.

장치 매핑이 실패하면 동일한 재생 작업이 하드웨어 처리에서 소프트웨어 처리로 전환될 수 있습니다. Jellyfin 트랜스코딩 벤치마크에서는 하드웨어 가속 경로와 필터링 경로에서 CPU 및 GPU 부하가 얼마나 크게 달라지는지 확인할 수 있습니다.

하드웨어 트랜스코딩이 필요한 알려진 테스트 파일을 하나 재생하고, 활성 프로세스와 장치 매핑을 확인하세요. 화질을 낮추거나 코덱을 변경하기 전에 런타임의 장치 액세스를 복구하세요.

-15% OFF

ZimaBoard 2 - 당신의 큰 아이디어를 위한 미니 홈 서버

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

로컬 재생이 작동한 후에만 네트워크 경로를 다시 테스트

원격 DNS, VPN 또는 프록시 서비스가 Jellyfin보다 늦게 시작되면 원격 환경에서만 문제가 발생할 수 있습니다. 로컬 미디어 재생과 원격 연결 가능 여부를 별도의 승인 테스트로 유지하세요.

네트워크 용량은 실제 전송 지점에서 확인해야 합니다. 스트리밍 대역폭 모델은 모든 재생 문제를 서버 연산 문제로 취급하는 대신 LAN, Wi-Fi, NAS 및 원격 업로드의 한계를 구분합니다.

먼저 유선 로컬 클라이언트를 확인한 다음 원격 클라이언트 하나를 확인하세요. 로컬 재생이 정상이라면 서버 상태를 다시 구축하지 말고 남은 문제를 라우팅, DNS, 프록시 또는 터널 구성에서 해결하세요.