barnopss 7 Posted July 31, 2023 Posted July 31, 2023 (edited) Every time I launch Emby on my TV (Android TV 9) it gets stuck at the spinning wheel unless I Clear Data from the app. Then it picks up my server and lets me log in. As a test, I shut down my Emby server and booted a test one. This issue went away. It always signed in to the app as expected and worked first try. Booted my server back up and the issue came back. Server: Windows server 2019 1809 Emby server: 4.7.13.0 Server logs: embyserver.txt Edited July 31, 2023 by barnopss
Abobader 3470 Posted July 31, 2023 Posted July 31, 2023 Hello barnopss, ** This is an auto reply ** Please wait for someone from staff support or our members to reply to you. It's recommended to provide more info, as it explain in this thread: Thank you. Emby Team
Luke 42083 Posted July 31, 2023 Posted July 31, 2023 Hi, something on your network is hammering your emby server with repeated requests: 2023-07-31 03:42:44.272 Info Server: http/1.0 HEAD http:///. UserAgent: 2023-07-31 03:42:44.272 Info Server: http/1.0 Response 302 to 192.168.1.1. Time: 0ms. http:/// I would suggest trying to determine what that is and shutting it down. Then restart emby server and see how things compare.
barnopss 7 Posted July 31, 2023 Author Posted July 31, 2023 I believe that is just HAProxy checking uptime. I disabled the check and am going to test.
barnopss 7 Posted July 31, 2023 Author Posted July 31, 2023 Ok, disabled. Tested. Same behavior. Data clear on the Emby Android app lets me log in. If I quit then open it again, it spins. 2nd emby server does not exhibit this behavior. Logs from the offending server. I quit the server to start a new log before my test. Then quit after I was done. So this should only include the test. The test includes opening the app. Testing playback of a movie for a few seconds. Closing the app. Opening it again (which resulted in the spinning wheel). Thanks! embyserver-63826413158.txt
Solution rbjtech 5284 Posted August 1, 2023 Solution Posted August 1, 2023 Maybe try and force a single binding for emby for 192.168.1.67 (the IP address of the server). Force that under Network > Local IP Address' Then restart emby. It may also be worth entering in your LAN's in the field above - but leave that blank for the moment.
Luke 42083 Posted August 1, 2023 Posted August 1, 2023 That's a good point. Does your server machine ip address change regularly?
barnopss 7 Posted August 3, 2023 Author Posted August 3, 2023 On 8/1/2023 at 11:00 AM, rbjtech said: Maybe try and force a single binding for emby for 192.168.1.67 (the IP address of the server). Force that under Network > Local IP Address' Then restart emby. It may also be worth entering in your LAN's in the field above - but leave that blank for the moment. Hi! The IP is static (I have a reservation for the machine). But I will also alter the setting in Emby. Updated. Also my LAN IP's were already added above: 192.168.0.0/16 (I use a /16 bc I have multiple subnets that access it), 172.27.153.218/16
barnopss 7 Posted August 3, 2023 Author Posted August 3, 2023 On 8/1/2023 at 3:41 PM, Luke said: That's a good point. Does your server machine ip address change regularly? It does not. It has a static reservation and is always 192.168.1.67
rbjtech 5284 Posted August 3, 2023 Posted August 3, 2023 (edited) 32 minutes ago, barnopss said: Hi! The IP is static (I have a reservation for the machine). But I will also alter the setting in Emby. Updated. Also my LAN IP's were already added above: 192.168.0.0/16 (I use a /16 bc I have multiple subnets that access it), 172.27.153.218/16 I was referring to binding emby to just that IP, leaving it blank will bind all interfaces. In my system, I have 3 or 4 interfaces, so I bind it to just one that I want emby to use. The 'Lan networks' field above is just used to dictate what is considered a 'local' network for bandwidth restrictions within emby - it will have no impact on the actual binding. I would also delete all the App saved 'connections' (in the App itself) and re-try once you have made the changes above. The 'broadcast' used for detection (UDP) will then only be answered on the 192.168.0.0/16 subnet. (also worth checking your subnet mask..) Edited August 3, 2023 by rbjtech
barnopss 7 Posted August 7, 2023 Author Posted August 7, 2023 So for whatever reason, binding it to the primary IP worked! Thank you all for your help!!! 1 1
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now