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

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 --versionDocker version 19.03.13, build 4484c46pi@debian-buster-64:~ $ sudo docker-compose --versiondocker-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 -Sminidlna.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:46616upnphttp.c:259: debug: Range Start-End: 10117400 - -1clients.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.1Host: 192.168.1.11:8200Accept: */*Accept-Language: en_USUser-Agent: VLC/3.0.11 LibVLC/3.0.11Range: 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]