저장소 경로 변경 후 Jellyfin에 오래된 데이터가 표시됨

에바 왕

IceWhale author

에바 왕 는 기술 작가 그리고 이자 ZimaSpace의 상주 장인입니다. 평생을 기술에 열정을 가진 사람으로서 홈랩과 오픈소스 소프트웨어에 열정을 가지고 있으며,복잡한 기술 개념을 쉽게 이해할 수 있는 실습 가이드로 번역하는 데 전문성을 가지고 있습니다.에바는 셀프 호스팅이 어렵지 않고 재미있어야 한다고 믿습니다. 그녀의 튜토리얼을 통해 커뮤니티가 하드웨어 설정의 신비를 풀도록돕고 있습니다. 첫 NAS 구축부터 Docker 컨테이너 마스터링까지.

Jellyfin Shows Stale Data After a Storage Path Change - Zima Store Online

Jellyfin은 일반적으로 저장소를 옮긴 후 오래된 데이터를 표시합니다. 서비스가 이전 경로를 참조하거나, 새 마운트를 읽지 못하거나, 새 위치를 대상으로 유효한 스캔을 완료하지 않았기 때문입니다.

대시보드에 이전 항목, 누락된 항목 또는 두 가지가 섞여 표시되나요? 먼저 라이브러리를 삭제하거나 휴지통을 비우지 마세요. 메타데이터를 손상시키지 않고 각 분기를 테스트할 수 있도록 정확한 이전 경로와 새 경로, 마운트 상태, 서비스 소유자, 스캔 결과를 기록하세요.

Jellyfin이 실제로 인식하는 경로 확인

호스트 셸에서만 확인하지 말고 Jellyfin 프로세스 또는 컨테이너 내부에서 경로를 점검하세요. 부팅 후 마운트가 존재하는지, 서비스 계정이 샘플 파일을 나열하고 읽을 수 있는지, 컨테이너 매핑이 라이브러리 구성에 저장된 경로와 일치하는지 확인하세요.

경로가 비어 있거나 접근할 수 없다면 먼저 마운트, UID/GID 또는 컨테이너 볼륨을 수정하세요. 수동 로그인 후에만 나타나는 저장소 마운트 때문에 Jellyfin이 시작 시 빈 디렉터리를 스캔할 수 있습니다.

라이브러리 구성과 데이터베이스 레코드 하나에서 이전 경로와 새 경로를 비교하세요. 두 경로가 모두 남아 있으면 Jellyfin이 유효한 항목 하나와 오래된 참조 하나를 표시하는 것은 정상일 수 있습니다.

오래된 메타데이터와 스캔 실패 구분

경로를 읽을 수 있게 된 후 제어된 스캔을 실행하고, 로그에서 라이브러리 이름, 항목 수, 권한 오류 및 건너뛴 파일을 확인하세요. 이전 항목으로 확인된 파일 하나와 새로 추가한 파일 하나를 비교하세요. 스캔이 완료되었는데도 이전 경로가 남아 있다면 데이터베이스에 이전 위치가 여전히 포함되어 있거나, 이전 참조를 제거하지 않은 채 새 경로가 추가된 것입니다.

캐시된 포스터를 미디어 파일을 사용할 수 있다는 증거로 해석하지 마세요. 저장소 경로 규칙에 따라 마운트된 파일 시스템과 애플리케이션 경로는 별도로 확인해야 합니다.

매핑을 수정한 후 한 번만 제어된 스캔을 실행하고 항목 수와 확인된 파일 하나를 비교하세요. 경로를 수정하기 전에 반복해서 다시 스캔하면 상태가 더 혼란스러워질 수 있습니다.

분기를 확인한 후에만 복구

경로 매핑 또는 권한을 수정하고 한 번 재시작한 다음 다시 스캔하세요. 데이터베이스 경로가 잘못되었다면 라이브러리 위치를 가능한 한 최소한으로 변경하고, 오래된 항목을 정리하기 전에 예상 항목 수를 확인하세요. 대량 메타데이터 작업을 수행하기 전에 애플리케이션 데이터와 백업을 보존하세요.

재부팅 후에도 서비스가 새 경로를 계속 인식하고, 대표 클라이언트에서 항목이 재생되며, 두 번째 스캔에서도 오래된 상태가 다시 생성되지 않아야 복구가 입증됩니다. 파일 시스템에서 손상이 보고되거나, 데이터베이스에 충돌하는 경로가 포함되어 있거나, 정상적인 마운트와 재시작 후에도 문제가 재발하면 에스컬레이션하세요.

복구 후 부팅 시 마운트를 사용할 수 있는 상태에서 재시작하고 스캔을 반복하세요. 재시작 후에도 동일한 경로가 계속 표시될 때까지 오래된 데이터가 해결된 것으로 볼 수 없습니다.

-15% OFF