INTERACT FORUM

Please login or register.

Login with username, password and session length
Advanced search  
Pages: 1 [2] 3 4   Go Down

Author Topic: MCAutoQueue: Automatically Process Files In MC With External Applications  (Read 89835 times)

glynor

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 19608

0.8.6.0 (06/05/2013) -- BETA

http://glynor.com/files/MCAutoQueue/MCAutoQueue-0860.exe

1. Fixed: File logging loops when file or directory is locked or read-only (partial fix only).
2. NEW:  MCVideoRedoer Processor included.
3. NEW:  Setup wizard included for distribution.
4. Updated MCFileIngester to 0.8.0.

MCFileIngester 0.8.0 -- BETA

1. Changed: Refactored Logging and Options system to use new modular approach.
2. Fixed: Logging improved during program execution (more information included in the log, reformatted, etc).
3. Fixed: Options weren't saving when Ingestion was run.

MCVideoRedoer 0.8.0 -- BETA

1. Initial Release
Logged
"Some cultures are defined by their relationship to cheese."

Visit me on the Interweb Thingie: http://glynor.com/

glynor

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 19608

MCVideoRedoer is a Processor that can be used with MCAutoQueue or by itself to convert files through VideoReDo Suite 4, and then re-ingest them into MC (via MCFileIngester).  Very handy for fixing flaky TS recordings (VideoReDo is great at auto-fixing these), or converting from one format to another.

This requires a licensed copy of VideoReDo TV Suite 4 for operation.  The unlicensed free trial does not work!  This is because VideoReDo's COM interface is turned off in that version.  However, you can get a 15-day trial key from them from within VideoReDo that enables full operation of the trial, including COM, and then MCVideoRedoer will function normally.

Here's a screenshot of the current version:

Click to embiggen.


Using the Command Line:

Here is basic information on the command line formatting.  This follows essentially the same pattern as MCFileIngester, though with the non-necessary options omitted (of course), and the relevant new stuff added in.

s|source= - the source filename (must be a full filename) to process.
p|profile= - the VideoReDo Profile to use for processing.
qsffirst - run a QSF pass first before running the regular processing routine.
adscan - run in AdScan Pass Mode instead of the normal Video Export mode.

t|type= - the Ingest Type (Clone, Stack, or Replace) to use.
stackclone - Clone source metadata (for Stack IngestType).
cloneonlystats - Clone only stats when cloning metadata.
stacktop - Add new file as stack top (for Stack IngestType).
deletesource - Delete the original source file from disk when finished.

e|autoexit - automatically exit after running.  This option is ignored if an error occurs and the relevant preference is set.

a|autorun - automatically run the processor.
runmin - start up minimized.  This has no effect if autorun is not also set.


These last two command-line options are not accessible via the GUI.  They are best used when you have a "fully prepared" command line configuration, and where you want to run directly into the process.

The order that options are given on the command line is not important, though the options are case sensitive.

Options can be specified using any of the following notations:
-opt
--opt
/opt


Options that take a parameter (like --source or --profile) can be specified like any of these styles:
--source:"M:\Temp\script test\TheBigBangTheory-S06E10-TheFishGutsDisplacement-12851987-0.ts"
-p="H.264 Matroska MKV"
/profile "H.264 MP4"


The parameter must immediately follow the related option flag if the = or : notation is not used.

If any unknown command line options are passed, then AutoRun is disabled and the UI will alert you of the mistake.

Excluding Fields from Metadata Cloning:

When you use MCVideoRedoer to clone metadata from the source file to the newly processed file, it copies all fields (including custom ones) except the following stock fields:

[Filename], [File Type], [Media Type], [Volume Name], [Filename (name)], [Filename (path)], [Stack Top], [Stack Files], [Stack View], [Bitrate], [File Size], [Duration], [Width], [Height], [Date (day)], [Date (month)], [Date (year)], [Date (filename friendly)], [Dimensions], [Sample Rate], [Channels], [Bit Depth], [Compression], [Aspect Ratio], [FPS]

It also will not clone any read-only fields, even if they aren't listed above.  If you need to exclude any additional fields, you can add these to the IngesterExceptionFields.xml configuration file to manually exclude them from MCVideoRedoer and any other similar Ingesting Processor.  Please see this post for additional details.

Change Log:

Change logs for the current release:

* glynor.common-ChangeLog.txt
* MCVideoRedoer-ChangeLog.txt
Logged
"Some cultures are defined by their relationship to cheese."

Visit me on the Interweb Thingie: http://glynor.com/

astromo

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 2251

glynor, this application that you've worked up is very intriguing. Kudos to you for making the effort.

I've got a licenced version of VideoReDo TVSuite, so I could try this out. Would you be able to draft up a short worked example to give me a guide to put MCAutoQueue to work?

Currently, I'm using TVSuite manually and I run the Ad-Detective. After which I manually select the video segments to cut and then save the edited file for ad free viewing. By the sounds of it MCAQ doesn't have that level of sophistication functional yet but all in good time.

Thanks ..  ;)
Logged
MC33, Win10 x64, HD-Plex H5 Gen2 Case, HD-Plex 400W Hi-Fi DC-ATX / AC-DC PSU, Gigabyte Z370 ULTRA Gaming 2.0 MoBo, Intel Core i7 8700 CPU, 4x8GB GSkill DDR4 RAM, Schiit Modi Multibit DAC, Freya Pre, Nelson Pass Aleph J DIY Clone, Ascension Timberwolf 8893BSRTL Speakers, BJC 5T00UP cables, DVB-T Tuner HDHR5-4DT

glynor

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 19608

Thanks very much for the kudos!

Unfortunately, MCVideoRedoer doesn't (yet) handle VideoReDo's AdDetective Scan.  That is absolutely part of the plan, though.  Right now, this is just a simple command line drivable interface for opening a file in VRD, saving it out using a VRD Profile, and then ingesting the resulting file into MC (using MCFileIngester which means you can replace an existing file, clone metadata from existing files, stack with existing files, etc).

However... The main reason I wrote this wrapper, and chose VideoReDo for it, is because of the AdScan that VRD offers.  I want that too!  The one thing I'm not sure how I'll work it is related to the actual cutting of the commercials out of the source file.  Personally, I don't want that.  I just want them marked so that they can be easily skipped, but left intact (in case the AdDetective scan isn't perfect, since it will be fully automated).  I've done some initial testing and it IS possible to use VideoReDo (via the GUI) to do an AdScan on a source H.264 TS file, detect commercials, and then save the file out as a MKV including the AdScan results as chapters.  When you do this, MC recognizes the chapters in the MKV and you can easily skip the ads with a remote (without worrying that you might delete part of the "good stuff" via the automated scan).

But that part isn't done yet.

It is next on my list, after I quash some bugs (like the dumb --profile bug I already found).
Logged
"Some cultures are defined by their relationship to cheese."

Visit me on the Interweb Thingie: http://glynor.com/

glynor

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 19608

Also, I should add...

I plan to do some video walkthroughs on how to set up and use MCAutoQueue fairly soon.  The main thing that has been holding me back on the documentation is that I wanted to do these with something "real" to use, rather than using the example processors and hacked-together scripts (which is what I've been using the past couple of months).  MCVideoRedoer was the main thing I was waiting for in order to finish this (I also need to fix my website, apparently my theme broke).

However, if you know MC fairly well and are competent at a command line, usage isn't that complicated.  Ask if you have any questions, and bump this thread if I go off the radar for a long time again.

There will be a new version with the --profile option fixed soon (maybe tonight, maybe tomorrow).  Then, I'm working on documentation and the AdDetective scanning.  I might, just might, even be doing a wrapper for HandbrakeCLI when this is done, but that's further out.  (I should note:  You could already use this to auto-run HandbrakeCLI with a tiny little shell, python, VB, or perl script that just feeds the output file from HandbrakeCLI to MCFileIngester when it is done.  But I might do something similar to this wrapper for it if I get to it to make it nicer to use.)
Logged
"Some cultures are defined by their relationship to cheese."

Visit me on the Interweb Thingie: http://glynor.com/

astromo

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 2251

Thanks very much for the kudos!

Unfortunately, MCVideoRedoer doesn't (yet) handle VideoReDo's AdDetective Scan.  That is absolutely part of the plan, though.  Right now, this is just a simple command line drivable interface for opening a file in VRD, saving it out using a VRD Profile, and then ingesting the resulting file into MC (using MCFileIngester which means you can replace an existing file, clone metadata from existing files, stack with existing files, etc).

However... The main reason I wrote this wrapper, and chose VideoReDo for it, is because of the AdScan that VRD offers.  I want that too!  The one thing I'm not sure how I'll work it is related to the actual cutting of the commercials out of the source file.  Personally, I don't want that.  I just want them marked so that they can be easily skipped, but left intact (in case the AdDetective scan isn't perfect, since it will be fully automated).  I've done some initial testing and it IS possible to use VideoReDo (via the GUI) to do an AdScan on a source H.264 TS file, detect commercials, and then save the file out as a MKV including the AdScan results as chapters.  When you do this, MC recognizes the chapters in the MKV and you can easily skip the ads with a remote (without worrying that you might delete part of the "good stuff" via the automated scan).

But that part isn't done yet.

It is next on my list, after I quash some bugs (like the dumb --profile bug I already found).

Your welcome. Easy to dish out kudos points when they're deserved.

I like where you're heading with this. VDR has a pretty active forum. I would imagine that you'd get good support from that side given the user base of both items of software.

On the details provided, thanks for the run down. This has given me plenty to think about. Where I get to will be a function of how much time I get to test and evaluate. At least I feel like I've got a better handle on your objective.

Cheers ..  ;)
Logged
MC33, Win10 x64, HD-Plex H5 Gen2 Case, HD-Plex 400W Hi-Fi DC-ATX / AC-DC PSU, Gigabyte Z370 ULTRA Gaming 2.0 MoBo, Intel Core i7 8700 CPU, 4x8GB GSkill DDR4 RAM, Schiit Modi Multibit DAC, Freya Pre, Nelson Pass Aleph J DIY Clone, Ascension Timberwolf 8893BSRTL Speakers, BJC 5T00UP cables, DVB-T Tuner HDHR5-4DT

glynor

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 19608

0.8.7 (06/06/2013) -- BETA

http://glynor.com/files/MCAutoQueue/MCAutoQueue-0870.exe

1. Updated MCFileIngester to 0.8.1
2. Updated MCVideoRedoer to 0.8.1
3. Changed: Minor improvements to Loging system

MCFileIngester 0.8.1 (06/06/2013) -- BETA

1. Changed: Improved logging and error handling system.

MCVideoRedoer 0.8.1 (06/06/2013) -- BETA

1. Changed: Improved error handling and logging system.
2. Fixed: --profile command line option wasn't working.
3. Fixed: Profile loading system wasn't properly parsing certain profile filename extensions (such as MP4-IPOD).
4. Changed: Improved Profile Loading and parsing systems.
5. Changed: Improved Options saving system.
6. Fixed: Removed temporary Log window.
Logged
"Some cultures are defined by their relationship to cheese."

Visit me on the Interweb Thingie: http://glynor.com/

glynor

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 19608

