Profile Match Used When It Shouldn't Have

msmart

New member
Using VAP 1.05 with these arguments: -p0 -hotstart -metapytivo -config:1. I processed a file last night and a profile was used based on profile match but it shouldn't have. It should have used the active Output Profile instead (H.264 M4v iPod Touch - 640x368).

From the log:

12/31/2012 5:15:25 AM Started auto-cuts, input: Despicable Me (Recorded Sep 16, 2012, HBOP)
12/31/2012 5:15:25 AM Using profile "H.264 MP4 iPod Touch" based on profile match file
12/31/2012 5:15:25 AM Using profile: H.264 MP4 iPod Touch
12/31/2012 5:15:31 AM VideoReDo said: INFO: VideoReDo version 4.20.7.629 - Nov 7 2011
12/31/2012 9:54:35 AM VideoReDo completed manual cuts on: Despicable Me (Recorded Sep 16, 2012, HBOP)

Needless to say, "Despicable Me" is not in my ProfileMatchList1.txt file.

Other files were processed during the same run so I'm not sure if it plays into what happened. I can give you the unabridged log file if you need.
 

dlflannery

Moderator
Please post or attach all your ProfileMatchList#.txt files that you use. Also, could you update to VAP 1.08? Are your input files .tivo?

It might help to get the portion of the log file that covers processing the problem file, plus the file processed before it.
 
Last edited:

msmart

New member
I'll update to 1.08 and try again. If the problem persists, I'll get you the files. Yes, all files are .tivo.
 

msmart

New member
The problem persists. With a different file as well.

Files attached. (Let me know when you got them so I can delete them.)

PS Happy New Year!!
 
Last edited:

dlflannery

Moderator
I've got the files, thanks.

Does this just happen for that one particular file? If not please describe the type files it happens on as best you can. Also, did this just start?

EDIT (After looking at your profile match list and reviewing code behavior):
Think I see the problem (or two):

Matching occurs if any portion of the input file name (including extension) contains the match string, and is not case-sensitive.

Thus:
1. The match string "V" will match any input file name that has (upper or lower case) 'v' in it, i.e., any .tivo file!. Why hasn't this caused more problems? Probably because the matches are compared in the order listed in the ProfileMatchList#.txt file and the first match is used. Thus if there is a match for any of the match strings prior to the 'V' item, that match will govern.

How to get around this? One idea is to make the match string longer, perhaps: "V (recorded"
Obviously you have to be careful to have the right number of spaces between 'V' and "(recorded". Actually if you're unsure about that, you can configure multiple match strings with differing number of spaces! (An additional match string might add a few milliseconds to VAP processing time. ;))

2. Consider the entries:
Code:
An Idiot Abroad :: H.264 M4v iPod Touch - 640x368 :: .m4v :: true :: true :: false
An Idiot Abroad The Bucket List :: H.264 M4v iPod Touch - 640x368 :: .m4v :: true :: true :: false
The second match will never occur since the match string is a superset of the first match string. In this case no harm is done since the two match strings have identical profiles and process flow flags. If you wanted to define different profiles for these two cases, you could just reverse the order in the list (so the longer match string case would be tried first).
 
Last edited:

msmart

New member
I haven't been processing files with VAP (or at all for that matter) for quite some time sine I had been having PC stability issues. Just getting back to it.

Matching occurs if any portion of the input file name (including extension) contains the match string, and is not case-sensitive.
Ah, hadn't considered that. I figured it looked only at the show name alone. Silly me. Given that I won't be processing any new files for the show V, I removed it from the match file. Problem solved.

I'll also update the entry for An Idiot Abroad. Why TiVo or the network had to change the show name the second season I'll never know, but that's beside the point.

Anyways, I'm glad this was an easy fix. Good chatting with you.
 
Top Bottom