Possible maybe, is my guess…
Does it make sense, No,
Just because this year they run it in that combination, next year they may rerun a few in another combination. Here we have re runs all the time and some times they binge run them twenty random episodes at a time…
I split them into their individual episodes and save them that way.
Easier to locate and play, weed out the duplicates.
What do you mean? I think you are misunderstanding…
I got my files… I will not update them with a next airing.
I just need a naming scheme that supports multi-episode, non-consecutive episode numbering, cross-season.
I don’t care for automatic recording naming.
What you do with hundreds of airings is up to you… I would like to have Plex to help me not having to manually split them. If you split, then you also don’t need multi-episode spanning of consecutive episodes - which already is supported.
If you search for that topic… it is a long-standing question from many different users. So, having a new agent would be a perfect opportunity to start supporting it.
nvdave69’s point is that tv stations keep mixing up airings all over the place.
Your safe bet is to organize them as they’re listed in TheTVDB.com – if necessary using one of their supported alternative orders (e.g. dvd or absolute order).
If the DVR recorded that double-episode which combines a wild mix of episodes it MIGHT be helpful to manually split them up (e.g. using MKVToolnix).
Keep in mind… if you name that file as multi-episode file (even in today’s world, where that only supports consecutive episodes), you get 2 (or more) items representing that file in your library – but if you play it, it’ll still play the entire file (worst case: multiple times).
So the effort of doing some dusting / spring cleaning for your recorded files will also give you a significantly improved user experience.
Just my 2 ct
That would be totally fine.
Keep in mind… there is no special order in which these episodes should be watched. I would be able to check that all episodes are there.
This has nothing to do with recordings.
In “Snapped”, for example, episodes have been aired in twice in different seasons. Watching the episode once would mark both representations as watched which is exactly what is wanted.
I still do not agree. I have a recorded file. Period. This contains two non-consecutive episodes.
I do not care if TV stations will air it in a different mix next year. I already have it and I am willing to rename the file manually to have the different representations in my library.
I really understand what both of you are saying. But I am neglecting the importance of your argument. 
(no pun intended - really).
I’m not arguing you should re-record your file.
All I say is you’ll only get the metadata and episode information if you split those files as Plex cannot deal with non-consecutive files merged in a single file.
Erm… dear @tom80H
What can I say? I am asking for an expansion of a feature and I think that with the development of a better, quicker and more flexible agent, this would perfectly fit in.
I understand that currently I am not getting that.
@tom80H what is your argument against such an expansion? I cannot see a single one. It would make a good thing (providing a way of naming multi-episode files) even better.
There is no difference between multi-episode files with consecutive episodes (or even episode spanning) and non-consecutive episodes - all limitations are the same as are the advantages. The only difference is: Plex does currently recognize the first use case and not the latter.
I’d be very happy to have this expanded.
If you don’t feel you would use or need it - that’s okay. In my opinion, a media server should try its best (and I mean its best) to work for the media provider and not have her or him cut hundreds of files, if the solution is as simple as what is suggested.
Since I am not the only person to have that problem, I find it a bit odd to hear the repeated suggestion to invest hundreds of hours in cutting what could be watched in that time. Plex is a cord-cutting software solution, not a movie cutting 
Let’s take your example from above:
s01e01 and s03e16 of The FBI Files (1998).s01e01 and s03e16 will show up – looks nices01e01, Plex will play the entire file – so you’ll see s03e16 right after s01e01 (then s01e02 which is merged with s03e03 and so on).s03e16, Plex will play the entire file again – so you’ll see first s01e01 (again) and then s03e16And before you ask… Plex doesn’t know where each episode starts / ends, so it has no way to change that behavior.
Again… just my 2 ct; you asked why I consider it not a good extension.
That being said… let’s end this as we’re drifting far off topic
Based on this original post, can you describe the mechanism when you say “cloud-based metadata service”? Does this mean that Plex itself is hosing a cloud metadata service to combine multiple metadata sources in which each Plex server instance is querying or is each Plex server instance going to each website (IMDB, TheMovieDb…ect) to collect the metadata?
I am trying to figure from a security perspective the web requests my Plex Server will be requesting from now to future. Also, thanks for your hard work in these improvements!
Thanks @tom80H for being open-minded.
Before you end this discussion, let me just add a few things.
Yes, it looks nice. I can keep track of which episode I have and which not.
Exactly what I wish for.
Yes, again exactly what I want. Please keep in mind that those episodes do not need to be watched in a specific order. If I would have watched them on TV, I would have seen exactly the same. Perfect for me.
This is where you are wrong. If I watch both in-file episodes, both representations get marked as “watched”. Plex “next” and “home” mechanisms will respect that. And I can see that I already watched it. Everything would be just as I want and expect it.
If you are not a fan of it, just split your files as you always did. I want Plex sparing me from that and I am quite clear about that I would have to follow special naming guidelines to make it look as I want it - once you guys implement it.
I see the new agent to be the perfect place to give it a go (and you will find other threads where people ask for it).
If you say “no, we just don’t want it”… hey, it is your cake and you just invited me to your birthday party. But I cannot see a real reason for this reluctance.
All I ask is: please consider this even if it is not YOUR use case. Cool, thank you.
Took me by surprise, but couldn’t figure out why this title was merging 11 movies together automatically and giving me Stargate as the title. Turns out it was my external drive folder named Seagate HD that was pulling the title from and not the respective enclosing folder. Even then, the titles needed to be matched with year before it found its true match-if not, it wouldn’t appear in the closest matches list.
Hmm, that seems undesirable. I’ll see what we can do about that.
After the first scan I have about 800 unmatched movies in the library.
Is there any way to start Auto Match for all unmatched movies? Why are the movies with only one result in the manual match not matched automatically on the initial run (or when i refresh metadata on all of them)?
This is not only a problem with the new scanner but I would love to see it fixed 
I am thinking of testing this, but I know what is going to happen if it all goes a little wonky… I will be asked to put back the old version.
If i want to test it, do I:
Another thing, if Plex sees the same files, is it going to maintain the watched status across the library, or are they all going to be unwatched (queue reaction 4b 
)
Obviously in the instance of 4b I would be also reporting back here any issues.
Thanks for your help 
That seems strange. Sounds like the first scan failed to match those (my best guess is that the requests to the service failed for some reason) but they should try to match again when you hit refresh.
Could you send me your logs (Settings → Troubleshooting → Download Logs)?
There is always some level of risk when running the latest versions of something however the new scanner code is separate from the existing one so creating a test library shouldn’t interfere with your other libraries.
It’s always best to have a recent database backup in case something does go wonky you can then just install the stable public version again and restore to your database backup.
Yep, it’s expected that these libraries created with the new scanner are just temporary and you should ideally remove these anyway once you’re done testing with them.
The ideal situation if you don’t want to disrupt the operation of your normal server is to install this somewhere else completely (virtual machine, docker, different PC, etc). You then don’t have to worry about it affecting anything on your main server.
Yeh, I understand that there is always a risk… hence the reason why I am thinking about it… I have “just gone ahead” with other things in the past and kinda regretted it after 
I have backups, so there is always that to go back to.
Sorry to pester about it, but what happens to the watched status… does Plex see that they are the same files and assume the same status as the “old” library… or is it going to make them all unwatched? I guess it isn’t too much of an issue, as we can just carry on using the “old” library and leave the new library unpinned in the client.
Watched status is per library.
ah cool… no matter… plan B… create new library and don’t have it pinned… I may give it a try in a bit… wife is away this evening, so if I break it, I have the night to fix it! lol
Another thing that’s per library is “Date Added”. So if you use “Recently Added” you’ll want to wait for the official release and library/database migration.
I did wonder about that as well… no worries… I will try it… see if I have any issues, and then squirrel the test library away (or delete and reinstall older version).
Thanks for all your help
