Support 'Cleanup' option on Grabber Editor Search page for filebased reader grabbers like NFO

[GoogleCodeExporter]

What area does your enhancement or feature relate to? (i.e. Config/Setup,
GUI, options, Skin, AMC Updater, Grabber Interface, etc.)
Grabber Editor/Interface
What is the purpose or benefit of the new feature or enhancement?
Particularly for grabbing from NFO files with multipart filenames (e.g. 
<movie>-CD1 etc). Although it may be useful in other cases as well to allow 
'cleanup' of filenames in filebased reader grabbers.
How would you expect it to work? (Accessed via, new settings required, Skin
changes/new properties)
Probably needs to support Regex to 'simulate' the same filename cleanups used 
in AMCU Scan Path and Filters tab - since the main issue is to ensure correct 
matches when grabbing using NFO where the NFO filename may not exactly match 
the media filename.
Can you illustrate it with examples such
as images (screenshots), scenarios or examples from other Plugins?

If this issue has been discussed in the MyFilms forum, add a link to the
related thread or post.
See Conversation: 
http://forum.team-mediaportal.com/conversations/nfo-grabber.109196/page-5

Original issue reported on code.google.com by Dade...@gmail.com on 10 Feb 2014 at 8:51

[GoogleCodeExporter]

This issue was closed by revision r3002.

Original comment by Guzz...@googlemail.com on 18 Jun 2014 at 12:02

• Changed state: Fixed

[GoogleCodeExporter]

Original comment by Guzz...@googlemail.com on 20 Jun 2014 at 5:24

• Added labels: Milestone-6.1.0, Priority-Medium, Difficulty-Minor

[GoogleCodeExporter]

When I open NFO grabber in Grabber Editor there is still no cleanup option 
available and it still doesn't work if you select a multi-part file.

Original comment by Dade...@gmail.com on 21 Jun 2014 at 2:38

• Changed state: ReOpened

[GoogleCodeExporter]

Field was visible, but the label not - will fix.

Original comment by Guzz...@googlemail.com on 21 Jun 2014 at 2:26

[GoogleCodeExporter]

This issue was closed by revision r3033.

Original comment by Guzz...@googlemail.com on 21 Jun 2014 at 2:27

• Changed state: Fixed

[GoogleCodeExporter]

I can verify the field (and label) now appear in Grabber Engine.
I'm not entirely sure how to test this though. 
I tried loading an NFO file with multipart ext - e.g. Step Up 3D (2010) -CD1.nfo
and entered " -CD1" in Cleanup but still get:
(51) URL (mapped)
C:\ProgramData\Team MediaPortal\MediaPortal\MyFilms\SampleMovies\Step Up 
(Group)\Step Up 3D (2010)\Step Up 3D (2010) -CD1.nfo
So I don't get cover or fanart (fields that use #NFO##Filename#)
I also tried adding AMCU filter for multipart files:
[-|_|.| +][cC][dD][0-9]|[-|_|.| +][dD][iI][sS][kKcC][0-9]|[0-9]of[0-9]
but that didn't work either.
So what am I doing wrong?"

Original comment by Dade...@gmail.com on 22 Jun 2014 at 8:29

[GoogleCodeExporter]

Hmmm, tbh, I am not sure, if we're talking about the same use case?
We have a multipart movie
movie-CD1.avi, movie-CD2.avi
and an nfo
movie.nfo
The goal is to identify the nfo file - we were not talking about images, right?
However, I can confirm, that it does NOT work as I hoped - will have to debug 
that issue. We might have to introduce code changes, e.g. "#Cleanup#" keywork 
for the nfo identification pattern to process the cleanup expression properly. 
That one could maybe also be used later on for images.
Re images, we discussed before, that currently, this is using some sort of 
"workaround" and it should be changed to use the details path subpage - that 
one lists all jpgs found in the movie directory and allows to get the proper 
ones with some regex I suppose...

Original comment by Guzz...@googlemail.com on 22 Jun 2014 at 9:40

[GoogleCodeExporter]

The original use case is that some systems (like AMCU Update NFO!) save the nfo 
file based on the movie name (not folder). So you get <movie name>-CD1.nfo or 
some such depending on your multipart filenames. AMCU correctly finds the 
movie/nfo and adds/updates it.

BUT when you download/import covers they are based on the movie name, not the 
filename. It is highly unlikely you have covers (or fanart) named <movie 
name>-CD1.jpg (or <movie name>-CD1-fanart.jpg for fanart) so they are not 
grabbed because NFO and filebased grabbers grab covers (and fanart) based on 
#NFO##FILENAME# they are not grabbed! That is why we need a way to clean up 
filenames for filebased grabbers. 

Maybe there is a better/easier solution?

Original comment by Dade...@gmail.com on 22 Jun 2014 at 10:26

[GoogleCodeExporter]

