Need to restart Serviio server for LG Roku to see DLNA sourc
I've seen similar sounding questions but the last one from a couple years ago so wanted to post this one specifically.
This started happening within the last few weeks, I've been using Serviio for at least 5 years and everything about transcoding etc works great.
Using the Roku Media Player app, Serviio isn't seen until I stop/start the server from the console page. I don't need to stop the windows service, just bounce the server from the console. As soon as I do, Serviio appears in the player app as a source. I'm also running windows media sharing and that one always shows up as a source.
No firmware updates or config changes on my home router/wireless access point recently that I can recall, nothing fancy about my LAN like subnets or routing rules, all pretty vanilla. No changes to windows firewall or anything like that. I'm guessing it's something on the PC where Serviio is running because of the log entry below.
I do see this in the log about the time I bounced the server last night which seems like it might be relevant and it happened on July 24, 28, 29th but only once per day:
2026-07-30T19:49:58,855 WARN [DiscoverySearchResponder] Problem during DiscoverySearchResponder, response will not be sent
java.net.SocketException: Invalid argument: Datagram send failed
at java.net.TwoStacksPlainDatagramSocketImpl.send(Native Method) ~[?:1.8.0_492]
at java.net.DatagramSocket.send(DatagramSocket.java:693) ~[?:1.8.0_492]
at org.serviio.util.MultiCastUtils.send(MultiCastUtils.java:109) ~[serviio.jar:?]
at org.serviio.upnp.discovery.DiscoverySearchResponder.sendReply(DiscoverySearchResponder.java:124) ~[serviio.jar:?]
at org.serviio.upnp.discovery.DiscoverySearchResponder.run(DiscoverySearchResponder.java:96) ~[serviio.jar:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) ~[?:1.8.0_492]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) ~[?:1.8.0_492]
at java.lang.Thread.run(Thread.java:750) ~[?:1.8.0_492]
This entry first appeared Feb 2026 twice, then again once in March, once in April so not very frequently originally (my current set of logs started December 2025). Now it's happening more frequetly as above.
This started happening within the last few weeks, I've been using Serviio for at least 5 years and everything about transcoding etc works great.
Using the Roku Media Player app, Serviio isn't seen until I stop/start the server from the console page. I don't need to stop the windows service, just bounce the server from the console. As soon as I do, Serviio appears in the player app as a source. I'm also running windows media sharing and that one always shows up as a source.
No firmware updates or config changes on my home router/wireless access point recently that I can recall, nothing fancy about my LAN like subnets or routing rules, all pretty vanilla. No changes to windows firewall or anything like that. I'm guessing it's something on the PC where Serviio is running because of the log entry below.
I do see this in the log about the time I bounced the server last night which seems like it might be relevant and it happened on July 24, 28, 29th but only once per day:
2026-07-30T19:49:58,855 WARN [DiscoverySearchResponder] Problem during DiscoverySearchResponder, response will not be sent
java.net.SocketException: Invalid argument: Datagram send failed
at java.net.TwoStacksPlainDatagramSocketImpl.send(Native Method) ~[?:1.8.0_492]
at java.net.DatagramSocket.send(DatagramSocket.java:693) ~[?:1.8.0_492]
at org.serviio.util.MultiCastUtils.send(MultiCastUtils.java:109) ~[serviio.jar:?]
at org.serviio.upnp.discovery.DiscoverySearchResponder.sendReply(DiscoverySearchResponder.java:124) ~[serviio.jar:?]
at org.serviio.upnp.discovery.DiscoverySearchResponder.run(DiscoverySearchResponder.java:96) ~[serviio.jar:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) ~[?:1.8.0_492]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) ~[?:1.8.0_492]
at java.lang.Thread.run(Thread.java:750) ~[?:1.8.0_492]
This entry first appeared Feb 2026 twice, then again once in March, once in April so not very frequently originally (my current set of logs started December 2025). Now it's happening more frequetly as above.
