Lecture vidéo Emby qui ne fonctionne pas

Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

Lecture vidéo Emby qui ne fonctionne pas

Rathorian

Bonjour à tous,

Je viens d'installer sur ma Dedibox Limited 33816, une Debian 8.7 avec un kernel 3.16.
Dessus j'y est installé une Seedbox toute simple avec des images Docker.
Voici mon docker-compose.

Premier problème : Impossible de lire une vidéo avec Emby. Aucun message d'erreur, la vidéo reste en chargement.

Deuxième problème : Qui est moins important, j'ai toujours au moins 1 de mes coeurs processeurs qui est à 100% d'usage....

Auriez-vous une idée du problème s'il vous plait ?

Merci
Cordialement

Aerya

Pour le CPU => top ou htop et tu verras ce qui le pompe.
Pour Emby, ffmpeg est-il bien à jour ?

Rathorian

Aerya

Je savais déjà que c'était "rtorrent" qui faisait monter l'utilisation du processeur mais j'ai oublié de le signaler dans mon message précédent. Du coup, j'avais déjà essayé avec l'image docker "wonderfall/rtorrent-flood" et c'était le même problème, l'issue le concernant. Je sais donc pas si c'est le même problème.

Concernant la lecture des vidéos, je ne sais pas du tout pour "ffmpeg" car j'utilise tout simplement l'image docker de Xataz et comme je suis un peu une brêle avec Docker 🙂

bmth

Tu devrais plutôt fournir les logs d'Emby.

Rathorian

bmth En effet, voici les logs d'Emby.

Merci

Aerya

Pour rTorrent c'est classique, ne te prends pas la tête.
Pour Emby je ne vois rien d'anormal dans les logs. Tu as testé plusieurs films/séries ? Plusieurs codecs/conteneurs (x264/x265/avi/mkv/...) ? Plusieurs navigateurs ? (ou tu lis avec le client ?)

Rathorian

Aerya Si c'est classique pour "rTorrent", c'est seulement sur Docker car sur une installation à la main aucun problème personnellement.

J'en ai testé 2-3 oui de différents codecs et sur différents clients, notamment sur Chromecast.
Par contre je viens de voir dans les logs à plusieurs reprises

Error, Main, Error loading ImageMagick. Will revert to GDI.
Info, GDI, GDIImageEncoder starting
Error, Main, Error loading GDI. Will revert to NullImageEncoder.
appHost.Init
Info, App, Application version: 3.2.13.0
Info, App, Application configuration:

C'est rien d'anormal ?

xataz

Salut,

Pour rtorrent, on regarde avec Wonderfall pour savoir d'où viendrais le problème, on soupsonne overlayFS. Pourrais tu me fournir le contenu de uname -a et de docker info.

Pour emby, je n'ai personnellement pas de soucis avec mon image, avec client web et client android (enfin c'est assez instable en 4G). Au niveau de la logs, je ne pense pas que ce sois cela, ça doit surtout être une erreur de conversion de miniature ou un truc du genre, mais je vais voir pour corriger ceci.

Rathorian

xataz Salut,

Contenu de "uname -a" :

Linux server 3.16.0-4-amd64 #1 SMP Debian 3.16.39-1+deb8u2 (2017-03-07) x86_64 GNU/Linux

Docker info

Pour emby, est-ce que se serait pas à cause du fait que je l'ai build moi même avec la nouvelle version d'emby ?
J'avais fait :

docker build -t xataz/emby:3.2.13.0 --build-arg MEDIAINFO_VER=0.7.95 --build-arg EMBY_VER=3.2.13.0 github.com/xataz/dockerfiles.git#master:emby

Merci pour votre aide

Wonderfall

Ça rend le problème d'autant plus étrange que j'ai le même souci avec Linux 4.10 et overlay, et toi avec 3.16 et aufs... Pourtant @xataz assure ne pas avoir le problème. On doit passer à côté de quelque chose...

Rathorian

Wonderfall C'est clair qu'on doit passer à côté de quelque chose si @xataz n'a aucun souci avec rtorrent. Mais on est quand même une bonne poignée de personnes à avoir ce problème.

Après si quelqu'un veut prendre la main sur mon serveur avec teamviewer pour regarder, pas de soucis !

Merci

xataz

Wonderfall Oui c'est vraiment étrange, la seul différence pour moi, c'est que j'utilise btrfs :

xataz@sldock01:~$ docker info
Containers: 27
 Running: 26
 Paused: 0
 Stopped: 1
Images: 586
Server Version: 17.05.0-ce
Storage Driver: btrfs
 Build Version: Btrfs v3.17
 Library Version: 101
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: bridge host macvlan null overlay
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 9048e5e50717ea4497b757314bad98ea3763c145
runc version: 9c2d8d184e5da67c95d601382adf14862e4f2228
init version: 949e6fa
Kernel Version: 3.16.0-4-amd64
Operating System: Debian GNU/Linux 8 (jessie)
OSType: linux
Architecture: x86_64
CPUs: 8
Total Memory: 31.32GiB
Name: sldock01
ID: TZD5:QZCK:EIRU:5USK:NKBY:K537:AF5U:HLE2:XKC5:TNF6:J4V4:T3FD
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Username: xataz
Registry: https://index.docker.io/v1/
Experimental: false
Insecure Registries:
 127.0.0.0/8
Live Restore Enabled: false

Rathorian

Je pense retourner à des installations basiques à la main sans Docker. J'arrive que très rarement à utiliser Docker correctement. La seule image que j'ai réussi à comprendre et utiliser sans problème c'est "hardware/nsd-dnssec".

Wonderfall

@Rathorian On a peut-être trouvé une solution, ajoute tty: true à ton docker-compose.

Rathorian

Wonderfall Merci, je vais essayer

BXT

@Wonderfall pour savoir, quelles sont tes images impactées par ce bug ?

Tu penses que NextCloud peut l'être ? 😃

Wonderfall

BXT C'est un autre problème celui avec chown, et malheureusement tty: true n'y arrange rien (j'ai toujours 1 voire 2 minutes à attendre pour rtorrent-flood par exemple). Mais ça serait génial si on avait une solution autre que de changer de fs...