Jellyfin은 기기 간 변경 사항을 어떻게 감지하고 조정하나요?

Jellyfin은 중앙 서버를 통해 대부분의 기기 간 변경 사항을 조정합니다. 중앙 서버는 라이브러리 업데이트를 감지하고, 공유 상태를 저장하며, 그 결과를 클라이언트에 제공합니다.

휴대폰, 텔레비전, 브라우저, 태블릿은 일반적으로 서로 직접 미디어 라이브러리의 기준을 협의하지 않습니다. 이들은 동일한 Jellyfin 서버와 통신하며, 서버는 색인된 라이브러리 메타데이터와 시청 진행률 같은 사용자별 상태를 관리합니다. 파일 시스템 검색, 재생 업데이트, 클라이언트 새로 고침은 서로 다른 단계이지만 하나의 서버 측 권한으로 수렴하므로, 서버가 변경 사항을 수락하고 각 클라이언트가 새로 고침을 수행하면 기기들은 대체로 동일한 상태를 보게 됩니다.

공유 권한은 개별 클라이언트가 아니라 서버에 있습니다

클라이언트는 라이브러리 화면을 표시하고 사용자 작업을 전송하지만, 지속적으로 공유되는 카탈로그는 서버에 저장됩니다. 이러한 구조 덕분에 텔레비전과 휴대폰은 전체 데이터베이스를 기기 간에 복사하지 않고도 동일한 항목을 볼 수 있습니다. 각 클라이언트는 표시 상태를 캐시할 수 있지만, 라이브러리 소속과 사용자 진행률에 대한 기준 기록은 중앙에 유지됩니다.

미디어 서버는 일반적으로 실제로 이용 가능한 항목과 로컬 사용자 계정에서 재생된 항목에 대한 권한을 가집니다. 기준 데이터 모델에서는 재생을 담당하는 미디어 서버와 휴대형 추적 시스템을 서로 구분합니다. 같은 원리가 Jellyfin 클라이언트에도 적용됩니다. 클라이언트들은 피어 기기 중 승자를 선택하는 대신 서버 상태에 수렴합니다.

이 모델은 수락된 변경 사항이 지속적으로 저장되는 위치를 하나로 만들기 때문에 충돌 처리를 단순화합니다. 클라이언트가 일시적으로 오래된 캐시 데이터를 표시할 수는 있지만, 아직 새로 고침하지 않았다는 이유만으로 동일한 수준의 두 번째 데이터베이스가 되는 것은 아닙니다. 조정이란 클라이언트 화면을 서버가 수락한 상태로 되돌리는 것을 의미합니다.

파일 시스템 변경 사항은 서버 측 검색을 통해 라이브러리 상태가 됩니다

미디어 파일을 추가하거나 교체하거나 이름을 변경하거나 삭제해도 처음에는 저장소만 변경될 뿐 Jellyfin 카탈로그는 바뀌지 않습니다. 서버는 스캔, 모니터링 트리거 또는 자동화 신호를 통해 해당 파일 시스템 이벤트를 감지하고, 영향을 받은 경로를 검사한 뒤 색인된 표현을 업데이트해야 합니다. 이 저장 작업이 완료된 후에야 클라이언트가 새로운 라이브러리 화면을 받을 수 있습니다.

대상 지정 라이브러리 업데이트와 같은 자동화 도구가 존재하는 이유는 광범위한 예약 스캔을 기다리는 것보다 검색을 더 정확하게 트리거할 수 있기 때문입니다. 핵심 구조는 변하지 않습니다. 파일 이벤트가 기기 간 UI 변경으로 나타나기 전에 먼저 서버 측 라이브러리 업데이트가 되어야 합니다.

이로 인해 검색이 진행되는 동안 저장소의 기준과 카탈로그의 기준이 분리됩니다. 디스크에 파일이 존재해도 클라이언트에는 아직 보이지 않을 수 있고, 삭제 처리가 끝날 때까지 색인된 항목이 잠시 남아 있을 수도 있습니다. 따라서 파일 시스템 변경부터 서버 색인 업데이트까지 걸리는 시간과, 서버가 이미 변경을 저장한 뒤 클라이언트가 얼마나 빨리 새로 고침되는지를 측정하는 것은 서로 다릅니다.

