Server crashes when connecting with Android client app

[jnk 0]

Hello everyone,

 

I have a weird problem when using Android Emby clients.

 

Every time I open up the Emby app on any Android phone (tried this with 4 different smart phones and a Fire HD 10 tablet), the server just crashes after a few seconds.

When doing the exact same thing on my iPhone 7 everything works perfectly fine, no errors or anything.

 

Maybe you can see something in the log that I couldn't find?

server-63656998508.txt

Edited March 19, 2018 by jnk

[Luke 42078]

Hi, what exactly do you mean by server crashing?

[jnk 0]

The Emby server (not the whole server PC) just stops and I can not access it from any other client or from my web browser anymore.

 

"sudo service emby-server status" shows that the process is dead, so after it crashed I have to manually start it again by typing "sudo service emby-server start".

[Luke 42078]

@@jnk is this still happening?

[jnk 0]

Yes, still the same :/

 

This is the status error message I am getting right after it crashed:

● emby-server.service - Emby Server is a personal media server with apps on just about every device.
   Loaded: loaded (/usr/lib/systemd/system/emby-server.service; enabled; vendor preset: enabled)
   Active: failed (Result: signal) since Thu 2018-03-22 16:18:03 CET; 1s ago
  Process: 21620 ExecStart=/opt/emby-server/bin/emby-server (code=killed, signal=ILL)
 Main PID: 21620 (code=killed, signal=ILL)

Mar 22 16:17:38 server emby-server[21620]: Info App: Sqlite version: 3.21.0
Mar 22 16:17:38 server emby-server[21620]: Info App: Sqlite compiler options: COMPILER=gcc-6.3.0,ENABLE_COLUMN_METADATA,ENABLE_DBSTAT_VTAB,ENABLE_FTS3,ENABLE_FTS3_PARENTHESIS,ENABLE_FTS3_TOKENIZER,ENABLE_FTS5,ENABLE_JSON1,ENABLE_PREUPDAT
Mar 22 16:17:38 server emby-server[21620]: Info App: Default journal_mode for /var/lib/emby/data/sync14.db is wal
Mar 22 16:17:38 server emby-server[21620]: Info App: PRAGMA synchronous=1
Mar 22 16:17:38 server emby-server[21620]: Info App: Entry point completed: Emby.Server.Sync.SyncManagerEntryPoint. Duration: 0.0070897 seconds
Mar 22 16:17:38 server emby-server[21620]: Info App: Starting entry point Emby.Server.Sync.SyncNotificationEntryPoint
Mar 22 16:17:38 server emby-server[21620]: Info LibraryMonitor: Watching directory /mnt/disk2/videos
Mar 22 16:18:03 server systemd[1]: emby-server.service: Main process exited, code=killed, status=4/ILL
Mar 22 16:18:03 server systemd[1]: emby-server.service: Unit entered failed state.
Mar 22 16:18:03 server systemd[1]: emby-server.service: Failed with result 'signal'.

[Luke 42078]

is this running on system startup or did you start manually?

[jnk 0]

I tried it again with the new Beta version 3.3.1.14 today, same problem still happening :/

 

I haven't changed anything about the startup behavior of Emby. So the server either starts when the system (Ubuntu) has started as well, or with a manual command "service emby-server start". Both ways lead to the same outcome.

 

I guess there must have gone something wrong (maybe with the user profiles or watched states?) when backing up the server using the (old) repo installation method to the new dpkg-installation method.

 

If there is no other chance of resolving this I'll try setting up the server without importing any user profiles/watched states.

[Luke 42078]

I'm not sure this will make a difference, but as a test can you try disabling the realtime monitor for each of your libraries? thanks.

[jnk 0]

I'm not sure this will make a difference, but as a test can you try disabling the realtime monitor for each of your libraries? thanks.

 

Nope, did not help :/

 

 

I also tried reinstalling the Emby server without importing any users or watchstates or anything. Same error keeps happening.

 

I have attached 2 new log files, both show the same error message. (one with active library watching, the other one after turning it off)

embyserver-63658881055.txt

embyserver-63658881258.txt

[jnk 0]

I have done some more testing and started with a fresh install of Emby without importing anything from before. (so no specific settings, plugins, etc.)

 

I only created some new users (with and without Emby Connect), but as soon as I open up Emby on an Android device, it takes a few seconds and the server will get shut down.

 

 

Most of the logs (or maybe all of them?) end with this line:

2018-04-09 16:24:34.878 Info HttpServer: HTTP GET http://192.168.0.10:8096/emby/System/WakeOnLanInfo. UserAgent: Mozilla/5.0 (Linux; Android 5.1.1; KFSUWI Build/LVY48F; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/59.0.3071.125 Safari/537.36

[Luke 42078]

Yea I noticed that before. It's crashing when we query the network adapters to try and get the mac addresses. The problem is that it's crashing in a way we can't catch and handle.

 

You're saying this is on a computer?

[jnk 0]

Yes, with some normal desktop hardware:

- Gigabyte GA-H270-HD3

- Intel Pentium G4620

 

System:

- Ubuntu 16.04.4 LTS (GNU/Linux 4.4.0-112-generic x86_64)

 

There are some other applications running on it as well, like nginx, Tvheadend, CUPS, MariaDB and so on.

[Luke 42078]

Any odd network setup that is worth mentioning?

[jnk 0]

I don't think so.

 

nginx is running as my webserver, but without any SSL or any other settings and only on port 80 and 8080.

 

There is also Pi-hole running as my ad blocker in my network, but I have checked multiple times and nothing seems to get blocked by it regarding my Emby server.

 

Then there is also my OpenVPN server, but no weird configuration there as well.

 

My switch is a Netgear GS716Tv3, but nothing special there. No VLAN settings or anything, just basic switching functionality set up.

[Luke 42078]

Ok, please try again with the next release, thanks.

[jnk 0]

Hey Luke, just wanted to give some feedback on this problem.

 

It all seems to be solved with the new version 3.5.0.0 that was released yesterday.

 

So far I have logged in from 3 different Android clients, and no more crashes!

 

 

Do you happen to know what exactly fixed this or was it due to some various other updates you implemented for this release?

Either way, it's great to see this working again. Thanks a lot!!

[Luke 42078]

There's just a lot of stability related improvements in 3.5 so although I didn't know for sure that this would be resolved, i had a feeling. Much of the stability improvements come from the update to the .NET Core runtime.