docker - 从RPi到TV的MiniDLNA(docker)流卡住了/非常慢的.mkv文件缓冲

Question

设置:
我有一个带有miniDLNA(ReadyMedia)和samba的RPi 4，它们分别在docker中运行，通过USB3连接到RPi的SSD和通过WiFi连接的电视。所有设备都在我的区域网络中。 SSD的格式为ext4。我可以通过samba访问我SSD上的一个文件夹，该文件夹也可用作miniDLNA卷。
通过LAN和WiFi到我的samba共享的传输速度约为90MB / s。但是问题是，当通过miniDLNA流式传输视频时，我注意到缓冲时间很长，通常在观看几秒钟后就卡住了(无论是在电视[WiFi]上还是在Win10机器[LAN]上)。直到现在，我还没有注意到.mp4文件的这种行为，而只有.mkv文件。视频文件为1080p。
我使用的两个docker文件分别来自dperson/samba和ypopovych/readymedia。
我认为这不是我的docker-compose文件的问题，而不是编码问题，但是这是我的docker-compose文件:

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:

是否有人有一些指示或经历过类似的行为？
编辑:
经过进一步测试后，我可以排除miniDLNA和samba。我在RPi的SD卡上创建了一个共享，然后从那里播放了mkv视频。完全没有缓冲问题。从通过USB3连接的SSD播放后，每隔几秒钟就会出现缓冲问题。发生这种情况时，SSD在几秒钟内完全没有响应。这很奇怪，因为通过网络从SSD读取和写入数据的速度恒定为90-100MB / s。

Answer 1

嘿@ landmann123我在这里有完全一样的问题!我将添加一些详细信息以仔细检查您的方案。
我正在使用ds64-shell通过x64终端raspbian-nspawn-64运行docker。您如何运行docker？这是我的 docker 信息:

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

您检查过minidlna日志吗？我之前尝试过几张图像-其中一幅我发现了upnphttp.c:1272: debug: sendfile error :: error no. 32 [Broken pipe]错误，尽管project page上没有记录在案的解决方案，但似乎连接断开了。
我使用一些avi文件和此mp4示例进行了测试。我遇到了同样的问题，唯一的区别是mp4播放的缓冲区比其他缓冲区的播放时间多了0.5s，而.avi(约180MB)的缓冲区播放0.5秒需要1或2分钟的时间，然后两者都会卡住或播放再0.5秒
我怀疑这可能是网络问题(可能与docker有关)，尽管我有100/20光纤，并且我以前在另一个树莓派镜像中使用minidlna确实工作得很好，所以我需要澄清一下这一理论。顺便说一句，如果您使用network_mode: host，则会忽略ports。
编辑:我尝试了ypopovych/readymedia图像并遇到了相同的问题，比较了我注意到该图像只是警告日志级别的图像，也许它可能在您的情况下隐藏了一些调试/提示。 minidlna版本与我的图像相同，并且使用的是tini，我删除它只是为了仔细检查，尽管很少更改。
所有这些变化导致了相同的结果。另一件事，您可以使用相应的参数-d和-v在minidlna命令上启用调试和详细模式。请在下面的日志中找到显示我正在使用的参数和minidlna版本的日志:

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

我使用ypopovych/readymedia尝试使用/不使用命名卷进行缓存，没有什么不同。我的一项测试将视频暂停了几分钟(只是想知道它是否可以缓冲所有内容，谁知道)，但是遇到了同样的错误。我怀疑它可能是在传输之前围绕一些渲染的东西，VLC在卡住时显示出一条金色的条，因为它正在等待某些东西，如下所示:

附言:我使用Windows机器和iPad尝试的所有测试-均带有VLC。我已经安装了SD路径和外部HD，但都存在相同的问题。尽管仅使用SMB，但我可以在两个设备和两个路径上播放。嗯，我还没有尝试过在树莓派中本地玩游戏，看看它是否在网络上，这是另一回事。
更新:在DLNA上的Raspberry VLC上运行可同时在图像和路径上使用!再次将我带到网络，顺便说一句，即使它像 super 按钮一样工作，破损管道错误也会出现在日志中:

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]