재생 진행률은 동일한 서버 측 사용자 상태로 돌아갑니다

시청 진행률은 파일 시스템 검색과 다른 입력 경로를 따릅니다. 시청자가 40분 지점에 도달해도 미디어 파일 자체가 변경되는 것은 아닙니다. 클라이언트가 인증된 사용자와 연결된 재생 상태를 전송하면 서버가 해당 사용자별 업데이트를 기록합니다. 같은 계정으로 로그인한 다른 기기는 나중에 공유 서버 상태를 조회하여 서버가 수락한 위치부터 재생을 이어갈 수 있습니다.

따라서 Jellyfin은 텔레비전과 휴대폰 사이에 로컬 진행률 파일을 직접 복사하지 않고도 클라이언트 간에 시청 기록을 기기 간에 동기화할 수 있습니다. 두 기기가 수렴하는 이유는 피어 투 피어 조정을 수행하기 때문이 아니라, 서버의 동일한 사용자 기록을 통해 읽고 쓰기 때문입니다.

관찰 가능한 경계는 기록 시점입니다. 기기가 진행률 업데이트를 서버에 전달하기 전에 오프라인 상태가 되면, 다른 기기에 서버에 저장된 이전 값이 표시될 수 있습니다. 연결이 복구된 후 최종 결과는 애플리케이션이 어떤 업데이트를 어떤 순서로 수락하는지에 따라 달라집니다. 오프라인 상태의 로컬 진행률을 이미 커밋된 공유 상태로 착각해서는 안 됩니다.

Featured

ZimaCube 2 개인용 클라우드 홈 NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

클라이언트는 서로 병합하지 않고 서버에서 새로 고침하여 조정합니다

서버가 변경 사항을 저장한 후에도 클라이언트는 새 상태를 가져오는 새로 고침, 이벤트, 탐색 동작 또는 후속 요청이 필요합니다. 브라우저에는 이미 업데이트가 표시되는데 텔레비전은 메모리에 오래된 포스터 격자를 유지할 수 있습니다. 서버 자체에 충돌하는 기록이 있는 것이 아니라면 이러한 일시적인 차이는 표시 캐시 문제입니다.

서로 다른 Jellyfin 클라이언트는 동일한 서버를 서로 다른 인터페이스와 재생 동작으로 표시할 수 있으므로, 클라이언트의 다양성은 이러한 차이를 분명하게 보여줍니다. 한 클라이언트만 오래된 화면을 표시하고 다른 클라이언트는 최신 상태라면 먼저 서버 상태를 확인한 다음 문제가 있는 클라이언트를 새로 고치거나 다시 연결해야 합니다. 이를 데이터베이스 충돌로 간주해서는 안 됩니다.

이러한 구분은 디버깅할 때 중요합니다. 두 클라이언트의 상태가 다르면 먼저 서버 상태를 조회하거나 검사하세요. 서버에 예상한 값이 있고 한 클라이언트만 오래된 상태라면 새로 고침 또는 캐시 동작이 원인일 가능성이 높습니다. 서버 자체에 업데이트가 없다면 두 번째 클라이언트를 탓하기 전에 검색, 권한 또는 기록 이벤트를 조사해야 합니다.

장애 경계: 별도의 서버는 데이터베이스를 자동으로 조정하지 않습니다

중앙 권한 모델은 하나의 Jellyfin 서버 인스턴스 내부에 적용됩니다. 한 가정에서 서로 독립된 서버 두 대를 운영하면 각 서버가 사용자, 시청 상태, 메타데이터 편집, 라이브러리 데이터베이스 변경 사항을 자체적으로 축적할 수 있습니다. 비슷한 미디어 파일을 가리킨다는 이유만으로 두 데이터베이스가 서로를 발견하고 안전하게 병합할 것이라고 가정할 수는 없습니다.

