Server Version#: 1.20.5.3551
Player Version#: 4.46.2
Since I upgraded to 1.20.5.3551 I have noticed this error in the logs which to my knowledge was not there before:
SSDP: Error parsing device schema for http://192.168.1.16:49153/description2.xml
What is interesting is that ip tracks back to a SkyHD+ set top box and has nothing to do with plex outside of being on the same network.
Full logs attached below:
(File removed)
Are you sure this started with 1.20.5? That seems like just generic discovery, it finds that devices but then when trying to check for DVR capabilities it fails, because ofc the expected xml wouldnât be there, those only show when Debug is enable too, so there also the chance that Debug logging was not enabled before.
You can totally ignore that in any case, it would only be a real issue if that was in fact a real DVR device.
@mikec_pt I cannot say with any level of certainty it started with 1.20.5 but I regularly review my logs and Iâve never seen this error reported previously.
Debug logging is enabled (think its that way by default), regardless I have disabled debug for now.
Anyhow, thanks â Iâll ignore if I see it into the future.
I see youâre on a Linux box⊠I was seeing this spam my Plex logs recently as well too and starting digging around. I saw this thread, decided if Plex wasnât going to fix it â Iâd stop it myselfâŠ
So I went as far as to block outbound UDP on port 1900 because as far as I am aware I am not using any SSDP-related features of Plex and it kept hitting various Ubiquiti devices on my network for no good reason.
sudo iptables -A OUTPUT -p udp --dport 1900 -j DROP
I mean, no more SSDP spamming but also now your logs get a whole new level of spam 
WARN - NetworkServiceBrowser: Error sending out discover packet from 192.168.30.138 to 239.255.255.250: Operation not permitted
WARN - NetworkServiceBrowser: Error sending out discover packet from 172.19.0.1 to 239.255.255.250: Operation not permitted
I have read dozens of reports regarding this âSSDP: Errorâ and have not found a solution yet. Is there one.
Many people seem to think that reconfiguring non-Plex devices or ever growing logs is acceptable. For me it isnât, for two reasons:
The devices that Plex is complaining about are Sky Q boxes, and I have absolutely no control over how they respond to anything. In no way can I, or should I, change their configuration.
The Plex server is filling its own logfiles and it should be possible to stop it doing so. Why, when it has discovered that one of my other devices isnât going to join in, must it ask it again 30 seconds later. The answer will be the same!
Given the number of posts on this subject, it is now extremely hard to find one that hasnât been automatically closed. Why are they being closed automatically? Can somebody please pick this issue up and fix it once and for all. After all, it is a Plex fault.
Thank you for any attention this gets.
I do have basically the same issueâŠseems my Fire TV Stick is causing this every 30 seconds so it is unecessarly filling up the log, and more over preventing my Synology NAS to go into Sleep Mode for the harddrivesâŠ
Read thousands of threads but could not find a solution eitherâŠ
thanks in advance
No need to become alarmed.
Engineering already released a changed version of PMS which addressed it.
That report is old and âover 2 week old newsâ (the update has been released for at least a week now)
Please stay on topic.
The SSDP messages in the logs are meaningless.
Not all SSDP-responding devices provide their reply in XML. Some use a hybrid form while others use JSON.
Those messages in the logs are:
My Off-Topic comment was in regard to the Plex Media SSDP (PMSSDP) Reflection/Amplification DDoS Attack Mitigation Recommendations link.
It has nothing to do with this thread.
The issue is resolved, published in PMS public version, and therefore moot.
I donât think disabling Enable local network discovery (GDM) prevents the server from sending other types of SSDP requests.
100%. No idea why this thread is being polluted with references to DDoS as its nothing to do with it.
I do have issue with this. Any developer worth their salt should be able to resolve this. I have never enabled DVR so PMS should not even be scanning for a compatible device.
Regardless, if its something that plex feel is important to have in their logs then remove its frequency and/or reclassify from error to warning. Doing a quick search I have this over 900 times and its growing by the minute.
[mcurran@pegasus Logs]$ pwd ; grep âSSDP: Error parsing device schema forâ *.log | wc -l
/var/lib/plexmediaserver/Library/Application Support/Plex Media Server/Logs
933
[mcurran@pegasus Logs]$
There is no pleasing everyone on this.
-or-
Do I wish we could say âIgnore the Denon and Sony PS4â ?
Yeah, that would be nice but how often are people micromanaging their logs?
This has always been there and itâs only now, with the issue that was already resolved before the vast majority even knew it existed, that people are making noise about what is in the DEBUG log files.
As for the âcompetentâ developer comment I saw here somewhere, I am reading the code as I write this. Thereâs already a great deal of UDP / SSDP junk it knows to ignore.
The fact that 1) its a dirty red error when viewed using the plex console (not even a warning a error), 2) its frequency and 3) the fact I donât even have DVR enabled but am getting errors from it leads to (at least) surmising that this can be improved.
How often do folks look at the logs, anyone debugging does and those of us who are admins do very often. I was debugging another problem when I found this and thought initially it was related which it turned out not to be.
Iâve written a request for Engineering to review.
While a double edged sword in many ways, Iâve requested Engineering consider providing the ability to turn them off by linking them to âVerboseâ logging.
If they concur, the messages will only be reported IF and only IF Verbose logging is enabled.
Thank you @ChuckPa and I understand. Lets see what the development team decide is best, thatâs all I ask really.
Hi,
did anybody got already feedback from engineering reviewing this ? I have similar issue with my FireTv 4K stick and even it does not harm it is quite inconvenient as it keeps my NAS staying active 24H/7 and not going into sleep modeâŠ
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.
