MiniDLNA (docker) stream from RPi to TV gets stuck/very slow buffering with .mkv files

Question

Setup: I have a RPi 4 with miniDLNA (ReadyMedia) and samba each running in a docker, a SSD connected via USB3 to the RPi and a TV connected via WiFi. All devices are in my locale network. The SSD is formatted as ext4. I have access via samba to a folder on my SSD which also functions as the miniDLNA volume.

I have transfer speeds of around 90MB/s via LAN and WiFi to my samba share. But the issue is when streaming videos via miniDLNA I notice long buffering times and it usually gets stuck after watching for just a few seconds (both on TV [WiFi] as well as on a Win10 machine [LAN]). Until now, I didn't notice this behaviour with .mp4 files, only with .mkv files. The video files are 1080p.

The two docker files I use are from dperson/samba and ypopovych/readymedia, respectively.

I do not think this is an issue with my docker-compose file, rather than an encoding issue, but nevertheless here is my docker-compose file:

version: '3.4'

services:
 samba:
   image: dperson/samba
   environment:
     TZ: 'Europe/Berlin'
     USER: 'username;password'
     SHARE: 'share;/mnt/transit;yes;no;yes'
   ports:
     - "137:137/udp"
     - "138:138/udp"
     - "139:139/tcp"
     - "445:445/tcp"
   restart: unless-stopped
   volumes:
     - "/mnt/transit:/mnt/transit"
   command: '-p'
   
 dlna:
   image: ypopovych/readymedia
   network_mode: "host"
   environment:
     FRIENDLY_NAME: "DLNA4B"
     VIDEO_DIR1: "/media"
   volumes:
     - "/mnt/transit/videos:/media"
     - "readymediacache:/cache"
   ports:
     - 8200:8200
   restart: unless-stopped
   depends_on:
     - "samba"

volumes:
 readymediacache:

Does anybody have some pointers or experienced similar behaviours?

Edit: After some further testing I can rule out miniDLNA and samba. I created a share on the SD-card on my RPi and played a mkv video from there. No buffering problems at all. As soon as I play it from my SSD connected via USB3, I get the buffering problems every few seconds. When that happens the SSD does not respond at all for a couple of seconds. This is strange, because reading and writing from the SSD works with constant 90-100MB/s via network.

Answer 1

Hey @landmann123 I have exactly the same issue here! I'm gonna add some details to double-check with your scenario.

I'm running docker through the x64 terminal ds64-shell using raspbian-nspawn-64. How are you running your docker? And here are my docker info:

pi@debian-buster-64:~ $ sudo docker --version
Docker version 19.03.13, build 4484c46
pi@debian-buster-64:~ $ sudo docker-compose --version
docker-compose version 1.21.0, build unknown

Have you checked minidlna logs? I tried several images before - one of them I've found an error upnphttp.c:1272: debug: sendfile error :: error no. 32 [Broken pipe] which seems to be some broken connection though there's no documented solution on their project page.

I tested using some avi files and this mp4 sample. I faced the same issue, the only difference is the mp4 plays 0.5s than buffer for other 10s, while the .avi (around 180MB) it takes 1 or 2 min to buffer and play a 0.5 sec, then both randomly got stuck or play another 0.5s.

I suspect it could be a network issue (maybe related just w/ docker) although I have a fibre 100/20 and I use to have minidlna in another raspbian image working really well, so I need to clarify a little bit this theory. By the way, if you use network_mode: host the ports are ignored.

Edit: I tried ypopovych/readymedia image and got the same issue, comparing the images I noticed this one has just warn log level, perhaps it could be hiding some debug/hint in your case. The minidlna version is the same as my image, and it was using tini, I removed just to double check, although it's something rarely would change something.

All these changes drove to the same result. Another thing, you can enable debug and verbose mode on the minidlna command w/ respective arguments -d and -v. Please find below one log showing the arguments I'm using and the minidlna version:

++ /usr/sbin/minidlnad -d -v -P /minidlna/minidlna.pid -S
minidlna.c:1048: warn: Starting MiniDLNA version 1.2.1.
Server: 5.4.27-0-lts DLNADOC/1.50 UPnP/1.0 MiniDLNA/1.2.1

Using ypopovych/readymedia I tried with/without the named volume for caching, nothing different happened. One of the tests I paused the video for several minutes (just to check if it would buffer everything, who knows) but got the same error. I'm suspecting it's probably around some rendering stuff before the transfer, VLC was showing a golden bar while stuck, as it was waiting for something, like this:

P.S.: all the tests I tried using a windows machine and iPad - both with VLC. I have mounted an SD path and an external HD, all with the same issue. Although using just SMB I'm able to play on both devices and both paths. Ah and I haven't tried to play locally in the raspberry to see if it's something on the network, it would be another thing to give a try.

Update: Running on Raspberry's VLC on DLNA worked on both images and both paths! That brings me to the network again, BTW the broken pipe error appeared in the logs even when it worked like a charm:

minidlna.c:1309: debug: HTTP connection from 192.168.1.11:46616
upnphttp.c:259: debug: Range Start-End: 10117400 - -1
clients.c:331: debug: Client found in cache. [Generic UPnP 1.0/entry 0]
upnphttp.c:889: debug: HTTP REQUEST: GET /MediaItems/9074.avi HTTP/1.1
Host: 192.168.1.11:8200

Accept: */*
Accept-Language: en_US
User-Agent: VLC/3.0.11 LibVLC/3.0.11
Range: bytes=10117400-
upnphttp.c:1937: info: Serving DetailID: 9074 [/media/animes/bleach 2004/S01E030.avi]
upnphttp.c:1281: debug: sendfile error :: error no. 32 [Broken pipe]