Android devices crashing after latest update

Plex Players
, ,
1

Since the new Android update where plex swipes in from the left side, all of my android based plex clients crash as soon as the plex logo comes on, and transitions to the home screen. When I clear cache/data, or reinstall I am able to get to the login prompt and then after logging in the same thing happens.

I can login via the Web and everything works just fine. I don’t have any MAC or IOS devices I am able to test with at the moment.

Server Version#: 1.29.2.6364
Player Version#:9.12.2.36964

Log attached
server_log.txt (5.8 KB)

2

Plexamp loads and works fine.

When I load the android apps, I get to “user select” then the app immediately closes.

I’ve tried this on a Sony TV running android tv, pixel 7 pro, Firestick 4k, firestick non 4k

Had a friend try on his IOS device and Plex worked fine, but when he tried his android device it crashed immediately.

3

I have the same issue.
Same versions.

4

plex-android-logs.txt (31.7 KB)

My friend got those logs from his android tablet when launching the app and having the crash.

Last error:

12-07 20:02:05.656  e: Stacktrace: java.lang.NullPointerException: Attempt to invoke interface method 'java.util.Iterator java.util.List.iterator()' on a null object reference
  at hm.i.q(SourceFile:37)
  at hm.i.o(SourceFile:14)
  at ik.i$b.invokeSuspend(SourceFile:50)
  at kotlin.coroutines.jvm.internal.a.resumeWith(SourceFile:12)
  at kotlinx.coroutines.b1.run(SourceFile:119)
  at kotlinx.coroutines.internal.n.run(SourceFile:13)
  at kotlinx.coroutines.scheduling.k.run(SourceFile:3)
  at kotlinx.coroutines.scheduling.a.k(SourceFile:1)
  at kotlinx.coroutines.scheduling.a$c.d(SourceFile:15)
  at kotlinx.coroutines.scheduling.a$c.n(SourceFile:29)
  at kotlinx.coroutines.scheduling.a$c.run(Unknown Source:0)
  Suppressed: kotlinx.coroutines.z0: [x2{Cancelling}@58c4a8d, Dispatchers.IO]
5

I think I fixed the issues I was having. My issue appears to be DNS related. I have two DNS servers setup on the DHCP scope for these clients, one internal and one external. The internal server has an A record with an RFC1918 address pointing the internal reverse proxy. I noticed that the clients were using the external DNS server to resolve the hostname (instead of the primary internal), and sending traffic to the cloudflare reverse proxy address. Removing the external DNS server from the DHCP scope solved the issue.