Post reply

Warning: this topic has not been posted in for at least 120 days.
Unless you're sure you want to reply, please consider starting a new topic.

Note: this post will not display until it's been approved by a moderator.

Name:
Email:
Subject:
Message icon:

Attach:
(Clear Attachment)
(more attachments)
Allowed file types: gif, jpg, png, txt, tpl, lng, ini, pvd, psf, ini, cfg, csv, zip, xml, pas, 7z
Restrictions: 4 per post, maximum total size 1024KB, maximum individual size 1024KB
Note that any files attached will not be displayed until approved by a moderator.
Verification:
Type the letters shown in the picture
Listen to the letters / Request another image

Type the letters shown in the picture:
What is the best video database software?:

shortcuts: hit alt+s to submit/post or alt+p to preview


Topic Summary

Posted by: Lordfinarfin
« on: May 06, 2010, 09:59:05 am »

If the file scanner has detected a change in the file, it should update the information as I described. I can only guess you're still asking NMM to add files—so when the scanner is run afterwards, no changes are detected.

Thanks for your help, The problem was that I am asking NMM to add files.
Posted by: rick.ca
« on: May 05, 2010, 07:30:30 pm »

If the file scanner has detected a change in the file, it should update the information as I described. I can only guess you're still asking NMM to add files—so when the scanner is run afterwards, no changes are detected.
Posted by: Lordfinarfin
« on: May 05, 2010, 02:50:30 pm »

Setting a field to not be overwritten only makes a difference if something is already there. If NMM runs the download plugin first, it's going to get the English episode title. If you run the file scanner after downloading the series, it will replace the episode titles with those from the filenames. If you then update the episodes, with the overwrite setting off for Title and on for Original title, you should end up with a Spanish Title and English Original title—as in the attached screen shot.

If I first run NMM it get episode tittle from IMDB. Then If I launch the file scanner, this tool do not detect any change, so the episode tittle remain in english. DO you know why?
Posted by: rick.ca
« on: May 04, 2010, 09:00:23 pm »

Setting a field to not be overwritten only makes a difference if something is already there. If NMM runs the download plugin first, it's going to get the English episode title. If you run the file scanner after downloading the series, it will replace the episode titles with those from the filenames. If you then update the episodes, with the overwrite setting off for Title and on for Original title, you should end up with a Spanish Title and English Original title—as in the attached screen shot.

[attachment deleted by admin]
Posted by: Lordfinarfin
« on: May 04, 2010, 04:57:44 pm »

Rememenber that Im a spanish user, so, sometimes I have the episode names in spanish, and IMDB return the name in english, that is why I prefer this way.

I was commenting for the benefit of others reading this as well. In your circumstance, where the IMDb record is in English, you'll probably do better updating the series than attempting to update each episode as it is added—using a Spanish episode title it will not be able to find. By setting the plugin not to overwrite Title, you should end up with a Spanish Title and English Original title. And, for a Spanish series, adding the episode title from the filename is only going to help.

Well. Now I test with Babylon 5 (english serie). I have the episode title in spanish.

If I add a this TV serie using "New movie master (CTRL+M)", setting:
Movie Information > IMDB
Movie Poster > nothing
cover > nothing
File information > "active"
Tittle > Babylon 5
Original Tittle > "nothing"
File(s) > I browse to the main folder Babylon 5

I desactivate the option in the pluggin to not allow to replace the Tittle.

The  result is that PVD get the episode tittle from IMDB in english.
Posted by: Lordfinarfin
« on: May 04, 2010, 12:49:45 pm »

Rememenber that Im a spanish user, so, sometimes I have the episode names in spanish, and IMDB return the name in english, that is why I prefer this way.

I was commenting for the benefit of others reading this as well. In your circumstance, where the IMDb record is in English, you'll probably do better updating the series than attempting to update each episode as it is added—using a Spanish episode title it will not be able to find. By setting the plugin not to overwrite Title, you should end up with a Spanish Title and English Original title. And, for a Spanish series, adding the episode title from the filename is only going to help.

I will try it.

My regex is ok?
Posted by: rick.ca
« on: May 04, 2010, 10:42:17 am »

