Download failing to iOS/iPadOS - 8.16->8.17 regression

Updated to the latest version of the app: the issue persists. Downloading on cellular or using Infuse still works.

My setup (hardware/network) has been the same for over a year. Downloads always worked (a rarity I know). It’s solely the app update that broke it.

Sadly I’ve been seeing the same issue, just another issue with downloads, the only feature I have a plex pass for, yet doesn’t work reliably at all.

Can we please get clarity on what version of the iOS app (and Plex server?) this is fixed in? It’s definitely regressed for me, but some people say that it’s fixed?

I really do want to advocate for a set of stronger test bench cases and regression testing on the part of the Plex team for downloads. It’s a multi-year poop-show of difficulties and workarounds for so many, seeing regressions like this is just plain painful.

If you need debug files let me know. Still an issue for me, however re-starting the app on iPadOS get’s downloads moving again. Would be nice to not have a two step process soon (ie not to step downloads, force quit the app and re-launch).

Can we expect this bug fixed pls ? or at least an idea of a date ?

It’s a premium feature which doesn’t work for 3 weeks now !!!

I have the same problem. When will there be a solution to the problem?

Plex management please pay attention, downloads needs some love (as did sync before it), many of us are still having this latest issue and no one really seems to care about basic user functionality.

At what point do I just give up, it’s been years coming and all I want is reliable offline viewing for some files for when I travel.

Server Version: 1.32.0.6973
Player Version: 8.18
Player Details: iPadOS 16.4.1 (a)

2023/05/03 13:56:49.791 (495 MB) (446240) :x: PMKLogging.m:14 | Download failed: Data transfer failed (The certificate for this server is invalid. You might be connecting to a server that is pretending to be “101.176.28.191” which could put your confidential information at risk.).

2023/05/03 13:56:49.851 (495 MB) (447730) :x: PMKLogging.m:14 | Download failed: Data transfer failed (The certificate for this server is invalid. You might be connecting to a server that is pretending to be “101.176.28.191” which could put your confidential information at risk.).

I deleted app and reinstalled. Downloads stated working again. V8.18

I also deleted the app last week, sadly didn’t clear the issue.

Please Plex can you put some focus into this issue and provide some feed-back, the response so far hasn’t been appropriate.

Deleting and reinstalling did nothing. Still broken.

Any help? i am getting same error… Tomorrow i wil take a flight and it will be a nightmare without plex

Folks.

In the one log excerpt above, I see certificate errors.

Looking at that particular account, there’s no reason for it other than a complete mash-up of what’s on the server, what’s on Plex.tvv, and what the app pulls.

I can reset the server’s certicate.

This, in conjunction with Stopping PMS, deleting the local cert, Starting PMS, allowing it to pull a new cert THEN force kill and start apps fresh will clear the certificate issues.

I can’t do anything about the 250 Mbps download speed. (Plex/web is so much faster)

@ChuckPa wonderful you have taken the time to solve one particular problem for 1 guy , but no comments for all other members

are you sleeping ? do you think you can continu to be blind ? for me , i finish my year pass and bye bye ! i pay for features but for support too

i was very surprised to see that it’s impossible to open a ticket for members of plex pass but i was thinking the issue will have a solution, or a beginning of an explanantion 1 month after

but OK that’s business, iwill just leave that soon

Resetting the cert didn’t fix it for me. Also, as part of my troubleshooting (noted above), I used the same server with my wife’s iPad while it was still running 8.16. If it was just the server’s cert, hers would have failed too. Once her iPad auto updated its app to 8.17, it started failing with the same error messages.

With the widespread reports of this and the fact that a total app uninstall/reinstall along with setting up a new server still results in the error, I am surprised it is not easy to repro. The only thing I can think of is the people that have this working are going through the plex relay for some other config reason. All my iOS (and iPadOS) devices will sync when off network, either on my guest network our outside the house.

Dan

Same Problem on my Server…

I am one person, part time at that, doing what he can.
I have primary duties in the Linux forum and Synology forum.

I am NOT an app developer. I am a system/server engineer.

I support synology because I’m the guy who wrote the packaging and know how PMS works on Synology (I designed and wrote that)

I’m sorry if I’m not serving to your expectations.

PS: I retired 10 years ago and yes, I do sleep

1 Like

ALL:

I am using 8.18.

Give me a few minutes and I will show where I’m at in my investigation.

1 Like

Hi, just to confirm i have the exact same issues. i can download perfectly to my Mac, my windows PC, but NOT to my iphone or ipad running 8.18… but my older ipad on 8.16 still can download

in the PMS logs “CERT: incomplete TLS handshake”

(also - thanks for your help ChuckPa)

In the PMS logs:

  1. Turn off IPv6 if you don’t need it and it’s enabled. It’s a PMS bug .
    It’s harmless and shouldn’t even be printed.

I have it turned off.

Downloading to the ipad is clean.

