GetShowsByIdEpisodes returns incomplete MediaSources for non-admin users since 4.9.x

[PiliPili 0]

Hi,

I noticed a behavior change in recent Emby 4.9.x versions regarding the GET /Shows/{Id}/Episodes endpoint.

Observed behavior:

When calling this endpoint with Fields=MediaSources,Path to retrieve all episodes in a season:

• Admin account: Each episode's MediaSources array contains all available versions (e.g., 3 versions per episode if the item has 3 merged alternate versions).
• Non-admin account: Each episode's MediaSources array contains only 1 entry (the default version), even though the same item has multiple merged versions visible in the web UI.

Steps to reproduce:

1. Have a TV show with episodes that have multiple alternate versions merged together.
2. Call GET /Shows/{SeriesId}/Episodes?SeasonId={SeasonId}&Fields=MediaSources,Path using an admin API key → each Item has multiple entries in MediaSources.
3. Call the exact same endpoint using a non-admin user API key → each Item has only 1 entry in MediaSources.

Additional observations:

• The single-item endpoint GET /Users/{UserId}/Items/{ItemId} with the same non-admin user does return all MediaSources correctly. So the limitation appears to be specific to the bulk episodes listing endpoint.
• The API documentation states this endpoint only "Requires authentication as user" with no mention of different response payloads for admin vs. non-admin roles.
• This also affects GET /Users/{UserId}/Items?Ids=... when querying multiple items at once — non-admin users receive only 1 MediaSource per item.

Impact / Use Case:

This change makes it impossible for non-admin users to programmatically build a season playlist that respects a specific version preference. For example:

• A user has a TV show where each episode has multiple merged versions (e.g., different subtitle/source variants). They want to play through the season using a consistent version.
• Previously, calling the Episodes endpoint once would return all MediaSources, allowing the client to pick the preferred version for each episode and build a coherent playlist.
• Now, non-admin users only see one (default) version per episode from this endpoint. The result is a playlist with mixed, inconsistent versions across episodes — some episodes get version A, others get version B, depending on whichever the server chose as default.
• The only workaround is to call the single-item endpoint individually for every episode in the season, which feels unnecessarily heavy when a single bulk endpoint used to handle this.

Environment:

• Emby Server version: 4.9.5.0
• OS: Linux (Docker)

Questions:

1. Is this an intentional change? If so, could the documentation be updated to reflect the difference in response between admin and non-admin users?
2. If intentional, is there a recommended way for API consumers to retrieve all available MediaSources for a season's episodes in a single request as a non-admin user?
3. Would it be possible to revert this behavior so that non-admin users receive the full MediaSources in bulk endpoints as before? This change has caused real inconvenience for users who rely on version selection to maintain a consistent playback experience across a season.

Thanks for any clarification.

[Abobader 3503]

Hello PiliPili,

** This is an auto reply **

Please wait for someone from staff support or our members to reply to you.

It's recommended to provide more info, as it explain in this thread:

Thank you.

Emby Team

[nekoda 0]

I am experiencing the exact same issue.  Everything was working perfectly prior to the 4.9.0.x updates. However, after updating the server to the latest version, ⁠GetShowsByIdEpisodes⁠ returns significantly less data (incomplete ⁠MediaSources⁠) for non-admin users. This regression has been quite frustrating. I really hope Luke and the team can consider reverting to the previous logical behavior.

[PiliPili 0]

Just to add a quick follow-up observation regarding this issue:

I did some further testing and confirmed that if a non-admin user queries the single-item endpoint (GET /Users/{UserId}/Items/{ItemId}) or the playback info endpoint (POST /Items/{Id}/PlaybackInfo), the API correctly returns ALL available MediaSources for that episode.

Since non-admin users clearly have the permission to view and access all merged versions via single-item requests, restricting the bulk listing endpoint (GET /Shows/{Id}/Episodes) to only return 1 MediaSource seems highly inconsistent and illogical.

Currently, this inconsistency forces API consumers to make dozens of individual single-item requests just to build a proper version-aware season playlist. This completely defeats the purpose of having a bulk episodes endpoint and unnecessarily increases server load.

Hopefully, this inconsistency can be addressed so that the bulk endpoint matches the behavior of the single-item endpoints.

[Luke 42592]

HI, try also adding the field AlternateMediaSources to the url.

Quote

The only workaround is to call the single-item endpoint individually

This is recommended anyway. The only reason it is there is because some insist that they want it, and they're going to do it anyway despite our recommendation. But pulling down this information in bulk is not going to be optimal because many database queries will be one at a time for each item.

It is best to wait and do /playbackinfo prior to playback of each episode.

Quote

This completely defeats the purpose of having a bulk episodes endpoint and unnecessarily increases server load.

No it does not. The typical usage of a bulk endpoint is to display items in a list. When you're displaying in a list, you're not typically going to be displaying this level of detail.

The same idea applies to requesting things like Chapters and People. It is there in case you're going to insist that you need it, but some things are going to happen one at a time and it's not going to be optimal.

[PiliPili 0]

Hi Luke,

Adding AlternateMediaSources to the Fields parameter worked perfectly! It successfully returned all the available versions for non-admin users. Thank you for pointing out this field as a workaround.

I also completely understand your point regarding the database performance overhead when querying this much detail in bulk, and the recommendation to defer deep version/chapter retrieval to the individual PlaybackInfo request just prior to playback. That makes total sense from an optimization standpoint.

Thanks again for the quick and clear response, really appreciate it!