I got a QSF pass working in MCVideoRedoer today (it does QSF on the files currently, but it doesn't do it as a "pre-pass" so that the file can then be opened and AdScanned).  That's a big step.

A question to anyone interested...  Would you prefer it do the QSF pass (which is essentially just detecting the current type of the file and then saving it out to some file format in the same codec as the original) into a temp directory alongside the original, or in the AppData path somewhere?  I'm leaning towards AppData because I don't want MC to pick up the temporary file via Auto-Import.

I could solve the latter by having MC remove the temporary file after it is done, but... That's annoying.  Currently MCVideoRedoer doesn't directly touch MC at all (the MC-connecting code isn't involved at all and it calls MCFileIngester as the last step).  I could solve that by doing the MC-part of the processing directly, but... That adds a bunch of complexity, and I like that if I later add features to MCFileIngester that I don't ever have to touch MCVideoRedoer (or any of the other "video processor" wrappers I add) to implement the extra features.

I don't know...  If anyone is reading this, opinions?

I could work more on that integration, but after AdScanning is done, the next one is a HandbrakeCLI wrapper, and I think that'll be more useful to spend my time (and the current MCVideoRedoer is a nice template for that).
Logged
"Some cultures are defined by their relationship to cheese."

Visit me on the Interweb Thingie: http://glynor.com/

glynor

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 19608

Unfortunately, it isn't looking promising to use VideoReDo to build AdScanned chapters into MKVs (and, I hoped, MP4s) the way I wanted.  More details here:
http://www.videoredo.net/msgBoard/showthread.php?33356-Embedding-Chapters-in-MKV-via-COM-Interface

I have, however, come up with a plan that would make it possible to use this to prep VPrj files and import those into MC (stacking them with their source files).  Then, you could queue them up with a smartlist and run through them one at a time manually, and when set, have MCVideoRedoer actually cut out the ads in automated fashion.  I almost certainly won't use that myself (I'm way too lazy), but I'll probably implement it as most of the background work is done now since I was trying to solve it "my way".

More details will be coming when I get a little more done...  I've made good progress on this.
Logged
"Some cultures are defined by their relationship to cheese."

Visit me on the Interweb Thingie: http://glynor.com/

glynor

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 19608

0.8.8 (06/22/2013) -- BETA

http://glynor.com/files/MCAutoQueue/MCAutoQueue-0880.exe

1. Updated MCVideoRedoer to 0.8.2

MCVideoRedoer 0.8.2 (06/22/2013) -- BETA

1. Fixed: Run Ingester checkbox wasn't working.
2. Changed: VideoReDo Processing uses a new modular wrapper system (will allow future AdScanning and other capabilities).
3. Changed: MC Ingester processing is now fully integrated (no longer requires launching external MCFileIngester.exe application).
4. Changed: Command Line options now include relevant commands from MCFileIngester directly (--type, --stackclone, etc).

EDIT: I had to re-upload the installer because I forgot to include some new (required) files in it.  Sorry for any trouble, it is all fixed up now (the bad one was only up for a few minutes).
Logged
"Some cultures are defined by their relationship to cheese."

Visit me on the Interweb Thingie: http://glynor.com/

glynor

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 19608

0.8.9 (06/24/2013) -- BETA

http://glynor.com/files/MCAutoQueue/MCAutoQueue-0890.exe

1. Fixed: Small formatting issue with logging errors
2. Updated MCFileIngester to 0.8.2
3. Updated MCVideoRedoer to 0.8.2
4. Changed: Automated release building process.
5. Changed: Extended Beta Timeout through 11/2013

MCFileIngester 0.8.2 (06/24/2013) -- BETA

1. Changed: Implemented new modular Ingester Mode panel system (dramatically simpler and unified code with other Processors).
2. Fixed: Ingester no longer starts up MC at launch-time (makes launching quicker).  MC connection happens on demand when running Ingester.
3. Fixed: Minor tweaks to logging and error handling system.
4. Changed: Implemented new modular Ingester Sources panel system
5. Fixed: Ingester StackSwap and UsingMCFields Panels now self-documented properly
6. Fixed: Source Comboboxes now build history lists properly when in Single-File mode (not persistent through runs)
7. Fixed: Source Error reporting improved.
8. Fixed: Help Button now opens the relevant documentation post from the MCAutoQueue Interact Thread (until I finish building my own page)
9. Fixed: User settings now persist even when new builds are installed.

MCVideoRedoer 0.8.3 (06/24/2013) -- BETA

1. Fixed: Logger properly unregisters itself even at the very outset in the case of an error (preventing infinite loops)
2. Fixed: Help Button now opens the relevant documentation post from the MCAutoQueue Interact Thread (until I finish building my own page)
3. Fixed: User settings now persist even when new builds are installed.
Logged
"Some cultures are defined by their relationship to cheese."

Visit me on the Interweb Thingie: http://glynor.com/

glynor

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 19608

0.9.0 (06/27/2013) -- BETA

http://glynor.com/files/MCAutoQueue/MCAutoQueue-0900.exe

1. Updated MCFileIngester to 0.8.3
2. Updated MCVideoRedoer to 0.8.4
3. Changed: Implemented new modular Utilities system (fixed problems with out-of-process logging).
4. Fixed: Minor logging issue when checking loaded MC Library.

MCFileIngester 0.8.3 (6/27/2013) -- BETA

1. Fixed: Logging was mostly broken in the last build (it didn't log output from the MC wrappers correctly).

MCVideoRedoer 0.8.4 (6/27/2013) -- BETA

1. Fixed: Actually incremented the minor version number this time.
2. Fixed: Profile combobox uses the proper style to denote that it is read-only.
3. NEW: QSF First Mode.  This automatically runs a QuickStreamFix pass on the source file before then processing it normally.  This
   will sometimes help to fix broken source files which will not otherwise encode properly in VideoReDo, but it adds processing time.
4. NEW: AdScan Mode.  This runs a VideoReDo AdScan on the Source file, then saves out a VPrj file which it imports into MC (and clones/stacks
   it with the source file).  You can then manually check the VPrj file in VideoReDo and verify the detected ads, and then run
   it through MCVideoRedoer again to finish processing to the final output file and have the ads removed.
5. NEW: AutoProfile Mode.  There is now a special "Automatic" Profile you can choose which determines which "real" Profile to use
   based on the encoding of the source file.  It chooses Program Stream (.mpg) for MPEG2 content, and either MP4 or MKV for H.264 content.
6. Fixed: Logging was mostly broken in the last two builds (it didn't log output from the VideoReDo wrapper or the MC wrappers correctly).
7. NEW: Advanced Settings dialog allows you to set a temporary storage location (defaults to the normal Windows Temp directory), and
   other options related to AdScan and AutoProfile modes.
8. Changed: More robust file checking and processing logic.
9. NEW: Imports VPrj files created by AdScan mode into Media Center, clones them with the original source file, so that you can easily
   queue them up for review.  If you re-process the VPrj files through MCVideoRedoer, it will process them normally and "finish" them.
Logged
"Some cultures are defined by their relationship to cheese."

Visit me on the Interweb Thingie: http://glynor.com/

glynor

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 19608

Today's version of MCVideoRedoer is a fairly major change.  I've implemented a ton of useful stuff, which warrants additional explanation and documentation.  Aside from getting said documentation done (as part of a big project to build better documentation for the whole suite), it is essentially feature-complete now.  There are three major new features:

1.  Auto Profile

The typical purpose of using MCVideoRedoer is to use the profiles built into VideoReDo to automate the transcoding of your TV Recordings to a more suitable format for long-term storage (or, perhaps, to transcode a new copy for use on mobile devices, reduce file size, and for other similar purposes).  The biggest problem with this is that, if you want to do a transcode in VideoReDo that does not re-encode the video (an "Ingelligent Reencode" as VideoReDo puts it), you must pick a profile that matches the original codec of the source file.

Essentially, to get a fast (and non-lossy) transcode, you have to use one of the MPEG2 profiles for MPEG2 sources, and one of the H.264 Profiles for H.264 sources.  That's a big problem if you are using MCVideoRedoer from the command line in an automated fashion (spawned by MCAutoQueue, for example), since you need to specify a profile by name on the command line for MCVideoRedoer, but your script has no (easy) way to tell what kind of video is inside that source file.

The new, special Auto Profile solves this problem.  If you choose this special profile, MCVideoRedoer will automatically select the output profile for you based on the source file in question and the following simple rules:

* MPEG2 Content will be exported using the default MPEG2 Program Stream profile (.mpg).
* H.264 Content will be exported using either the default H.264 MP4 profile, or the H.264 Matroska MKV profile, at your choice.

You can choose which specific H.264 export profile to use for Auto Profile mode under the new Advanced Settings button.  Please note that this will fail if you've removed any of these profiles from VideoReDo.  MVVideoRedoer defaults to using the H.264 MP4 profile because it is a "required, non-removable" profile in VideoReDo, while the MKV profiles can be deleted easily.  If you manually change to MKV mode, just ensure that you have a profile called exactly "H.264 Matroska MKV" in your list of profiles (as it is by default) and it will be selected and used.

Like any other profile, this can be chosen in the drop down in the GUI or specified on the command line by using the normal profile flag:
--profile="Auto Profile"

2. QSF First Mode

Another handy capability of VideoReDo is to do a fast "just fix the streams" export of the source file type export, which they call QuickStreamFix (QSF).  Their documentation is a bit vague, but essentially this is just exporting a file using the proper "matching codec" (very similar to the Auto Profile mode described above).  The only difference between doing a QSF on a source file and actually opening it and choosing a profile to save manually is that QSF mode uses a special way to open the files which minimizes parsing and pre-processing (to limit errors to a bare minimum) before it does the Export.

This is typically useful for source files with very bad timecode errors.  These "bad files" are sometimes created by certain encoders and capture devices, particularly DVB tuners in Europe (and the rest of the world) and ATSC/QAM tuners in the States.  In many cases, MC will be able to play the original source files without issue, but if you try to transcode them (using VideoReDo itself, or more commonly, something like Handbrake or MC's transcoding engine) they will get all messed up, with missing hunks, inaccurate seeks, and bad timecodes during playback.

QSF First Mode attempts to fix this, in an automated and behind the scenes fashion.  Essentially, it opens the source file using this special "QSF Batch Mode" in VideoReDo, then selects an appropriate export profile based on the codec of the source, and saves it out to a "fixed" TS file.  It does this into a temporary directory, and then after it completes, the new TS File "becomes" the source, and processing resumes from the beginning and your output is created.

This, obviously, has two costs:  Time (as it requires two transcodes, even though at least one of them will be "Ingelligent" and does not require re-encoding the video stream itself), and disk space (as it has to store this TS file while it does the final output.  By default, the temporary storage location is in your current user's regular "temp" folder provided by Windows.  If you want to move it elsewhere, you can select any folder you'd like under the new Advanced Options dialog.  This file is temporary, though.  It is saved with a randomly generated filename, and is deleted when the "real encoding pass" completes.  Basically, I'd only move it if you are very space limited on your C drive or you have other similar issues.

3. AdScan Mode

This is the biggest change, so I saved the best for last.

VideoReDo includes a very powerful, and quite accurate, AdDetective feature.  This, much like comskip, does a scan through the source video and tries to find commercials.  However, VideoReDo does not provide an automated way to export an EDL or Chapters list in their API, so there is no way to save these detections as "chapters" currently (you can do this in the GUI, but it doesn't work in their automation interface).  And, unfortunately, while the ad detection scheme is quite good, it isn't 100% accurate, so if you automate the actual cutting process without a human going "eyes on" with the file, you could end up with a poorly edited video.

However, if you do want to actually bother to look at it with your eyes and then cut and remove the commercials, this will enable a very simple-to-use workflow for manually checking them before saving them out and having new ad-free versions created and imported into MC.

When you enable AdScan mode in MCVideoRedoer, what it does is this:

1. It opens the source file and performs an AdDetective scan on the file.  This will mark the suspected commercials it finds with "scene markers".
2. It then saves this information out to a VideoReDo Project file (.VPrj).
3. It then imports this VPrj file into MC, and clones the metadata from the original source file over onto the new VPrj file (even though this VPrj is imported as a "Document Media Type" in MC, this works fine).  It also adds the new VPrj file as a stack with the existing source file.

You can then:

4. Have a smartlist that finds all the VPrj files in your Library, and go through them at your leisure to verify that the ads it detected are actually ads, and make sure it didn't miss anything.  You can just double click on the VPrj files in MC to open them in VideoReDo (so long as they are properly associated on your system).
5. Then, when you are satisfied, just save them with VideoReDo.
6. Reprocess those same VPrj files through MCVideoRedoer, and it will do a "normal pass" on them, saving to your selected exporting profile, and cutting out any marked ads.

This should make the task of commercial cutting quite simple and as painless as is possible.  You'll have an automatically filling "queue" of work in MC, and as you finish them, you can just add a MCAutoQueue NeedsProcessing flag that sends them back to MCVideoRedoer next time it is scheduled to run (in the middle of the night or whatever).  Just like with any source file, MCVideoRedoer can clone, stack, or replace the VPrj file in your library with the new output file, and remove the VPrj from disk when it is done if you'd like.

I should also note, that in "step 1" above, VideoReDo has two different "ways" it can "pre-mark" these ads.  You can have it just add scene markers to the VPrj file (which are like saved edit points, but which don't tell VideoReDo to actually do anything when it is re-encoding the file for export), or you can have them pre-marked as Cut Points (this is called AutoCut).  AutoCut does not actually delete sections of the files, it simply "prepares" the VPrj file more fully.  I'd recommend you enable this option for this mode, which you can do under the Advanced Options dialog.  If you prefer to run VideoReDo in "Scene Mode" or you have some other established workflow, then you may want to leave AutoCut disabled.

You can enable this special AdScan Mode in MCVideoRedoer by using the new --adscan flag on the command line, or by checking the box in the GUI before hitting the "process" button.  Unlike the other options in MCVideoRedo, this one does not persist between runs (it can't be the default mode), so your best bet is to use the command line argument.

Lastly, I added a neat trick to MCVideoRedoer that if you try to do an AdScan Mode run using a source file that is already a VPrj, it will assume you are done with it, and actually export the file instead (essentially, auto-disabling AdScan Mode if the source is a VPrj file).  This should make it simpler to set up the processor in MCAutoQueue, as you can just have one entry for MCVideoRedoer, including the -adscan flag, and it'll do the right thing depending on the source file.

So, let me know what you think!  I think this adds a lot of power to MCAutoQueue for automating processing of TV Recordings.  I hope someone out there finds it useful, as I worked pretty hard on it, and I'm quite pleased with the results.
Logged
"Some cultures are defined by their relationship to cheese."

Visit me on the Interweb Thingie: http://glynor.com/

astromo

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 2251

Holy snapping duck do-do, glynor, this looks massive.

I haven't fired up MCAutoQueue on my unit yet but this development pretty well much forces the issue. Looks like a weekend job though. Will let you know how things go.

Thanks for all your hard work.. ;D
Logged
MC33, Win10 x64, HD-Plex H5 Gen2 Case, HD-Plex 400W Hi-Fi DC-ATX / AC-DC PSU, Gigabyte Z370 ULTRA Gaming 2.0 MoBo, Intel Core i7 8700 CPU, 4x8GB GSkill DDR4 RAM, Schiit Modi Multibit DAC, Freya Pre, Nelson Pass Aleph J DIY Clone, Ascension Timberwolf 8893BSRTL Speakers, BJC 5T00UP cables, DVB-T Tuner HDHR5-4DT

glynor

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 19608

So...  I've decided to refactor the original MCAutoQueue application a bit, primarily to re-work the Settings saving and loading code (which is an ugly mess) using some of what I've learned along the way.  This should make any future improvements to that code much easier to implement, and make it work better to-boot, but it will require trashing the old aqconfig system and replacing it with something entirely new.

Functionality won't be impacted (or, at least, nothing of import is going to be removed, though stuff internally will certainly be made better).  The new version will use a command line parser like the ones used by the other Processors I've made (in fact, it will now share a lot with those, rather than being the "snowflake" that it is now).

So... If anyone out there is using this, and you've made a bunch of custom AQConfig files with stored settings, this is your chance to speak up.  If you are only using the default file, even with changes, this shouldn't be a huge hassle, as the options can be easily re-set in the UI.  But if you have a bunch of different lists and stuff, then it could be... Troublesome.  I'm not currently planning to build a system to import the old-style settings files and convert them to the new style, as that would be a massive pain in the lower extremities.

If it is only a handful of people with a few files (or no one at all, of course), then I'd probably just rather hand-convert them for you than to build a converter into the system (which would require globbing on all of the old code I want to murder into my shiny new sleek thing).  I'm willing to do some hand-conversions (I'm planning to do my own, after all).  Also, doing it yourself with a text editor also shouldn't be a big nightmare, and the new format is easier to read.

Here's an example from the tester I have running now:

Code: [Select]
<?xml version="1.0" encoding="utf-8"?>
<AQSettings xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <QueuePlaylistPath>Utility\MCAutoQueue</QueuePlaylistPath>
  <FieldToProcess>NeedsProcessing</FieldToProcess>
  <ProcessorConfigs>
    <ProcessorSetting>
      <Name>Example Processor Error</Name>
      <Command>C:\Program Files (x86)\MCAutoQueue\Processors\EchoTster.exe</Command>
      <Argument>[Filename]</Argument>
      <MCStyle>false</MCStyle>
      <UpdateField>false</UpdateField>
      <Timeout>30</Timeout>
    </ProcessorSetting>
    <ProcessorSetting>
      <Name>Example Normal</Name>
      <Command>C:\Program Files (x86)\MCAutoQueue\Processors\EchoTester.exe</Command>
      <Argument>[Filename]</Argument>
      <MCStyle>false</MCStyle>
      <UpdateField>true</UpdateField>
      <Timeout>30</Timeout>
    </ProcessorSetting>
  </ProcessorConfigs>
  <DisableProcessorTimeouts>false</DisableProcessorTimeouts>
  <DefaultTimeout>30</DefaultTimeout>
  <MinimizeProcessors>true</MinimizeProcessors>
</AQSettings>

This project will probably take a couple weeks, because we have a holiday intervening, but a lot of the "background" work is done.  All of the core classes are converted and working right, now I just have to re-wire the UI to use them, and move some processing logic to the class where it should really live (it currently lives somewhat intermingled with the UI code)

A lot of copypasta and Find-and-Replacing is in my future.

Again... Now's your chance.  Don't worry about it much if you're not loading aqconfig files at the command line (which is the main purpose of them).  If you just run it, set it up, and then use it for that one Smartlist and Field, then you'll be fine (or mostly fine, and I'll help if needed).

If there's a big outcry, I'll figure out a way to build a converter.  It will almost certainly be a separate standalone converter widget thing, because I don't want the old stuff crimping my style, but it should be possible.  It'll just be a pain and will take time, and I don't need it so...

PS.  This won't impact MCFileImporter or MCVideoRedoer in the slightest.  Only MCAutoQueue.  If you're just using one of the Processor applets to do manual conversions, then you're good to go and can ignore me.
Logged
"Some cultures are defined by their relationship to cheese."

Visit me on the Interweb Thingie: http://glynor.com/

astromo

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 2251

Cool by me. No issues from this quarter. My weekend got side-tracked with more fundamental issues of just trying to get a TV signal and record the old school way.
Logged
MC33, Win10 x64, HD-Plex H5 Gen2 Case, HD-Plex 400W Hi-Fi DC-ATX / AC-DC PSU, Gigabyte Z370 ULTRA Gaming 2.0 MoBo, Intel Core i7 8700 CPU, 4x8GB GSkill DDR4 RAM, Schiit Modi Multibit DAC, Freya Pre, Nelson Pass Aleph J DIY Clone, Ascension Timberwolf 8893BSRTL Speakers, BJC 5T00UP cables, DVB-T Tuner HDHR5-4DT

glynor

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 19608

0.9.1 (7/5/2013) -- BETA

http://glynor.com/files/MCAutoQueue/MCAutoQueue-0910.exe

1. Fixed: Installer wasn't working properly in the last two builds.
2. Changed: Log file is now saved in the current user's AppData directory
3. Updated MCFileIngester to 0.8.4
4. Updated MCVideoRedoer to 0.8.5

MCFileIngester 0.8.4 (7/5/2013) -- BETA

1. Changed: Log file now saved in the current user's AppData directory.

MCVideoRedoer 0.8.5 (7/5/2013) -- BETA

1. NEW: VideoReDo Output process can now be cancelled while in progress.
2. Changed: Log file now saved in the current user's AppData directory.
Logged
"Some cultures are defined by their relationship to cheese."

Visit me on the Interweb Thingie: http://glynor.com/

glynor

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 19608

So, astromo discovered that my installer wasn't working (which actually impacted the last two builds).  Thanks!

Sorry for the trouble.  It should be fixed (but please let me know if there are any other issues).  I have two development systems (my laptop and my desktop box at home in the man cave), and they have slightly different paths to where the files live (the laptop has a different username).  This means my Inno Setup script needs to be machine-specific so that it can find the files, which is how it was all along (actually, I just never did release builds on my laptop)

A couple builds ago I decided to try to get fancy and make the same Inno Setup script work on both the laptop and the desktop box.  This failed, and caused NOTHING to be copied into the installer EXE at all.  Oops!

It should be fixed now.  I also tweaked the Logging system.  It now saves the log files to your AppData\glynor\<AppName> directory.  This means the applications no longer needs write access to their own directories, which is safer, and simpler in the installer.  If you want to move the log elsewhere, you should be able to move it by putting a full path in the .NET User Settings file for the processor applets.  This won't work for the current version of MCAutoQueue (which doesn't have a simple User Settings file currently).

Work on the rebuild of MCAutoQueue is progressing nicely, but this build isn't it.  Again, when that's done, not much will change except the file-format for how it saves its settings out to disk (and loads those settings).  Worst case, you'll have to set up your defaults in MCAutoQueue again.  So, don't build a whole bunch of aqconfig files right now, but if you're just using one, it won't be a big deal.
Logged
"Some cultures are defined by their relationship to cheese."

Visit me on the Interweb Thingie: http://glynor.com/

astromo

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 2251

Getting Started:

1. You create a new Field in Media Center that you will use to "trigger" different "Processors" that you define in MCAutoQueue.  Add further instruction This field can really be any simple String or Integer field, but I'd suggest that you use a String Type Field with the Acceptable Values set to "lock" it to your list of Processors.  Here's an example:

Please provide additional instruction at the point noted such as:
Quote
You'll need to navigate to "Manage Library Fields" located at Tools > Options > Manage Library Fields to make the required edits to MC's configuration.



Getting Started:

2. Then, you create a Smartlist in Media Center that shows any file that has an entry in this field, except for the special value "Failed".

What name should the Smartlist be given?
I've defaulted to "NeedsProcessing" but does it matter?
[Edit: I can answer my own question MCAutoQueue points to the smartlist that the user sets up. As long as the names match, then it should work. In fact the utility uses the name "MCAutoQueue" by default, so that's what I've named the smartlist as.]
Logged
MC33, Win10 x64, HD-Plex H5 Gen2 Case, HD-Plex 400W Hi-Fi DC-ATX / AC-DC PSU, Gigabyte Z370 ULTRA Gaming 2.0 MoBo, Intel Core i7 8700 CPU, 4x8GB GSkill DDR4 RAM, Schiit Modi Multibit DAC, Freya Pre, Nelson Pass Aleph J DIY Clone, Ascension Timberwolf 8893BSRTL Speakers, BJC 5T00UP cables, DVB-T Tuner HDHR5-4DT

astromo

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 2251

Today's version of MCVideoRedoer is a fairly major change.  I've implemented a ton of useful stuff, which warrants additional explanation and documentation.  Aside from getting said documentation done (as part of a big project to build better documentation for the whole suite), it is essentially feature-complete now.  There are three major new features:

1.  Auto Profile

You can choose which specific H.264 export profile to use for Auto Profile mode under the new Advanced Settings button.

Like any other profile, this can be chosen in the drop down in the GUI or specified on the command line by using the normal profile flag:
--profile="Auto Profile"


Ummmmm ... where do I find this in the GUI?

I'm posting a screen shot of the Tools > Options > General Parameters and Tools > Edit Profile List dialogue boxes and can't find mention of "Advanced Settings" or "Auto Profile". I've got the latest stable version v4.21.2.662 and the latest beta v4.21.2.665 on my system and I can't find "Advanced Settings" in the obvious spots. A search of the help file yields zip for me as well.

If the default settings are in Auto Profile mode, then I don't have to worry and all's cool but it would be reassuring to know this.

[Edit: D'oh!  *smacks self in the head*
Oops!  Auto Profile is staring at me from MCVideoRedoer when I fire it up.]

As a suggestion, you could modify the installer to give the user the option to load MCVideoRedoer and MCFileIngester to the desktop. I didn't realise they were independent programs.
Logged
MC33, Win10 x64, HD-Plex H5 Gen2 Case, HD-Plex 400W Hi-Fi DC-ATX / AC-DC PSU, Gigabyte Z370 ULTRA Gaming 2.0 MoBo, Intel Core i7 8700 CPU, 4x8GB GSkill DDR4 RAM, Schiit Modi Multibit DAC, Freya Pre, Nelson Pass Aleph J DIY Clone, Ascension Timberwolf 8893BSRTL Speakers, BJC 5T00UP cables, DVB-T Tuner HDHR5-4DT

astromo

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 2251

Today's version of MCVideoRedoer is a fairly major change.  I've implemented a ton of useful stuff, which warrants additional explanation and documentation.  Aside from getting said documentation done (as part of a big project to build better documentation for the whole suite), it is essentially feature-complete now.

I've been able to get MCVideoRedoer to do a successful scan and produce a Vprj file for me. When I executed the Vprj file by clicking on it, it wasn't pre-associated with VRD as glynor cautioned. I find that a bit bizarre but I simply went through the process manually of associating the file type with VRD.

I like the simple efficiency of MCVideoRedoer. Nice. Yet to put this together with MCAQ and MCIngester.
Logged
MC33, Win10 x64, HD-Plex H5 Gen2 Case, HD-Plex 400W Hi-Fi DC-ATX / AC-DC PSU, Gigabyte Z370 ULTRA Gaming 2.0 MoBo, Intel Core i7 8700 CPU, 4x8GB GSkill DDR4 RAM, Schiit Modi Multibit DAC, Freya Pre, Nelson Pass Aleph J DIY Clone, Ascension Timberwolf 8893BSRTL Speakers, BJC 5T00UP cables, DVB-T Tuner HDHR5-4DT

glynor

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 19608

When I executed the Vprj file by clicking on it, it wasn't pre-associated with VRD as glynor cautioned. I find that a bit bizarre but I simply went through the process manually of associating the file type with VRD.

Very weird that they don't associate their own extension with their application, I agree.  You can, apparently, associate it through the UI, but it isn't by default.

Thanks for all the feedback, it's great.  New eyes are always the most important feedback you can get.  However, it is the Fourth of July weekend and I don't have much I can contribute tonight because 'merica and beer.  But I'll read through tomorrow or at some point soon.
Logged
"Some cultures are defined by their relationship to cheese."

Visit me on the Interweb Thingie: http://glynor.com/

glynor

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 19608

As a suggestion, you could modify the installer to give the user the option to load MCVideoRedoer and MCFileIngester to the desktop. I didn't realise they were independent programs.

I didn't include that because those default desktop icons annoy me.  I could do it as a non-default option.
Logged
"Some cultures are defined by their relationship to cheese."

Visit me on the Interweb Thingie: http://glynor.com/

glynor

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 19608

What name should the Smartlist be given?
I've defaulted to "NeedsProcessing" but does it matter?
[Edit: I can answer my own question MCAutoQueue points to the smartlist that the user sets up. As long as the names match, then it should work. In fact the utility uses the name "MCAutoQueue" by default, so that's what I've named the smartlist as.]

It doesn't matter at all.  Any playlist will do (though a Smartlist would, obviously, be more useful).  The default name is just something simple.  You can use whatever you want.  When you hit the Settings button, the combobox pre-fills with all of the Playlists you have available in MC, so you can just pick the one you want from there.

Mine is:  "Utilities\MCAutoQueue"
Logged
"Some cultures are defined by their relationship to cheese."

Visit me on the Interweb Thingie: http://glynor.com/

glynor

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 19608

Just a quick update on this... The rewire is effectively done.  I have it back to (and past) feature parity with the currently available build here.  One result?  A fairly dramatic speed boost when loading the Playlist, which is nice.  There were all sorts of inefficiencies in my old code.

Right now I'm just trying to button up some details on the Settings screen to make it nicer than the old version (detect Processor collisions and add browse buttons for selecting the executables are my goals) and then I'm going to push it out.

I've made a few screencasts already as well, and as soon as I get this Settings screen finished up, I should be able to have a decent "getting started" guide.  It really isn't too bad to get set up at all (much simpler than Sage Job Queue, for example).
Logged
"Some cultures are defined by their relationship to cheese."

Visit me on the Interweb Thingie: http://glynor.com/

glynor

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 19608

http://glynor.com/files/MCAutoQueue/MCAutoQueue-0950.exe

MCAutoQueue 0.9.2 - 0.9.4 -- Not Released To Public

MCAutoQueue 0.9.5 (07/31/2013) -- BETA

1. Changed: MCAutoQueue Settings system re-architected from the ground up.  WARNING: aqconfig file format changed.  Previously used files will need to be recreated (PM me for assistance if you have a big one).
2. Changed: Automatic settings loading is much simpler and more robust, and works similarly to MCFileIngester.
3. NEW: Processor Settings dialog has much more robust error checking and feedback.
4. Changed: Now uses NDesk.Options style command line options like MCFileIngester and MCVideoRedoer.
         Command line options have changed.  The most essential of the older syntax have been preserved.
5. NEW: Command line --help option shows command line documentation.
6. Fixed: Program doesn't block anymore while launching MC.
7. Fixed: Dramatic speed improvements when dealing with the File Queue and Processor Settings lists.
8. Fixed: Queued File error checking and processing is more robust.
9. NEW: Help button in the Settings screen.  Currently links to the MCAutoQueue thread.
10. Changed: Added Tooltip inline help throughout.
11. NEW: Log file can be set to rotating mode, including deleting old logs after a set number of days.
12. NEW: Uses modular Global Options system, making it identical to the other Processors.
13. NEW: Browse button in the Processor Settings grid view (to make it easier to pick the Processor executable file).
14. Fixed: Duplicate Processor Name checking (and warning).
15. Changed: Like MCFileIngester and MCVideoRedoer, AutoExit and AutoRun are only available from the command line.
16. Changed: Core MCnet.dll refactored to provide more flexible usage model for the future.
17. Changed: MCAutoQueue sets the Field to Process (this is [NeedsProcessing] by default) to "Completed" for
   successful jobs (continues to use "Failed" for incomplete or failed jobs).
18. Fixed: MCAutoQueue sets the Field to Process to blank before processing, so that metadata cloning operations
   don't copy the original (pre-completion) flag over to the newly created output files.
19. Changed: Currently processing status is shown and highlighted in Green.
20. Fixed: Way too many small issues and bugs to count.

MCFileIngester 0.9.0 (07/31/2013) -- BETA

1. Changed: Uses modular Global Options system.  Shares code and controls with other applications for more unified usage model.
2. Changed: Minor improvements to the Logging system.

MCVideoRedoer 0.9.0 (07/31/2013) -- BETA

1. Changed: Uses modular Global Options system.  Shares code and controls with other applications for more unified usage model.
2. Changed: Minor improvements to the Logging system.
3. Fixed: AdScan and QSF First modes are more robust.
4. Fixed: The default exit mode for the application is Cancelled (Exit Code 1), rather than Normal (Exit Code 0).
5. Fixed: AdScan mode can be cancelled properly.
Logged
"Some cultures are defined by their relationship to cheese."

Visit me on the Interweb Thingie: http://glynor.com/

glynor

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 19608

http://glynor.com/files/MCAutoQueue/MCAutoQueue-0960.exe

MCAutoQueue 0.9.6 (08/04/2013) -- BETA

1. Fixed: MCAutoQueue could crash if it tried to nicely close a processor that exceeded the timeout.
2. Changed: Processor Timeout setting is reported in the log as processor runs.
3. Fixed: Command Line and Settings Loading errors were not being handled properly.

MCFileIngester 0.9.1 (08/04/2013) -- BETA

1. Fixed: Command line errors were not being handled properly.

MCVideoRedoer 0.9.1 (08/04/2013) -- BETA

1. Fixed: Command Line Errors were not behing handled properly.
2. Changed: When program is closed while Processing is running, the warning dialog now has a timeout (which allows it to be automated, yet still closed nicely if it takes too long).
3. Changed: When processing is cancelled, the partial file is deleted from disk.
Logged
"Some cultures are defined by their relationship to cheese."

Visit me on the Interweb Thingie: http://glynor.com/

glynor

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 19608
Re: MCAutoQueue: Automatically Process Files In MC With External Applications
« Reply #77 on: January 11, 2014, 03:54:42 pm »

http://glynor.com/files/MCAutoQueue/MCAutoQueue-0970.exe

MCAutoQueue 0.9.7 (01/11/2014) -- BETA

1. Fixed: Additional error checking in background threads.  If you receive any errors referencing a background thread, please report them along with any available log file.

MCFileIngester 0.9.2 (01/11/2014) -- BETA

1. Fixed: Replace Type ingesters were retaining some metadata from the new file. Clones the metadata from the source file to the new file first, before replacing.
2. Fixed: Stack with Source Type ingesters were unintentionally cloning some metadata from whatever file was set as the Stack Top.
3. Fixed: Additional error checking in background threads.
Logged
"Some cultures are defined by their relationship to cheese."

Visit me on the Interweb Thingie: http://glynor.com/

astromo

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 2251
Re: MCAutoQueue: Automatically Process Files In MC With External Applications
« Reply #78 on: January 13, 2014, 03:40:19 am »

Thanks for the update.
Logged
MC33, Win10 x64, HD-Plex H5 Gen2 Case, HD-Plex 400W Hi-Fi DC-ATX / AC-DC PSU, Gigabyte Z370 ULTRA Gaming 2.0 MoBo, Intel Core i7 8700 CPU, 4x8GB GSkill DDR4 RAM, Schiit Modi Multibit DAC, Freya Pre, Nelson Pass Aleph J DIY Clone, Ascension Timberwolf 8893BSRTL Speakers, BJC 5T00UP cables, DVB-T Tuner HDHR5-4DT

glynor

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 19608
Re: MCAutoQueue: Automatically Process Files In MC With External Applications
« Reply #79 on: January 26, 2014, 07:44:11 pm »

New demo for MCFileIngester.

This demonstrates how to use MCFileIngester to replace a set of existing files in your Library with newly ripped duplicates, while preserving all of the original metadata (including Playlists, Date Imported, Play Stats, etc).


MCFileIngester - Standard Replace Playlist Demo
Click to play video.
Logged
"Some cultures are defined by their relationship to cheese."

Visit me on the Interweb Thingie: http://glynor.com/

glynor

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 19608
Re: MCAutoQueue: Automatically Process Files In MC With External Applications
« Reply #80 on: January 27, 2014, 03:39:31 pm »

Sigh...

In attempting to make a similar demo of StackSwap Mode, I discovered that this function is broken, at least with current builds of MC19.  Please don't use MCFileIngester's StackSwap mode for anything mission critical for now.  I'm looking into it and will have a new build fairly soon.

All of the other modes in MCFileIngester are now well-tested and work as expected (at least for me on a few systems here).

By the way, MCAutoQueue has been processing my newly recorded videos fully automatically now for two months, without any serious issues.  MCAutoQueue itself is pretty rock-solid.  And MCFileIngester seems to be pretty solid too, other than the StackSwap issue I mentioned above.  MCVideoRedoer needs some additional work, though works for basic tasks just fine.  I have it set up now to automatically apply a few different VideoReDo profiles to recordings made on my system with MCVideoRedoer, and it works very well.  The only issues I've seen are with source recordings that are otherwise pretty badly borked (issues with the original signal, lots of missing frames and bad encoding), which end up failing and VideoReDo itself crashes.

Otherwise, though, the system is completely usable now.

Current Known Issues:

* MCFileIngester: StackSwap mode fails to do replacement properly.
* MCVideoRedoer: QSF First mode isn't working right.
* MCVideoRedoer: VideoReDo crashes when certain "broken" source files are used, which makes MCVideoRedoer crash too, and the conversion fails.  I can't fix VideoReDo itself, of course, but QSF should be able to solve these issues if it worked right.

I'm not sure when I'll get to the last two items.  I'm actually much more keen to work on a Handbrake wrapper than to continue to work on VideoReDo, though those things are all tied up in some foundational problems I'm not sure I'll resolve quickly.

The MCFileIngester StackSwap problem should be fixed soon, unless it turns out to be a huge unexpected hassle.
Logged
"Some cultures are defined by their relationship to cheese."

Visit me on the Interweb Thingie: http://glynor.com/

astromo

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 2251
Re: MCAutoQueue: Automatically Process Files In MC With External Applications
« Reply #81 on: January 27, 2014, 06:25:39 pm »

Thanks glynor.

Looking forward to reviewing the example vid file and applying the message for homework. I'll be back here if I have any questions.

Also, glad you mentioned the problem with QSF. I wasn't sure if I'd done something odd when I put it to use yesterday..  ;)
Logged
MC33, Win10 x64, HD-Plex H5 Gen2 Case, HD-Plex 400W Hi-Fi DC-ATX / AC-DC PSU, Gigabyte Z370 ULTRA Gaming 2.0 MoBo, Intel Core i7 8700 CPU, 4x8GB GSkill DDR4 RAM, Schiit Modi Multibit DAC, Freya Pre, Nelson Pass Aleph J DIY Clone, Ascension Timberwolf 8893BSRTL Speakers, BJC 5T00UP cables, DVB-T Tuner HDHR5-4DT

astromo

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 2251
Re: MCAutoQueue: Automatically Process Files In MC With External Applications
« Reply #82 on: January 28, 2014, 04:37:28 am »

New demo for MCFileIngester.

This demonstrates how to use MCFileIngester to replace a set of existing files in your Library with newly ripped duplicates, while preserving all of the original metadata (including Playlists, Date Imported, Play Stats, etc).

Great piece of work.

The video demonstration really helps get the message. I don't have a need for File Ingester right now (that I can think of) but I'm sure that with the concepts firmly imprinted in my brain that there's a good chance I'll think of something down the track.

My applause to you. I'll keep an eye out for the follow up demos.


As a side question, (bear in mind that I use VideoRedoer standalone to run AdScan) what's the reasoning for only giving the user the option to exit once a process is complete? If I want to do more than one scan, it would be handy if the application could be left open so that I could select an new file.

Or have you done this by design to show up newbs like me who haven't got the hang of the CLI? If so, I'm re-reading the relevant post:
http://yabb.jriver.com/interact/index.php?topic=76147.msg552751#msg552751
I think it's sinking in a bit more.

I find Redoer very handy to run AdScan. What I do is then fire up the project file and cut the ads. Unfortunately the technology is easily duped by crafty TV stations who don't program neat breaks or it often picks up scenes that go light-dark-light as ads. Anyhoo, I find that I have to manually sort through the cuts so that they turn out right. I can't see a way around the manual handling.

Ultimately, I'd like to set up a process to parse files for AdScan during low use periods.

Anyway, be assured that you've got at least 1 soul out here on Interact that rates your effort..  ;)
Logged
MC33, Win10 x64, HD-Plex H5 Gen2 Case, HD-Plex 400W Hi-Fi DC-ATX / AC-DC PSU, Gigabyte Z370 ULTRA Gaming 2.0 MoBo, Intel Core i7 8700 CPU, 4x8GB GSkill DDR4 RAM, Schiit Modi Multibit DAC, Freya Pre, Nelson Pass Aleph J DIY Clone, Ascension Timberwolf 8893BSRTL Speakers, BJC 5T00UP cables, DVB-T Tuner HDHR5-4DT

glynor

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 19608
Re: MCAutoQueue: Automatically Process Files In MC With External Applications
« Reply #83 on: January 28, 2014, 07:08:53 am »

Great piece of work.

The video demonstration really helps get the message. I don't have a need for File Ingester right now (that I can think of) but I'm sure that with the concepts firmly imprinted in my brain that there's a good chance I'll think of something down the track.

My applause to you. I'll keep an eye out for the follow up demos.

Thanks.  I'm working on one for MCAutoQueue now.  My original plan for the MCFileIngester video was really to "practice" for making the longer MCAutoQueue video.  They take a while to make, though, so it'll be a little bit yet.

As a side question, (bear in mind that I use VideoRedoer standalone to run AdScan) what's the reasoning for only giving the user the option to exit once a process is complete? If I want to do more than one scan, it would be handy if the application could be left open so that I could select an new file.

Or have you done this by design to show up newbs like me who haven't got the hang of the CLI? If so, I'm re-reading the relevant post:
http://yabb.jriver.com/interact/index.php?topic=76147.msg552751#msg552751
I think it's sinking in a bit more.

Hah.  Actually, no.  It was laziness.

It is, of course, really designed to process one file at a time, in an automated fashion.  I considered, of course, making it able to do so.  But I'd need to write a fair bit of "checking" code to make it reset itself back to a clean state (make sure it gets a new, fresh instance of VideoReDo, mostly) and since this wasn't a strong design consideration, it got left on the cutting room floor.

I find Redoer very handy to run AdScan. What I do is then fire up the project file and cut the ads. Unfortunately the technology is easily duped by crafty TV stations who don't program neat breaks or it often picks up scenes that go light-dark-light as ads. Anyhoo, I find that I have to manually sort through the cuts so that they turn out right. I can't see a way around the manual handling.

Ultimately, I'd like to set up a process to parse files for AdScan during low use periods.

Anyway, be assured that you've got at least 1 soul out here on Interact that rates your effort..  ;)

Yeah, there's really no way around a manual pass if you want them to be perfect (which, obviously, you need to actually cut the files).

Automating it substantially, however, is absolutely possible.  Keep an eye out for that MCAutoQueue video.  ;)
Logged
"Some cultures are defined by their relationship to cheese."

Visit me on the Interweb Thingie: http://glynor.com/

glynor

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 19608
Re: MCAutoQueue: Automatically Process Files In MC With External Applications
« Reply #84 on: January 30, 2014, 10:16:29 pm »

http://glynor.com/files/MCAutoQueue/MCAutoQueue-0971.exe

MCAutoQueue 0.9.7.41525 (01/30/2014) -- BETA

1. Changed: Processor updates only.

MCFileIngester 0.9.3 (1/30/2014) -- BETA

1. Fixed: StackSwap mode replacements weren't cloning all metadata properly.
2. Fixed: StackSwap mode replacements weren't properly removing the original database entry, unless Delete Source was enabled.
3. Fixed: The UI could get confused depending on the order in which different options were enabled or disabled.
4. Fixed: Ingest progress dialog sometimes didn't fill the list properly when opened.
5. Changed: Ingest progrees dialog file table now scrolls to keep the currently processing item centered in the visible part of the table.
6. Fixed: Ingest progress dialog row header labels (the list number) was aligned oddly with two and three digit numbers.

MCVideoRedoer 0.9.2 (01/30/2014) -- BETA

1. Fixed: QSF First Mode was not actually, you know, saving a QSFed file.
Logged
"Some cultures are defined by their relationship to cheese."

Visit me on the Interweb Thingie: http://glynor.com/

glynor

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 19608
Re: MCAutoQueue: Automatically Process Files In MC With External Applications
« Reply #85 on: January 30, 2014, 10:22:04 pm »

MCVideoRedoer 0.9.2 (01/30/2014) -- BETA

1. Fixed: QSF First Mode was not actually, you know, saving a QSFed file.

This one was a trixy one.  Sneaky little bugger.  Took me three tries on three days to find it.

It wasn't even one line of code.  Somehow, and I'm not sure how because it worked before, what should have been this:

VRD.Instance.FileSaveProfile(outputFile.FullName, qsfProfile.Name);

got changed into

VRD.Instance.FileSaveAs(outputFile.FullName);

I stared at that line fragment (the latter one, unfortunately) for hours over the past few days, I'm sure, and never "saw" that it was wrong.

The latter is valid with older versions of VideReDo, but it doesn't work* with the v4+ ones (the only ones I care about because the older ones don't support H.264).  I certainly intended to use the FileSaveProfile version.  I went to substantial trouble to determine and grab the correct profile object (qsfProfile) only a few lines above that line, and then didn't use it.  That old "FileSaveAs" method in Intellisense is so pretty looking and tempting to choose accidentally.  Sigh.

* Right, they have a method in their API that looks valid (and isn't marked in the Intellisense documentation as deprecated or anything), called FileSaveAs, that just doesn't work at all with any reasonably modern version of their software.  It just fails.  I should have been checking better for failure, but their FileSaveProfile doesn't work the same way at all (the old one returns a simple worked/failed int, the new one returns the XML of the profile and is all weird), so my poor-man's check didn't catch it.
Logged
"Some cultures are defined by their relationship to cheese."

Visit me on the Interweb Thingie: http://glynor.com/

glynor

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 19608
Re: MCAutoQueue: Automatically Process Files In MC With External Applications
« Reply #86 on: January 30, 2014, 10:44:25 pm »

And, I forgot to add, the crash logs from when VideoReDo chokes on a bad file and dies mid-processing should be (fingers crossed) better now, which will let me catch the annoying little bugger when it crops up again.  I think so, anyway.

As I mentioned before, this fails "properly".  It crashes.  It won't delete, or modify, the source file (even if Delete Source when done is enabled).  Not that it matters a huge deal because if it does this, the source file is likely already pretty hosed.  That's what makes VideoReDo choke on them.  In the older versions, only the background thread would crash and the UI would get confused in a loop warning you about the running processor.  I hope I made it so it just outright crashes.  That will give me better logs, and is still safe.  Plus, then if it is running in MCAutoQueue, it won't have to wait so long to get shut down, and hold up the rest of the queue.

The problem has been that I haven't seen it with any of my auto-processing files this past week or so at all.

That's good.  My recordings have been a-ok.  Bad because it makes that particular problem hard to diagnose, or even check to see if the "fix" worked.  I wish I'd saved one of my old example files, but for a while there, I had a ton, and they were all among my "auto-purged" TV Recordings (Dora the Explorer episodes mostly).  I didn't think it would be difficult to find examples until it was.   :-\
Logged
"Some cultures are defined by their relationship to cheese."

Visit me on the Interweb Thingie: http://glynor.com/

glynor

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 19608
Re: MCAutoQueue: Automatically Process Files In MC With External Applications
« Reply #87 on: February 08, 2014, 03:59:24 pm »

http://glynor.com/files/MCAutoQueue/MCAutoQueue-0980.exe

MCAutoQueue 0.9.8 (02/08/2014) -- BETA

1. Fixed: When MCAutoQueue was set to AutoRun at the command line, it could not be cancelled.  Cancelling the queue now automatically cancels both auto-run and auto-exit.

MCFileIngester 0.9.4 (02/08/2014) -- BETA

1. Fixed: AutoExit caused an unhandled exception error message.
2. NEW: CopyMetadataUserExceptFields configuration setting allows the user to provide list of fields that are always skipped when copying metadata.

MCVideoRedoer 0.9.3 (02/08/2014) -- BETA

1. NEW: CopyMetadataUserExceptFields configuration setting allows the user to provide list of fields that are always skipped when copying metadata.
Logged
"Some cultures are defined by their relationship to cheese."

Visit me on the Interweb Thingie: http://glynor.com/

glynor

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 19608
Re: MCAutoQueue: Automatically Process Files In MC With External Applications
« Reply #88 on: February 08, 2014, 04:29:30 pm »

NOTE: This system is deprecated (it only lasted publicly for one day).  See below for instructions.

This version has a new option in the core Ingester system, CopyMetadataUserExceptFields.  This is a string array stored in the user.config file for any application that uses the Ingester system that allows you to exclude certain fields from ever being cloned.  Basically, it is a global "ignore these fields" setting.

Right now, there is no UI within the application for setting this option, though I hope to add this at a later date.  It is easy enough to exclude fields using this setting manually, though, as the options are stored in simple XML.  First, you must run the new versions of MCFileIngester and MCVideoRedoer at least once to have your settings file updated.  Then, browse and locate the user.config file for the current version.  This should be located here:

C:\Users\<USERNAME>\AppData\Local\glynor.com\MCFileIngester.exe_Url_<RANDOM STRING>\0.9.4.30359
C:\Users\<USERNAME>\AppData\Local\glynor.com\MCFileIngester.exe_Url_<RANDOM STRING>\0.9.3.30359


(If you have multiple MCFileIngester.exe_Url or MCVideoRedoer.exe_Url folders in there, just sort them and use the one most recently modified.)

Inside that folder, you'll find a user.config file.  Open it in a text editor, and inside the Properties.Settings section, you should see a setting like this:

Code: [Select]
<setting name="CopyMetadataUserExceptFields" serializeAs="Xml">
<value>
<ArrayOfString xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<string>Last Played (Editable)</string>
<string>NeverCopyThisField</string>
</ArrayOfString>
</value>
</setting>

Hopefully this is pretty self-explanatory, but if you have a custom, user-created field called [Last Played (Editable)] or [NeverCopyThisField], then these will be skipped whenever the ingesting application is cloning metadata from one file to another.

You can just add your own by adding additional <string>MY FIELDNAME</string> lines between the <ArrayOfString> tags.  If you add one, for now at least, you have to add it to both MCFileIngester and MCVideoRedoer's options.  At some point, I hope to break this off into its own settings file that is global to all of them (and any future ingesters I create).

The reason I added this:

For the last little while (but not the whole time I've been working on this), I've been having trouble with the [Last Played] metadata becoming corrupt when using any of these "ingesting" applications on my main system.  When this happened, the date would reset itself back to the "epoch" (1969, I think).  The obnoxious thing was it did NOT happen with my test setups that I use while debugging, only on my "real" system, so it was annoying to diagnose.  But then, I recently set up a new VM with a test Library in order to make the MCFileIngester demo video you can check out above.  And, I discovered that the issue reappeared with this Library, but still not with my Laptop's Library.  But, when doing this setup, I had restored my main Library and Settings from my main server as part of the setup process.  I haven't done this on my Laptop in a while.

You'll notice that one of the default settings I added for this new option was [Last Played (Editable)].  At some point, I added this field to my MC Library, to let me edit the [Last Played] date by hand.  It looks like this:


Click to embiggen.


This calculated field was causing the corruption.  The problem was that the real [Last Played] field was getting cloned over properly (so it was right, at first), but then this simplistic calculated field got cloned over as well.  The problem was that it got cloned over as a "human readable" date, but apparently (unlike in the Tag Action Window from within MC) when you write this via COM, it doesn't actually "parse" the date entered, and just copies it over to [Last Played] verbatim, which breaks Last Played.

Most calculated fields don't cause trouble, as they end up being read-only, so the attempt to clone them fails.

However, if you have any special user-created fields like this, those used to end-run the otherwise locked-down Date fields, you will have to exclude these custom fields or you will end up with corrupt dates in those fields.  Unfortunately, MC's COM interface doesn't provide any mechanism to tell if a field is calculated or not (they all show up the same) so I can't exclude all calculated fields entirely.  You can use this new option to accomplish this (and if you happen to use the same Field Name as me, then you're golden).
Logged
"Some cultures are defined by their relationship to cheese."

Visit me on the Interweb Thingie: http://glynor.com/

glynor

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 19608
Re: MCAutoQueue: Automatically Process Files In MC With External Applications
« Reply #89 on: February 09, 2014, 03:32:56 pm »

http://glynor.com/files/MCAutoQueue/MCAutoQueue-0981.exe

MCAutoQueue 0.9.8.29092 (02/09/2014) -- BETA

1. Changed: Processor updates only.

MCFileIngester 0.9.5 (02/09/2014) -- BETA

1. Changed: CopyMetadataUserExceptFields system replaced with IngesterExceptionFields.xml configuration file so that this setting is unified across different Ingesters.
2. Changed: Added additional fields to stock metadata clone exception list.

MCVideoRedoer 0.9.4 (02/09/2014) -- BETA

1. Changed: CopyMetadataUserExceptFields system replaced with IngesterExceptionFields.xml configuration file so that this setting is unified across different Ingesters.
2. Changed: Added additional fields to stock metadata clone exception list.
Logged
"Some cultures are defined by their relationship to cheese."

Visit me on the Interweb Thingie: http://glynor.com/

glynor

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 19608
Re: MCAutoQueue: Automatically Process Files In MC With External Applications
« Reply #90 on: February 09, 2014, 03:38:51 pm »

I've now fixed one of the issues with the CoreMetadataUserExceptFields system:

If you add one, for now at least, you have to add it to both MCFileIngester and MCVideoRedoer's options.  At some point, I hope to break this off into its own settings file that is global to all of them (and any future ingesters I create).

This involved modifying the system a bit (for the better).  There is still no GUI for adding exceptions to the list, but it is now much simpler to add them and the settings are now universal across both MCFileIngester and MCVideoRedoer (and any future additional ingesting processors I create).

These instructions will supersede the above instructions.
Logged
"Some cultures are defined by their relationship to cheese."

Visit me on the Interweb Thingie: http://glynor.com/

glynor

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 19608
Re: MCAutoQueue: Automatically Process Files In MC With External Applications
« Reply #91 on: February 09, 2014, 03:56:10 pm »

Preventing An Ingesting Processor From Cloning Certain Fields

If you need to block any of my Ingesting Processors (MCFileIngester or MCVideoRedoer, for example) from ever touching a particular field or fields when cloning metadata, you can use the new Ingester Exception Fields system.  You may need to do this if you have created custom Fields in MC that allow you to modify otherwise read-only dates (such as [Last Played] or [Date Imported]).  If you do not have any of these custom fields, then you probably won't need to modify this setting.  I explained why I added this option earlier in this thread.

There is not (yet) a GUI to edit this list, though I may add one in the future (and will update this post if I do).

The core Ingesting system now stores a list of field exceptions in an XML file located at:
C:\Users\<USERNAME>\AppData\Roaming\glynor\IngesterExceptionFields.xml

This file is created automatically if one doesn't already exist when you run any of my Ingesting Processors (such as MCFileIngester).  The format of this file should be pretty self explanatory.  Here is the default file:

Code: [Select]
<?xml version="1.0" encoding="utf-16"?>
<IngesterExceptionFields xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <UserExceptionFields>
    <string>Last Played (Editable)</string>
    <string>NeverCopyThisField</string>
  </UserExceptionFields>
</IngesterExceptionFields>

So, by default, it will never clone metadata in these fields in MC: [Last Played (Editable)] or [NeverCopyThisField]

If you want to add your own exceptions to this list, simply add additional <string> lines to the XML file between the <UserExceptionFields> tags.  To add an exception for a field called [MyCustomField] you'd change the file to:

Code: [Select]
<?xml version="1.0" encoding="utf-16"?>
<IngesterExceptionFields xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <UserExceptionFields>
    <string>Last Played (Editable)</string>
    <string>NeverCopyThisField</string>
    <string>MyCustomField</string>
  </UserExceptionFields>
</IngesterExceptionFields>
Logged
"Some cultures are defined by their relationship to cheese."

Visit me on the Interweb Thingie: http://glynor.com/

alspoll

  • World Citizen
  • ***
  • Posts: 118
Re: MCAutoQueue: Automatically Process Files In MC With External Applications
« Reply #92 on: February 15, 2014, 12:00:14 am »

Glynor,

Is there a way for this to be used with Mediainfo to pull back stream count for audio and text (subtitles)?

What I want to do is to identify video files where there are multiple audio and subtitles streams so I can remux them to remove them to save on some harddrive space (I envision adding 2 fields in jriver audio stream count and subtitle stream count and then creating a smartlist afterwards with > 1 to review).

I looked at mediainfo and see it supports command line, but is beyond my understanding on how to use it and your program to populate MC19.

TIA,

AL
Logged

MrC

  • Citizen of the Universe
  • *****
  • Posts: 10462
  • Your life is short. Give me your money.
Re: MCAutoQueue: Automatically Process Files In MC With External Applications
« Reply #93 on: February 15, 2014, 01:32:37 pm »

While glynor has not yet had a chance to respond...

What types of files are you wondering about?  Most of mine are mkv files, and are single-stream, and I've never bother pulling the subtitles, etc., so I perhaps don't have the necessary data for evaluating what the mediainfo command line results would look like in your case.

Edit: I've split the topic, and moved our conversation to pscriptor:

   http://yabb.jriver.com/interact/index.php?topic=85990.msg599194#msg599194

Let's continue our discussion over there, but any discussion regarding glynor's tool / help should remain here.
Logged
The opinions I express represent my own folly.

glynor

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 19608
Re: MCAutoQueue: Automatically Process Files In MC With External Applications
« Reply #94 on: February 15, 2014, 08:48:28 pm »

I was basically going to make that suggestion.  Perhaps automate it with this?
Logged
"Some cultures are defined by their relationship to cheese."

Visit me on the Interweb Thingie: http://glynor.com/

MrC

  • Citizen of the Universe
  • *****
  • Posts: 10462
  • Your life is short. Give me your money.
Re: MCAutoQueue: Automatically Process Files In MC With External Applications
« Reply #95 on: February 15, 2014, 09:01:13 pm »

Cool.  I got alspoll all squared away.
Logged
The opinions I express represent my own folly.

Fred1

  • Regular Member
  • Galactic Citizen
  • ****
  • Posts: 491
  • Change this by choosing profile

Hello glynor,

i'm very interested in MCFileIngester but i can't find where to load it down.
When i installed from here (http://glynor.com/files/MCAutoQueue/MCAutoQueue-0981.exe), i thought MCFileIngester is included -  but it obviously isn't.

What's the trick?
Logged

astromo

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 2251

Hello glynor,

i'm very interested in MCFileIngester but i can't find where to load it down.
When i installed from here (http://glynor.com/files/MCAutoQueue/MCAutoQueue-0981.exe), i thought MCFileIngester is included -  but it obviously isn't.

What's the trick?

No real trick from what I can make out. MCAQ has Ingester and VideoRedoer packaged up in the one executable.

Where [X:] is the drive you've load MCAQ to, if you navigate to:
  • [X:]\Program Files (x86)\MCAutoQueue\Processors\
Ingester shows up for me. From the Start menu, at the MCAQ menu there's a Processors menu similar to the folder structure shown above.
Logged
MC33, Win10 x64, HD-Plex H5 Gen2 Case, HD-Plex 400W Hi-Fi DC-ATX / AC-DC PSU, Gigabyte Z370 ULTRA Gaming 2.0 MoBo, Intel Core i7 8700 CPU, 4x8GB GSkill DDR4 RAM, Schiit Modi Multibit DAC, Freya Pre, Nelson Pass Aleph J DIY Clone, Ascension Timberwolf 8893BSRTL Speakers, BJC 5T00UP cables, DVB-T Tuner HDHR5-4DT

glynor

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 19608

Yep... As the old lady in the commercials said: Its in there.

It the installer puts a link to it in the Start Menu folder for MCAutoQueue.
Logged
"Some cultures are defined by their relationship to cheese."

Visit me on the Interweb Thingie: http://glynor.com/

Fred1

  • Regular Member
  • Galactic Citizen
  • ****
  • Posts: 491
  • Change this by choosing profile

Thanks!

I had read the whole thread but couldn't find a hint how to start MCFileIngester.
Perhaps i missed it.

I have to rerip about 1200 CDs, so MCFileIngester will be very handy.

By the way: is it possible not to delete the old files but to move them to another disk intelligently (adding a number at the end of the filename if the file already exists in the destination directory)?
Or setting a field inside MC when processing is done?
Logged
Pages: 1 [2] 3 4   Go Up