Server Version#: 1.24.4.5081
Player Version#: 4.63.0
QNAP TS670 pro 4gb ram current firmware 4.3.6.1750
Issue:
When the plex server is running the qnap is constantly dropping packets on both interfaces. If I stop the plex service it returns to normal.
Can anyone offer any help in fixing this?
Have you set a default gateway for the QNAP for plex to stay attached to?
“Auto” is not the best when there are multiple interfaces.
If you intend to run two, and both are on the same subnet, BOND them into 1 address.
Thanks Chuck
They were bonded until today, when I reset the networking to discount the bond as an issue, the problem was happening with the bond as well.
What is the current state? Bonded? Not bonded?
May I have the logs please after starting PMS? I’ll be able to tell you what Plex sees
Just reinstated the bond with fixed gw but that has thrown pms as I cant open the plex admin page as the browser seems to be in redirect loop, so just restarted to see if fixes it.
Nope, pms seems totally broken now, will try a reinstall.
Okay, back to a working configuration;
Bond with fixed gw
Reinstalled plex
Logs attached
Plex Media Server Logs_2021-10-21_23-28-44.zip (1.6 MB)
Is everything up?
I see the device at 192.168.103.80 not responding with standard XML and that’s causing Plex to spit out a lot of spam errors.
It apparently wants a username to access it?
That’s strange as there is nothing on 103.80
sorry… typo: ..103.210:80
Oct 21, 2021 23:14:49.589 [0x7f6728961b38] DEBUG - HTTP requesting GET http://192.168.103.210:80/xml/devicedesc.xml
Oct 21, 2021 23:14:49.634 [0x7f6728961b38] DEBUG - HTTP/1.1 (0.0s) 200 response from GET http://192.168.103.210:80/xml/devicedesc.xml
Oct 21, 2021 23:14:49.634 [0x7f6728961b38] ERROR - XML: Entity: line 8:\00
Oct 21, 2021 23:14:49.634 [0x7f6728961b38] ERROR - XML: parser\00
Oct 21, 2021 23:14:49.634 [0x7f6728961b38] ERROR - XML: error :\00
Oct 21, 2021 23:14:49.634 [0x7f6728961b38] ERROR - XML: Opening and ending tag mismatch: link line 7 and head\00
Oct 21, 2021 23:14:49.634 [0x7f6728961b38] ERROR - XML: </head>\00
Oct 21, 2021 23:14:49.634 [0x7f6728961b38] ERROR - XML: ^\00
Oct 21, 2021 23:14:49.634 [0x7f6728961b38] ERROR - XML: Entity: line 51:\00
That is a managed switch, upnp was on… off now
My switches are managed. If you’ve set it for etherchannel mode and the ports
or mode wasn’t set right, you will drop packets.
(example: Set mode on for ports 2 & 3 but use 2 & 5 (or similar… which I’ve done myself)
Sure, I have double-checked and reconfigured all the port settings.
As soon as I stop the PMS it doesn’t miss a ping for hours, the moment I start PMS the drop-outs start again.
The latest logs are attached.
I appreciate your time on this.Plex Media Server Logs_2021-10-22_10-30-10.zip (2.3 MB)
Here’s what I don’t get.
Ping (ICMP) replies are handled by the OS.
Once the adapter has an IP address, the OS will start responding to PING requests.
Plex is an application which runs on that OS and uses that networking service the OS provides.
Initial conclusion:
Inquiry:
Indeed, it defies logic.
?Why QTS 4.3.6?
There is no newer version for the TS670pro Intel as far as I’m aware.
Wow. I did not know the TS-670PRO was in EOL/EOS status
This shows me they are only providing bug fixes now; soon to be locked.
QTS
4.3.6.1750 build 20210730 2021-08-02
Care to conduct an experiment?
cd /share/*/.qpkg/PlexMediaServer
mv Library Library-KEEP-THIS
Switch back to the browser
Sign out of Plex.tv
Start Plex (it’ll spin a new server we can use to test with without impacting existing)
Open an incognito window to the QNAP and start setup
MAKE CERTAIN to give it a non-conflicting “Test” friendly name.
Bring it to the dashboard having added only 1 small library section.
Now see if it still drops packets.
Results;
new library didn’t start as no tmp dir was created in the new library
manually mkdir tmp
now starts okay
Added in the same folder of home movies I had before and it is stable with no loss of pings!
I apologize. That’s on me. I will fix the scripting to handle that.
EDIT: Update submitted to QA for review and release into PMS.
During the process I did notice a small gotcha:
If the qnap is forcing https the plex setup fails as the setup script calls http.
Good news is the qnap is no longer dropping packets 
Spoke too soon, overnight it has started dropping packets again 
PING 192.168.103.131 (192.168.103.131): 56 data bytes
64 bytes from 192.168.103.131: icmp_seq=0 ttl=64 time=0.370 ms
64 bytes from 192.168.103.131: icmp_seq=1 ttl=64 time=0.251 ms
64 bytes from 192.168.103.131: icmp_seq=2 ttl=64 time=0.238 ms
64 bytes from 192.168.103.131: icmp_seq=3 ttl=64 time=0.266 ms
Request timeout for icmp_seq 4
Request timeout for icmp_seq 5
Request timeout for icmp_seq 6
Request timeout for icmp_seq 7
64 bytes from 192.168.103.131: icmp_seq=8 ttl=64 time=0.292 ms
64 bytes from 192.168.103.131: icmp_seq=9 ttl=64 time=0.247 ms
64 bytes from 192.168.103.131: icmp_seq=10 ttl=64 time=0.276 ms
64 bytes from 192.168.103.131: icmp_seq=11 ttl=64 time=0.242 ms
64 bytes from 192.168.103.131: icmp_seq=12 ttl=64 time=0.248 ms
64 bytes from 192.168.103.131: icmp_seq=13 ttl=64 time=0.248 ms
Request timeout for icmp_seq 14
Request timeout for icmp_seq 15
Request timeout for icmp_seq 16
Request timeout for icmp_seq 17
64 bytes from 192.168.103.131: icmp_seq=18 ttl=64 time=0.286 ms
64 bytes from 192.168.103.131: icmp_seq=19 ttl=64 time=0.248 ms
64 bytes from 192.168.103.131: icmp_seq=20 ttl=64 time=0.235 ms
64 bytes from 192.168.103.131: icmp_seq=21 ttl=64 time=0.320 ms
64 bytes from 192.168.103.131: icmp_seq=22 ttl=64 time=0.276 ms
64 bytes from 192.168.103.131: icmp_seq=23 ttl=64 time=0.283 ms
Request timeout for icmp_seq 24
64 bytes from 192.168.103.131: icmp_seq=25 ttl=64 time=0.306 ms
64 bytes from 192.168.103.131: icmp_seq=26 ttl=64 time=0.259 ms
64 bytes from 192.168.103.131: icmp_seq=27 ttl=64 time=0.300 ms
64 bytes from 192.168.103.131: icmp_seq=28 ttl=64 time=0.289 ms
64 bytes from 192.168.103.131: icmp_seq=29 ttl=64 time=0.309 ms
64 bytes from 192.168.103.131: icmp_seq=30 ttl=64 time=0.313 ms
64 bytes from 192.168.103.131: icmp_seq=31 ttl=64 time=0.241 ms
64 bytes from 192.168.103.131: icmp_seq=32 ttl=64 time=0.284 ms
64 bytes from 192.168.103.131: icmp_seq=33 ttl=64 time=0.246 ms
Request timeout for icmp_seq 34
Request timeout for icmp_seq 35
Request timeout for icmp_seq 36
Request timeout for icmp_seq 37
64 bytes from 192.168.103.131: icmp_seq=38 ttl=64 time=0.284 ms
64 bytes from 192.168.103.131: icmp_seq=39 ttl=64 time=0.210 ms
64 bytes from 192.168.103.131: icmp_seq=40 ttl=64 time=0.233 ms
64 bytes from 192.168.103.131: icmp_seq=41 ttl=64 time=0.280 ms
64 bytes from 192.168.103.131: icmp_seq=42 ttl=64 time=0.218 ms
64 bytes from 192.168.103.131: icmp_seq=43 ttl=64 time=0.315 ms
Request timeout for icmp_seq 44
Request timeout for icmp_seq 45
Request timeout for icmp_seq 46
Request timeout for icmp_seq 47
64 bytes from 192.168.103.131: icmp_seq=48 ttl=64 time=0.253 ms
64 bytes from 192.168.103.131: icmp_seq=49 ttl=64 time=0.238 ms
64 bytes from 192.168.103.131: icmp_seq=50 ttl=64 time=0.258 ms
64 bytes from 192.168.103.131: icmp_seq=51 ttl=64 time=0.189 ms
64 bytes from 192.168.103.131: icmp_seq=52 ttl=64 time=0.265 ms
