Sort by version name before resolution sorting

[gnattu]

Changes

We need to sort by resolution in descending order so that higher resolutions are listed first in the alternate version menu. However, we currently do not consider sorting when the resolutions are the same, leading to unwanted descending order for supplemental titles. This sorts the titles additionally after the resolution, providing a more natural listing.

Issues

Closes #12620
Fixes #12618

[dmitrylyzo]

This can probably be simplified further: if ResolutionRegex returns an empty string for resolution-less versions, we can remove the grouping.
But it LGTM.

[theguymadmax]

Just tested these changes. Results:

Filenames:

Resolutions:
All file resolutions correspond to the resolutions specified in their filenames. For files lacking resolution information in their filenames, the following resolutions were applied:
X-Men Apocalypse (2016).mp4 -> 720p file
X-Men Apocalypse (2016) - Directors Cut -> 2160p file
X-Men Apocalypse (2016) - Theatrical Release -> 1080p file

[gnattu]

I wonder why the sorting result is different from your instance and the unit test... it does not make many sense to me tbh

[theguymadmax]

videoInfos provides resolution metadata, which is utilized regardless of whether the resolution is in the filename. The sorting is based on resolution, whether it's specified in the filename or not. #12129

[gnattu]

So current sorting is correct and the intended behavior right?

[theguymadmax]

Two separate issues here

1. Sorting does not follow current documentation: Movie versions are presented in an alphabetically sorted list. An exception applies to resolution names, which are sorted in descending order from highest to lowest resolution. A version name qualifies as a resolution name when ending with either a p or an i.

2. Sorting is reversed when resolutions are in the file name. Current sorting behavior:
   

[gnattu]

Then probably we should not hijack this PR to extend its scope because what you pointed out is something that having a much deeper impact. When we are fetching mediastreams for everything we always sort by width if available and that is in the very cursed BaseItem.cs:

jellyfin/MediaBrowser.Controller/Entities/BaseItem.cs

Lines 1090 to 1095 in c67b78b

	.ThenByDescending(i =>
	{
	var stream = i.VideoStream;
	return stream is null || stream.Width is null ? 0 : stream.Width.Value;
	})

Which means the prober correctly sorted things, but the reader just sorted it again. I prefer to make a separate PR for that because that one may contain more unwanted side effects.

[theguymadmax]

This PR does fix the issue, thank you. Hopefully, there will be a PR to address the other issue as well, rather than just changing the documentation, which is understandable. As it stands now, there is no way for users to sort alternative versions without considering video resolution when the resolutions vary between files.

[gnattu]

This PR does fix the issue, thank you. Hopefully, there will be a PR to address the other issue as well, rather than just changing the documentation, which is understandable. As it stands now, there is no way for users to sort alternative versions without considering video resolution when the resolutions vary between files.

It up: #12626