Small problems identified with file stacking

[Sanduleak 0]

Hi again.

As I said in a previous post I am in the process of jumping from Plex to Emby and I have identified some small problems that maybe need correction (not sure if the corrections are in the development side or in my side).

Just to be clear, I know that the recomended configuration is having just one file for each movie, I know it and accept it, however I have literally thousands of movies and a good percentage of them are multi file, so I wanted to try to get to the best possible configuration to try to avoid the many hours required to merge those movies.

 

Usually I use Ember Media Manager or Tiny Media Manager to scrape movie data and have Emby make zero scrapping, just to make things clear.

My normal naming is "movie-cd1.mkv", "movie-cd2.mkv", "movie-cd3.mkv"... and so on, never more than 7 files.

 

Problem 1: Emby insists in using "movie-fanart.jpg" instead of "movie-poster.jpg" as the cover for the movie in the gallery. This doesn´t happen every time and I have not been able to isolate when it happens or what is producing it, but I have to manually select the "movie-poster.jpg" to correct it, this doesn´t happen only with multi part movies but also with one file movies.

 

Problem 2: When I start the movie in the first file "movie-cd1.mkv" the file plays ok, but when it finishes it goes back to the movie menu, not jumping to the "movie-cd2.mkv" file as expected, curiously when I play "movie-cd2.mkv" and it gets to the end of the file it automatically jumps to "movie-cd3.mkv" and goes on and on until it gets to the last file of the movie.

 

Problem 3: The movie is presented with an "aditional parts" menu and the first part is not in that menu (Of course I understand that is by design, but it whould be nice to have the first part also in that menu), this is not a problem, just a suggestion.

 

Problem 4: This is the most annoying of them all. When I use Ember Media Manager or Tiny Media manager they create a "movie.nfo" with all the data but Emby insists in creating a "movie-cd1.nfo" and ignoring the "movie.nfo", my solution is just to remane "movie.nfo" to "movie-cd1.nfo" but I find it curious that Emby is capable of detecting that a movie is a multi part file but not detecting that a .nfo file with the same name exists in the same folder

 

To this moment those are the "small problems" I have detected, I will be happy to provide any info anyone whould need.

Thanks

 

Edited January 2, 2025 by Sanduleak

[GrimReaper 4740]

33 minutes ago, Sanduleak said:

Problem 1: Emby insists in using "movie-fanart.jpg" instead of "movie-poster.jpg" as the cover for the movie in the gallery. This doesn´t happen every time and I have not been able to isolate when it happens or what is producing it, but I have to manually select the "movie-poster.jpg" to correct it, this doesn´t happen only with multi part movies but also with one file movies.

"movie-fanart.ext" is not listed as one of the supported naming conventions (which doesn't necessarily mean it ain't supported):

https://emby.media/support/articles/Movie-Naming.html#video-images

Quote

while there are several "movie-type.ext" variations for Primary (poster) images:

Quote

Maybe it's confusing parser, never used that backdrop naming so have no idea how would it behave, try dumping the "movie-"part from fanart filename, see how does it compare.

33 minutes ago, Sanduleak said:

Problem 2: When I start the movie in the first file "movie-cd1.mkv" the file plays ok, but when it finishes it goes back to the movie menu, not jumping to the "movie-cd2.mkv" file as expected

It should, specific example would be required:

how to report a media playback issue

33 minutes ago, Sanduleak said:

Problem 3: The movie is presented with an "aditional parts" menu and the first part is not in that menu (Of course I understand that is by design, but it whould be nice to have the first part also in that menu), this is not a problem, just a suggestion.

You are welcome to open FR topic in the appropriate forum section:

Feature Requests

33 minutes ago, Sanduleak said:

Problem 4: This is the most annoying of them all. When I use Ember Media Manager or Tiny Media manager they create a "movie.nfo" with all the data but Emby insists in creating a "movie-cd1.nfo" and ignoring the "movie.nfo", my solution is just to remane "movie.nfo" to "movie-cd1.nfo" but I find it curious that Emby is capable of detecting that a movie is a multi part file but not detecting that a .nfo file with the same name exists in the same folder

That appears as if Emby is looking for the exact <moviefilename>.nfo match (as with all the movies), and that would include "-cd1" part, @Luke?

 

 

Edited January 2, 2025 by GrimReaper

[Sanduleak 0]

9 minutes ago, GrimReaper said:

"movie-fanart.ext" is not listed as one of the supported naming conventions (which doesn't necessarily mean it ain't supported):

https://emby.media/support/articles/Movie-Naming.html#video-images

Never used that so have no idea how would it behave, try dumping the "movie-"part from filename, see how does it compare.

 

Oh, the problem is not with the "movie-fanart.ext", that works fine, the problem is that, even when there is a "movie-poster.ext" in the folder Emby just ignores it and uses "movie-fanart.ext" as the cover of the movie... maybe I should try to rename "movie-fanart.ext" to one of the supported naming conventions and see if that makes Emby find "movie-poster.ext"?

14 minutes ago, GrimReaper said:

It should, specific example would be required:

 

I will try to provide that example later.

14 minutes ago, GrimReaper said:

You are welcome to open FR topic in the appropriate forum section:

 

 

Oh, thanks, I will.

 

[GrimReaper 4740]

13 minutes ago, Sanduleak said:

maybe I should try to rename "movie-fanart.ext" to one of the supported naming conventions and see if that makes Emby find "movie-poster.ext"?

That was my suggestion, yes, see what gives:

29 minutes ago, GrimReaper said:

try dumping the "movie-"part from fanart filename, see how does it compare.