slow webfrontend

[hanschke 1]

i use 

• My Cloud EX2 Ultra

with plex in the past and it is very fast. I can login fast or correct my prefs but with emby os5_4.8.8.0_arm.bin or os5_4.9.0.30_arm.bin the webfront end is very slow and I dont know why? I only want to login and want to go to the m3u settings and after 10 minutes the login is not ready of the reaction of I try to open different settings is very slow.

I want to change my system to emby because of the addons and bought premium but at the moment I dont know why I cannot use it like the the webfront end like plex or my router or nas fast and easy?

[Luke 38096]

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

How to Report a Problem

Thanks !

[hanschke 1]

better 

embyserver.txt embyserver-63861954970.txt embyserver-63862041288.txt embyserver-63862127606.txt

[sa2000 144]

20 hours ago, hanschke said:

I only want to login and want to go to the m3u settings and after 10 minutes the login is not ready of the reaction of I try to open different settings is very slow.

Could you enable debug logging in server settings for logs and restart the server and when this delay happens - take a screenshot and note down the time and then provide that together with the logs covering this period

debug logging may give us some clues. The logs you provided show lots of upnp related errors but apart from initial errors relating to port 1900, the other errors are only every 10 minutes so should not affect the performance. 

The logs show the network / internet access was down at 2024-09-16 04:30 am

And from 2024-09-16 15:06:11 to 15:06:13 there were errors sending ssdp/udp packets to "239.255.255.250:1900" with error "Network is unreachable" with about 20 errors a second 

There were further network related errors later - at 2024-09-16 15:06:47 with "Error querying network interface"

After that there were periodically logged erorrs (every 10 minutes for failing to auto map port for remote access)

 

 

[hanschke 1]

I want to do it but after trying to login again the login website dont apear and with plex all work fine and I dont have a network error.

[sa2000 144]

12 minutes ago, hanschke said:

 after trying to login again the login website dont apear

Which login website ? Is the emby user account on the server linked to an Emby Connect user account?

Is this the local IP Address of the Emby Server NAS ? 192.168.178.22

Is it a fixed IP address/DHCP Reserved? Could you ensure it is

If it is the IP address, what happens when you put this in a browser on a PC on the same local network ? "http://192.168.178.22:8096/web" 

With the server shutdown, you could enable debug logging by editing the following file with a text editor:

/mnt/HD/HD_a2/emby/config/system.xml

and ensuring this line exists

<EnableDebugLevelLogging>true</EnableDebugLevelLogging>

If there is a line already for "EnableDebugLevelLogging" - change it so that it has "true" value as above

 

[hanschke 1]

http://192.168.178.xx:8096/web/index.html#!/logs my url but instead of xx the correct local ip.

embyserver.txt embyserver-63862173195.txt embyserver-63862214406.txt

[sa2000 144]

Thank you for the logs. What time was the slow to respond to opening emby web page ? Is that the issue ? http://ip-of-server:8096/web slow to open up?

The last set of logs cover period from launch of server at 12:34 on the 17th to 11:18 am on the 18th

By the way local ip addresses are ok to be known / shared.

[sa2000 144]

I see a lot of slow DB queries in the emby server log

This relates to the library.db file in this path /mnt/HD/HD_a2/emby/data/library.db

This log analysis shows the slow queries that were logged

If the problem does relate to db performance, you could do an optimize by running a vacuum. See server settings in Emby Web. Have a look at Scheduled Tasks Vacuum Database entry. You can run it more often than the default by deleting the current trigger and adding a trigger to run it more frequently

Also you can look at Server Settings for the Database and run a vacuum at next restart to see if it improves performance on subsequent launch and use

The other thing to check is the health of the disk drives that relate to mnt/HD/HD_a2/

When you give me the time when the issue was noticable to you, I can then look at the log for that time

 

[sa2000 144]

Ah !!! It is the vacuuming on launch that is taking a long time for the server to start responding 

2024-09-17 12:34:31.057 Info SqliteItemRepository: Result of setting SQLITE_DBCONFIG_DQS_DDL to 0 is 0
2024-09-17 12:34:31.057 Info SqliteItemRepository: Result of setting SQLITE_DBCONFIG_DQS_DML to 0 is 0
2024-09-17 12:47:22.766 Info App: Completed vacumming SqliteItemRepository after 771709ms

So server was busy vacuuming the database for 13 minutes

Check your trigger in Scheduled Tasks for Vacuum Database

 

Interesting that despite the vacuum being run, the db access was slow at times. 

 

Edited September 18 by sa2000

[Luke 38096]

On 9/18/2024 at 6:49 AM, sa2000 said:

Ah !!! It is the vacuuming on launch that is taking a long time for the server to start responding 

2024-09-17 12:34:31.057 Info SqliteItemRepository: Result of setting SQLITE_DBCONFIG_DQS_DDL to 0 is 0
2024-09-17 12:34:31.057 Info SqliteItemRepository: Result of setting SQLITE_DBCONFIG_DQS_DML to 0 is 0
2024-09-17 12:47:22.766 Info App: Completed vacumming SqliteItemRepository after 771709ms

So server was busy vacuuming the database for 13 minutes

Check your trigger in Scheduled Tasks for Vacuum Database

 

Interesting that despite the vacuum being run, the db access was slow at times. 

 

If you vacuum again, does it take that long again?

[Carlo 4354]

@hanschkeHi,

Did you get a chance to try what Luke asked?

Carlo