Problèmes de mise en mémoire tampon avec kodi (sur openelec)

9

Chaque fois que j'essaie de diffuser des vidéos lourdes (principalement 1080p) via le réseau (webdav, sftp ...), cela échoue ou je reçois le message "le cache est plein", etc. Les vidéos commencent à jouer, mais s'arrêtent au hasard (pour tamponner à nouveau , J'imagine).

Je sais que c'est un problème commun et je connais les réglages que je peux faire ( boucler aussi).

L'environnement:

J'utilise un RPi modèle B et j'ai une connexion Internet de 100M / b. J'ai testé avec Kodi 14.2 et Kodi 15 (openelec 5.0.7, openelec 5.95.2).

Les tests:

Jusqu'à présent, parmi de nombreuses options supplémentaires, voici ce que j'ai essayé:

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
--------------------------------------------------------------------------

Problème vidéo?

Nan. S'il est copié sur la carte SD, il fonctionne correctement.

Problème de RAM?

Je comprendrais la limitation matérielle si la RAM était pleine, mais, en regardant des vidéos, free -mme donne ceci:

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

Il semble qu'il y en ait beaucoup disponibles ...

Fait intéressant, comme l'a remarqué @goldilocks, les tampons sont inhabituellement bas.

Problème de réseau?

Si je télécharge un fichier vidéo manuellement avec SFTP, tout en lisant ce même fichier en même temps, cela fonctionne. Vitesse de téléchargement: ~ 1,5 Mo / s. Donc, ni le réseau, ni le décryptage n'est un goulot d'étranglement.

Un autre problème?

Erreurs dans le fichier journal (avec débogage vidéo, débogage ffmpeg), à l'exception du débogage et des notifications:

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

OK, donc curl n'est pas optimisé pour le streaming vidéo. Mais qu'en est-il du SFTP? Ce devrait être un morceau de gâteau.

Problème de configuration?

Le dernier test ci-dessus (cache sdcard) est intéressant. Il commence à lire la vidéo, après avoir téléchargé environ 150M (!) Sur la carte SD ( .kodi/temp/filecache000.cache). Bien qu'il fonctionne bien, ce n'est pas une solution viable car il est trop lent à démarrer.

Il semble essayer de télécharger la même quantité de RAM, en ignorant la configuration advancedsettings.xml. J'ai vérifié, le fichier est chargé sans aucun problème. Voici un exemple de quelque chose que j'ai testé ( .kodi/userdata/advancedsettings.xml):

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

Remarque: certaines de ces options ne sont plus correctes dans kodi 17, voir la réponse @ZacWolf pour la mise à jour

Alors, quelqu'un a une idée? Qu'est-ce qui pourrait mal ici? Quelle que soit la solution, je veux également savoir pourquoi une utilisation normale (mémoire tampon RAM) échoue dans ce cas.

EDIT: Test sur Archlinux

J'ai installé kodi sur Archlinux, pour déterminer s'il s'agit d'un problème kodi ou openelec. C'est la même chose: les vidéos HD sont saccadées, donc il semble que ce soit un bug dans kodi. Cela ressemble plus à un problème de protocole (SFTP et WebDAV: http) car mon test avec SSHFS fonctionne très bien. Malheureusement, il n'est pas trivial d'installer SSHFS sur openelec.

EDIT 2: une solution de contournement

Je l'écris ici, car il ne résout pas directement le problème de mise en mémoire tampon, mais j'ai installé kodi sur Archlinux depuis plus d'un an maintenant, et cela fonctionne parfaitement bien. Il est moins convivial que openelec, mais pour ceux qui sont intéressés:

  • Installez Archlinux pour ARM (très facile, suivez simplement le guide - c'est pour rpi1, pour les plus récents, changez simplement de plateforme);
  • Installez Kodi ( suivez le guide du wiki Archlinux - en gros, installez le kodi-rbppaquet);
  • Activez le service kodi pour exécuter automatiquement kodi au démarrage: # systemctl enable kodi.service;
  • Installer SSHFS: pacman -Suy sshfs;
  • Les très utiles SSHFS le montage automatique avec /etc/fstabpour monter votre part lointaine.

Terminé. N'oubliez pas de mettre à jour fréquemment ( pacman -Suy).

kodi openelec Guidon
la source
150 Mo sont peut-être trop élevés, mais 5 Mo sont probablement trop bas pour un contenu à ~ 1 Mo / s de débit binaire si vous voulez éviter les haches. J'abandonnerais la paranoïa de la carte SD. Vous l'avez acheté pour l'utiliser non? Sinon, il sera encore plus sûr dans un placard frais et sec quelque part.
goldilocks
Merci pour votre inquiétude. Mais sachez que ma question ne concerne pas uniquement le tampon de la carte SD. Deuxièmement, 150 Mo, à ~ 1 Mo / s ... Oui, 150 secondes. C'est absurdement long. Existe-t-il une option pour modifier la taille du tampon lors de l'utilisation de la carte SD? Cela pourrait être une solution. Ensuite, quelle que soit la taille du cache, il chargera l'intégralité de la vidéo (parfois plusieurs Go) sur la carte SD, pas seulement le tampon. Je sais, les cartes SD sont bon marché. Ce n'est pas grave. Je connais. Mais pourquoi devrais-je me soucier de la carte SD alors que la RAM devrait fonctionner?
Gui-Don
Désolé - j'ai atténué cela un peu après y avoir jeté un coup d'œil. Je n'ai pas utilisé Kodi donc je ne peux pas être d'une grande aide ici, c'était juste une observation générale. IMO, la mise en mémoire tampon sur disque est une meilleure stratégie que la mise en mémoire tampon sur RAM car si vous remplissez 100% de RAM, le système n'a plus de cache disque, ce qui aura un impact notable sur tous les aspects du fonctionnement. Cependant, si vous ne remplissez pas la RAM et que rien d'autre ne le fait, ce que vous écrivez (et lisez simultanément sur) le disque sera certainement placé dans le cache du disque - c'est-à-dire la RAM, mais géré dynamiquement par le noyau, qui est ce qui en fait une meilleure stratégie.
goldilocks
Dans le cas où ce n'est pas clair: le système d'exploitation utilise autant de RAM non engagée que possible pour la mise en cache (je l'ai appelé ci-dessus "cache de disque", ce qui est un peu inapproprié, mais souligne le fait qu'il s'agit généralement de choses fréquemment lues à partir du disque. ). Sur le pi, il ne serait pas inhabituel que ce soit toute la RAM non engagée, c'est le chiffre des "tampons" free- donc quelque chose d'intéressant dans votre article est le fait que ce nombre est relativement petit. Si vous augmentez le cache sur disque de Kodi, ce nombre pourrait / devrait augmenter pendant l'action pour le faire correspondre.
goldilocks
1
J'ai vu;) OK, je comprends qu'il est préférable d'utiliser le disque que de remplir la RAM. C'est une bonne solution pour le faire fonctionner, si je peux réduire la taille de tampon nécessaire pour lire la vidéo. BTW, il semble être un pourcentage plutôt qu'un montant absolu. Pourtant, je suis curieux de savoir ce qui se passe ici. C'est étrange, j'ai tellement de RAM inutilisée, même lorsque la vidéo est en mémoire tampon.
Gui-Don

Réponses:

2

EDIT (12/2017)

Balises Kodi v17 renommées et déplacées dans advancedsetting.xml

<cachemembuffersize> renommé en <memorysize>

<readbufferfactor> renommé en <readfactor>

ET ils ont été supprimés de <network> et ajoutés à <cache>

Mon avancesettings.xml ressemble maintenant à:

<?xml version="1.0" encoding="utf-8"?>
<advancedsettings>
        <cache>
                <memorysize>524288000</memorysize>
                <buffermode>1</buffermode>
                <readfactor>6</readfactor>
        </cache>
</advancedsettings>
ZacWolf
la source
C'est spécifiquement pour un appareil Vero4K, qui a plus de mémoire qu'un Pi, vous devrez donc modifier ces paramètres spécifiques à votre mémoire disponible.
ZacWolf
1

J'utilise Pi 3 avec OpenElec dessus et j'ai également rencontré beaucoup de problèmes de mise en mémoire tampon.

J'étais en train de le diffuser via Wi-Fi car je pensais qu'il était juste à côté du routeur et ne devrait pas avoir de problèmes. Eh bien, après avoir branché via Ethernet, j'ai pu supprimer le fichier xml avancé tous ensemble car les problèmes de mise en mémoire tampon se sont arrêtés.

Mon ordinateur portable et mon téléphone fonctionnent bien via Wi-Fi sans mise en mémoire tampon, donc quelque chose avec le Wi-Fi intégré du Pi 3 sur OpenElec est à l'origine du problème.

Marcus
la source
Je suis heureux que vous ayez résolu votre problème et je suis sûr que cela aidera de nombreuses personnes qui ont rencontré ce problème. Dans mon cas, j'ai utilisé Ethernet depuis le début. Pour rpi1, je ne pense pas que ce soit la solution. Cela étant dit, c'est étrange que vous ayez eu un problème similaire sur rpi3, car il a deux fois plus de RAM que rpi1… Je peux me tromper mais il semble que la gestion du cache sur kodi soit juste merdique.
Gui-Don
-1

J'ai eu le même problème et j'ai utilisé ce «hack» , les choses se passent bien maintenant.

--- modifier --- Suite à la suggestion de @Simulant:

  • Installez l'outil de maintenance de xunity.
  • Entré dans le programme (pas les paramètres), xunity - réglages.
  • Sélectionnez «Ajouter 0 cache XML avancé
Meir
la source
1
Veuillez aligner les trucs clés de votre source liée. Sinon, si la source liée se déconnectait, votre message serait inutile.
Simulant
1
Xunity n'est-il pas simplement une interface graphique à cet effet? Je veux dire, en quoi est-ce différent de modifier moi-même le fichier advancedsettings.xml ? En fait, j'ai fait le paramètre sans cache, c'est un moyen de ralentir le chargement pour les vidéos SFTP ou webdav.
Gui-Don du
C'est un gui. Mais d'après mon expérience, l'édition directe peut être délicate (en raison des autorisations, etc.). L'addon fonctionne bien, je l'ai utilisé :-)
Meir