8, 2023 17:02:01.935 [140283466713912] DEBUG - Request: [192.168.0.13:43276 (Subnet)] GET /statistics/bandwidth?timespan=6 (9 live) #2a7e TLS GZIP Signed-in Token (ChuckPA) (Chrome)
May 08, 2023 17:02:01.938 [140283736800056] DEBUG - Completed: [192.168.0.13:43276] 200 GET /statistics/bandwidth?timespan=6 (9 live) #2a7e TLS GZIP 2ms 1469 bytes (pipelined: 31)
May 08, 2023 17:02:02.943 [140283468823352] DEBUG - Request: [192.168.0.13:43276 (Subnet)] GET /statistics/bandwidth?timespan=6 (9 live) #2a80 TLS GZIP Signed-in Token (ChuckPA) (Chrome)
May 08, 2023 17:02:02.946 [140283736800056] DEBUG - Completed: [192.168.0.13:43276] 200 GET /statistics/bandwidth?timespan=6 (9 live) #2a80 TLS GZIP 2ms 1476 bytes (pipelined: 32)
May 08, 2023 17:02:03.844 [140283462495032] DEBUG - Request: [192.168.0.13:43276 (Subnet)] GET /statistics/resources?timespan=6 (9 live) #2a81 TLS GZIP Signed-in Token (ChuckPA) (Chrome)
May 08, 2023 17:02:03.846 [140283734690616] DEBUG - Completed: [192.168.0.13:43276] 200 GET /statistics/resources?timespan=6 (9 live) #2a81 TLS GZIP 1ms 822 bytes (pipelined: 33)
May 08, 2023 17:02:03.946 [140283468823352] DEBUG - Request: [192.168.0.13:43276 (Subnet)] GET /statistics/bandwidth?timespan=6 (9 live) #2a82 TLS GZIP Signed-in Token (ChuckPA) (Chrome)
May 08, 2023 17:02:03.948 [140283734690616] DEBUG - Completed: [192.168.0.13:43276] 200 GET /statistics/bandwidth?timespan=6 (9 live) #2a82 TLS GZIP 2ms 1381 bytes (pipelined: 34)
May 08, 2023 17:02:04.956 [140283462495032] DEBUG - Request: [192.168.0.13:43276 (Subnet)] GET /statistics/bandwidth?timespan=6 (9 live) #2a83 TLS GZIP Signed-in Token (ChuckPA) (Chrome)
May 08, 2023 17:02:04.959 [140283736800056] DEBUG - Completed: [192.168.0.13:43276] 200 GET /statistics/bandwidth?timespan=6 (9 live) #2a83 TLS GZIP 2ms 1383 bytes (pipelined: 35)
May 08, 2023 17:02:05.962 [140283690195768] DEBUG - Request: [192.168.0.13:43276 (Subnet)] GET /statistics/bandwidth?timespan=6 (9 live) #2a84 TLS GZIP Signed-in Token (ChuckPA) (Chrome)
May 08, 2023 17:02:05.964 [140283734690616] DEBUG - Completed: [192.168.0.13:43276] 200 GET /statistics/bandwidth?timespan=6 (9 live) #2a84 TLS GZIP 2ms 1394 bytes (pipelined: 36)
May 08, 2023 17:02:06.963 [140283690195768] DEBUG - Request: [192.168.0.13:43276 (Subnet)] GET /statistics/bandwidth?timespan=6 (8 live) #2a85 TLS GZIP Signed-in Token (ChuckPA) (Chrome)
May 08, 2023 17:02:06.965 [140283734690616] DEBUG - Completed: [192.168.0.13:43276] 200 GET /statistics/bandwidth?timespan=6 (8 live) #2a85 TLS GZIP 2ms 1405 bytes (pipelined: 37)
May 08, 2023 17:02:07.965 [140283690195768] DEBUG - Request: [192.168.0.13:43276 (Subnet)] GET /statistics/bandwidth?timespan=6 (8 live) #2a87 TLS GZIP Signed-in Token (ChuckPA) (Chrome)
May 08, 2023 17:02:07.967 [140283734690616] DEBUG - Completed: [192.168.0.13:43276] 200 GET /statistics/bandwidth?timespan=6 (8 live) #2a87 TLS GZIP 2ms 1409 bytes (pipelined: 38)
May 08, 2023 17:02:08.843 [140283466713912] DEBUG - Request: [192.168.0.13:43276 (Subnet)] GET /statistics/resources?timespan=6 (8 live) #2a88 TLS GZIP Signed-in Token (ChuckPA) (Chrome)
May 08, 2023 17:02:08.845 [140283734690616] DEBUG - Completed: [192.168.0.13:43276] 200 GET /statistics/resources?timespan=6 (8 live) #2a88 TLS GZIP 1ms 826 bytes (pipelined: 39)
May 08, 2023 17:02:08.965 [140283690195768] DEBUG - Request: [192.168.0.13:43276 (Subnet)] GET /statistics/bandwidth?timespan=6 (8 live) #2a89 TLS GZIP Signed-in Token (ChuckPA) (Chrome)
May 08, 2023 17:02:08.968 [140283736800056] DEBUG - Completed: [192.168.0.13:43276] 200 GET /statistics/bandwidth?timespan=6 (8 live) #2a89 TLS GZIP 2ms 1422 bytes (pipelined: 40)
May 08, 2023 17:02:09.972 [140283466713912] DEBUG - Request: [192.168.0.13:43276 (Subnet)] GET /statistics/bandwidth?timespan=6 (8 live) #2a8a TLS GZIP Signed-in Token (ChuckPA) (Chrome)
May 08, 2023 17:02:09.975 [140283734690616] DEBUG - Completed: [192.168.0.13:43276] 200 GET /statistics/bandwidth?timespan=6 (8 live) #2a8a TLS GZIP 2ms 1422 bytes (pipelined: 41)
May 08, 2023 17:02:10.981 [140283468823352] DEBUG - Request: [192.168.0.13:43276 (Subnet)] GET /statistics/bandwidth?timespan=6 (8 live) #2a8b TLS GZIP Signed-in Token (ChuckPA) (Chrome)
May 08, 2023 17:02:10.984 [140283736800056] DEBUG - Completed: [192.168.0.13:43276] 200 GET /statistics/bandwidth?timespan=6 (8 live) #2a8b TLS GZIP 2ms 1432 bytes (pipelined: 42)
May 08, 2023 17:02:11.986 [140283462495032] DEBUG - Request: [192.168.0.13:43276 (Subnet)] GET /statistics/bandwidth?timespan=6 (7 live) #2a8c TLS GZIP Signed-in Token (ChuckPA) (Chrome)
May 08, 2023 17:02:11.989 [140283734690616] DEBUG - Completed: [192.168.0.13:43276] 200 GET /statistics/bandwidth?timespan=6 (7 live) #2a8c TLS GZIP 2ms 1441 bytes (pipelined: 43)
May 08, 2023 17:02:12.991 [140283690195768] DEBUG - Request: [192.168.0.13:43276 (Subnet)] GET /statistics/bandwidth?timespan=6 (7 live) #2a8e TLS GZIP Signed-in Token (ChuckPA) (Chrome)
May 08, 2023 17:02:12.994 [140283736800056] DEBUG - Completed: [192.168.0.13:43276] 200 GET /statistics/bandwidth?timespan=6 (7 live) #2a8e TLS GZIP 2ms 1445 bytes (pipelined: 44)
May 08, 2023 17:02:13.852 [140283466713912] DEBUG - Request: [192.168.0.13:43276 (Subnet)] GET /statistics/resources?timespan=6 (7 live) #2a8f TLS GZIP Signed-in Token (ChuckPA) (Chrome)
May 08, 2023 17:02:13.854 [140283734690616] DEBUG - Completed: [192.168.0.13:43276] 200 GET /statistics/resources?timespan=6 (7 live) #2a8f TLS GZIP 1ms 834 bytes (pipelined: 45)
May 08, 2023 17:02:13.997 [140283466713912] DEBUG - Request: [192.168.0.13:43276 (Subnet)] GET /statistics/bandwidth?timespan=6 (7 live) #2a90 TLS GZIP Signed-in Token (ChuckPA) (Chrome)
May 08, 2023 17:02:14.000 [140283736800056] DEBUG - Completed: [192.168.0.13:43276] 200 GET /statistics/bandwidth?timespan=6 (7 live) #2a90 TLS GZIP 2ms 1463 bytes (pipelined: 46)
May 08, 2023 17:02:15.003 [140283468823352] DEBUG - Request: [192.168.0.13:43276 (Subnet)] GET /statistics/bandwidth?timespan=6 (7 live) #2a91 TLS GZIP Signed-in Token (ChuckPA) (Chrome)
May 08, 2023 17:02:15.006 [140283736800056] DEBUG - Completed: [192.168.0.13:43276] 200 GET /statistics/bandwidth?timespan=6 (7 live) #2a91 TLS GZIP 3ms 1469 bytes (pipelined: 47)

It took me 30 minutes but I was successfully able to download a 90 minute 1080p movie and immediately play it.

My iPad (2017) is 500 Mbps-capable
The wifi is WiFi 6 capable.
The connection to the server is 2.5 Gbps

I took screenshots and sent logs to the app team showing them the weaknesses as compared to Plex/web

When I turn IPv6 back on, from my desktop, you see.

May 08, 2023 17:22:01.871 [140283736800056] WARN - [CERT] TLS connection from [::ffff:192.168.0.13]:38200 came in with unrecognized plex.direct SNI name '192-168-0-20.d9637707bcfc4c14a65794726cd0a089.plex.direct'; using installed plex.direct cert
May 08, 2023 17:22:01.875 [140283734690616] DEBUG - CERT: incomplete TLS handshake from [::ffff:192.168.0.13]:38200: sslv3 alert certificate unknown (SSL routines)

It’s stupid noise and yes, I’ve asked them to fix it because it doesn’t belong in the first place.

that fixed it! thank you so much :slight_smile: