Naming of files which hold multiple non consecutive TV Episodes

[ebr 16169]

Just now, MBSki said:

but order for displaying is important.

Why?  As long as the metadata (descriptions) are correct, why would the display order be important when the playback order is not?

[MBSki 1114]

5 minutes ago, ebr said:

Why?  As long as the metadata (descriptions) are correct, why would the display order be important when the playback order is not?

Because I want to SEE which episodes are which and what order they're supposed to go in. Just because the order for some shows doesn't matter, doesn't mean the order doesn't matter for any shows.

[ebr 16169]

17 minutes ago, MBSki said:

Just because the order for some shows doesn't matter, doesn't mean the order doesn't matter for any shows.

We're just talking about one specific show and in a very specific situation - not "any shows"...

In any case, if one file has multiple random episodes in it, there is going to be no way we can show all those episodes in "proper" order.  They would show in the order of the first episode of each file at best.

[MBSki 1114]

2 minutes ago, ebr said:

We're just talking about one specific show and in a very specific situation - not "any shows"...

No we're not, we're talking about how to handle this situation.

2 minutes ago, ebr said:

In any case, if one file has multiple random episodes in it, there is going to be no way we can show all those episodes in "proper" order.  They would show in the order of the first episode of each file at best.

Why not? That's the point of having a naming convention that can accommodate a multi episode file with non-sequential episodes. Why couldn't you have a naming convention like: s01e01;e04. The colon indicates a split rather than meaning "include every file from 1-4". ; Is just an example. That might already be in use. I'm just saying find a symbol that works to indicate a split them show that video at multiple episode locations in the show.

[Gilgamesh_48 1240]

I just reread through this thread and I really see no important problem. I have some cartoons where the aired order does not matter and for most early TV shows it does not matter either. For the most part early TV did not build on earlier episodes so the order they air in does not matter and neither does the order viewed.

I read that there are objections to users splitting these combined shows but it seems to me that inconveniencing the developers for options that adversely impact what appears a very tiny subset of users. I wold almost bet that the number of users that even have such files is less that 0.001% of Emby's user base.

I have a few "desires" that I believe I "need" but, for what those "desires" will do the effort to make them work is greatly disproportional to the number of people it would help.

In an ideal world software can be setup so as everyone that uses it finds all desired options fulfilled but this world is somewhat short of ideal and I, for one, see no good reason for Emby to waste any time on implementing a solution for what is a problems to very very very few people.
There are lots of thing Emby needs to look at or change but wasting time on this causes more harm than good and, if implemented, would cause many potential problems.

In other words: If there were a valid voting system I would vote NO!!!!

[MBSki 1114]

27 minutes ago, Gilgamesh_48 said:

In other words: If there were a valid voting system I would vote NO!!!!

Geez man, I'm not saying it's the most important feature and should go to the top of the list. It's just something that would make my life better. 

Was all of that really necessary? I understand everyone is entitled to their own opinion, but that just seemed a little overboard to me. As I described the solution it isn't going to affect any other users. If they ever implemented it, you just don't have to use it. That's it.

[Gilgamesh_48 1240]

1 minute ago, MBSki said:

Was all of that really necessary? I understand everyone is entitled to their own opinion, but that just seemed a little overboard to me. As I described the solution it isn't going to affect any other users. If they ever implemented it, you just don't have to use it. That's it.

Yes. I felt it was needed. Your argument holds from a use standpoint but what you want would add a LOT of complications to the matching engine and those complications might have side effects. Emby is a complex organism and changing one are can have ramifications all over that are very hare to find. 

There are a lot of areas that Emby needs to fix that truly need improvement but this is NOT one.  

This one of those things that sounds easy but I believe it is not and why waster the developers time.
Again I vote strongly no.

[rbjtech 5284]

Maybe just move the request/thread as an FR - because that's what it is.    

[MBSki 1114]

1 minute ago, Gilgamesh_48 said:

Yes. I felt it was needed. Your argument holds from a use standpoint but what you want would add a LOT of complications to the matching engine and those complications might have side effects. Emby is a complex organism and changing one are can have ramifications all over that are very hare to find. 

There are a lot of areas that Emby needs to fix that truly need improvement but this is NOT one.  

This one of those things that sounds easy but I believe it is not and why waster the developers time.
Again I vote strongly no.

If it's complicated, they won't do it. That's not for you to evaluate. It's for the devs to evaluate. 

[Gilgamesh_48 1240]

5 minutes ago, MBSki said:

If it's complicated, they won't do it. That's not for you to evaluate. It's for the devs to evaluate. 

Oh I see. Your input is important and mine is not. I will continue to post as I feel I should and your attempts at suppressing different views than yours will not stop me. If you have the "right" to ask for a feature I have the "right" to object.

BTW: I only pointed out the complication because I do not want this feature and I feel Emby is already too forgiving of naming.

[ebr 16169]

2 hours ago, MBSki said:

show that video at multiple episode locations in the show

IMO that would be incredibly confusing and would also probably be quite a performance issue as there would be no natural sort that could do that (have the same file sort to multiple different positions).

