Feature Requests and Response Status

vidiot1985

New member
I don't need to create DRAX files, so I normally won't try to create both formats.

Thanks for the correction about the meaning of "<CutList/>", I'm glad learn something new every day. :)

On the .tp extension, thanks, I totally missed that Extension field!

I'll try it some more with other video files and see if I can get TVSuite5's auto-cut stuff to work interactively first. I may have to play with the block length tuning.

When I've used the Ad Detective interactively, I've used it only to find transition points, then done the cutting manually, never to auto-cut.

OK, I tried it with another video file and it worked mostly as desired, successfully finding at least one .vprj <CutList> entry to translate into a .chapters.xml. So now it's a matter of tuning the ad detective parameters.

Thanks for all your efforts!
 

vidiot1985

New member
I've had it running for a couple of days now, successfully generating useful BeyondTV chapters.xml files for video programs from a variety of TV networks and it seems to be working decently well on normal programs, about as well as the original BeyondTV Smart Chapters processing at its best.

Programs with short programming content in between long commercial breaks (a common thing in some late night talk shows), or lots jump cuts like weather alerts, breaking news, out of sync handoffs between local and network feeds are problematic and hard to tweak out, but that's not unexpected.

Thanks again!
 

dlflannery

Moderator
Glad this is helping you. I've been considering adding another work flow to VAP that would allow you to review/modify the cuts before finalizing the .vprj file and creating the BTV chapters file. It would also have other advantages compared with the recent mod:

1. You could use ComSkip commercial detection if desired.
2. You could skip the QSF step if desired.

Would this be of value to you?
 

vidiot1985

New member
Glad this is helping you. I've been considering adding another work flow to VAP that would allow you to review/modify the cuts before finalizing the .vprj file and creating the BTV chapters file. It would also have other advantages compared with the recent mod:

1. You could use ComSkip commercial detection if desired.
2. You could skip the QSF step if desired.

Would this be of value to you?
I don't think I would normally want to review the .vprj before generating the chapters.xml file. But having the ability/option to keep around the .vprj from which the chapters.xml is produced is helpful. Most of the video I'm dealing with is of the watch-once-and-delete variety (maybe saving a small segment) so inaccurate chapters isn't that big a deal--it's just for skipping commercials while watching. I occasionally want to archive an entire program with commercials removed accurately and maybe burned to DVD via TVSuite, but for those relatively rare cases, having the .vprj left around for a starting point for manual checking for accuracy is sufficient, independent of the chapters.xml generation for BeyondTV viewing.

Being able to optionally skip the QSF step is useful to run a little quicker and avoid potential space issues since I tend to run close to the edge of free space on the drive I use for BeyondTV.

I read a lot of good things about Comskip on the BeyondTV forums, but never felt motivated to get it working with BeyondTV since its built-in Smart Chapters has worked well enough for me until recently. The ability to use Comskip as an alternative to the TVSuite Ad Detective and produce a chapters.xml from that would be a nice to have option, but for now, I'm having good success with what you've generously provided already and wouldn't want to ask you to do anything more.

However, if this is something you would want to do anyway, I'd be happy to try it out and see how it compares to Ad Detective in my rig.

Thanks!
 
Last edited:

TPeterson

New member
This is certainly a terrific app. One feature that I'd like to see added is for it to handle extended characters in file names. E.g., the Stephen Colbert episode names often include guest names with diacritical marks on letters, such as "áøü", and those cause VAP's VRD launch to fail and it then moves the file to the Failed Files folder. Thanks for considering this.
 

dlflannery

Moderator
This is certainly a terrific app. One feature that I'd like to see added is for it to handle extended characters in file names. E.g., the Stephen Colbert episode names often include guest names with diacritical marks on letters, such as "áøü", and those cause VAP's VRD launch to fail and it then moves the file to the Failed Files folder. Thanks for considering this.
Can VideoReDo (VRD) load and process these files manually (not within VAP)? I'm guessing this is a VRD problem, in which case VAP would have to rename the file without extended characters in order to get VRD to process it. This approach could be considered.


Also please include some example file names in your post. Be sure to enclose them in code so they don't get modified by posting.
 
Last edited:

TPeterson

New member
Can VideoReDo (VRD) load and process these files manually (not within VAP)? I'm guessing this is a VRD problem, in which case VAP would have to rename the file without extended characters in order to get VRD to process it. This approach could be considered.


Also please include some example file names in your post. Be sure to enclose them in code so they don't get modified by posting.
Thanks for your reply. Attached is the section of VAP's log file for a run where there was a failed file caused by an extended character (e-umlaut) in the name Chloë. I found out that the only issue with it was that VAP's vprj file (the name of which actually included the e-umlaut) incorrectly specified the file for VRD to process by changing the e-umlaut to a pair of other characters. When I edited the vprj file in Wordpad to change that character pair back to an e-umlaut (<ctrl>-:, e) and then saved and executed it, VRD was perfectly happy to process it. I would have also attached the vprj file, but it's been deleted so I hope that this information is sufficient for clear understanding.
 

Attachments

dlflannery

Moderator
Thanks for your reply. Attached is the section of VAP's log file for a run where there was a failed file caused by an extended character (e-umlaut) in the name Chloë. I found out that the only issue with it was that VAP's vprj file (the name of which actually included the e-umlaut) incorrectly specified the file for VRD to process by changing the e-umlaut to a pair of other characters. When I edited the vprj file in Wordpad to change that character pair back to an e-umlaut (<ctrl>-:, e) and then saved and executed it, VRD was perfectly happy to process it. I would have also attached the vprj file, but it's been deleted so I hope that this information is sufficient for clear understanding.
Try test version 1.37T2 downloadable here:
https://vap.videoredo.net/VAPexe137T2.zip
NOTE: This is only a substitute executable file NOT an installer.

Thanks for your debug info. The problem is caused by the text formatting of the .vprj file produced by comskip. I've added a cleanup routine that seems to handle the special characters in my testing.
 

TPeterson

New member
I think that you nailed it. I set up a dummy ts file with one of the offending names, put it in the Monitored folder, and VAP (comskip) processed it without errors. Thanks again!
 

dlflannery

Moderator
Try test version 1.37T2 downloadable here:
https://vap.videoredo.net/VAPexe137T2.zip
NOTE: This is only a substitute executable file NOT an installer.

Thanks for your debug info. The problem is caused by the text formatting of the .vprj file produced by comskip. I've added a cleanup routine that seems to handle the special characters in my testing.
I think that you nailed it. I set up a dummy ts file with one of the offending names, put it in the Monitored folder, and VAP (comskip) processed it without errors. Thanks again!
Ver. 1.37 has been released, functionally identical to 1.37T2
 
Last edited:

TPeterson

New member
Oops. I just installed Ver. 1.39 and found that it evidently does not incorporate the fix that you put into 1.37 because it bombed on last night's Colbert program:

The Late Show With Stephen Colbert-Phil McGraw; Kayli Carter; Janelle Monáe
 

dlflannery

Moderator
Oops. I just installed Ver. 1.39 and found that it evidently does not incorporate the fix that you put into 1.37 because it bombed on last night's Colbert program:

The Late Show With Stephen Colbert-Phil McGraw; Kayli Carter; Janelle Monáe
Can you provide a VAP log file excerpt and/or the .vprj file created by ComSkip?
 

TPeterson

New member
BTW, since this is a problem caused by comskip, an app that appears to have non-english users, it seem odd that there is no configuration setting in that app that would avoid the issue of non-ASCII characters in names.
 

dlflannery

Moderator
Oops. I just installed Ver. 1.39 and found that it evidently does not incorporate the fix that you put into 1.37 because it bombed on last night's Colbert program:

The Late Show With Stephen Colbert-Phil McGraw; Kayli Carter; Janelle Monáe
Using ver. 1.39 and an input file named "The Late Show With Stephen Colbert-Phil McGraw; Kayli Carter; Janelle Monáe.ts" I am unable to duplicate this problem. When I copy-paste that file name from your post the character á comes through as Unicode 0x00E1 which is "Latin small letter a with acute" which I would call accented a. Comskip's output .vprj file has the á in UTF-8 format but VAP 1.39 converts it to the correct Unicode (code page 1252) before feeding it to VRD. The .vprj file you furnished does NOT have that correction made -- the á is in UTF-8 format.

Possible explanations for differences between my results and yours:
1. Copy and paste from your post doesn't maintain the actual á character used on your system. Very unlikely I think.
2. I notice theTVDB searches succeeded on your system and they don't on mine. I'm guessing that's because you are using an input-file-parsing template to parse out parameters that allow theTVDB searching to succeed.
3. You are using any old version of VRD. (I'm not willing to install an older version for debugging purposes). I don't see how this can explain it. The problem occurs because the .vprj file has the wrong (UTF-8) encoding for á in the file name line.

If you furnish me your input file parsing templates, we can eliminate difference #2.

Also, try substituting the VAP executable Ver. 1.40T4 (not an installer) in the attached zip. It shouldn't make any difference in the issue at hand but it does have a correction for similar UTF-8 vs. Unicode problems that were showing up in the log file.
 

Attachments

dlflannery

Moderator
OK, using Ver. 1.39 with process flow of Do Ad Scan + Use ComSkip Ad Scans + Auto Cut after Ad Scans
Input file = 181026-29.1-The Late Show With Stephen Colbert-Phil McGraw; Kayli Carter; Janelle Monáe.ts
filename parsing template = {wildcard2}-{wildcard}-{title}-{eptitle} for .ts input files
TV Series Output file template = c:\temp\mgmoves\{title}\{year}-{month}-{day}({wildcard2})_{wildcard}_{eptitle}

Processing succeeded.
theTVDB metadata search succeeded.
output file = 2018-10-26(181026)_29.1_Phil McGraw; Kayli Carter; Janelle Monáe.ts
the file name line in the .vprj file had the correct 'á' character.

So it would appear your issues must be related to differences in one of the following files:
1. The input video (I used one I had on hand, renamed to your input file name)
2. Your VRD executable (different version than mine)
3. Your ComSkip.exe and .ini (I used those distributed with VAP 1.39)

I believe the key issue is the UTF-8 version of 'á' in your .vprj file. I cannot see how this is happening. Are you sure this was generated with VAP Ver. 1.37 or later? This should be done with process flow of Do Ad Scan + Use ComSkip Ad Scans but with Auto Cut after Ad Scans NOT checked. If it is done outside of VAP the UTF-8 to Unicode correction does not occur.
 
Last edited:

TPeterson

New member
Thanks for checking. I'll look into this further. That program was captured and processed successfully on another PC here using a different (newer) VRD and VAP 1.37 so I leaped to the evidently wrong conclusion when it failed using Version 1.39 (with bundled Comskip) and the older VRD.

(BTW, I still got no email notice of your reply above.)
 
Top Bottom