Kodi의 버퍼링 문제 (openelec)


9

네트워크 (webdav, sftp ...)를 통해 무거운 (대부분 1080p) 비디오를 스트리밍하려고 할 때마다 실패하거나 "캐시가 가득 찼습니다"라는 메시지가 표시됩니다. 비디오 재생이 시작되지만 무작위로 중지 (다시 버퍼링) 나는 추측한다).

나는 이것이 알고 일반적인 문제 와 나는 알고 조절을 해 가며 내가 (할 수있는 컬을 너무).

환경 :

RPi 모델 B를 사용하고 100M / b 인터넷 연결이 있습니다. Kodi 14.2 및 Kodi 15 (openelec 5.0.7, openelec 5.95.2)로 테스트했습니다.

테스트 :

지금까지 많은 추가 옵션 중에서 이것이 시도한 것입니다.

Cache\Protocol | Webdav      | SFTP (local and internet)
--------------------------------------------------------------------------
No cache       | not loading | loads quickly, no error, stops frequently
--------------------------------------------------------------------------
(5mb cache)    | not loading | slow to load, cache error, stops randomly
--------------------------------------------------------------------------
(25mb cache)   | not loading | very slow to load, cache error, stops randomly
--------------------------------------------------------------------------
sdcard cache   | not loading | incredibly slow to load, no error, fine
--------------------------------------------------------------------------

비디오 문제?

아니. SD 카드에 복사하면 원활하게 실행됩니다.

RAM 문제?

RAM이 가득 차면 하드웨어 제한을 이해하지만 비디오를 보면서 free -m다음과 같이 나에게 알려줍니다.

             total         used         free       shared      buffers
Mem:           373          236          137            4           34
-/+ buffers:                202          171
Swap:            0            0            0

사용 가능한 것이 많이있는 것 같습니다 ...

흥미로운 사실은 @goldilocks에서 알 수 있듯이 버퍼가 비정상적으로 낮습니다.

네트워크 문제?

SFTP를 사용 하여 비디오 파일을 수동으로 다운로드하는 경우이 파일을 동시에 재생하면서 작동합니다. 다운로드 속도 : ~ 1.5MB / s. 따라서 네트워크 나 해독도 병목 현상이 없습니다.

다른 문제?

디버그 및 알림을 제외한 로그 파일의 오류 (비디오 디버그, ffmpeg 디버그 포함) :

ERROR: CCurlFile::FillBuffer - Failed: Timeout was reached
ERROR: OMXPlayerVideo: Got MSGQ_IS_ERROR(-1) Aborting

curl은 비디오 스트리밍에 최적화되어 있지 않습니다. 그러나 SFTP는 어떻습니까? 케이크 조각이어야합니다.

구성 문제?

위의 마지막 테스트 (sdcard 캐시)는 흥미 롭습니다. sdcard ( .kodi/temp/filecache000.cache) 에 약 150M (!)을 다운로드 한 후 비디오 재생을 시작합니다 . 잘 실행되지만 시작하기에는 너무 느리므로 실행 가능한 솔루션이 아닙니다.

의 구성을 무시하고 같은 양의 RAM을 다운로드하려고합니다 advancedsettings.xml. 확인했는데 파일이 아무런 문제없이로드되었습니다. 이것은 내가 테스트 한 것의 예입니다 ( .kodi/userdata/advancedsettings.xml).

<advancedsettings>
    <network>
        <buffermode>1</buffermode>
        <cachemembuffersize>5242880</cachemembuffersize>
        <readbufferfactor>4.0</readbufferfactor>
        <curlclienttimeout>60</curlclienttimeout>
        <curllowspeedtime>20</curllowspeedtime>
    </network>
</advancedsettings>

참고 : kodi 17에서는 이러한 옵션 중 일부가 더 이상 올바르지 않습니다. 업데이트는 @ZacWolf 답변을 참조하십시오.

