여러 기기에서 동시에 스트리밍할 때 Plex가 간헐적으로 작동하지 않는 이유는 무엇인가요?

에바 왕

IceWhale author

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

Why Does Plex Fail Intermittently When Multiple Devices Stream at Once? - Zima Store Online

간헐적으로 여러 클라이언트에서 Plex 재생이 실패하는 문제는 어떤 스트림 요소가 먼저 변하는지 관찰하면 대개 원인을 파악할 수 있습니다. 트랜스코딩, 대역폭, 스토리지 I/O 또는 특정 클라이언트에만 해당하는 경로 중 무엇이 먼저 변하는지 확인하세요.

TV 한 대에서는 안정적인 서버도 휴대폰, 원격 브라우저, 스마트 TV가 동시에 서로 다른 파일을 재생하기 시작하면 실패할 수 있습니다. 클라이언트마다 요구하는 작업이 다를 수 있습니다. 한 클라이언트는 Direct Play를 사용하는 반면, 다른 클라이언트는 비디오 트랜스코딩을 강제하거나 자막을 영상에 입히거나 WAN을 통과할 수 있습니다. 클라이언트를 한 번에 하나씩 추가해 문제를 재현하고, 제한이나 하드웨어를 변경하기 전에 Plex 대시보드에서 각 세션이 실제로 어떤 작업을 수행하는지 기록하세요.

동시성 테스트 전에 단일 스트림 기준선 설정하기

가장 자주 실패하는 클라이언트와 파일 조합으로 시작하되, 해당 스트림 하나만 실행하세요. Plex가 Direct Play, Direct Stream 또는 Transcode 중 무엇으로 표시하는지 기록하고 CPU, GPU, 네트워크 및 디스크 동작을 확인하세요. 스트림이 단독으로도 실패한다면 동시성이 주된 원인이 아니므로 나머지 테스트를 중단해야 합니다.

Plex는 트랜스코딩이나 원격 재생이 관련된 경우 서버 스트리밍 용량이 주로 프로세서 성능과 네트워크 대역폭에 의해 제한된다고 설명합니다. 이 차이는 중요합니다. 서버가 Direct Play 세션은 많이 처리할 수 있지만 여러 클라이언트가 변환을 요청하면 빠르게 한계에 도달할 수 있기 때문입니다.

기준선 테스트가 정상이라면 첫 번째 클라이언트는 그대로 둔 채 두 번째 클라이언트를 추가하세요. 처음으로 눈에 띄는 문제가 발생할 때까지 클라이언트를 한 번에 하나씩 계속 추가합니다. 문제가 발생한 시점에 추가한 스트림은 무작위 오류 메시지보다 더 많은 정보를 제공합니다. 어떤 새로운 작업이 서버 상태를 바꾸었는지 알려주기 때문입니다.

대시보드로 트랜스코딩 부하와 네트워크 부하 구분하기

문제가 나타나면 대시보드에서 모든 활성 세션을 확인하세요. 문제가 발생한 시점에 새로운 하드웨어 또는 소프트웨어 트랜스코딩이 시작되었다면, Direct Play와 호환되는 파일이나 더 단순한 자막 경로로 같은 클라이언트를 테스트하세요. 오류가 사라진다면 트랜스코딩 파이프라인이 가장 유력한 원인입니다.

ZimaSpace 하드웨어 가속 가이드는 여러 스트림이 CPU 작업을 사용 가능한 가속기로 옮길 수 있는 이유와, 서버에 다른 NAS 작업을 처리할 여유 성능이 여전히 필요한 이유를 이해하는 데 유용합니다. 하드웨어 가속을 사용한다고 해서 동시성이 무제한이라는 뜻은 아닙니다. 확인해야 할 여러 리소스 경로 중 하나일 뿐입니다.

로컬 세션은 정상인데 원격 스트림만 실패한다면 같은 시간대에 서버의 실제 업로드 대역폭을 측정하고, 이를 전체 스트림 요구량과 비교하세요. 로컬 및 원격 클라이언트가 함께 실패한다면 인터넷 연결을 공통 원인으로 간주하기보다 컴퓨팅 성능이나 스토리지 쪽을 계속 확인하세요.

문제 발생 시 컨테이너 또는 호스트가 포화되는지 확인하기

스트림을 추가하는 동안 Plex 컨테이너와 호스트를 관찰하세요. 동일한 클라이언트 수에서 CPU 한계, GPU 비디오 엔진 포화, 메모리 부족 또는 높은 I/O 대기가 나타난다면, 문제가 발생한 뒤 관찰한 평균 사용률보다 훨씬 강력한 단서가 됩니다. 어떤 리소스가 가장 먼저 한계에 도달하는지 확인하세요.

Docker의 컨테이너 stats 명령은 테스트가 진행되는 동안 컨테이너의 CPU, 메모리, 네트워크 및 블록 I/O를 보여줄 수 있습니다. 이를 Plex 세션 화면과 함께 확인하면 리소스 급증이 Plex에서 발생한 것인지, 어떤 클라이언트 작업이 이를 유발했는지 파악할 수 있습니다.

리소스 사용량은 적당한데 특정 클라이언트만 실패한다면 해당 클라이언트 또는 미디어 파일만 교체해 보세요. 특정 기기, 코덱, 자막 형식 또는 네트워크 경로를 따라 문제가 발생한다면 더 좁은 범위의 클라이언트 호환성 문제로 분류해야 합니다. 특정 엔드포인트에서만 재현되는 문제를 해결하기 위해 서버 전체 제한을 낮추지 마세요.

-15% OFF

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

Single board computer zimaboard2

원인에 맞는 최소한의 수정 사항을 적용하고 같은 클라이언트 구성으로 재테스트하기

트랜스코딩 한계가 확인되었다면 불필요한 트랜스코딩을 줄이고, 하드웨어 가속을 확인하거나 NAS가 원활하게 작동할 수 있도록 동시 트랜스코딩 수를 적절히 제한하세요. 업로드 병목이 확인되었다면 원격 스트림 품질을 조정하거나 사용 가능한 업스트림 대역폭을 늘리세요. 스토리지 I/O 문제라면 파일을 옮기기 전에 미디어 경로와 임시 트랜스코딩 경로를 각각 테스트하세요.

처음 문제가 발생했던 클라이언트 추가 순서를 정확히 반복하고, 기존 문제가 발생했던 지점을 넘길 때까지 충분히 실행하세요. 성공적인 수정이란 단일 테스트 동영상이 재생되기 시작했다는 뜻이 아니라, 동일한 미디어 형식과 원격/로컬 조건에서 같은 수와 조합의 클라이언트가 안정적으로 유지된다는 의미입니다.

리소스와의 상관관계 없이 문제가 계속 다른 위치에서 발생한다면 각 클라이언트의 시작 및 실패 시각을 기록한 Plex 서버 로그를 수집하세요. 클라이언트 모델, Plex 앱 버전, 서버 버전, 미디어 세부 정보 및 처음 실패한 동시 클라이언트 단계를 함께 제공해 문제를 에스컬레이션하면 다음 진단을 재현 가능한 증거를 바탕으로 시작할 수 있습니다.