Sorry for the double post, I accidentally put this in the Android category first.
Windows 10, Plex version 2.7.0, server 1.0.0.2261.
Background: My media is stored on a NAS, my desktop has read access to all shares. Trying to add a new Movie library at root \\10.0.0.111\Video\Movies, and in that root folder I have a .plexignore file with the following:
Meta/*
So then, given the following directory structure, relative to the root:
I would expect ignore1.mkv and ignore2.mkv to be excluded, but they are not. However, when repeating the same test from my local Windows filesystem, it does properly ignore those two files. So it seems that sub folder ignore matching doesn’t work properly when using network shares.
I also repeated the test with adding the share as a mapped network drive, and recreated everything above but now from V:\ instead of \\10.0.0.111, and that still didn’t work.
I at first thought this was a regression of this bug:
But after confirming it filters properly on my local filesystem, it must be a problem with using network shares. Is this a known limitation?
** Title Edited by sa2000 9th January 2017 to reflect results of investigation below
I’m pretty sure something is wrong with plexignore. It works very inconsistently. Seems to work ok for the movie files I’m trying to hide, but not music files in my case.
Do any developers read this forum? Your .plexignore syntax still does not work as you say it should.
Tried again after several months, now on version 1.3.3.3148 and it still does not work. You have this beautiful software that is now literally on EVERYTHING, yet the server can’t do simple low-level stuff. In plain english… when scanning a library, if it comes across a folder named “Meta” anywhere, I want to exclude it and everything in it. Why is that so hard? I have a huge media library, meticulously organized, and I can provide a simple regular expression that would tell the scanner to ignore everything I want it to, yet Plex cannot handle this.
For anyone finding this with .plexignore issues… if you look at the source of the ignore parser, folder filters are matched via glob, while file filters converted to a regex.
Since my issue is trying to match against a Meta folder at any depth inside the root folder, I was able to match that with the double star glob filter:
**/Meta/*
On server v1.3.3.3148, that successfully ignores all the appropriate folders with just the single .plexignore file in the root.
Just noticed your thread from the link you provided in the other .plexignore thread
I have managed to reproduce the issue and will refer it to the development team
Sorry - double checking the logs - it worked ok. It added the folder to the list to be scanned but did not actually scan it
Jan 08, 2017 22:59:26.005 [35468] DEBUG - Adding subdirectory for scanner: \
as-london-1\Qmultimedia\Videos Test 1\Meta
The contents of the Meta folder and its subfolders got ignored ok
Tried it with both IP address and NAS name
The test I did was
Create a Videos library (Other Videos)
Root being \ as-london-1\Qmultimedia\Videos Test 1
I had mkv there in root and under it Meta folder and further mkv files and subfolder with mkv
\
as-london-1\Qmultimedia\Videos Test 1\Test File 1-1.mkv
\
as-london-1\Qmultimedia\Videos Test 1\.plexignore
\
as-london-1\Qmultimedia\Videos Test 1\Meta\Test File 1-2.mkv
\
as-london-1\Qmultimedia\Videos Test 1\Meta\Test Folder 1-3\Test File 1-3.mkv
The .plexignore file has one line
Meta/*
and it worked ok - ignoring the Test File 1-2.mkv and Test File 1-3.mkv files
The \ as-london-1\Qmultimedia\Videos Test 1\Meta folder was added to the list for scanning but contents did not get selected
Could you do a simple test and see if it works for you - please provide logs if it does not and zip of the .plexignore - using absolute paths in the zip
Thanks for taking the time to look into it. The problem was always the fact that it wouldn’t match folders inside nested sub folders. So in my original post, the example folder structure has the .plexignore in the share root, and the problem always has been getting it to match recursively.
So as you’ve set it up in your previous example, that works fine. But say the share root was \ as-london-1\Qmultimedia instead, and you only want to have one .plexignore file in the root folder. That does not work.
You’d think that:
*Meta/*
or
*/Meta/*
Would then match any child folder nested within the root named “Meta”. But that is not the case. When I posted the original issue, I think I tested it on a local drive, and it did correctly filter recursively like I wanted, but it would not when the root was a network drive. I don’t know whether or not that is still true.
However, after seeing it was using a glob pattern and trying
**/Meta/*
makes it work exactly the way I wanted it to. One .plexignore file in the root folder, ignores all the deeply nested folders named “Meta”. So is it functioning how I think it should according to the docs? Not exactly. But I found a way to get it to work the way I wanted it to so I’m happy
OK, this was driving me insane. Finally figured it out…
I could not reproduce it either on network drive using:
Meta/*
And a small test sample folder. This confused the hell out of me, so then I re-tried it on my movie library, but that failed to exclude the folders. Then I realized, it’s my naming convention - I put the movie year in brackets like so:
Move Title [2017] 720p
The brackets are special characters for a glob pattern and were causing the match to fail. When I added a similar naming to my small test folder, it failed to match too. In your example, if you rename Subfolder to Subfolder [1980], it should reproduce the issue.
Some kind of escaping would probably solve the problem.
That being the case,
**/Meta/*
is the only pattern that manages to exclude what it should given my naming style.
Thanks for helping debug the problem.
EDIT: I think when I was originally trying to reproduce it and saw that it worked on my local drives but not network, I did a simple test with folder names without brackets in them, which lead me to incorrectly believe that it only worked locally and not on network shares.
Would you happen to know if this was ever fixed? Is there a public bug tracker somewhere? As far as I can see, the scanner source code has not been updated since 2015 and would still have this issue.