Multi-series episode matching BUG

[pshanew]

I meant to post this much earlier but completely forgot. Back when we were originally discussing this, I linked this thread in another one where a user was having some strange matching issues. They made the off-hand remark that a workaround to your issue might be to present these files through a filesystem which masked the presence of hard links.

I’m not able to test this right now, but perhaps a bindfs mount, or cifs mount of the directory/directories with the hard-linked files?

If I find the time I might test this myself, as I’m curious now.

For reference, here’s the other thread:

Some content comes and goes when scanning, some content is simply skipped

Thanks! - No, no hard links is used in my setup. I guess the guy could just hide the hard links simply by exposing the files over a protocol that would hide them. But interesting find, it appears to me again that there is some very strange magic going on in the Scanner In my case everything is mounted in over CIFS from a Synology NAS; there are no local media files at the Plex server. The move between the staging and the final libraries is a simple file move inside the same CIFS mou…

[Philoplexer]

Those were some good ideas. After seeing your note, I gave the bind mount a try a couple different ways but, ultimately, since it’s just mounting a directory on disk to second location on that same disk, the same inodes for all the files in that directory still show up.

I might be wrong but I think any CIFS solution would be similar to creating a Windows network share and mounting that. I’m not sure how I’d do that without a second machine and a large latency. If you spot a way to leverage CIFS on one machine it would be interesting to see.

The title of that other poster’s thread is exactly how I would’ve described watching Plex scan a bunch files with hard or symbolic links because the files belong to two different series at the same time. It really just depends on which ones the scanner spots first and the de-duplicator purges from the metadata database as to which will finally win.

[pshanew]

Hmm… I just did a test with these files/folder hierarchy:

/home/myuser/test_tv/
├── MGM Cartoons (1934)
│   └── Season 1934
│       └── MGM Cartoons (1934) - S1940E02.mkv
└── Tom and Jerry (1940)
    └── Season 1940
        └── Tom and Jerry (1940) - S1940E01.mkv

The Tom and Jerry episode is a hard link to the MGM Cartoons episode. Pointing my test library to “test_tv” resulted in the behavior we observed earlier: When a scan is performed it finds one or the other series, but not both. Refreshing metadata causes the detection to flip to the other series.

To test the CIFS/SMB3 mount, I created a share on my system; in /etc/samba/smb.conf:

[tempcifs]
        path = /home/myuser/test_tv
        guest account =
        writeable = yes
        valid users = myuser
        user = myuser

Restarted smbd and nmbd:
sudo systemctl restart smbd nmdb

And then, still on the same system, mounted that share via the loopback interface on a temp directory:
sudo mount -t smb3 -o username=myuser //127.0.0.1/tempcifs /mnt/cifstest/

(/mnt/cifstest/ is owned by myuser.)

This is /mnt/cifstest/ after mounting:

/mnt/cifstest/
├── MGM Cartoons (1934)
│   └── Season 1934
│       └── MGM Cartoons (1934) - S1940E02.mkv
└── Tom and Jerry (1940)
    └── Season 1940
        └── Tom and Jerry (1940) - S1940E01.mkv

I removed my existing test_tv directory from the library configuration and added /mnt/cifstest. (Actually, I performed a Plex Dance to ensure there were no remnants of the previous configuration.) A scan was performed and it then matched both series separately, with correct metadata.

Some notes:

• I already had samba installed and configured on my server; the configuration I added above was in addition to the existing one.
• I tend to use CIFS and SMB(3) interchangeably. However, in this test, I’m mounting via SMB3. Just ignore that I named everything with cifs.
• This testing was done with a dummy file generated from dd:
  dd if=/dev/random of="MGM Cartoons (1934) - S1940E02.mkv" bs=1M count=10
  Then I created the hard link to it.
• I did some testing with bindfs as well but saw some weird results. I need to do those tests again.
• Other stuff I likely forgot.

All that to say it appears that looping back via a local network share might workaround this problem for you. If I were going to take this approach, I’d only do it for my problematic series. That is, put those series in a separate folder hierarchy and then only share that.

[Philoplexer]

Would you mind double-checking the inode values of the files (e.g., ls -i)? Your samba mounting approach is interesting and I’ve tried it three ways (slight variations on smb share definition, folder locations) but in both cases the every samba-mounted file exhibited the same inode as it’s original source. For a file with two hardlinks, its one inode shows up in four places.

Also, are /home and /mnt on the same filesystem in your example? Normally they would be but I figured I’d double check. My OS and library on on separate XFS filesystems, and I kept the samba test limited to just the library’s filesystem:

/home/library/
├── .plexfix
│   └── Episodes <---------------------------shared via samba
│       └── (content with hardlinked files)
└── Episodes     <---------------------------Plex TV Series Library
    └── Plexfix  <---------------------------samba share mount location
        └── (content with hardlinked files)

Essentially, I’m seeing the same behavior that I saw with the bind mount experiment.

[pshanew]

Here you go:

myuser@computestick:/mnt$ find ./cifstest -type f -exec stat {} \;
  File: ./cifstest/MGM Cartoons (1934)/Season 1934/MGM Cartoons (1934) - S1940E02.mkv
  Size: 1048576   	Blocks: 2048       IO Block: 1048576 regular file
Device: 2eh/46d	Inode: 3055        Links: 1
Access: (0755/-rwxr-xr-x)  Uid: ( 1000/myuser)   Gid: ( 1000/myuser)
Access: 2024-02-09 18:04:52.013834400 -0500
Modify: 2024-02-09 17:57:56.443196300 -0500
Change: 2024-02-09 17:57:56.443196300 -0500
 Birth: 2024-02-09 17:57:56.078340000 -0500
  File: ./cifstest/Tom and Jerry (1940)/Season 1940/Tom and Jerry (1940) - S1940E01.mkv
  Size: 1048576   	Blocks: 2048       IO Block: 1048576 regular file
Device: 2eh/46d	Inode: 3057        Links: 1
Access: (0755/-rwxr-xr-x)  Uid: ( 1000/myuser)   Gid: ( 1000/myuser)
Access: 2024-02-09 18:04:52.013834400 -0500
Modify: 2024-02-09 17:57:56.443196300 -0500
Change: 2024-02-09 17:57:56.443196300 -0500
 Birth: 2024-02-09 17:57:56.078340000 -0500

I’m using the ‘noserverino’ option in my mount command, which is likely affecting this. I only added this today, but it was working without it in my initial tests (though the real inodes were exposed there).

[Philoplexer]

pshanew for the win!!!

Adding the -o noserverino to the mount command makes all the difference. Either the RHEL kernel or the XFS filesystem, or the combo of both, were passing the inode data straight through before. The noserverino option obfuscates the original inodes quite nicely. I think a straight bind mount might be a little cleaner than using cifs/samba and a loopback device, so I’ll give that a try next, but this bit of trickery has finally fooled Plex into working the way it should.

And subsequent calls to “Scan Library Files” aren’t undoing the result, either: it’s stable.

Hallelujah!

[pshanew]

Nice, glad you got it working!

[Philoplexer]

It turns out bind mounts don’t support the noserverino option, so samba is currently the best and only solution.