Viewing artists fails consistently due to "includeStations" in query - can it be disabled?

Viewing artists fails consistently due to “includeStations” in query

Server Version#: 1.30.0.6359
Player Version#: 4.87.2

Is there a way to always have this “includeStations” query parameter removed?

I have a very large music collection and have found that almost all Artists consistently fail to load, just getting “Something went wrong” page.
So I optimized the database, rebooted my server, optimized again to be sure. No luck each time.
I turn on debug and verbose logging and confirmed that the query is taking just over 30 seconds - every single time. Consistently between 32 and 35 seconds.

I found no way to change the timeout setting at first, so I tried resubmitting the request through browser tools without any of the “include*” flags, and it was instantaneous. I start adding one by one, and then all but one, and confirmed it is specifically the includeStations flag that is causing this issue. Including this flag on the request caused it to be over 30seconds. Without it, it took milliseconds. Including it but setting flag to Zero took 4seconds, then several subsequent runs each took only 300ms.
To be sure, reboot the server, resend the request without includeStations at all, and its still 300ms (tried to make sure its not overly cached)

I edited music library, to unchecked the “Popular Tracks” setting, which appeared to cause a rescan of entire library. Waited it out, tried again and still 34 seconds to try (fail) to view an artist. Stop server, start it, but still times out. Optimize database: still times out. Stop and start, still times out.
To be sure, removed all include* query params except for includeStations, and still takes over 30seconds.

Current music library advanced settings: Plex Music for both scanner and agent; Visibility: include in home screen and global search; Album sort: library default; Sonic Analysis: off; Prefer local metadata: on; Store track progress, include related content, artist bios, album reviews and ratings, popular tracks, find lyrics: all off; Generes: plex music; Album Art: plex music only.

Debug/Verbose logs of it taking over 30seconds when includeStations is present:

Nov 14, 2022 12:57:09.674 [10356] DEBUG - Request: [127.0.0.1:6495 (Loopback)] GET /library/metadata/1509877?includeConcerts=1&includeExtras=1&includeOnDeck=1&includePopularLeaves=1&includePreferences=1&includeReviews=1&includeChapters=1**&includeStations=1**&includeExternalMedia=1&asyncAugmentMetadata=1&asyncCheckFiles=1&asyncRefreshAnalysis=1&asyncRefreshLocalMediaAgent=1 (4 live) #104 GZIP Signed-in Token (Al L) (Microsoft Edge) / Accept => application/json, text/plain, / / Accept-Encoding => gzip, deflate, br / Accept-Language => en / Connection => keep-alive / DNT => 1 / Host => 127.0.0.1:32400 / Referer => http://127.0.0.1:32400/web/index.html / sec-ch-ua => “Microsoft Edge”;v=“107”, “Chromium”;v=“107”, “Not=A?Brand”;v=“24” / sec-ch-ua-mobile => ?0 / sec-ch-ua-platform => “Windows” / Sec-Fetch-Dest => empty / Sec-Fetch-Mode => cors / Sec-Fetch-Site => same-origin / User-Agent => Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/107.0.0.0 Safari/537.36 Edg/107.0.1418.42 / X-Plex-Client-Identifier => u8m… / X-Plex-Device => Windows / X-Plex-Device-Name => Microsoft Edge / X-Plex-Device-Screen-Resolution => 1671x1352,3440x1440 / X-Plex-Drm => playready / X-Plex-Features => external-media,indirect-media,hub-style-list / X-Plex-Language => en / X-Plex-Model => bundled / X-Plex-Platform => Microsoft Edge / X-Plex-Platform-Version => 107.0 / X-Plex-Product => Plex Web / X-Plex-Provider-Version => 5.1 / X-Plex-Text-Format => plain / X-Plex-Token => xxxxxxxxxxxxxxxxxxxx / X-Plex-Version => 4.87.2