Rememenber that Im a spanish user, so, sometimes I have the episode names in spanish, and IMDB return the name in english, that is why I prefer this way.

I was commenting for the benefit of others reading this as well. In your circumstance, where the IMDb record is in English, you'll probably do better updating the series than attempting to update each episode as it is added—using a Spanish episode title it will not be able to find. By setting the plugin not to overwrite Title, you should end up with a Spanish Title and English Original title. And, for a Spanish series, adding the episode title from the filename is only going to help.
Posted by: Lordfinarfin
« on: May 04, 2010, 09:42:49 am »

Rememenber that Im a spanish user, so, sometimes I have the episode names in spanish, and IMDB return the name in english, that is why I prefer this way.
Posted by: rick.ca
« on: May 03, 2010, 11:53:12 pm »

Sorry, I meant ...(?P<eptitle>.*)\..{3,4} not ...(?P<eptitle>)\..{3,4}. Without the "any number of any character" there could be no match for <eptitle>. I suppose that results in the expression doing nothing, and the whole filename is therefore treated as a Title by default. :-\

Your solution of ...(?P<eptitle>[^.]+) means "one or more character not a period." That, of course, will match everything up to a period, whether in the episode title or the beginning of the extension—and the rest is ignored.

BTW, this whole business is not so complicated if you consider it's almost impossible not to match "(YEAR)" or "0x00" or "S00 E00". So if these are used in filename patterns to separate a movie title from other information or a series title from an episode title (or other information), it's difficult to go wrong.

Quote
Second, there's no need to get the episode title from the filename if that is being downloaded anyway.

This may not always be true. When updating episodes as they're released, the IMDb plugin uses the episode title to search for the record (even though the season and episode number are known). This is not the case for The TVDb. I download from both, so I get the episode title from there first, and then the IMDb is able to use that in it's search. If an episode title is provided, but the IMDb hasn't yet recorded one (i.e., it's still using something like "Episode #2.19"), that record probably won't be found. I suppose that doesn't matter, however, because it probably doesn't have anything of value. So, when updating episodes as they are released from the IMDb only, it may very well be helpful to get the episode title from the filename.

For updating episodes not recently released, it's more efficient to update the series record. This will add the URL's of all available episodes, and then no search will be necessary to find them.
Posted by: Lordfinarfin
« on: May 03, 2010, 01:00:16 pm »

Continue with my last Thread about it......

To test de regex I delete all the regex availables.

File name example >
<tv serie tittle> - <season - episode> - <episode tittle>

Example: Aqui no hay quien viva - 1x01 - Erase una mudanza.avi


(?i)^.*\\(?P<title>.*)(s|\b)(?P<season>[0-9]{1,3})e(?P<episode>[0-9]{1,3}) > original > Result > "Aqui no hay quien viva - 1x01 - Erase una mudanza"

(?i)^.*\\(?P<title>.*)(s|\b)(?P<season>[0-9]{1,3})x(?P<episode>[0-9]{1,3}) > result: "1"

(?i)^.*\\(?P<title>.*).?-.?(?P<season>[0-9]{1,3})x(?P<episode>[0-9]{1,3}).?-.?(?P<eptitle>\w*\b) > Original > Result: "Erase"

(?i)^.*\\(?P<title>.*).?-.?(?P<season>[0-9]{1,3})x(?P<episode>[0-9]{1,3}).?-.?(?P<eptitle>)\..{3,4} > suggested by rick.ca > result: "Aqui no hay quien viva - 1x01 - Erase una mudanza"


At this point I started trying several combinations found trough internet, due to my lack of experiense with code or language

(?i)^.*\\(?P<title>.*).?-.?(?P<season>[0-9]{1,3})x(?P<episode>[0-9]{1,3}).?-.?(?P<eptitle>*\W)$ > Result: "Aqui no hay quien viva - 1x01 - Erase una mudanza avi" it doesnt remove the file extention

(?i)^.*\\(?P<title>.*).?-.?(?P<season>[0-9]{1,3})x(?P<episode>[0-9]{1,3}).?-.?(?P<eptitle>[^\\/]*[.avi$]) > Result: "Aqui no hay quien viva - 1x01 - Erase una mudanza avi" it doesnt remove the file extention