Ok, I debugged the code for the use case I descripbed above (to get nfo files 
named like media filename without multipart extensions - that was indeed not 
implemented properly and I fixed it.
I will now look at the covers and fanart grab parts and apply the same logig - 
so that should fix it I hope.

Original comment by Guzz...@googlemail.com on 22 Jun 2014 at 10:33

[GoogleCodeExporter]

This issue was closed by revision r3046.

Original comment by Guzz...@googlemail.com on 22 Jun 2014 at 10:36

[GoogleCodeExporter]

This issue was closed by revision r3047.

Original comment by Guzz...@googlemail.com on 22 Jun 2014 at 10:53

[GoogleCodeExporter]

I'm still not getting covers when using multipart files. Am I supposed to enter 
anything in the Cleanup field? It finds the NFO when I search/preview if I 
don't, but not if I add '-CD1'.

To reproduce cover issue:
1. Generate NFO for SampleMovies (or at least Avatar, which is multipart)
2. You should get Avatar (2009) CD1.nfo 
3. Ensure you have a cover named Avatar (2009).jpg
3. Create a quick test config using NFO and just the SampleMovies\Avatar folder 
for movies
4. Import that movie via AMCU

Everthing imports nicely EXCEPT the cover! :( and probably not fanart. Movies 
without multipart NFO/files import cover correctly using NFO grabber.

Original comment by Dade...@gmail.com on 24 Jun 2014 at 1:10

• Changed state: ReOpened

[GoogleCodeExporter]

ok, this is another use case. What I implemented was assuming, you have "Avatar 
(20089).nfo" - so you'd had to add a cleanup expression stripping the multipart 
extension and it would have found "Avatar (20089).jpg" too.
So what you need is not only applying the cleanup expression, but also 
searching for the noin cleaned expression, right? Should I implement that for 
all three parts (nfo, cover, fanart? (First searching for uncleaned file, then 
for cleaned file)

Original comment by Guzz...@googlemail.com on 24 Jun 2014 at 6:59

[GoogleCodeExporter]

I think we have to because AMCU Update NFO file handling saves nfo as multipart 
filename :(. Most catalogs save nfo and images as <movie title>, not <movie 
filename> like AMCU does. But it's possible MyVideos or one of the MovPics NFO 
methods also does.

Personally I would prefer to change AMCU NFO file naming to save nfo as <movie 
title>.nfo (e.g. cleaned filename) like most catalog managers do.  But your 
suggestion would ensure multlipart files/nfo/covers/fanart are correctly 
imported no matter which way they are stored.

Original comment by Dade...@gmail.com on 24 Jun 2014 at 7:11

[GoogleCodeExporter]

This issue was closed by revision r3053.

Original comment by Guzz...@googlemail.com on 24 Jun 2014 at 11:32

• Changed state: Fixed

[GoogleCodeExporter]

Unfortunately I still don't get covers for multipart files/nfo e.g. Avatar 
(2009) CD1.nfo (generated by AMCU Update NFO). If I change the cover image name 
to match the nfo filename (e.g. Avatar (2009) CD1.jpg it works.

Do I need to do update NFO grabber in some way to enable latest changes?

Grabber Engine still shows:
(51) URL (mapped)
C:\ProgramData\Team MediaPortal\MediaPortal\MyFilms\SampleMovies\Avatar\Avatar 
(2009) CD1.nfo
and
(62) Fanart (mapped)
C:\ProgramData\Team MediaPortal\MediaPortal\MyFilms\SampleMovies\Avatar\Avatar 
(2009) CD1-fanart.jpg
(63) Generic 1 (mapped)

but (79) Picture URL' (mapped) is empty

For now I would be happy if AMCU Update NFO either:
1. Cleaned up filename before saving it OR
2. Used folder name, not file name

Original comment by Dade...@gmail.com on 25 Jun 2014 at 7:54

• Changed state: ReOpened

[GoogleCodeExporter]

For the cleanup to apply, you have to define a value in the respective field - 
it will then try to find a "cleaned" value, but only, if it can't find an exact 
match (like media file name), so this should be deleted, otherwise it is used 
in case it exists.
Re the requested AMCU changes:
ad 1: well, we don't have a problem finding the nfo file, do we? Changing nfo 
filename there would make it even more difficult to later find it, as users 
might have individual expressions of name cleanup that we don't even know 
about, it is unpredictable.
ad 2: Folder name would be possible, but that is the same like using 
"movie.nfo" name to find and identify - again, this does not solve our problem 
finding the cover/fanart.
As mentioned above, it is maybe better using the new native feature to find 
artwork instead of the older "#NFO#" workaround - however, this probably also 
needs a small addition, as it is currently not automatically triggering the 
download...

Original comment by Guzz...@googlemail.com on 25 Jun 2014 at 8:32

[GoogleCodeExporter]

This issue was closed by revision r3067.

Original comment by Guzz...@googlemail.com on 26 Jun 2014 at 12:56

• Changed state: Fixed

[GoogleCodeExporter]

This issue was closed by revision r3068.

Original comment by Guzz...@googlemail.com on 26 Jun 2014 at 1:00

[GoogleCodeExporter]

This issue was closed by revision r3069.

Original comment by Guzz...@googlemail.com on 26 Jun 2014 at 1:00

[GoogleCodeExporter]

Verified
I fixed Regex to accommodate spaces in multi-part filenames (e.g. Avatar 
-CD1.avi) in revision r3073

Original comment by Dade...@gmail.com on 26 Jun 2014 at 11:53

• Changed state: Verified