그래서 누군가 어떤 아이디어가 있습니까? 여기서 무엇이 잘못 될 수 있습니까? 솔루션이 무엇이든,이 경우 정상적인 사용 (RAM 버퍼)이 실패하는 이유를 알고 싶습니다.

편집 : Archlinux에서 테스트

Kodi 또는 openelec 문제인지 확인하기 위해 Archlinux에 kodi를 설치했습니다. HD 비디오가 고르지 않아 kodi의 버그 인 것 같습니다. SSHFS 테스트가 훌륭하게 작동하기 때문에 프로토콜 문제 (SFTP 및 WebDAV : http)와 비슷합니다. 불행히도 openelec에 SSHFS를 설치하는 것은 쉬운 일이 아닙니다.

편집 2 : 해결 방법

버퍼링 문제를 직접 해결하지 못하기 때문에 여기에 작성했지만 Archlinux에 kodi를 1 년 이상 설치했으며 완벽하게 작동합니다. openelec보다 덜 멍청하지 않지만 관심이있는 사람들에게는 다음과 같습니다.

  • Archlinux for ARM을 설치하십시오 (매우 쉬우 므로 가이드를 따르십시오 -최신 버전의 경우 rpi1의 경우 플랫폼 변경).
  • (KODI를 설치 아치 리눅스 위키 가이드를 따라 - 기본적으로 설치 kodi-rbp패키지);
  • kodi 서비스가 시작시 kodi를 자동으로 실행하도록 설정하십시오 # systemctl enable kodi.service.
  • SSHFS를 설치하십시오. pacman -Suy sshfs;
  • 원격 공유를 마운트 하려면 매우 유용한 SSHFS 자동 마운트 를 사용하십시오 /etc/fstab.

끝난. 자주 업데이트하는 것을 잊지 마십시오 ( pacman -Suy).


150MB가 높은쪽에있을 ​​수 있지만, 고르지 않게하려면 ~ 1MB / s의 비트 전송률 콘텐츠에 대해 5MB가 너무 낮을 수 있습니다. 나는 SD 카드에 대해 편집증을 버릴 것입니다. 당신은 바로 사용하기 위해 그것을 구입? 그렇지 않으면 시원하고 건조한 찬장에서 더 안전합니다.
goldilocks

걱정 해주셔서 감사합니다. 그러나 내 질문은 sdcard 버퍼에만 관한 것이 아닙니다. 둘째, 150M, ~ 1MB / s ... 예, 150 초. 이것은 터무니없이 길다. sdcard를 사용할 때 버퍼 크기를 변경하는 옵션이 있습니까? 이것은 해결책이 될 수 있습니다. 그런 다음 캐시 크기에 관계없이 버퍼뿐만 아니라 전체 비디오 (때로는 몇 GB)를 sdcard에로드합니다. 나는 sdcard가 싸다는 것을 안다. 별거 아니에요 알아. 그러나 RAM이 작동 해야하는 동안 왜 sdcard에 대해 신경 써야합니까?
Gui-Don

죄송합니다. 다시 살펴본 후 약간 줄였습니다. 나는 Kodi를 사용하지 않았으므로 여기서 많은 도움을 줄 수는 없으며 일반적인 관찰이었습니다. RAM을 100 % 채우면 시스템에 디스크 캐시가 남지 않아 작동의 모든 측면에 눈에 띄게 영향을 미치므로 IMO, 디스크 버퍼링은 RAM 버퍼링보다 나은 전략 입니다. 그러나 RAM을 채우지 않고 다른 작업을 수행하지 않으면 디스크에 쓰거나 동시에 읽는 것은 디스크 캐시에 저장됩니다 (즉, RAM이지만 커널이 동적으로 관리합니다). 이것이 더 나은 전략을 만드는 것입니다.
goldilocks

