Jellyfin이 예상한 구성 파일을 사용하고 있는지 확인하는 방법

예, 호스트에 파일이 존재하는 위치만 보고 추측하지 않고도 Jellyfin이 예상한 구성 디렉터리를 사용하고 있는지 확인할 수 있습니다. 신뢰할 수 있는 방법은 Jellyfin의 경로 우선순위를 확인하고, 실행 중인 프로세스 또는 컨테이너 설정을 점검한 다음, 구성 파일을 변경하기 전에 시작 로그에서 활성 경로를 확인하는 것입니다.

패키지 설치에서 Docker로 전환했거나, compose 파일을 복제했거나, 이전 서버를 복원한 후에는 이 과정이 중요합니다. network.xml, system.xml, logging.json의 복사본이 여러 개 존재할 수 있지만 실제로 활성화된 디렉터리는 하나뿐일 수 있습니다. 증상이 사라질 때까지 모든 복사본을 수정하지 마세요. 먼저 활성 구성 디렉터리를 식별하고, 되돌릴 수 있는 변경을 한 번만 적용한 뒤, 재시작 후 Jellyfin이 동일한 경로를 보고하는지 확인하세요.

먼저 구성 경로 우선순위를 확인하세요

Jellyfin이 실행된 방식을 확인하는 것부터 시작하세요. 명령줄의 --configdir는 JELLYFIN_CONFIG_DIR 환경 변수보다 우선하며, 더 높은 우선순위의 설정이 없을 때만 플랫폼 기본값이 사용됩니다.

공식 구성 경로 우선순위 문서에는 데이터, 구성, 캐시, 웹 디렉터리의 경로 우선순위가 설명되어 있습니다. 익숙한 호스트 폴더가 활성 상태라고 가정하기 전에 서비스 유닛, 컨테이너 환경 변수 또는 시작 명령에서 해당 순서를 비교하세요.

더 높은 우선순위의 설정이 예상하지 못한 위치를 가리킨다면 그 지점에서 멈추세요. 디스크에서 발견한 파일이 Jellyfin이 해당 파일을 읽고 있다는 증거는 아닙니다. 실행 구성을 수정하거나, 활성 경로를 의도적으로 유지하고 그 내용을 문서화하세요.

실행 중인 컨테이너 또는 서비스 정의를 점검하세요

Docker에서는 디스크에 저장된 compose 파일만 확인하지 말고 실행 중인 컨테이너를 점검하세요. 실행 중인 객체를 확인하면 컨테이너 생성 시 실제로 적용된 환경 변수와 마운트를 알 수 있습니다.

Docker의 실행 중인 컨테이너 정의는 실행 중인 컨테이너에 대한 하위 수준 정보를 반환하므로, 환경 변수 값과 마운트 대상 경로를 예상한 Jellyfin 경로와 비교하는 데 유용합니다. 컨테이너가 생성된 후 수정된 compose 파일은 현재 런타임과 일치하지 않을 수 있습니다.

네이티브 서비스의 경우 systemd 유닛과 해당 유닛이 불러오는 환경 파일을 점검하세요. 런타임 정의와 기록해 둔 내용이 다르면 런타임을 기준으로 판단한 다음, 의도한 경로로 서비스를 다시 생성할지 결정하세요.

Jellyfin 시작 정보에서 경로를 확인하세요

예상 경로를 기록한 후 한 번 재시작하고, Jellyfin 시작 과정의 가장 이른 로그 줄을 읽으세요. 구성, 캐시 또는 저장소 경로가 표시되는지 확인하고, 방금 점검한 프로세스 또는 컨테이너 정의와 비교하세요.

웹 로그인에 성공했다는 사실만으로 올바른 구성 디렉터리가 활성 상태라고 판단하지 마세요. Jellyfin은 새 구성 경로나 이전 구성 경로로도 정상적으로 시작하여 유효한 인터페이스를 표시할 수 있습니다. 이 경우 사용자 설정, 네트워크, 플러그인 또는 예약 작업은 잘못된 상태에서 불러와질 수 있습니다.

미디어 서버를 다른 배포 방식으로 옮길 때는 더 넓은 스택에도 동일한 경로 원칙을 적용해야 합니다. 실용적인 시작점으로는 Jellyfin 홈 미디어 설정이 있으며, 여기서는 앱 경로, 미디어 경로, 액세스 경로를 설정의 서로 다른 요소로 다룹니다.

Featured

ZimaCube 2 개인용 클라우드 홈 NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

무해한 구성 변경 하나로 구분하세요

두 후보 디렉터리가 여전히 모두 가능해 보인다면 서버 XML 구성 파일을 수정하기 전에 Jellyfin을 중지하세요. 효과가 분명하고 되돌릴 수 있는 설정 하나를 선택한 다음, 활성 디렉터리로 의심되는 곳에서만 변경하세요. 파일 선택 여부를 확인하려고 사용자 데이터, 라이브러리 경로 또는 대규모 재검색을 유발할 수 있는 항목은 건드리지 마세요.

Jellyfin을 시작하고 선택한 설정이 적용되었는지 확인하세요. 적용되었다면 서비스를 다시 중지하고 변경을 되돌린 뒤, 한 번 더 시작하여 변경 사항이 유지되지 않는지 확인하세요. 적용되지 않았다면 해당 파일이 활성 파일이 아니거나, 더 높은 우선순위의 구성 소스가 파일을 덮어쓰고 있는 것입니다.

이처럼 통제된 오프라인 A/B 테스트는 타임스탬프를 비교하는 것보다 확실합니다. 백업 도구, 패키지 업그레이드, 편집기는 모두 비활성 파일을 건드릴 수 있기 때문입니다. Jellyfin은 이러한 구성 옵션을 일반적으로 정적이며 서버 시작 전에 설정해야 하는 항목으로 문서화하고 있으므로, 특정 설정에 다른 동작이 명시되어 있지 않다면 실행 중인 상태에서 수정하지 마세요.

활성 경로가 재시작 후에도 유지되면 멈추세요

런타임 정의, 시작 정보, 되돌릴 수 있는 구성 변경 하나가 재시작 후에도 모두 동일한 디렉터리를 가리킬 때 결론이 확인됩니다. 해당 경로를 배포 기록과 백업 범위에 기록하세요.

컨테이너를 다시 생성한 후 활성 경로가 바뀐다면 Jellyfin 파일을 반복해서 수정하지 말고 볼륨과 환경 변수가 어떻게 생성되는지 점검하세요. 이 경우 문제는 Jellyfin의 구성 파서가 아니라 배포 상태에 있습니다.

런타임 경로가 명확한데도 Jellyfin이 활성 파일의 유효한 설정을 계속 무시할 때만 지원을 요청하세요. 문의하기 전에 시작 로그와 정확한 버전을 보존해야 중복 파일 문제와 실제 문제를 구분할 수 있습니다.