Next Episode order broken due to implied Sort Title?

[Revenent 15]

Hi folks,

Seeing the same issue as the following thread: 

But since I don't want to recreate the library and fix a bunch of naming issues, I did a little troubleshooting, and found that even though none of the episodes have a Sort Title, it seems to be using the Title as the Sort Title.  However, when I go and manually add and remove a Sort Title (basically add "A" and then remove it), the episodes start playing in the correct order.

For example:

The special is set to appear before episode 10000, but as you can see, it shows up before the first episode.  If I go and modify the Sort Title for episode 1, the following happens:

That season has a few specials, and that first special is supposed to play before episode 10, so now episode 1 is in the correct position.

If I go and do the same to all the episodes, the correct ordering (in terms of episode ordering) is restored.

Another symptom, episodes with the issue don't show up on the "Next Up" list.  Continuing with the same series, I "fixed" 1x01 and 3x01, and this is what shows up in the list:

As you can see, none of the other episodes show up.

 

While I can go through all the episodes and "fix" the issue manually, is there something that can fix this automatically?  I've tried refreshing the metadata (show level, season level, episode level), but it doesn't solve the issue.

 

Thanks in advance!

[Luke 42083]

Hi, it's all based on episode numbers now so I would just check those in the metadata editor.

[Revenent 15]

All the episodes have the correct metadata (in terms of season and episode numbers).

Is there something in the code that uses the title as the sort title if the sort title is an empty string instead of a null string?

This feels like the sort title field is "broken" for those episodes, but when I force the sort title to be empty again, it updates the DB correctly and things work properly again.

[Revenent 15]

OK, took a look at the DB itself.

It seems like all the episodes that I haven't touched have a SortIndexNumber of 10000 and a SortParentIndexNumber of 0.

The ones I have touched both have (NULL) in the field.

Did the DB upgrade mess something up and set those fields to some default value?

Edit: Specials seem to be hit as well - if the special had an airing season but not a before episode, it would stuff 10000 in the episode (which I assume maps to SortIndexNumber).

Edited February 24, 2022 by Revenent

[Luke 42083]

44 minutes ago, Revenent said:

 

Did the DB upgrade mess something up and set those fields to some default value?

 

No, although this could have happened if you went up and down server versions at some point. Did you do that? 

In any event, you could try refreshing the metadata on the entire series and see if that helps.

[Revenent 15]

I've only ever upgraded, never downgraded.  And I've tried refreshing the metadata at all levels (show, season, episode).  It doesn't fix the issue.

Forcing a write of the metadata at the UX level seems to work - is the write logic for metadata refresh different from the UX save?

[Luke 42083]

Quote

Forcing a write of the metadata at the UX level seems to work - is the write logic for metadata refresh different from the UX save?

No, but it's possible you just didn't give it time to finish, which is common because when you kick off a metadata refresh, there is currently no way to monitor the progress of it apart from the server log.

[Revenent 15]

For the series that I showed in the example, I left it overnight after touching those two episodes, and having kicked off refreshes.  If the refresh didn't finish by then, even for a few episodes, then we have a bigger issue at hand.  

Note that I went into the DB and ran an UPDATE query against a small subset of episodes on the series, NULL'ing out the SortIndexNumber and SortParentIndexNumber and it seems to fix the issue as well.  I may do the same on a per series basis (scoped down by the path) and fix the episodes that way.

[Happy2Play 9783]

Something is not right here but would need to see this from a metadata standpoint.

[Revenent 15]

Agreed, something definitely isn't right.  The wonky thing is, normal episodes (i.e. non-special episodes) don't have the aired in season and before episode fields in the UX.  So that means there is code that is reading in the fields, but when writing them back out, is doing validation and clearing out those fields.

Here's some items in the DB that haven't been "fixed" yet:

You can see, they're normal episodes (in the sense that they're not specials), but they have a SortIndexNumber and SortParentIndexNumber.

When I look at the episodes in the Metadata Manager, it doesn't show the air before data.

[Happy2Play 9783]

Airs during season/Airs before episode only applies to specials nothing else.

Not sure what you have done but sort title is irrelavent and don't really know why it is available as it should never be used for episodes in a series.

This change did not move the special to a different location as its place is Season 12 last.

[Revenent 15]

Yup, totally get that.  Unfortunately, at some point, something added the airs before info to the normal episodes (as both you and I have pointed out, there is no UX in the website to add that data to normal episodes).

Because of that, it breaks the next episode playing, since the server seems to take those values into account even for normal episodes.  It also breaks other things, such as Next Up.

The questions are now, how those values got there and who put them there?

If there is no solution, I may just run the SQL UPDATE queries and fix the episodes directly in the DB.

[Happy2Play 9783]

Yes there is something wrong with your data and would guess your method may be your only recourse.  Just ensure you have backups of your database.

As all I have is Specials.

[Revenent 15]

Thanks, I'll probably go through series by series and run the query to fix them.

But it might be something the devs want to look into at some point, since there are at least 2 people who have shown the same symptoms, so there may be other users, but just haven't complained yet.

[Happy2Play 9783]

Just now, Revenent said:

Thanks, I'll probably go through series by series and run the query to fix them.

But it might be something the devs want to look into at some point, since there are at least 2 people who have shown the same symptoms, so there may be other users, but just haven't complained yet.

Or Remove the Series, scan to clear the database, readd the Series, scan.

I would think it will be impossible to trace but would assume a previous update did not play well.  But can say I don't see this on 4 test beta system that are about 2 years old but are all Windows.