Plugins Catalog spinning wheel

[skm94 1]

I just installed Emby on a Debian 12 server and upgraded to Premiere, so I'm trying out all of the features. When I go to "Plugins" and choose "Catalog", I get a spinning wheel icon.  I left it overnight to see if it timed out or eventually worked, but 8 hours later, it was still spinning.

On two occasions, it did show the catalog but as soon as I chose a Plugin to install, the spinning wheel started.  Restarting the server did not help.

When I look in the "embyserver.txt" log file, it has no new entries in the past 8+ hours,  I don't see an option for deeper reporting other than the "Enable debug" (which I did but with no additional entries being added).

I have this issue whether I am accessing through a browser on Windows or Linux. I also tried three different browsers - Brave,  Firefox, and Opera - and had the same issue.  Note that Opera did actually show the catalog one time, after several minutes of spinning, but the other two could sit for hours and never show it.

Any suggestions on where to look for the issue?

[Luke 37119]

Hi there, please attach the emby server log from when the problem occurred:

How to Report a Problem

Thanks.

[skm94 1]

I retried opening the Catalog about 5 minutes before puling the attached log file.  I looked at the log, but not really knowing what 'keywords' to seek, I gave up for now.  Certainly lots of stuff in it!

embyserver.txt

[Luke 37119]

HI, something is blocking all of your server's outgoing connections, not just including the plugin catalog but also metadata providers, checking for server updates, etc.

Typical causes of this are firewall, security software or VPN. Can you look into those and let us know what you find? Thanks.

[skm94 1]

Are you referring to lines such as this in the logs:

2023-12-20 14:53:18.488 Error HttpClient: Connection to https://www.mb3admin.com/admin/service/EmbyPackages.json timed out

2023-12-20 14:53:18.492 Error Server: Error processing request

I tried the Plugins|Catalog again (which failed) and found that message near the end of the logs, Oddly, when I copy the URL from the error message and paste it into my browser, the page (JSON text) appears immediately.  I tried a few other URLs in the error messages and all worked fine.  It seems the issue happens with outgoing requests issued programmatically from Emby as I have not experienced any connection errors or time-outs with any other outbound traffic, whether it be html, email, ssh, and even Plex (which I watch remotely on the road - for now).

I will look though all of my network settings and your suggestions, but on the surface, there must be something "different" between me just typing the address into a browser and Emby doing it programmatically.

[Luke 37119]

Right that means you can reach the url but something is blocking the server process from reaching it. Again typical causes are firewall, security software or VPN.

[skm94 1]

I think I've found a culprit but not a reason.  I finally turned to Wireshark to see if it would show why https requests from Emby fail yet the same address pasted in a browser works just fine.  And it did...sort of.

It appears Emby is making the request using IP6 while the browser uses IP4. 

I attached the pertinent Wireshark output in a text file.  I first tried to open the Plugins catalog in Emby while WS captured the packets. Wireshark shows a DNS request for mb3admin.com, followed by two responses: one with an IP4 address and one with IP6.  Immediately after, there is a request sent to the IP6 address of mb3admin.com. Several packets later (with no reply having been received), there is a retransmit packet.  This repeats several more times.

Below that in my text doc is the capture from when I plugged mb3admin.com into my browser.  It did not do a DNS request as I assume the addresses were still cached.  Almost immediately after a packet is sent to the IP4 address, a packet of "Application data" is returned.

I'm not sure why the IP6 is not working as it looks enabled on both of my routers.  I've not had any other issues, though very few places actually are using IP6.

So, is there a way to force Emby to use IP4 protocols in making its Internet requests?

wireshark-out.txt

[Luke 37119]

Quote

I'm not sure why the IP6 is not working as it looks enabled on both of my routers.  I've not had any other issues, though very few places actually are using IP6.

So, is there a way to force Emby to use IP4 protocols in making its Internet requests?

@skm94Hi, Emby doesn't make any decisions related to this. We contact the domain name, and the underlying platform handles the network transport for us.

What you could do for now is disable ipv6 in your router altogether and that should do it.

[skm94 1]

Luke, Thanks for the reply and your answer was actually what I expected. I've done a little network programming and don't recall ever specifying the protocol to use, but thought maybe there was a optional parm to do so. Would seem a silly thing for a program to do, though.

Your suggestion of disabling IPv6 (I did it on the Linux server rather than the router) worked perfectly.  At least on a few quick tests, and reviews of the logs, it looks much better. Headsmack to myself for not thinking of it.

At some future time, I may try to determine how Linux decides which protocol to use.  I remain baffled as to why a URL request from my browser used IPv4, while the same URL from Emby was sent using IPv6, and why it did not fall back to IPv4 when v6 timed out. Concerns for another day.

Thanks for all of your suggestions and help.  Happy New Year!

[Luke 37119]

HI, let us know what you find. Thanks.