명확하지 않은 경우 : OS는 캐싱 을 위해 할 수있는만큼 커밋되지 않은 RAM을 사용합니다 (위에서 이것을 "디스크 캐시"라고 부릅니다. ). 그 일을 위해 파이에 이상한되지 않을 것 모든 커밋되지 않은 RAM, 이것은 "버퍼"그림입니다에서 free- 게시물에 뭔가 흥미로운는이 숫자가 상대적으로 작다는 사실은 그래서. Kodi의 디스크 간 캐시를 늘리면 실제로 일치하는 횟수만큼 증가 할 수 있습니다.
goldilocks

1
나는 디스크를 사용하는 것이 RAM을 채우는 것보다 낫다는 것을 이해했다. 비디오를 재생하는 데 필요한 버퍼 크기를 줄일 수 있다면 작동시키는 것이 좋습니다. BTW는 절대 금액이 아닌 백분율로 보입니다. 아직도, 나는 여기서 일어나는 일이 궁금합니다. 비디오가 버퍼링되는 동안에도 너무 많은 RAM을 사용하지 않는 것이 이상합니다.
Gui-Don

답변:


2

편집 (2017 년 12 월)

KODI V17 이름이 바뀐 재배치 태그 advancedsetting.xml

<cachemembuffersize>가 <memorysize>로 이름이 변경되었습니다.

<readbufferfactor>가 <readfactor>로 이름이 변경되었습니다.

그리고 그들은 <network>에서 제거되었고 <cache>에 추가되었습니다

advancesettings.xml은 다음과 같습니다.

<?xml version="1.0" encoding="utf-8"?>
<advancedsettings>
        <cache>
                <memorysize>524288000</memorysize>
                <buffermode>1</buffermode>
                <readfactor>6</readfactor>
        </cache>
</advancedsettings>

이것은 Pi보다 더 많은 메모리를 가진 Vero4K 장치를위한 것이므로 사용 가능한 메모리에 따라이 설정을 조정해야합니다.
ZacWolf

1

OpenElec을 사용하여 Pi 3을 실행 중이며 많은 버퍼링 문제가 발생했습니다.

라우터 바로 옆에 있으며 문제가 없어야한다고 생각하면서 Wi-Fi를 통해 스트리밍했습니다. 이더넷을 통해 연결 한 후 버퍼링 문제가 중지되면서 고급 xml 파일을 모두 제거해야했습니다.

내 노트북과 휴대 전화 모두 버퍼링없이 Wi-Fi를 통해 제대로 재생되므로 OpenElec의 Pi 3 내장 Wi-Fi에 문제가 있습니다.


문제가 해결되어 다행이며이 문제를 겪은 많은 사람들에게 도움이 될 것입니다. 제 경우에는 처음부터 이더넷을 사용했습니다. rpi1의 경우 이것이 해결책이라고 생각하지 않습니다. 즉, rpi3보다 RAM이 두 배나 많기 때문에 rpi3에서 비슷한 문제가 발생하는 것은 이상합니다. 잘못되었을 수 있지만 kodi의 캐시 처리는 단지 엉터리입니다.
Gui-Don

-1

나는 같은 문제가 있었고이 'hack'을 사용했는데 상황이 순조롭게 진행됩니다.

--- 편집 --- 다음 @Simulant 제안에 따라 :

  • xunity 유지 관리 도구를 설치하십시오.
  • 프로그램 (설정이 아님), xunity-조정에 들어갔습니다.
  • '0 캐시 고급 XML 추가'를 선택하십시오.

1
링크 된 소스에서 주요 기능을 정리하십시오. 그렇지 않으면 링크 된 소스가 오프라인 상태가되면 게시물이 쓸모가 없게됩니다.
Simulant

1
Xunity가 그 목적을위한 GUI가 아닙니까? 내말은, advancedsettings.xml 파일을 직접 조정하는 것과 어떻게 다른 가요? 실제로 캐시 없음 설정을 수행했습니다. SFTP 또는 webdav 비디오의 로딩 속도가 느려집니다.
Gui-Don

GUI입니다. 그러나 내 경험으로는 직접 편집이 까다로울 수 있습니다 (권한 등으로 인해). 애드온은 잘 작동합니다. 저는 이것을 사용했습니다 :-)
Meir
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.