I manage to solve the problem, "WITH MY FILE STRUCTURE" with next expresion.

(?i)^.*\\(?P<title>.*).?-.?(?P<season>[0-9]{1,3})x(?P<episode>[0-9]{1,3}).?-.?(?P<eptitle>[^.]+) > ok > result: "Erase una mudanza"

The problem I found with it is that I cant put a dot into the episode title
Posted by: buah
« on: May 02, 2010, 03:36:33 am »

I asked it hopefully you'd answer something different than me.
Posted by: rick.ca
« on: May 02, 2010, 02:28:19 am »

Quote
Now I'm confused.

I don't understand why. You asked a question. I answered it fully. I hope it's not because your question was rhetorical. ::)

My opinion that the idea is flawed was a separate idea, stated in a separate paragraph. I'm sorry if you feel it's a rejection of your idea. But after considerable thought (which I think is evident from my previous posts), it's one I believe is reasonable and with which I'm perfectly comfortable.
Posted by: buah
« on: May 01, 2010, 10:35:46 pm »

The expressions are processed in order—until a match is found. So if one is added to a position in the list after an existing one that already matches, it won't be processed. The fact of a match does not mean the existing expression does so correctly. Not only does the added expression have to match, preceding expressions that aren't meant to match have to not match.

Now I'm confused. In my last post I said that it's not clear to me how it's possible for a proven regex not to work, unless it is not set in the right place in Preferences, then you confirmed it won't work if it's not set in a right place in Preferences, then you said that I've illustrated a bigger flaw in the idea?

And my idea was exactly to save your energy, which you undoubtedly spend a lot, and I personally thank you for that.
Posted by: rick.ca
« on: May 01, 2010, 09:23:28 pm »

The expressions are processed in order—until a match is found. So if one is added to a position in the list after an existing one that already matches, it won't be processed. The fact of a match does not mean the existing expression does so correctly. Not only does the added expression have to match, preceding expressions that aren't meant to match have to not match.

But I think you've illustrated a bigger flaw in the idea. Most users don't understand regex, and are therefore reluctant to accept one of the necessary evils: either (1) learn enough about regex to make the modification necessary so your filenames are correctly recognized, or (2) change your filenames so they are recognized by the default regex. Providing a list will only appeal to those who want to do neither, and shift the pain onto those maintaining the list. I think I'll save my energy for those interested in helping themselves.
Posted by: buah
« on: May 01, 2010, 07:48:59 pm »

Well,
Please don't blame me for missing your point which was, as I understood, that it's impossible to finite sets in use.

In your last post you motivated another point of view, that's how I see it.

What I don't know is how
Quote
They add the "proven" regex to their configuration, and it still doesn't work
is possible, unless it's the order of regex set in Preferences to blame? Answer on this question will help me to better understand regex, and indirectly PVD functioning.
Posted by: rick.ca
« on: May 01, 2010, 07:21:46 pm »

Quote
We don't have to, need to or tend to...

It seems you're missing my point. Let's say someone has one specific filename pattern that's not being properly recognized by the default regex. They ask for help here, and someone suggests an expression. This expression is tested and proven to work for the given filename pattern. You're suggesting we create a list of these patterns with proven regex—in a locked topic. I'm saying this will be of limited use, if not misleading. Consider...

Another new user, using exactly the same filename pattern, finds it's entry in this list. They add the "proven" regex to their configuration, and it still doesn't work. Oops. We forgot to consider all the regex in the configuration continue to function. So a similar one in the default set still matches and occurs first. So should the list indicate which expressions should be removed when the "proven" one is added? No, we can't do that. It may still be applicable to another filename pattern. The list fails to recognize the proper solution could be to (1) replace an existing expression with the recommended one, (2) have two expressions, but put them in an order that doesn't result in conflicts, or (3) revise the existing expression so it will recognize both filename patterns. The last is obviously the best solution, and will rarely be found by anyone relying on such a list—especially if unfamiliar with regex.

My suggestion, as awkward as it may seem, provides a way of directing the user to the default expression that most closely fits their filename pattern. They may then effectively consider what changes might be necessary to their configuration (e.g., consider the three choices mentioned). If they need help they can ask. When the problem is solved—assuming there is a discussion about it—the list can be updated with another example, comment or variation. If that's not possible—because the solution is to add a completely different expression to the set—this new expression can still be documented in the same manner. I could provide a second list (in the message following the first) for such "custom" expressions. We could periodically consider which of these should be added to the default configuration.