So, it is a valid request to support non-sequential episodes in the same file but there will definitely be some drawbacks to doing that - primarily with display and playback order.

[MBSki 1114]

20 minutes ago, Gilgamesh_48 said:

Oh I see. Your input is important and mine is not. I will continue to post as I feel I should and your attempts at suppressing different views than yours will not stop me. If you have the "right" to ask for a feature I have the "right" to object.

BTW: I only pointed out the complication because I do not want this feature and I feel Emby is already too forgiving of naming.

I never said you can't have an opinion, that's the exact opposite of what I said and you know it. Your argument went overboard. That was my point. You don't want to use the feature? Fine, state you wouldn't use the feature. But was it necessary to continue crapping all over the idea after stating you wouldn't use it? I say no, because it adds nothing useful and it really rubs people the wrong way. Do I have thin skin? Maybe. Or maybe I just had a bad day. Either way I would've appreciated a less aggressive response to a a simple suggestion.

[MBSki 1114]

7 minutes ago, ebr said:

IMO that would be incredibly confusing and would also probably be quite a performance issue as there would be no natural sort that could do that (have the same file sort to multiple different positions).

So, it is a valid request to support non-sequential episodes in the same file but there will definitely be some drawbacks to doing that - primarily with display and playback order.

That's fine, and understand where you're coming from. If it could be done in a way to display it correctly and it wasn't too complicated, I'd appreciate it, but understand if that's not possible. I can keep using strm files. It's not elegant, but it's less involved than splitting.

[darkside40 107]

Those strange sortings are in 99% the result of the TMDB Scraper not supporting generic alternative orders. If that would work the workaroung with non consecutive Episoded in single files would not be needed. But i say that for the 10th time here and it seems that nobody gets it.

So its better to fix the TMDB Scraper to support more features of their API.

[MBSki 1114]

Sorry @darkside40. I definitely don't get it and it wouldn't help me because I want to see it in the aired or DVD order. I do think more of the API needs to be explored though.

@ebrwhat do you think?

[ebr 16169]

Sorry, I don't understand how supporting any other defined order is going to solve the issue of ordering non-consecutive episodes in the same file.  If, what you are saying is that you want to redefine the order to be the order that they are in the file, then they are no longer non-consecutive and there isn't really an issue - other than whatever number is showing on any specific episode maybe not matching something else.

@darkside40perhaps a specific example would help us see what you are saying.

[darkside40 107]

The problem with multiple non consecutive Episodes in one file only exist when you try to translate one TMDB Order to another.

My files of Phieas and Ferb hold the Production Order (listed on TMDB) which is totally fine, consecutive etc.

Because Embys TMDB scraper does not support this five year old feature i thougth: oh okay than translate that to Airdate Order, that leads to Episodes like Phines.and.Ferb.S03E62E59.mkv.

I am not voting for that Emby supports something like this, i know that this is some kind of shitty. It was just one of my last resorts because some Bugs in Emby prevent me adding this Series in a sane order.

So please fix or upgrade the TMDB scraper, that would be the real solution.

[ebr 16169]

19 minutes ago, darkside40 said:

because some Bugs in Emby prevent me adding this Series in a sane order

Hi. The lack of a feature you desire is not a bug .

But thanks for the further explanation.  I think I understand now.

[darkside40 107]

Take a look here, it is not a feature that i only desire:

And it is open for years now.

Also it wouldnt be a Problem if the nfo parser of Emby could handle files which multiple Episode, but he even cant in consecutive order.

Afaik the TMDB scraper is not open source, so there is no other way than wait and hope that the feature request will be fullfilled one day.

Edited July 20, 2023 by darkside40

[pwhodges 2012]

1 hour ago, ebr said:

Hi. The lack of a feature you desire is not a bug .

This is true.  But I find it hard to understand the amount of pushback we get whenever this request is brought up...

Paul

[ebr 16169]

11 minutes ago, pwhodges said:

But I find it hard to understand the amount of pushback we get whenever this request is brought up

Where?  I'm not pushing back on anything but that particular feature has a pretty narrow use-case and potentially high cost.  That would be the reason it hasn't gone anywhere yet.

[MBSki 1114]

42 minutes ago, ebr said:

Where?  I'm not pushing back on anything but that particular feature has a pretty narrow use-case and potentially high cost.  That would be the reason it hasn't gone anywhere yet.

I'm not sure it's a narrow use case, but maybe. Can you point us to the actual FR? I can't find it. We should probably be chatting there about it. 

[darkside40 107]

Scroll to my last post above. Mentioned that FR multiple times in this thread.

[rbjtech 5284]

So 33 likes in 3+ years ... 

I guess I've never been impacted by this - as for the really awkward shows (money heist being one of them), I manually sorted it all out - but can't say I have ever needed to do this on a regular basis.

I guess the Dev's will continue to monitor interest - but personally, I think there are a great deal many more important features for the masses that need their attention first.

[MBSki 1114]

43 minutes ago, darkside40 said:

Scroll to my last post above. Mentioned that FR multiple times in this thread.

Thanks. I think there's another FR for alternative sort order as well. I recall seeing it, but can't find it now.