Bug: Emby-Server Library Listing Error - Incorrect File Display

[ggs91 0]

This is a description of (I believe) a bug in Emby-Server. Under certain
conditions, detailed below, the listing of a library in the "Home->My Media"
area is displayed incorrectly. I am only describing this bug as it pertains
to video files. I have not verified if it also applies to picture files.

-- Computer Configuration --

Computer: HP p6516f Pavillion Desktop; 8Gb RAM; AMD Athlon 4-core processor
OS: Linux Lite V3.0 latest updates (Ubuntu 16.04 LTS core; XFCE V4 desktop)
Emby-Server: Version 3.2.26.0
Firefox: V54.0 (64-bit) for Ubuntu canonical - 1.0

-- Test Case Library --

Create a test library (Home->Admin->Manage Server->Library->Add Media Library)
of "Content type" "Home videos & photos", with default "Library Settings". Give
it any arbitrary "Display name" -- I'll use "TEST" here.

Add a folder that is in some convenient place, according to the usual
procedure. Save the library with "Ok". Nothing special here. This is just
for testing and (probably) has nothing to do with this bug.

NOTE:
After any change to the files in the library folder, as described below, it is
assumed that the library is re-scanned using "Home->Admin->Manage
Server->Library->Scan All Libraries".

-- Test Case --

Rename any arbitrary .MP4 file to "red0.mp4" and put it in the folder of the
TEST library. This should be the only file in the folder and only the filename
is important.

Look at the listing under "Home->My Media->TEST". It will correctly read "red0"
(the .mp4 extension is correctly hidden) and should play as expected. So far,
so good.

Rename a second arbitrary .MP4 file to "red1.mp4" and add it to the TEST
library folder.

The library folder now contains:
red0.mp4
red1.mp4

The Home->MyMedia->TEST listing should be:
red0
red1

Instead, only the following is displayed:
re

With the addition of the second file the listing only displays a single
corrupted filename "re" (i.e "d[01]" has been removed) that, when played, is
actually "red0.mp4". The "red1.mp4" file disappears from the listing although
it is still in the library folder, physically unharmed.

-- A General Description of the Conditions Causing the Error --

The Test Case above is a simple example of the bug. However, there are a number
of more complicated filename sets that will also cause this problem.
Following is  a more complete description of the filename format that will
cause the listing error.

The problem seems to be caused solely by sets of filenames. Metadata and file
content do not seem to matter.

There must be a set of two or more filenames in the library that follow the
pattern described below.  A single filename with this pattern will not, as far
as I can tell, cause a listing error, as noted in the first part of the Test
Case above.

-- The filename pattern that, in a set, will cause the error --

1. There must be an initial string, of one or more characters, that must match
between all of the filenames in the set. In the Test Case, this string is "re".

followed by:

2. Either the character 'd' or the character 'D' (i.e. case-insensitive [dD])

followed by:

3. Zero or more instances of the <space>, <dash/minus>, or <underscore>
characters, in any combination. The number and combination of these characters
does not have to match between filenames in the set.

followed by:

4. A number from 0 to 9. In the Test Case these were "0" and "1".

followed by:

5. Zero or more valid filename characters, that do not have to match in all of
the filenames of the set.

followed by:

6. A file extension that must match between all of the filenames in the
set. In the Test Case, this was ".mp4", but it could be any of the
supported file extensions (e.g. .WMV, .FLV, .AVI, .MKV, etc). Note that under
Linux, filenames, and thus extensions, are case-sensitive, which is not true
under Windows.

-- The Corrupt Filename That Will Result From This Bug --

The listing error will cause a set of filenames matching the pattern above to
display as a single corrupted filename in Home->My Media->TEST. The filename
will be the first sorted filename in the set, with the characters from [Dd] to
[0-9] (inclusive) removed. The file will play normally, but will only be the
single file that would be the first filename of a correctly listed set.

-- Examples --

The set of library files:
fred0.mp4
freD    1.mp4
fred__ __2.mp4
fred_3.mp4
fred -_-220.mp4
freD----374.mp4

Will display in Home->My Media->TEST as:
fre    (which will play as fred0.mp4)


The set of library files:
dead0fee.mp4
deaD  1fie.mp4
deaD__3foe.mp4
dead--4fum.mp4

Will display in Home->My Media->TEST as:
deafee    (which will play as Dead0fee.mp4)

An interesting wrinkle. If one or more valid filename characters that are not
<space>, <dash/minus> or <underscore> are interposed somewhere between [Dd] and
[0-9], the bug is inhibited for that filename.

Example:
food0fee.mp4
fooD  1fie.mp4
fooD_+___3foe.mp4     ('+' is added)
food-_blah_-4fum.mp4  ('blah' is added)

Will list as:
foofee           (corrupted filename)
fooD_+___3foe    (no bug here)
food-_blah_-4fum (or here)

-- Some Additional Notes --

In the Test Case, for simplicity, the "red[01].mp4" files were the only ones in
the folder. This does not have to be the case. There can be any arbitrary
number of files in the folder. The files with names that do not arrange
themselves into a set matching the criteria above that will activate the bug
will display and play correctly in the library listing.

The Emby-Server has been used to broadcast video to Roku devices using two
different Roku apps (latest versions): Roku Media Player and Emby Roku Player.
The library listings on both of these apps exhibit exactly the same errors as
the listings on Emby-Server. This seems to point the arrow.

END OF DOCUMENT
 

[ebr 16185]

Hi.  I believe your naming convention in your test case matches one of ours for defining multi-part movies (D0, D1, etc.).

 

So, the system is combining the videos into a single item as designed.

 

P.S.  Thank you very much for the detailed report.  That helps a lot in tracking these sorts of things down.

[Luke 42080]

Yea I think Ebr is right. These are close enough to our naming conventions for multi-part videos that they're falling into that:

 

https://github.com/MediaBrowser/Wiki/wiki/Movie%20naming