Проблемы с буферизацией в коди (на openelec)

9

Каждый раз, когда я пытаюсь транслировать тяжелые (в основном 1080p) видео через сеть (webdav, sftp ...), либо происходит сбой, либо появляется сообщение «кэш заполнен» и т. Д. Видео начинает воспроизводиться, но случайно останавливается (для буферизации снова , Я полагаю).

Я знаю, что это распространенная проблема, и я знаю, какие уловки я могу сделать ( тоже скручивать ).

Окружение:

Я использую модель 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-карту, он работает гладко.

Проблема с оперативной памятью?

Я бы понял аппаратное ограничение, если бы ОЗУ было заполнено, но при просмотре видео free -mвыдает следующее:

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

Кажется, есть много доступных ...

Интересный факт, как заметил @goldilocks, буферы необычно малы.

Проблемы с сетью?

Если я загружаю видеофайл вручную с помощью SFTP, одновременно воспроизводя этот же файл, он работает. Скорость загрузки: ~ 1,5 МБ / с. Таким образом, ни сеть, ни расшифровка не являются узким местом.

Другая проблема?

Ошибки в лог-файле (с отладкой видео, отладкой ffmpeg), кроме отладки и уведомлений:

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

Итак, curl не оптимизирован для потокового видео. Но как насчет SFTP? Это должен быть кусок пирога.

Проблема с конфигурацией?

Последний тест выше (sdcard cache) интересен. Воспроизведение видео начнется после загрузки примерно 150M (!) На SDCard ( .kodi/temp/filecache000.cache). Хотя он работает хорошо, это не жизнеспособное решение, так как он слишком медленный для запуска.

Кажется, пытается загрузить тот же объем оперативной памяти, игнорируя конфигурацию в 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>

Примечание: некоторые из этих опций больше не верны в коди 17, см. Ответ @ZacWolf для обновления

Итак, у кого-нибудь есть идеи? Что здесь может быть не так? Безотносительно решения я также хочу знать, почему нормальное использование (буфер ОЗУ) терпит неудачу в этом случае.

РЕДАКТИРОВАТЬ: Тест на Archlinux

Я установил kodi на Archlinux, чтобы определить, является ли это проблемой kodi или openelec. То же самое: HD-видео нестабильно, так что, похоже, это ошибка в коди. Это больше похоже на проблему с протоколом (SFTP и WebDAV: http), потому что мой тест с SSHFS работает отлично. К сожалению, не так просто установить SSHFS на openelec.

РЕДАКТИРОВАТЬ 2: Обходной путь

Я пишу это здесь, потому что это напрямую не решает проблему буферизации, но я установил kodi на Archlinux уже более года, и он отлично работает. Это менее дружественно, чем openelec, но для тех, кто заинтересован:

  • Установить Archlinux для ARM (очень просто, просто следуйте инструкциям - это для rpi1, для более поздних просто смените платформу);
  • Установите Kodi ( следуйте вики-руководству Archlinux - в основном, установите kodi-rbpпакет);
  • Включить Коди службу для автоматического запуска при запуске Коди: # systemctl enable kodi.service;
  • Установка SSHFS: pacman -Suy sshfs;
  • Используйте очень полезное SSHFS автомонтирования с /etc/fstabсмонтировать далекую долю.

Выполнено. Не забудьте обновить часто ( pacman -Suy).

