[Bug with Workaround] Plexamp Crash when Omitting Custom Server URL Default Port

[adietrichs]

Hi! Had some issues with the Plexamp and Plex Dash apps just now. All of them crashed right on startup. Was able to fix it, but looks like a bug in the url parsing, so should still be addressed in the app. Quick ChatGPT generated description below. Main Plex apps continued to work fine even before fix.

Issue I had
When my Plex server’s “Custom server access URLs” field contained an IPv6 plex.direct URL without an explicit port (e.g. https://<ipv6-hash>.<server-id>.plex.direct/), three clients crashed on launch:

• Plex Dash (iOS)
• Plexamp (iOS)
• Plexamp (macOS)

The main Plex apps (iOS & macOS) continued to work.

What fixed it
Adding :32400 to that IPv6 entry (→ https://<ipv6-hash>.<server-id>.plex.direct:32400/) immediately stopped the crashes in all three apps.

My explanation (narrowed-down cause)
Startup logs and the macOS crash trace show an uncaught std::invalid_argument from std::stoi inside NetworkConnection::NetworkConnection() (in treble.node). The code tries to convert the substring after the colon to an int; when the colon is missing, it receives an empty string and throws, aborting the renderer process. I only reproduced this with IPv6 URLs, but the same logic may affect IPv4 URLs without a port as well.

[elan]

i’m not sure what the default port should be but i guess picking 32400 is somewhat logical.

[pshanew]

The default port chosen (and the connection URL published) depends on how the custom server access URL is formatted.

For example, if you format it like this (method 1):
https://dash-delimited-ipv6-address.certificateUUID.plex.direct (https schema, no port specified)
It is published as:
https://dash-delimited-ipv6-address.certificateUUID.plex.direct (based on the URL schema)

Similarly (still method 1):
http://dash-delimited-ipv6-address.certificateUUID.plex.direct (http schema, no port specified)
It is published as:
http://dash-delimited-ipv6-address.certificateUUID.plex.direct (port 80 implied, but not included, based on the URL schema)

But including the port (still method 1):
https://dash-delimited-ipv6-address.certificateUUID.plex.direct:32400 (https schema, no port specified)
It is published as:
https://dash-delimited-ipv6-address.certificateUUID.plex.direct:32400 (actual port is included)

However, if you specify the custom server access URL like this (method 2):
https://[ipv6-address] (https schema, only IPv6 address in square brackets)
It is published as:
https://dash-delimited-ipv6-address.certificateUUID.plex.direct:443 (https schema, default HTTPS port added automatically, colons automatically changed to dashes)

Again, similarly:
http://[ipv6-address] (http schema, only IPv6 address in square brackets)
It is published as:
https://ipv6-address.certificateUUID.plex.direct:80 (https schema, default HTTPS port added automatically, colons automatically changed to dashes. Yes, HTTPS, using the square brackets always results in an https:// URL)

This all assumes the remote access is disabled. Otherwise it will use the manual port specified in the manually configured port field in all cases above (except when manually specified as part of the URL).

It’s generally recommended to use the second (http://[IPv6 address] ) method since Plex then does most of the work for you (adding the certficateUUID and plex.direct domain and the port). Plus you don’t have to manually change all the colons to dashes.

The first method (manually building the entire URL) is what we initially thought had to be done to manually configure an IPv6 connection back in the day. There are probably still a few threads around showing that.

At least this is what I observed when checking the resources URL after testing each of the above.
https://plex.tv/api/resources?includeIPv6=1&includeHttps=1&X-Plex-Token=[your token]

[adietrichs]

Ah interesting, and thanks for the quick responses! Then I was wrong in calling it a bug it seems, given that I effectively used an unspecified URL format.

Still worth noting that the main player app apparently uses 32400 as the implicit default port even for public https addresses, as it is able to launch and connect to the server.

And even Plexamp seems to mostly do that. My log file:

➜  ~ cat Library/Logs/Plexamp/Plexamp.log
May 04, 2025 12:40:16.108 [Javascript] INFO - Starting Plexamp 4.12.2 - darwin 24.4.0
May 04, 2025 12:40:16.110 [Javascript] DEBUG - [bugsnag] Loaded!
May 04, 2025 12:40:16.110 [Javascript] INFO - METRICS: Initializing.
May 04, 2025 12:40:16.110 [Javascript] INFO - USER: Refreshing users.
May 04, 2025 12:40:16.110 [Javascript] INFO - Autoupdate: Identifier desktop should check: false.
May 04, 2025 12:40:16.110 [Javascript] INFO - DEVICE: Initializing device manager.
May 04, 2025 12:40:16.111 [Javascript] INFO - DEVICE: Loaded 3 devices.
May 04, 2025 12:40:16.111 [0x0ab64c80] DEBUG - Networking: Create request 1: (GET https://plex.tv/api/users) network type -1.
May 04, 2025 12:40:16.111 [Javascript] INFO - DEVICE: Initializing manager.
May 04, 2025 12:40:16.111 [Javascript] INFO - DEVICE: Fetching latest provider list from cloud.
May 04, 2025 12:40:16.111 [Javascript] INFO - DEVICE: Fetching latest list from cloud.
May 04, 2025 12:40:16.111 [Javascript] INFO - DEVICE: Fetching latest cloud player list from https://sonos.plex.tv
May 04, 2025 12:40:16.111 [Javascript] INFO - DEVICE: Starting connection test.
May 04, 2025 12:40:16.112 [0x0ab64c80] DEBUG - Networking: Create request 2: (GET https://plex.tv/media/providers) network type -1.
May 04, 2025 12:40:16.112 [0x0ab64c80] DEBUG - Networking: Create request 3: (GET https://sonos.plex.tv/resources) network type -1.
May 04, 2025 12:40:16.112 [Javascript] INFO - DEVICE: Looking for an active server in 2 total servers.
May 04, 2025 12:40:16.112 [Javascript] INFO - DEVICE: Finding best connection for <my server name> <my certificateUUID>.
May 04, 2025 12:40:16.112 [0x0ab64c80] DEBUG - Networking: Create request 4: (GET https://dash-delimited-local-ipv4-address-a.certificateUUID.plex.direct:32400/) network type -1.
May 04, 2025 12:40:16.112 [0x0ab64c80] DEBUG - Networking: Create request 5: (GET https://dash-delimited-local-ipv4-address-b.certificateUUID.plex.direct:32400/) network type -1.
May 04, 2025 12:40:16.113 [0x0ab64c80] DEBUG - Networking: Create request 6: (GET https://dash-delimited-ipv6-address.certificateUUID.plex.direct:32400/) network type -1.
May 04, 2025 12:40:16.113 [0x0ab64c80] DEBUG - Networking: Create request 7: (GET https://dash-delimited-ipv6-address.certificateUUID.plex.direct:32400/) network type -1.
May 04, 2025 12:40:16.113 [0x6f4bf000] DEBUG - Networking: Completed request 6: (GET https://dash-delimited-ipv6-address.certificateUUID.plex.direct:32400/) with code -7 (have 0 bytes) in 0 ms.
May 04, 2025 12:40:16.113 [0x0ab64c80] DEBUG - Networking: Create request 8: (GET https://dash-delimited-ipv6-address.certificateUUID.plex.direct/) network type -1.

So it still fills in 32400 for the first few requests, then doesn’t do it once and quits. I think it might still make sense to align the behavior, or to at least catch this more gracefully (not have the app crash).

Thank you for the background on different URL formats, very interesting! Will look into switching over to the simpler format if possible. My case is actually a bit more complex (server only has public ipv6, so for ipv4 I need to use an ipv4->ipv6 port forwarder, that’s why I need the custom urls in the first place and can’t just use normal remote access configuration).

[elan]

hmm, i think 80 and 443 make much sense as defaults

[adietrichs]

agree in principle!

Would just note that there is a chance that there are other people in the same situation I was in (only using plex player app), for whom changing the de facto default port would break their existing setups - and for me it took a while to realize it was the missing port that was the issue.

[elan]

I’ve added protection against malformed ports and fall back to 32400 for compatibility. Thanks for the report!