명시적 시청 상태 동기화와 같은 서버 간 도구가 존재하는 이유는 독립적인 미디어 서버에서 공유 진행률을 조정하려면 명시적인 조정 메커니즘이 필요하기 때문입니다. 이러한 도구는 정해진 일부 상태를 동기화할 수 있지만, 두 개의 완전한 Jellyfin 데이터베이스를 투명한 다중 마스터 클러스터로 만들지는 않습니다.

같은 경계는 오프라인 기기에도 적용됩니다. 클라이언트가 오래된 로컬 화면을 유지할 수는 있지만, 이를 Jellyfin에 수동으로 병합해야 하는 권한 있는 데이터베이스로 취급해서는 안 됩니다. 여러 기록 주체나 서버를 도입할 때는 설계를 “조정됨”이라고 부르기 전에 어떤 상태가 기준인지, 어떤 필드를 동기화할지, 충돌하는 업데이트를 어떻게 해결할지 정의해야 합니다.

두 기기에서 4단계 조정 테스트를 실행하세요

동일한 테스트 사용자로 로그인한 두 클라이언트와 알고 있는 미디어 항목 하나를 사용하세요. 첫째, 테스트 파일을 추가하거나 이름을 변경하고 서버가 이를 검색하는 시간을 측정합니다. 둘째, 새로 고침 후 두 클라이언트가 새로운 카탈로그 상태를 받는지 확인합니다. 셋째, 클라이언트 A에서 시청 진행률을 변경하고 클라이언트 B가 서버에서 수락된 값을 받는지 확인합니다. 넷째, 서버를 다시 시작하고 저장된 상태가 유지되는지 검증합니다.

동시 상태 일관성에 대한 내부 설명은 보완적인 데이터베이스 경계를 제공합니다. 겹치는 활동이 완료되지 않은 업데이트를 노출하지 않도록 수락된 쓰기 작업에는 트랜잭션 및 순서 규칙이 필요합니다. 기기 간 테스트는 이러한 지속 상태 보장 위에 검색 및 클라이언트 새로 고침 시간을 추가합니다.

각 단계 후 서버가 동일한 관찰 가능한 권한이 되었을 때만 테스트를 통과한 것으로 간주하세요. 즉, 저장소 변경 사항이 한 번만 색인되고, 두 클라이언트가 동일한 라이브러리 결과로 수렴하며, 사용자 진행률이 중복되거나 손실되지 않고, 다시 시작해도 저장된 업데이트가 되돌아가지 않아야 합니다. 불일치가 남아 있다면 문제가 검색, 서버 저장, 클라이언트 새로 고침 또는 별도 서버 경계 중 어디에서 발생했는지 확인하세요.

자주 묻는 질문

Jellyfin 클라이언트는 서로 직접 동기화하나요?

일반적으로 그렇지 않습니다. 휴대폰, 텔레비전, 브라우저, 태블릿은 Jellyfin 서버를 통해 수렴합니다. 클라이언트가 업데이트를 서버로 보내고 나중에 서버 상태를 읽는 방식입니다. 클라이언트를 피어 복제본으로 취급하면 실제로는 존재하지 않는 충돌이 일반적인 새로 고침 지연 때문에 발생한 것처럼 보일 수 있습니다.

Jellyfin 클라이언트 하나에 오래된 라이브러리 데이터가 표시되는 이유는 무엇인가요?

서버에는 이미 라이브러리 또는 재생 변경 사항이 저장되었지만 한 클라이언트가 여전히 오래된 캐시 화면을 표시할 수 있습니다. 다른 클라이언트나 웹 인터페이스에서 서버 측 상태를 확인한 다음, 검색 또는 데이터베이스 문제를 조사하기 전에 문제가 있는 클라이언트를 새로 고치거나 다시 연결하세요.

서로 다른 Jellyfin 서버 두 대가 시청 진행률을 자동으로 동기화할 수 있나요?

서로 다른 Jellyfin 서버는 자동 다중 마스터 상태 시스템을 구성하지 않습니다. 동일한 사용자의 시청 기록을 독립적인 서버 간에 유지해야 한다면, 기준 데이터의 출처를 명확히 정하고 충돌 동작을 테스트한 뒤 명시적인 동기화 절차를 사용하세요.