kodi openelec Гун-Дон
источник
150 МБ может быть на верхней стороне, но 5 МБ, вероятно, слишком мало для контента с битрейтом ~ 1 МБ / с, если вы хотите избежать прерывистости. Я бы избавился от паранойи по поводу SD-карты. Вы купили его, чтобы использовать правильно? Если нет, это будет еще безопаснее в прохладном, сухом шкафу где-нибудь.
Златовласка
Спасибо за вашу заботу. Но учтите, что мой вопрос не только о буфере SDCard. Во-вторых, 150M, при ~ 1MB / s ... Да, 150s. Это нелепо долго. Есть ли возможность изменить размер буфера при использовании SDCard? Это может быть решением. Затем, независимо от размера кэша, он будет загружать все видео (иногда несколько ГБ) на SD-карту, а не только буфер. Я знаю, SDCard дешевы. Это не имеет большого значения. Я знаю. Но почему я должен беспокоиться о SDCard, когда оперативная память должна работать?
Гай-Дон
Извините - я немного смягчил это, оглядываясь назад. Я не использовал Kodi, поэтому я не могу здесь сильно помочь, это было просто общее наблюдение. IMO, буферизация на диск - лучшая стратегия, чем буферизация на ОЗУ, потому что, если вы заполняете ОЗУ на 100%, в системе не останется дискового кеша, что заметно повлияет на все аспекты работы. Однако, если вы не заполняете ОЗУ и больше ничего не делаете, то, что вы записываете (и одновременно читаете) с диска, несомненно, будет помещено в дисковый кэш - т.е. ОЗУ, но управляется динамически ядром, которое что делает это лучшей стратегией.
Златовласка
В случае, если это неясно: ОС использует как можно больше незагруженной оперативной памяти для кэширования (я упомянул это выше как «дисковый кеш», что является небольшим заблуждением, но подчеркивает тот факт, что обычно это в основном материал, часто читаемый с диска). ). На пи не было бы ничего необычного, чтобы быть всей незафиксированной оперативной памятью, это цифра "буферов", freeпоэтому в вашем посте интересен тот факт, что это число относительно мало. Если вы увеличите кэш-память Kodi на диске, это число может / должно увеличиться во время работы, чтобы примерно соответствовать ему.
Златовласка
1
Я видел;) Хорошо, я понимаю, использование диска лучше, чем заполнение оперативной памяти. Это хорошее решение, чтобы оно работало, если я могу уменьшить необходимый размер буфера для воспроизведения видео. Кстати, похоже, это процент, а не абсолютная сумма. Тем не менее, мне любопытно, что здесь происходит. Странно, что у меня так много оперативной памяти не используется, даже когда видео буферизуется.
Гай-Дон,

Ответы:

2

РЕДАКТИРОВАТЬ (12/2017)

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>
ZacWolf
источник
Это специально для устройства Vero4K, у которого больше памяти, чем у Pi, поэтому вам необходимо настроить эти параметры в зависимости от доступной памяти.
ZacWolf
1

Я использую Pi 3 с OpenElec и столкнулся с множеством проблем с буферизацией.

Я транслировал его по Wi-Fi, так как решил, что он находится рядом с маршрутизатором и не должен иметь никаких проблем. После подключения через Ethernet я удалил расширенный XML-файл, так как проблемы с буферизацией прекратились.

Мой ноутбук и телефон нормально работают через Wi-Fi без буферизации, поэтому что-то со встроенным Wi-Fi Pi 3 в OpenElec вызывает проблему.

Маркус
источник
Я рад, что вы исправили свою проблему, и я уверен, что это поможет многим людям, которые столкнулись с этой проблемой. В моем случае я использовал Ethernet с самого начала, хотя. Для rpi1 я не думаю, что это решение. При этом странно, что у вас была похожая проблема с rpi3, поскольку она имеет вдвое больше оперативной памяти, чем rpi1 ... Я могу ошибаться, но кажется, что обработка кэша в kodi просто дерьмовая.
Гай-Дон
-1

У меня была та же проблема, и я использовал этот «хак» , теперь все идет гладко.

--- edit --- После предложения @Simulant:

  • Установите инструмент обслуживания xunity.
  • Попал в программу (не в настройки), xunity - твики.
  • Выберите «Добавить 0 Cache Advanced XML».
Меир
источник
1
Пожалуйста, выделите ключевые факты из вашего связанного источника. В противном случае, если связанный источник отключится, ваша публикация будет бесполезной.
Simulant
1
Разве Xunity не просто графический интерфейс для этой цели? Я имею в виду, чем он отличается от настройки самого файла advancedsettings.xml ? На самом деле, я сделал настройку без кэша, это способ замедлить загрузку видео SFTP или webdav.
Ги-Дон
Это графический интерфейс. Но из моего опыта прямое редактирование может быть сложно (из-за разрешений и т. Д.). Аддон работает хорошо, я использовал его :-)
Меир