Nov 14, 2022 12:57:09.680 [10356] DEBUG - [Req#104] There were 1 top-level paths for Turnpike Troubadours.

Nov 14, 2022 12:57:43.312 [10356] VERBOSE - [Req#104] It took 32.7 sec to serialize a list with 1 elements.

Could you compare the results by using the hosted web app? The one you used is several months old.

Thanks for the idea @OttoKerner , however, same issue as seen below with new client:

Player Version#: 4.94.2

Nov 15, 2022 07:41:43.220 [18852] DEBUG - Request: [192.168.1.25:45376 (Subnet)] GET /library/metadata/1509877?includeConcerts=1&includeExtras=1&includeOnDeck=1&includePopularLeaves=1&includePreferences=1&includeReviews=1&includeChapters=1&includeStations=1&includeExternalMedia=1&asyncAugmentMetadata=1&asyncCheckFiles=1&asyncRefreshAnalysis=1&asyncRefreshLocalMediaAgent=1 (9 live) #43e TLS GZIP Signed-in Token (Al L) (Microsoft Edge) / Accept => application/json, text/plain, / / Accept-Encoding => gzip, deflate, br / Accept-Language => en / Connection => keep-alive / DNT => 1 / Host => 192-168-1-25.a0a76c60d02d4c5e9c999f61d6bb7573.plex.direct:32400 / Origin => https://app.plex.tv / Referer => https://app.plex.tv/ / sec-ch-ua => “Microsoft Edge”;v=“107”, “Chromium”;v=“107”, “Not=A?Brand”;v=“24” / sec-ch-ua-mobile => ?0 / sec-ch-ua-platform => “Windows” / Sec-Fetch-Dest => empty / Sec-Fetch-Mode => cors / Sec-Fetch-Site => cross-site / User-Agent => Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/107.0.0.0 Safari/537.36 Edg/107.0.1418.42 / X-Plex-Client-Identifier => oyvbxxxxxxxxx / X-Plex-Device => Windows / X-Plex-Device-Name => Microsoft Edge / X-Plex-Device-Screen-Resolution => 1671x1352,3440x1440 / X-Plex-Drm => playready / X-Plex-Features => external-media,indirect-media,hub-style-list / X-Plex-Language => en / X-Plex-Model => hosted / X-Plex-Platform => Microsoft Edge / X-Plex-Platform-Version => 107.0 / X-Plex-Product => Plex Web / X-Plex-Provider-Version => 5.1 / X-Plex-Text-Format => plain / X-Plex-Token => xxxxxxxxxxxxxxxxxxxx / X-Plex-Version => 4.94.2

Nov 15, 2022 07:41:43.229 [18852] DEBUG - [Req#43e] There were 1 top-level paths for Turnpike Troubadours.

Nov 15, 2022 07:42:17.644 [18852] VERBOSE - [Req#43e] It took 33.4 sec to serialize a list with 1 elements.

Thanks for confirming anyway!
I will relay to the developers.

Does this happen on AlbumArtists only?
Or also when you look at actors?

I am trying to reproduce, but I cannot.

Have you checked the health of your database?

  1. activate debug logging (not ‘verbose’!)
  2. quit Plex Server
  3. wait 1 minute
  4. start Plex Server
  5. wait 5 minutes
  6. fetch log files and attach them here

Or inspect them yourself. Take a look at the Plex Media Server.log file and seek for messages about database corrupt or malformed.
If you find these, you may have to repair your database.
https://support.plex.tv/articles/repair-a-corrupted-database/


Another idea: you have disabled “Popular tracks”. This provides a major data point for building artist radios. I assume that is what the Stations parameter is referring to.
I wonder if the large delay only happens when popularity data are missing.

Thanks for some more ideas and info @OttoKerner

Specifically AlbumArtists only that I’ve seen. Viewing albums of an artist works, but then to try and go to said album’s artist page will fail.

This does not occur when viewing actors, I went through maybe 20 different actors to confirm. Largest return set was 31 movies for one actor, and was always fast - fast enough to not worry about exact timing.

I had the “Popular Tracks” enabled originally. It was the only setting I saw that might be related to “includeStations” which is why I disabled it. So this issue has been occurring with and without it checked.

Followed the steps provided and found no mention of Corrupt or Malform database. Attached:
Plex Media Server Logs_2022-11-15_08-40-07.zip (736.8 KB)

What type of drive is E: ?

You have installed Plex server to drive E. This is not recommended.
Revert that to drive C: (Doing so will not affect the location of the Plex data folder on E:)

Thanks @OttoKerner really appreciate the feedback here. I’ve corrected my setup, uninstalled Plex and reinstalled to C: with the Plex Data folder still on E: which is an SSD.

Unfortunately, same problem persists. Followed previous steps to start (after installing on C:) with debug only, wait 5mins, tried to view the artist (failed) and attached logs.

Plex Media Server Logs_2022-11-15_09-15-00.zip (101.0 KB)

How much free space is there on it? Did you set up overprovisioning for this drive? How old is it? Which brand?

Is your server running during the configured maintenance period? https://support.plex.tv/articles/201553286-scheduled-tasks/
And if so, do you have “Refresh library metadata periodically” enabled?

350GB free space out of 465GB. One month old WD Red SA500 SATA SSD, though not in the NAS. It is not overprovisioned.

Scheduled Tasks are set for 1am to 7am, and I’m EST so not running during these logs and as I verify the issue persists with these changes.
Metadata refresh takes a few days, so definitely off.

Scheduled Tasks
Time at which tasks start to run: 1꞉00
Time at which tasks stop running: 7꞉00
Backup database every three days
Backup directory: E:\Plex\Plug-in Support\Databases
Optimize database every week
Remove old bundles every week
Remove old cache files every week
Refresh local metadata every three days
Update all libraries during maintenance
Upgrade media analysis during maintenance
Refresh library metadata periodically
Perform extensive media analysis during maintenance
Fetch missing location names for items in photo sections
Analyze and tag photos

Library Settings
Scan my library automatically
Run a partial scan when changes are detected
Scan my library periodically
Library scan interval: daily
Empty trash automatically after every scan
Allow media deletion
Weeks to consider for Continue Watching: 24
Maximum number of Continue Watching items which will appear: 40
Include season premieres in Continue Watching
Enable smart shuffling on artists and smart music playlists
Group albums by type: enabled
Run scanner tasks at a lower priority
Generate video preview thumbnails: never
Generate intro video markers: never
Generate chapter thumbnails: never
Analyze audio tracks for loudness: never
Analyze audio tracks for sonic features: as a scheduled task
Location visibility: admin only

This is not refreshing a complete library at a time, but only a few dozen items per night.
So, over time, you get a reasonably up to date library.

Same goes for the “media analysis” and “extensive media analysis”.
Both are recommended to get optimal transcoding decisions, based on the true bandwidth of the media (and not just the average B/W, which can be way off).

Any reason why you have “sonic” enabled but “loudness” not? The former is computationally more expensive.

Thanks @OttoKerner I’ll make a note to turn on those refresh metadata and media analysis ones, I didn’t know it was a smart partial like that.
No reason at all :slight_smile: other than I quickly went through and turned off what I thought might cause problems or slowness or just not necessary to get up and running. Probably just missed sonic analysis or poorly guessed at expense.

Anything to change here and now to try and resolve the issue?

Apart from those I mentioned above, there are none which could be related, IMHO.

I’d still perform the “Low-Level Database Recovery” – just to make sure there are no unpleasant surprises hiding in there.
Although the “repair” article doesn’t mention it, perform the repair also with the blobs database file.
Give it plenty of time for the first server restart after the repair procedure. It has to rebuild all the DB indices, which can take quite a while (depending on the size of your media collection).

I was able to follow the low-level database repair steps for main and blobs databases both, waited a long time, and it has marginally improved. Where it took 32-34 seconds usually before, now its 29 seconds - verified it with three times navigating to that artist. Tried a different artist, also took a full 29 seconds.

So while the artist page loaded, unfortunately it is dangerously close to that timeout still.

Confirmed that if I resend these artist requests through the browser tools, removing includeStations param, then they’ll return instantaneously (10-45ms) still.

Plex Media Server Logs_2022-11-15_18-37-29.zip (244.9 KB)

Any other suggestions? :slight_smile:

Where are your media files stored?
Do you use external USB driveswhich aggressively spin down to save power?
Or perhaps NAS device(s) which do the same?
Or even cloud storage?

Albums, Movies, TV Shows, Actors all don’t have this problem, so don’t think it’d be access issues to the media - not trying to play the music just yet. That query param flag includeStations causing the long wait is for database joins or subqueries I had guessed.

I have PMS running on my old gaming desktop machine, now installed on SSD C: drive. Plex’s App Data folder is on another SSD drive E: within desktop. Desktop is connected via ethernet to the router where QNAP NAS is also wired to. NAS is QNAP TVS 471 with TR-004 expansion, all WD Red 8TB which are mapped network drives for desktop/Plex. No cloud storage, no thumbdrives.

I added a new directory to the Music library, a new folder with new music on E: to see if there was a read issue of the music files themselves, bringing it in off the NAS. It caused a rescan of the entire music library, so after letting that finish, tried to navigate in Plex to that artist and had a 30+ second timeout.

Thank you for answering all those questions!

Yet, I still have some more: :sweat_smile:

Correct, the music library has “Plex Music” as both agent and scanner.
(To be extra clear: scanner is not the ‘plex music scanner’)

Password has been reset.

PMS update was available and have upgraded to latest to try it out. Current PMS version is now 1.30.0.6406

After doing the above two actions, still having the same problem though: timing out at the 30second mark trying to view most artists.
Still able to use browser tool to resend the same request, but without includeStations to have it successfully return within milliseconds.

Thanks, and sorry for the delayed response while out of town.

1 Like

@OttoKerner do you have hope that we’re going to be able to get this resolved?
As I see it, I’m going to have to figure out creating a browser extension that will remove this query parameter from every single Plex request…
I peeked into my copied database and couldn’t find any column or index specifically related to includeStations unfortunately. Would’ve been nice to manually recreate an index or optimize it; see what kind of column/data is causing the artist query to take an additional 30+ seconds every single time.

The problem is that for the 30 seconds of the delay there is literally nothing logged. So it is almost impossible to find out what is causing the delay.

Would it be a major inconvenience to re-enable the popular tracks?
Because if we find out that these, when absent, are causing the delay we have a direction for further investigation.