Quote
...or in PVD Wiki, why not.

Because it doesn't provide for a one-stop place for reference, discussion and help. Anyone is welcome to copy any material in this forum and add it to the wiki—where it may serve as a more permanent and static reference.
Posted by: buah
« on: May 01, 2010, 11:23:39 am »

Quote
My point is, we would never be able to pin down a finite number of filename pattern sets in use

We don't have to, need to or tend to. My idea was to constantly pin down in a separate pinned topic only those filename patterns discussed here and for which regexs were resolved (confirmed, proven). According to this, and taking place of an average user who's almost for sure inexperienced with regex, probably it would be appropriate to format your idea as

Type/Example (discussed in this forum)/Regex (resolved, you need to type in PVD's Preferences)

... or in PVD Wiki, why not.
Posted by: Lordfinarfin
« on: May 01, 2010, 10:14:41 am »

(sory for my english xD) I did that at work xD, so i dont have all the structures that I tried.  My expression exclude all the words that appear after a dot. Problem? you cant put a dot in the middle of an episode tittle. This formula is to remove the file the file extension.
Posted by: patch
« on: May 01, 2010, 03:02:36 am »

Considering this, I suggest to pin a topic with proven regexps for different syntax of file names. In such a topic, comments wouldn't be allowed ... only filename -> contributed proven regexp.
...
Any thoughts?
Why not put it in the PVD wiki
Posted by: rick.ca
« on: May 01, 2010, 02:37:25 am »

Quote
Because of sake of other users who might found it useful, I think it was a good idea not to open new topic but to activate old one you started, both of them upon same issue.

I thought it seemed familiar... ;)

Thanks. Topics merged.

Quote
Considering this, I suggest to pin a topic with proven regexps for different syntax of file names.

Hmmm... If one were deciding what filename structures to use that would work in PVD, there are a variety of answers easily determined by examining the regex. The problem is, most users already have files and would rather not have to change them to suit the regex provided. Users in that circumstance have to accept the choice they face: Either modify the regex to suit their filenames, or change their filenames to suit the regex. Then there are those who not only use patterns not recognized by the regex provided, they use a variety of different patterns. That, of course, makes everything more complicated. Generally, each pattern will require it's own regex, and more care will be necessary to ensure the regex don't conflict with one another and are processed in the correct order.

My point is, we would never be able to pin down a finite number of filename pattern sets in use. And it would mean listing a complete set of regex (in the correct order) for each. It would be much easier—and probably more useful—to document the intended purpose of each of the regex provided, together with examples of filename patterns that are correctly interpreted by each one. From that, it might be easier for a user to find a filename pattern close to what they are using, and then determine what modification is necessary so it would work for them.

This is the format I'm imagining...

Type/Regex/ExampleComments
Type:
1. Series (title in filename)folder ignored
Regex:
(?i)^.*\\(?P<title>.*)(s|\b)(?P<season>[0-9]{1,3})e(?P<episode>[0-9]{1,3})   case insensitive
Example:
Series title s01e01 remainder ignored.ext1-3 digit series/episode numbers
Variation:
Series title S01 E01.extadd a space before the "e"


Type:
2. Series (hyphen-delimited with episode title)folder ignored
Regex:
(?i)^.*\\(?P<title>.*).?-.?(?P<season>[0-9]{1,3})x(?P<episode>[0-9]{1,3}).?-.?(?P<eptitle>\w*\b)does "\w*\b" match a one
Example:
Series title - 1x001 episodetitle.extword episode title only?
Variation:
Series title - 1x001 episode title.ext...change to "\..{3,4}"



I could post the skeleton of such a thing, and then others could help flesh it out by posting suggestions and examples to the topic (e.g., "here's another example for type 1..."). I would then add those to the top post. Users could also post their personal modifications in the same format (e.g., "type 2 did not work for my series filenames, so I replaced it with this...").

Would such a topic be helpful, or too mind-numbing to be of any use? :-\
anything