INTERACT FORUM
Windows => Third Party Plug-ins, Programs, and Skins => Topic started by: glynor on December 04, 2012, 02:15:38 am
-
MCAutoQueue is a standalone application that can be used to fully automate things like Video Conversions, File Replacements, Post-Processing, Ad Skip Processing, and much more. It uses the power of MC's Smartlists, Database Fields, and Tag-On-Import settings to accomplish its magic. Here's a look:
(http://glynor.com/files/MCAutoQueue/MCAutoQueue-screenshot-small.png)
Click to embiggen. (http://glynor.com/files/MCAutoQueue/MCAutoQueue-screenshot.png)
Download Here (http://glynor.com/files/MCAutoQueue/MCAutoQueue-0992.exe)
Current Version: 0.9.9.2
Requirements:
1. JRiver Media Center: MCAutoQueue was developed on MC19. Prior versions are not supported (though it may be functional). Note: Confirmed still functional on MC27.
2. Microsoft .NET 4.5 Framework: This is the .NET framework from Microsoft. You probably already have it, but if not it is available here: Microsoft .NET 4.5 Framework Download (http://www.microsoft.com/en-us/download/details.aspx?id=30653)
3. Windows 10, Windows 8, Windows 7. The .NET 4.5 Framework is not available for Windows XP and older versions of Windows. Sorry, guys, no XP support.
Please Note: This is a BETA. However, this can be considered a release candidate. No further substantial changes should be expected before the 1.0.0 release. I've been using it in production now for quite some time.
Change Log:
Change logs for the current release:
* glynor.common-ChangeLog.txt (http://glynor.com/files/MCAutoQueue/glynor.common-ChangeLog.txt)
* MCAutoQueue-ChangeLog.txt (http://glynor.com/files/MCAutoQueue/MCAutoQueue-ChangeLog.txt)
* MCFileIngester-ChangeLog.txt (http://glynor.com/files/MCAutoQueue/MCFileIngester-ChangeLog.txt)
* MCVideoRedoer-ChangeLog.txt (http://glynor.com/files/MCAutoQueue/MCVideoRedoer-ChangeLog.txt)
Included:
I've also included a few quite handy processors that can be used with MCAutoQueue (or completely standalone), or as tools to build your own scripts. In particular, check out MCFileIngester (http://yabb.jriver.com/interact/index.php?topic=76147.msg528833#msg528833) and MCVideoRedoer (http://yabb.jriver.com/interact/index.php?topic=76147.msg552751#msg552751) details in the thread below.
Getting Started:
You need three main things set up to use MCAutoQueue: a Field and Smartlist in MC, and some Processors (command line tools) to run on the files with this field filled in.
1. Field:
MCAutoQueue uses a Field in Media Center as a key to pick which processor will be used for a particular file. The best option is to use a String Type field in Media Center, and then add an "Acceptable Values" restriction to that field. Here's an example:
(http://glynor.com/img/screenshots/MCAutoQueue/FieldToProcess-example-small.png) (http://glynor.com/img/screenshots/MCAutoQueue/FieldToProcess-example.png)
(I suggest you use [NeedsProcessing] but you can use anything you'd like.)
To use the examples in the included example configuration file, you'd use this in the Acceptable Values restriction box when configuring the field:
Completed;Failed;Echo Normal;Echo Series Argument;Echo Causes Timeout;Echo No Update;Echo MC Style;AdScan;VideoReDo-iPhone;VideoReDo-Auto
Then, add this Field to your Views in Media Center (as a column, or choose Also Show in the Tag Action Window). It is also convenient to make a view where you have the [NeedsProcessing] field added as a category, so you can see them in one place and filter by it. In any case, get it into your Views so you can tag some files with the field.
2. Smartlist:
Then, you create a Smartlist in Media Center that shows any file that has an entry in this field, except for the special values "Failed" and "Completed". Here's an example Smartlist:
(http://glynor.com/img/screenshots/MCAutoQueue/Smartlist_Setup-example.png)
-[NeedsProcessing]=[],[Failed],[Completed] ~sort=[Date Imported]
You can use any filters on the Smartlist you want, including things like adding limits, a sort order (to process things in the preferred order), or anything else. You could even, if you want, use a manual Playlist (though a smartlist is almost always going to be preferable).
3. Processors:
In MCAutoQueue itself, under the Settings button, you can define what command line tools you want to run on files that "match" this key. When it runs, MCAutoQueue will get the list of files from the playlist you made in Step 2. Then, for each of those files, it will read the contents of the field you defined in Step 1. And lastly, it will look at the names of the Processors you've defined looking for a match to decide which "Processor" (or command line tool) will be run on the file in question.
(http://glynor.com/img/screenshots/MCAutoQueue/MCAutoQueue_Settings-example-small.png)
Click to embiggen. (http://glynor.com/img/screenshots/MCAutoQueue/MCAutoQueue_Settings-example.png)
Each Processor can take these settings:
Key: The name of the processor, and the value that will trigger it in the [NeedsProcessing] field.
Command to Run: This must be a path to an executable file on disk (exe, script, etc).
Argument: The argument you'd like to use for the command. This setting is parsed, and works much like using MC's Rename, Move, and Copy tool. It can be as simple as the [Filename] of the file from MC, or as complex as using Media Center's expression language.
Options: Each Processor has a couple of options, which will be explained below.
Timeout: When they run, each processor is limited to a maximum run-time, after which MCAutoQueue kills the process and marks the file as failed. You can modify the timeout setting for each Processor independently here (in minutes).
Running MCAutoQueue
When you run MCAutoQueue, it will pull the contents of the Smartlist, look at the Field to Process, decide which Processor to use, and then execute the commands one at a time in sequence (following the sort order defined in your Playlist in MC). As each Processor completes execution, MCAutoQueue will then mark the field "Completed" (and mark them as Failed if they fail).
When it finishes with all of the files in the Smartlist, it is done, and can exit. MCAutoQueue logs all of its activity, and can be controlled by command line options itself.
For best results, you would add Tag On Import (https://wiki.jriver.com/index.php/Tag_on_Import) rules to your Auto Import settings in MC, that automatically set this [NeedsProcessing] field for you. Then, you schedule MCAutoQueue in the Windows Task Scheduler to run automatically in the middle of the night. It runs through and processes your files for you.
You can, of course, use it completely manually, though. Perhaps you just want to be able to queue up batches of files for processing manually? It doesn't matter, as it will work either way.
Command Line Options:
MCAutoQueue (by glynor) v0.9.5 Command Line Help
Usage:
Process Media Center files using settings provided in the AQConfig file.
If no --config option is provided, the most-recently used automatic config file will be used.
Options:
-c, --config=AQCONFIG the AQCONFIG file to use for processing.
--notimeout Disable all processor timeouts (not recommended).
-e, --autoexit automatically exit after running. This option
is ignored if an error occurs and the relevant
preference is set.
--AutoExit automatically exit after running (alternate
syntax).
-a, --autorun automatically run the processor.
--AutoRun automatically run the processor (alternate
syntax).
-m, --runmin start up minimized. This has no effect if
autorun is not also set.
--AutoMinimize start up minimized (alternate syntax).
-h, --help show this message and exit
So, download it, give it a whirl, and tell me what you think!
-
Processor Options:
Argument Styles:
The argument can be of two types: Normal, or MC Style.
Normal:
Normal Style uses simple Field replacement, using the [FieldName] notation we're all used to here. The nice thing about this mode, is that it automatically adds quotes around results from fields that need them (because they contain spaces), making it simple to use. So, for example, if you wanted to send files to a script that takes a few options and a filename identified by a -i= option, you'd just put this in the Argument box for that Processor
-a --MakeCool --fast -i=[Filename]
And MCAutoQueue will fill in the [Filename] field using the information from MC, adding quotes as needed. You can use any named Field in MC, but not expressions in this mode. If you include text that looks like a Field, but which isn't "tagged" on the file in question, then the field name will be passed through untouched (so if the options to your command line tool use square brackets for something, that isn't a problem).
MC-Style:
This sends the text exactly as it is to MC, and asks MC to return the results of the expression. This allows you to do full expression logic, using all of MC's language's bells and whistles. It also, incidentally, is faster than my Regular Expression based "normal" mode. However, it does force you to manually quote any fields that might have spaces, or else no quotation marks will be included (which will probably keep your command line tool from understanding the command line arguments you sent it).
Update MC:
Normally, when MCAutoQueue finishes processing a particular file, it will change the entry of the Field to Process for that file ([NeedsProcessing] by default), to Completed for files that "succeed" and Failed for those that "fail".
However, if the command line tool or script you are running is "MC aware" then it could conceivably set this field for you, perhaps to reassign it to another Processor. This would allow you to "chain" Processors together. For example, with a script, you could have it Quick Stream Fix video files in VideoReDo, and then (if that succeeds) compress them using HandbrakeCLI on the next "round".
Unchecking the Update MC box for a particular processor tells MCAutoQueue not to update that field at all, and to leave it alone.
Please note: If you use this, and you don't clear that field somehow (manually or by script) then MCAutoQueue will reprocess the file over and over again each time you run it.
Saving and Loading Settings:
MCAutoQueue can save out the set of loaded Processors, along with the specific Playlist and Field to Process, to an XML settings file on disk. Then, you can use the --config command line option to load these settings when you are running. This can allow you to have multiple different setups in MCAutoQueue all simultaneously.
Perhaps you want to have one "setup" for music files, and another for video files? Or a set of processors just for Classical music, or TV Shows, and a different set for movies (which run on a different schedule)? Or you want to compare the results of compression engines with different options? Save the settings out and you can do this!
Here is an example of an aqconfig settings file (this is the "real world.aqconfig" file included in the Example AQConfigs subdirectory of the installation folder):
<?xml version="1.0" encoding="utf-16"?>
<AQSettings xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<QueuePlaylistPath>MCAutoQueue</QueuePlaylistPath>
<FieldToProcess>NeedsProcessing</FieldToProcess>
<ProcessorConfigs>
<ProcessorSetting>
<Name>AdScan</Name>
<Command>Processors\MCVideoRedoer.exe</Command>
<Argument>--adscan --source=[Filename] -a -e</Argument>
<MCStyle>false</MCStyle>
<UpdateField>true</UpdateField>
<Timeout>120</Timeout>
</ProcessorSetting>
<ProcessorSetting>
<Name>VideoReDo-Auto</Name>
<Command>Processors\MCVideoRedoer.exe</Command>
<Argument>--profile="Auto Profile" --type=Replace --deletesource --source=[Filename] -a -e</Argument>
<MCStyle>false</MCStyle>
<UpdateField>true</UpdateField>
<Timeout>45</Timeout>
</ProcessorSetting>
<ProcessorSetting>
<Name>VideoReDo-iPhone</Name>
<Command>Processors\MCVideoRedoer.exe</Command>
<Argument>--profile="iPad / iPhone 4G" --type=Replace --deletesource --source=[Filename] -a -e</Argument>
<MCStyle>false</MCStyle>
<UpdateField>true</UpdateField>
<Timeout>360</Timeout>
</ProcessorSetting>
</ProcessorConfigs>
<DisableProcessorTimeouts>false</DisableProcessorTimeouts>
<MinimizeProcessors>false</MinimizeProcessors>
</AQSettings>
Global Options and Advanced Settings:
Minimize Processors: Select this if you want MCAutoQueue to automatically start any Processors up minimized. Note: This option is saved to the .aqconfig file, so you can have different choices for this per-settings-file.
Disable Processor Timeouts: This is basically "Safety Off mode". If a given processor lasts three weeks, months, years, or millenia, MCAutoQueue won't stop it or force it to time-out. It'll just patiently wait until it is done, and then run the next item in the queue. This, obviously, could spell trouble if you have a crashed Processor.
Default Timeout: When you make a new Processor, it gets this Timeout setting by default. This is an automatically-saved global option, just there for convenience if you don't use the default I preset very often.
Logging: You can rotate the log file, using a variety of choices, or disable logging altogether. Pretty self-explanatory.
-
0.8.0 (12/04/2012) -- BETA
1. Initial Release
Known Issues:
1. The Settings button does not properly disable while the Queue is processing, which would allow you to go in and muck about with the Settings mid-processing, a decidedly bad idea.
2. Validation of the aqconfig files is early. Manually edit them with care. If you run into trouble, delete your MCAutoQueue.exe.config file in the installation directory, and it will reload the defaults.
3. Error reporting is weak in the UI. The log is pretty good though. If you get any general exceptions or other unexplained errors, please retain the logs.
-
Very nice work.
I am trying to think of possible applications for myself. One idea is that I am trying to replace as much video as possible in my library with IOS friendly mp4.
Does anyone know if there is an mkv to mp4 converter that works in unattended mode and produces excellent results without having to tweak lots of conversion variables?
-
One idea is that I am trying to replace as much video as possible in my library with IOS friendly mp4.
Does anyone know if there is an mkv to mp4 converter that works in unattended mode and produces excellent results without having to tweak lots of conversion variables?
This is certainly one of my goals as well (in my case, I want to be able to create automatic stacked MP4 versions of certain videos). The easiest way? Handbrake. It is quite scriptable:
https://trac.handbrake.fr/wiki/CLIGuide
There are nice presets built into Handbrake that can do things like this quite easily. It can be (and usually is for simple Apple-compatible exporting) as simple as running:
HandBrakeCLI -i <input_filename> -o <output_filename> --preset="Universal"
This is one of the example scripts I'm going to create in the coming weeks. Combined with my CopySidecar.vbs script (already included), you could have this workflow:
1. Tag files with [NeedsProcessing] = "Handbrake Universal"
2. MCAutoQueue runs, and fires off a Handbrake Conversion script.
3. This script first copies the existing sidecar file over to a new copy with the extension changed to .mp4 (that way, when Handbrake creates the new destination MP4 file, it gets auto-imported with all the existing metadata intact) -- this is my included CopySidecar.vbs script.
4. Then, it calls HandbrakeCLI to do the conversion, putting the output file right next to the input file.
5. Then, it runs a final cleanup script/utility that (optionally) removes the original source file from MC, or maybe stacks the new one with the original.
Handbrake isn't perfect in every way, and there are cases where FFMPEG might do a better job, but it is easy to use, reliable, and produces quite good quality with the current builds.
Another script that I'm going to provide (even sooner) is one that does almost the same exact steps as above, but instead of #4 (the video transcoding step), it will simply run VideoReDo's QuickStreamFix on the file and then pump it through MKVMerge to enable a non-transcoded (but fixed) conversion from TS to MKV. Since it won't transcode, it will be very quick.
Lastly, I have some ideas for doing Re-Ripping replacements (so if you have old MP3s you ripped eons ago, and you re-rip to FLAC, it will go into MC's Library and replace the existing MP3 file entry with the new FLAC copy).
-
One thing I'm mulling changing with this already is the setup of the Processors, and I'd love some feedback, as I'm waffling back and forth on how I want to do it.
Right now, MCAutoQueue is pretty simple. You have two "pieces" to use to construct the command line that will execute for that Processor: the Command (application) to run, and the Argument (the field from MC to use as the command line arguments for the command). MCAutoQueue checks that the Command given for a particular processor exists on disk before it runs it, and therefore you can't add extra "static" command line arguments to the Command box when you are setting up a Processor.
My original thinking was that you could accomplish anything you want using a Calculated Field in MC and use that as your Argument for that particular command. Or, if you want something very simple that never changes depending on the input file, you could just wrap your tool in a simple VBS Script or BAT file that provides the other command line arguments needed. That is true for both things, but it might be too much work for a simple conversion task like the Handbrake one above.
So, I see three possible options (ranging from easiest to code to hardest).
1. Leave it as is.
2. Change it so that MCAutoQueue no longer sanity checks the command line you provide for the Processors to see if they exist. This would be the simplest option, of course, and then you could add whatever static command line arguments you want to a particular command line tool, and the [Filename] (or whatever field is chosen) will be added as the "last" argument in the chain.
3. Change it so that MCAutoQueue has two Arguments for each Processor. The first would be a string you type in like this:
-i <$MCfield> -o <$AutoOutput> --preset="Universal"
Then, you could define a second Argument based on a field. When the Processor runs, it would replace the <$MCField> part with whatever you provided in this second Argument Field, and replace the <$AutoOutput> item with a filename generated based on the source filename.
I don't know how much I like this third option, though. First of all, it would be clunky to use, and make the UI more cluttered and confusing (and there are already some esoteric steps to use this if you aren't comfortable making new Smartlists and Fields in MC). More importantly, I like that MCAutoQueue doesn't assume that the Argument given will be the [Filename] tag, but allows you to use any tag you want. In order to do the <$AutoOutput> magic, it would need to ensure that the field given was the filename (maybe not though...)
And, frankly, MC has all the tools built-in to generate this string with an existing Calculated Field. You could easily make a [Handbrake Universal Argument] field, which generates the same thing, and pass that to your "Handbrake Universal" Processor in MCAutoQueue. Perhaps all of this would be much better served with a separate "generic processor" application that could wrap other command line tools. Hmmm... I don't know exactly what to do. Opinions would be appreciated...
-
This is certainly one of my goals as well (in my case, I want to be able to create automatic stacked MP4 versions of certain videos). The easiest way? Handbrake.
Thanks. I will play a bit with Handbrake to see if I can get my confidence high enough to run it on batches of video with your app.
-
Some suggestions:
1) Use a command line option such as -f or -c to indicate the config file will follow. This allows you to reserve and use trailing arguments as one or more filenames.
2) It seems you can assume the first word in the command line is the command - thus you can always check for its validity as a processor/executable.
3) I'm not sure you'll be successful trying to cover all cases of argument passing, or abstract it to a convention which suits all needs. Why not consider just passing the entire argument chain Args in an MC field. E.g. -i [Filename] -o [Filename].out -x -y -t 20, etc. If a processor needs static arguments in all cases, define those in your configs as some static argument token, and construct your command as <cmd> <static args> <MC supplied argument chain>. You can have processor variants, such as Convert, Convert-Large, etc. which include the relevant static arguments so that uses don't have to include these in the argument chain.
4) For ease in documentation, debugging, and support, consider using predefined fields that your utility requires, such as _MCAutoQueue and _MCAutoQueueArgs. I'm not sure you gain much by generalizing this to be any configured variable. (This adds a layer of support questions - "Did you configure the variable name in the config?" "Does it match the variable you created in MC?")
-
2) It seems you can assume the first word in the command line is the command - thus you can always check for its validity as a processor/executable.
This is what I'm thinking of doing. I'll have to play around with it a bit to see what really makes sense. I really might not need to do the check at all, depending on what status the Process.Start() command gets back if the command doesn't exist/work (if it throws an exception, then I need to deal with it, since it is done in a Background Worker, if it just fails, then I can just report it as failed and not worry about it).
1) Use a command line option such as -f or -c to indicate the config file will follow. This allows you to reserve and use trailing arguments as one or more filenames.
I'm confused about most of the rest of your comments, though... In particular this one.
Do you mean in the Command to Process field? If so, this would have to match exactly what is being sent to the external processor (which is why I was thinking of using some kind of string-replacement scheme).
If not, and you mean MCAutoQueue's command line options, then no, it doesn't apply. MCAutoQueue doesn't care what order you give the command line options. It just parses each argument, and anything it gets that isn't a pre-defined command line argument, it assumes is an aqconfig filename (it checks this for sanity as well, though). You cannot pass multiple aqconfig filenames, and wouldn't ever need to. If you look at the structure, you'll see why.
The reason I want to keep the fields and playlists flexible is because I can envision people having multiple playlists and fields that they use for different purposes. So, say you have one Queue List that handles all video post-processing and is run automatically, but you also want a separate "set" that does audio-file replacement on demand.
With this scheme, you can just make two different aqconfig files, and launch them with:
MCAutoQueue.exe --AutoRun --AutoExit "my video processors.aqconfig"
MCAutoQueue.exe "my audio processors.aqconfig"
And these two things would look at and process two completely separate Playlists and Fields in MC. They could be scheduled separately in the Windows Task Manager (or schedule one, leave the other manual, or whatever). It does, of course, provide default examples. And, if all goes well, my future setup wizard would walk you through the process of creating these Library fields and Playlists.
So.... I'm a little confused. But I'm still thinking about it.
I'm leaning towards a modified version of #2 above, where it sanity checks the first item in the command list, but then just lets you put whatever else you want in there. For complex things, just use a BAT file or a script (and I'll probably make some nice ones for things like Handbrake myself).
-
Re-reading here...
3) I'm not sure you'll be successful trying to cover all cases of argument passing, or abstract it to a convention which suits all needs. Why not consider just passing the entire argument chain Args in an MC field. E.g. -i [Filename] -o [Filename].out -x -y -t 20, etc. If a processor needs static arguments in all cases, define those in your configs as some static argument token, and construct your command as <cmd> <static args> <MC supplied argument chain>. You can have processor variants, such as Convert, Convert-Large, etc. which include the relevant static arguments so that uses don't have to include these in the argument chain.
This was exactly my plan already, except without the separate static arguments field in MCAutoQueue. You can do that in your calculated field that you send to that Processor. So the way it is set up now is that you define two items per-processor.
<command> <argument_field>
The Argument field is a field in MC. Any field you want, and each processor can have their own. Command is an executable file (exe, vbs, bat, whatever). When you run the queue, it retrieves the contents of the field specified for that file from MC, does essentially Shell Run:
<command> <arguments>
The issue is only that if you want to run a command that takes complex arguments (more than just a source filename), you have to make a custom field in MC, even if the arguments you want to add don't change from file to file. That seems silly. I think I'm going to change it so that the <command> box in MCAutoQueue will let you put whatever arguments you want in addition to the EXE (and like you said, the EXE will be the first thing in the box, so I can still verify it exists if I want). Then, if all you want to do is something like: mycommand.exe -mp4 --noresize --foo -o:<filename> you'd just put:
mycommand.exe -mp4 --noresize --foo -o: in the Command box, and
Filename in the Argument box.
The only time you'd need to do a custom calculated field would be if you needed complex arguments where order matters, or if you needed to send multiple fields from MC into the processor (in which case you'd also want to consider wrapping your command in a script or BAT file to make life simpler).
Does this make sense?
If more complex options are needed, I'm willing to add them, but my goal is to keep MCAutoQueue simple. If complex edge-cases can be adequately handled by simply using a calculated field in MC as the argument for that particular processor, I'm thinking that is the way to go. I just don't want it to end up that you need to make a calculated field for everything you use it for...
-
Why not just use field placeholders in your config files, such that the user doesn't have to pass arguments, and instead your app queries the values from MC? This way, its sure to always get the correct values just before the command executes.
mycommand.exe -mp4 --noresize --foo -i:[Filename] -x [Media type] -n [Name] -s [Series] --debug
where each value in brackets is looked up from MC for a given file.
-
Why not just use field placeholders in your config files, such that the user doesn't have to pass arguments, and instead your app queries the values from MC? This way, its sure to always get the correct values just before the command executes.
mycommand.exe -mp4 --noresize --foo -i:[Filename] -x [Media type] -n [Name] -s [Series] --debug
where each value in brackets is looked up from MC for a given file.
Ahhh.... Now I see what you meant. I considered that way back when I first started this project. You'll have to excuse me a bit, but take note what time I posted this up above (EST, for reference). My brain not work right today.
The answer is this:
my goal is to keep MCAutoQueue simple.
Basically... Why reinvent the wheel? MC already has a powerful expression language with a complex parser. No matter what I implement, if isn't going to be as powerful as that, and I'll have to invent my own system (and maintain a more complex parser, which might be re-run with thousands of different files at a time and passed all kinds of weird things I don't expect).
JRiver has already done that work. If you want something like your example, regularly, to go with a particular processor, make a calculated field in MC and pass that!
So, in other words, I'd consider it (and I could implement some kind of simple find-and-replace scheme). But...
What if a command needs brackets? Then I need to find a way to escape them, and... I don't know. Seems like a rabbit hole to me, when the answer is right over here already built in, and it can use complex Regular Expressions and If-Else and the whole bit.
-
How will you implement a pipeline command chain should you desire?
cmdA argA | cmdB argB1 argB2
If you're going to place arguments in an MC field, then you have to place the pipe and subsequent commands there too.
There's nothing complex about using replacement tokens. You don't have to use brackets, you can use any number of ways to indicate in
the command syntax that something is to be looked up in MC. And supporting an escape character is pretty trivial. There's no need to replace MCs expression parser - the query to obtain a field's value will do the right thing and just return a text value which becomes your argument parameter. You're going to have to handle quoting anyway.
Anyway, just some thoughts. See how it works out.
-
Actually, no... You're right.
Well, with this:
How will you implement a pipeline command chain should you desire?
cmdA argA | cmdB argB1 argB2
How I'd implement it would be with a wrapper script. But you're right about this:
There's nothing complex about using replacement tokens. You don't have to use brackets, you can use any number of ways to indicate in
the command syntax that something is to be looked up in MC. And supporting an escape character is pretty trivial. There's no need to replace MCs expression parser - the query to obtain a field's value will do the right thing and just return a text value which becomes your argument parameter. You're going to have to handle quoting anyway.
And, I'm not right now.
Or not really. I tried to implement a special case for the [Filename] (as that's really all I needed right now), but it doesn't even seem to be working correctly. I hadn't noticed because almost all the files I've used it with happen to have no spaces in their names! My bad (SageTV, which doesn't use them, and my work systems, which are all space-character-free because they're used in URLs and RTMP addresses).
You're right. That's the simplest solution. I won't be able to tell if the user is passing me a complex, parsed expression as the argument (where they don't want it quoted) and the simple fields like Filename and Artist, where they probably do.
It needs a parser and replacement fields. Okay, that isn't impossible.
MrC, I'm going to be hitting you up for suggestions (and feel free to fire away). My thinking is this:
Allow any MC Field to be inserted into an otherwise string literal. I'd like to use [] to denote them, if it doesn't cause major problems, since that's our lingo anyway and it is used in MC. But no other complex parsing, as that can be done outside in MC itself. I'll quote all fields that contain spaces, and pass through any that do not. The rest is a string literal sent to the command line (essentially).
How's that sound?
-
Pretty much that's the idea!
-
Pretty much that's the idea!
Kept me up half the night reading about RegEx. I know now that this was really just your ploy to force me to learn it. But...
My brain hurts, and I'm still not 100% sure what to do. I'm going to play with it a bit, but I think I'm going to be asking for help.
EDIT:
Okay... My main questions are:
1. I want to do a first pass with a Regex and do a parse for any non-printing characters (stuff like Control-C and NewLine), and just strip them all out. That's mainly in case people copy-pasta in from a text editor or whatever. The textbox itself is a single-line job in a DataGridView, so... I'm just worried about weird non-printing characters messing up the command lines sent, without being immediately obvious what is going wrong. So, I figure, they're useless anyway, and I should strip them out.
But do I just have to do some kind of crazy "all the keyboard characters" match to do this? Suggestions?
2. Then I can do a more traditional RegEx.Match run to grab the values inside the brackets. I need, obviously, something along the lines of: "\[.*\]", but including grouping to capture the .* in the middle, and some way to avoid capturing the ones marked by whatever I use as an escape character (sorry, still learning, I only spent a couple hours reading). Then I should be able to iterate over the groupings with Match.Groups[n].Value to retrieve my replacement values from MC, and then all it would be is a simple substring replace to write the new values back in (once I decide whether to add "" or not).
Also, I'm thinking of using [] to denote fields (as discussed above) with the ^ as the escape character. Since ^ is an escape character at the cmd prompt anyway, I figure it should be relatively rare (particularly when combined with brackets). So, the rules would be simple:
\[.*\] = Field
\^\[ | \^\] = should be ignored (not a field). However, I need to also strip out the extra ^ characters when they're next to a [ or a ]. Probably at the end of the parsing, I'd assume? (And then, if someone does need to do ^[ or ^] for some reason, they can just double up on the ^ character, since it'd only replace the one character.
Strategies? Suggestions? Does that seem like a good choice for an escape character?
MrC, RegEx help for a hopeless newbie? I'm working on it, and I do want to understand whatever I put in there (for maintenance reasons), but... RegEx is hard, as we've discussed before. I know it is mostly a mental thing in that the syntax makes my eyes bug out (too many weird escapes and slashes and brackets and whatnot). I wish there was a "more verbose" version with less shorthand (like a VB of RegEx).... Sigh.
-
\[.*\] = Field
\^\[ | \^\] = should be ignored (not a field). However, I need to also strip out the extra ^ characters when they're next to a [ or a ]. Probably at the end of the parsing, I'd assume? (And then, if someone does need to do ^[ or ^] for some reason, they can just double up on the ^ character, since it'd only replace the one character.
Right, so I need a RegEx that does:
\[.*\] but NOT \^[.*\^\] and then gets a group on the .* in the middle of the matching set, right? I'd been thinking last night (late) that I could just ignore the first part ^[ and look for a space before the [, but that doesn't work if the user wants to do something like --inputfile:[Field]. So, it can't rely on spaces, it has to look for both patterns.
I need to get one of those RegEx tester thingies...
EDIT: Wait... Why use a separate character for the escape? I can just use double-brackets to escape, right?
So, [Artist] would output "Pink Floyd"
But, [[Artist]] would output "[Artist]"
That seems easier.
-
One other thing to consider...
I can easily add a GetFields() method to my existing MC Singleton class that returns a List<string> of all of the valid Field names in MC. Would it be useful/valuable or hurtful to check any results from the RegEx match against this list to see if they're actually valid Field Names (if not, I can treat them as literals).
I'm wondering if this could cause more problems than it would solve, though... Perhaps the expected behavior would be to return null for unmatched Fields? That is, I believe, what it would do if I just ignored it and tried to Get the value of them all from MC anyway (the IMJFileAutomation.Get(strField, bFormatted) function should return null if it the strField you send a field it can't find, so I can just replace those in-line and call it good).
And, it looks like want I want is something to do with the Regex.Replace() with a MatchEvaluator. But that is currently opaque to me, unfortunately. I need to read about Lambda expressions and the MatchEvaluator class.... Either that or something like this (http://www.stringtemplate.org/index.html), but that looks like it is way more complex than I need.
-
Before you spend much more time on this... consider:
https://www.google.com/search?q=argument%20processing%20.net (https://www.google.com/search?q=argument%20processing%20.net)
-
Before you spend much more time on this... consider:
https://www.google.com/search?q=argument%20processing%20.net (https://www.google.com/search?q=argument%20processing%20.net)
Hmmm... I looked into that stuff when I implemented the Command Line parsing for this application itself (but decided my needs were so simple, for now, that it wasn't worth the effort of building something more flexible).
But I'm not sure how that applies to this. I don't need to parse the command line in any way, just execute it (which just means I assign Process.StartInfo.Argument a string). I just need to do Token Replacement in the string first.
-
But I'm not sure how that applies to this. I don't need to parse the command line in any way, just execute it (which just means I assign Process.StartInfo.Argument a string). I just need to do Token Replacement in the string first.
Yes, you do. Otherwise you've just opened up a massive security hole.
Consider what happens when values contain metacharacters that you'll simply interpret. Redirects, pipes, commands that remove files, etc.
Anytime you're going to execute a command line from unfiltered data, you must untaint that data. Therefore, you need to examine each component.
-
I responded in a PM.
-
Yeah, I looked into it more, and I'm pretty sure this is not needed for the way I'm launching the external process.
The Argument field is NOT processed by cmd.exe, unless the user selects cmd.exe as the executable (file) to launch (which would probably be a bad idea).
In other words, you can't pipe commands like in your example above, MrC. The file that is "executed" is specified separately, and is executed directly (not by cmd.exe). If you really wanted to pipe, you could tell MCAutoQueue to use cmd.exe as the command, and then pass your "real command" as the Argument. All Arguments are sent only as parameters to the executable specified as the "Command".
Using cmd.exe would be a bad idea though because the fields in MC could contain dangerous characters as you mentioned. In fact, I may block it and require an explicit config override or something. I'm not going to protect against this by parsing all the command arguments (that would be terrible).
I'm struggling to get a RegEx working the way I want though... I'll post more later.
-
Thanks. I will play a bit with Handbrake to see if I can get my confidence high enough to run it on batches of video with your app.
I tried Handbrake and it's superb U/I replacement VidCoder. Neither seem to do what I want.
I want an app that will take as input an x264 mkv, pass through the video unchanged, transcode the audio to aac if not already aac, otherwise pass the aac through unchanged, pass through any imbedded subtitles or chapters unchanged, and change the container to mp4.
Anyone know of such an animal?
-
If the goal is to get Apple Device support, remuxing it to MP4 isn't going to work most of the time. The iDevices (as is true of all mobile devices) only support a subset of the H.264 spec, and most MKVs you probably have lying about don't have the right data rates, profiles, and whatnot.
The iPhone 4+ (and modern iOS devices of the same era) support more than Base Profile MP4 (finally), but you'd have very hit-or-miss support if you just remux them.
But....
To answer the question, not really. Not for a reasonable price. Telestream Episode can do it, but it can't take MKVs as source files (supposedly they were adding it, though, and I'm still on an older version). But that's a pretty penny! It would also be worth it to check out VideoReDo (which is a handy tool anyway). They have a free trial, but it still isn't cheap (and is really more of an editor, and is kind-of a pain to script).
You could use MP4Box and BeSweet to script it, if you're feeling ambitious. But I don't know of much free. Maybe HDConvertToX.
EDIT:
This is an older article (it mentions YouTube's videos don't work, which they now do, for example), but it covers many of the basics:
http://www.niallkennedy.com/blog/2010/07/h264-video.html
The iPhone 5 now supports High profile level 4.1, so it has more comprehensive H.264 support, but that's not always been the case, so unless you have a latest-gen device, you're going to have mixed results.
-
Thanks. I tried my old swiss army knife MediaCoder and it works except does not handle subtitles.
I think I found the perfect solution: MkvToMp4.
http://forum.videohelp.com/threads/340675-Mkv%D0%A2%D0%BEMp4-v0-222-rapid-tool-for-repack-Mkv-to-Mp4 (http://forum.videohelp.com/threads/340675-Mkv%D0%A2%D0%BEMp4-v0-222-rapid-tool-for-repack-Mkv-to-Mp4)
http://forum.doom9.org/showthread.php?t=163050 (http://forum.doom9.org/showthread.php?t=163050)
Sorry to hijack this thread. Will shut up now.
-
Nice find. Hadn't seen that one. Does it take files from the command line?
PS. The dude that posted in the thread in all caps was a riot. I don't know that I'd have been able to respond intelligently to him like the author did.
-
Does it take files from the command line?
Unfortunately not. Author in thread explicitly states no plans to support command line operation.
-
So, I figured out two ways to do the discussed multi-field replacement in the Argument.
Option 1: I should be able to get replacement working using a RegEx and essentially a modified version of this approach: http://blogs.msdn.com/b/akirsman/archive/2011/09/13/c-token-replacement-using-regex.aspx
I have a RegEx that does what I want, but I'm reasonably sure it isn't "correct". MrC, care to comment? My RegEx is:
\[([^\]]+[^\t\r\n])\]
I'm trying to ignore line breaks and other special characters, but capture what I want. It seems to be working fairly well, but I need help. It won't properly handle "double-braces". I had a version earlier today that I think worked better, but it is saved at the office, and I don't think I can recreate it easily tonight (I've tried). In any case, assuming I get the proper RegEx pattern figured out, it works.
The nice thing about this method, though, is that I won't have to worry about escapes at all. Any "match" that is not a valid field for that particular file doesn't get replaced. I already wrote a quick function for my MC wrapper that returns a list of strings that contains every field MC knows about (on my system around ~280). Then, I can pass a file in and do a mcFile.Get() for each possible field, and build a string dictionary, just like he uses in that example. It parses plenty quickly (for my purposes and for the types and lengths of text we can expect to have to parse), which I was worried about initially with this method.
But there are problems with this approach. So, take this example Argument (this would be a dumb argument example to use, but bear with me):
[Series]-[Season]e[Episode] -io:[Name] : [Cheetos] [Filename] -aqv /xx
Using this system, and feeding it a test file (an episode of Dexter), it spits out this:
Dexter-7e2 -io:"Sunshine and Frosty Swirl" : [Cheetos] "M:\Video\TV Show\Dexter\07\s07e02 - Sunshine and Frosty Swirl.mkv" -aqv /xx
So, that looks pretty good, but the problem is that there doesn't seem to be a way to pad the numbers like the way MC automatically formats them (normally) via the Automation interface. The Field Get() method has a formatted parameter, but nothing changes with this (and other) examples I tried when I turn it on or off. But, it would work. My function handles adding parenthesis properly automatically, and it ignores anything not recognized (hence the Cheetos example).
I can implement that pretty easily. However...
Option 2:
I just discovered the wonders of IMJFileAutomation.GetFilledTemplate(). I'd seen that in there before, but forgot about it. MC can do all the work. You can feed MC a line of text, using the full Expression language, and it'll spit out the results. It still doesn't do the automatic [Episode] and [Season] padding, but it doesn't much matter because you can use expressions.
The code is a heck of a lot simpler too. Literally, all I have to do is call .GetFilledTemplate(inputString) on the file object (which I already have), and it spits out the same exact thing. The beauty part is that you can add things like PadNumber([Season], 2) and whatever else you want, and it'll evaluate it the same way you already expect MC to evaluate it.
Here's the rub, though... It doesn't handle quoting at all. Of course not, MC's engine doesn't quote anything.
So, in order to produce identical results (including the quotes) to what I produced above, you have to use something more like this as the argument:
\"[Series]\"-PadNumber([Season],2)ePadNumber([Episode], 2) -io\"[Name]\" : [Cheetos] \"[Filename]\" -aqv /xx
It works perfectly, it is just that you have to (obnoxiously) add the quotes manually, and escape them with the \ character.
I'm leaning (strongly) towards going with the second method, as it is far more powerful and flexible. But it seems a bit harder to use. I could, of course, offer both, with a checkbox to enable "MC-style parsing" versus "default parsing". One would allow things like Expression logic and number padding, and the other would be simpler and auto-quote the results.
What do you think? Is the MC-style parsing all you'd need? Is the escaped manual quoting too difficult to deal with? Considering it would make it more complex and confusing, is it worth adding both styles (and which do you think should be the default)?
-
For option one above, I think with this I really do need two RegEx patterns instead.
I need one that I can use as a replace pattern to strip out any stupid non-printable characters (return, control-c, etc) and just allow "normal text" (alphanumerics, whitespace, and punctuation). Filter all that crap out of the input Argument first (in case people copy-pasta them in from Word or something equally dumb).
And then the second one just captures any text between two braces. One problem I encountered with this approach was that the RegEx patterns I kept coming up with wouldn't properly handle things like [[Episode]] (where you want the result to be [2], or something like that). Help from someone who is better at RegEx (which means, pretty much, anyone but me) would be greatly appreciated.
If I don't get help here, I'll ask at work. There are a bunch of database programming warriors I know I can ask, so...
-
Maybe this is more what you want:
\[([^\][]+)\]
This matches a bracket [, followed by anything not an opening or closing bracket [ ], followed by a closing bracket ]. This forces innermost pairs of brackets, and doesn't care what is outside.
-
Thanks, MrC! You're the best! It was, of course, simpler than I was making it. I really need to get a book or something.
I'd still love a comment if you can come up with an example of an argument string that would lead to trouble if sent unparsed for craziness so that I can test it, but I do think I'm okay going this route.
I've also implemented a function that strips out invalid (non-printing) characters from the Argument input string, without using RegEx actually, so it was easy for me to do. I did it the "cheap way" but it should work. I'm just basically replacing all characters below ASCII 32 and above (whatever it is) with null, without even reporting any issue to the user, just doing it when the property is set.
So, it is working well.
I'll have a new build in a day or two. I'm making these changes (among a few others):
1. The argument parsing scheme discussed above has been implemented (mostly, it just needs a tweak or two). It will be available in two modes:
1a. Default - replaces any [Fields] given, and valid for the file in question, with the contents of the field from MC. Wraps the contents in quotes if it contains spaces.
1b. MC-Style - as described above, gets a Filled Template from MC, which allows you to use expressions in your Argument and have them evaluated, but requires you to manually add quotes as needed.
2. The Settings DataGridView will have a Button Column with a browse button next to the Command field, allowing you to browse the filesystem and select your processor that way. You'll still be able to type it in manually.
3. If you select cmd.exe as your Processor Command, it will warn you the first time that this may set your house on fire, erase your hard drive, or kill your dog. The same thing, of course would be true if you pick other complex parsers like Perl or something, but if you're getting into that, we're going to assume you know what you're doing. This isn't implemented yet, but I'm going to do it.
4. And a few other odds and ends.
Thanks for the help, MrC! This method is WAY, WAY better. That's why I wanted to get this out there. I knew people would find things that I was doing dumbly (in my quest to solve my particular problem).
-
Sorry about my poor response time re: the quoting PM's etc. My wife is home sick this week after a mad New York work trip with too many late nights, and I was reworking our home network (added a ProSafe GS716T Network switch to provide Gb Ethernet to all rooms).
Anyway, it seems like you have the process launching stuff managed. The only issue that is possible at this point is if any of your processors call cmd.exe with your arguments. While this technically wouldn't be your fault, users will be ticked when issues occur.
So, to avoid that, you might consider stripping-out any dangerous shell meta-characters to be safe. Sure this will remove nice pipe characters, or redirects from some titles, etc., but better than the alternative.
-
You might consider that MC supports Unicode, so your token replacements may contain characters that are valid, but triggered by your current ASCII range checks. You can use regular expression character classes to be more robust:
http://msdn.microsoft.com/en-us/library/20bw873z.aspx (http://msdn.microsoft.com/en-us/library/20bw873z.aspx)
if you want.
-
Sorry about my poor response time re: the quoting PM's etc. My wife is home sick this week after a mad New York work trip with too many late nights, and I was reworking our home network (added a ProSafe GS716T Network switch to provide Gb Ethernet to all rooms).
No worries at all. I've been terribly sick the past two weeks as well, which has slowed my progress a bit on this. Children are horrible disease vectors. My daughter is lucky she's adorable.
I'd add that I love, love, love my ProSafe switches.
While this technically wouldn't be your fault, users will be ticked when issues occur.
Agreed, and if it becomes a major hassle that's what I'll do. For now, I'm hoping the warning will suffice. It was a very good point to bring up.
Honestly, it shouldn't be that much of an issue. The main danger would be if there was a | or something in a MC field, which you didn't realize, and then sent it to cmd.exe and it hoses your system. But, that's unlikely to occur because it will quote any field that has spaces, so unless your field contains both no spaces and a poorly placed metacharacter, it should be fine.
That's a pretty small problem window for something that would clearly be a quite advanced usage model, I think. I could be wrong, but I'm going to go with the warn but let the user act crazy if they want system. If it blows up in my face, well, then you can say I told you so. ;) :P
You might consider that MC supports Unicode, so your token replacements may contain characters that are valid, but triggered by your current ASCII range checks.
I'm only doing the filtering on the Argument string the user puts into MCAutoQueue, not the result from MC, so this shouldn't be an issue. I'd considered doing that (it was my original plan), but for these purposes I think this is sufficient. If it becomes an issue for some reason, I'll change it.
The only thing I can imagine it impacting is if someone needs non-ASCII characters in a Field Name (or otherwise sent to the command line). That seems like it would be rare, but if it happens and someone complains, I'll revisit it.
-
On the last thing, I'm already reconsidering...
We'll see. I'll take a look. I implemented the filtering with a method call, so I can change the method internally without much effort. I'll see if I can get the RegEx character filtering to work, or if it makes my brain explode.
-
I should note, this does not work with the latest public experimental 18.0.90 build (nor do pretty much any .NET applications or VBS scripts that try to grab the COM Automation object, unless they have some other tricky way to do it).
Matt's on it.
-
Greetings:
Thanks for writing this :
In the "Acceptable values" field, the content is truncated, can you write out the complete words?
Also, I still have the file, not yet installed.
Do I put this in its own folder or does it go to a specific folder.?
If there is going to be a final version, can this be placed in the Interact utility area.?
Thanks.
Ekpen.
-
In the "Acceptable values" field, the content is truncated, can you write out the complete words?
The Acceptable Values field when you are making a custom field in Media Center can be used to limit the choices in MC when setting the field to a pre-defined list. So, for example, if you made a field called [Colors], but you wanted the only choices possible to be Red, Blue, Green, Pink, and Black, then you'd put this in that field's Acceptable Values list:
Red;Blue;Green;Pink;Black
From there on, anywhere you can set the field in MC, these will be the only "choices" possible (it won't let you type in the box to add new values anymore).
So, the idea would be with this, you'd set it to whatever Processors you have defined in MCAutoQueue (probably plus Failed, though this really isn't necessary). The string to use with my example set of Processors is:
Failed;Example Normal;Example Series Argument;Example Timeouts;Example No Update
Thanks for writing this
No problem. I wanted it, badly, and it seemed like a good candidate for something that didn't have to be built into MC itself.
Also, I still have the file, not yet installed.
Do I put this in its own folder or does it go to a specific folder.?
I'd maybe hold off right now. The currently published version doesn't work with files that have spaces in their names correctly (which is pretty bad), unless you make a custom field and add the quotes yourself.
I have a new version almost finished that fixes that problem, and adds a much better way to define the Processor Argument (the command line sent to the application you have set up as the Processor). But I've been stalled by futzing around with the new builds trying to help them get their COM Automation stuff working again. Oh yeah, of course, it also doesn't work with build 18.0.90 and later (though JRiver is working on it).
I'm planning to have this new version out by the end of this weekend. It just needs a bit more work.
Then, assuming that works well, the next step will be to build a couple of wrapper Processors for HandbrakeCLI and for MKVMerge. For these, I'm not sure if I'll be writing them as VBScripts or as actual applications. I'm now leaning towards writing a couple small command line applications. For any of these that I release, though, they'll be open source, so that people can write their own easily (and, hopefully, make them way better).
-
0.8.1 -- Internal Build
0.8.2 (12/09/2012) -- BETA
http://glynor.com/files/MCAutoQueue/MCAutoQueue-0820.zip
1. Changed: Various tweaks to the interface (button alignment, window sizes, etc).
2. Fixed: Settings button properly enables and disables when appropriate.
3. NEW: Argument can be complex string containing MC fields that are evaluated and replaced with the specifics from each file (see below).
4. NEW: Argument formatting has two possible modes: default and MC-Style. In MC-Style, the argument is processed by Media Center, and allows you to use full Expression logic. However, you must manually insert quotes where appropriate when using this mode.
5. Fixed: Argument properly quotes fields when they contain spaces (in the default mode).
Known Issues:
1. Incompatible with MC 18.0.90 due to problems with MC's COM Automation interface (JRiver is working on this issue).
2. Validation of the aqconfig files is early. Manually edit them with care. If you run into trouble, delete your MCAutoQueue.exe.config file in the installation directory, and it will reload the defaults.
3. Error reporting is weak in the UI. The log is pretty good though. If you get any general exceptions or other unexplained errors, please retain the logs.
-
MCAutoQueue now uses a parsed Argument for each processor. The Default configuration gives examples of usage, but it is essentially as described above (http://yabb.jriver.com/interact/index.php?topic=76147.msg516171#msg516171).
The Argument can be built via two different modes now:
Default:
Fields are denoted via the regular [Field Name] notation. Any valid Fields in MC are processed and converted to their results from the file in question. Fields from MC that contain spaces are automatically wrapped in quotes. If the file doesn't have a corresponding tag, the [Field Name] token is removed, but the rest of the argument is left intact. Any items in brackets that do not correspond to a valid field in MC, are ignored and passed through.
Example:
--someOption --series:[Series] --inputfile:[Filename]
MC-Style:
Media Center is used to perform the field replacement, using normal Expression rules. This includes full expression support, so it can be used to format values appropriately (or anything else you can build with an expression). However, because MC doesn't automatically quote fields, this means you'll need to manually add quotes where they may be needed.
MC-Style arguments also load substantially more quickly.
Example:
--prefix:"[Series]"-PadNumber([Season],2)ePadNumber([Episode],2) --name:"[Name]"
-
I have a pretty nice wrapper for VideoReDo started up now. I can easily take an input TS file, quickfix the stream, and remux it to whatever format I want (and it'll recode if needed, but leave the stream untouched if it can, depending on the output format).
I'm working on connecting this to MC now. The idea will be that you can add files to MCAutoQueue (probably via a Tag On Import rule), and then it will call this application which will do the conversion, and then find the original source file in MC, and redirect the file record to the new "version" automatically (optionally deleting the source file from disk when done). This stuff is all working in my tester application, so now I just have to build the functions into something real, and design it in some kind of rational fashion. One nice thing is that I've been able to do all of this from within the automation interface directly, rather than relying on the Sidecar files like my original VBScript did, so it'll work even if Sidecar support is disabled.
I'm hoping to also figure out how to add the new file to MC and stack it with its "parent" file, but I haven't gotten there yet.
The goal will be to build the "MC handling" part of this all in separate classes, which call a generic "processor class" of some kind, so that it would be easy to extend to make it work with other converters/processors like MKVMerge, Handbrake, MeGUI, and whatever (and audio-only related things too, which I haven't even begun to think about).
I thought about trying to write something truly "generic" that would just handle the MC part of the equation, and then let you specify the "processor" yourself as the user. And, I might take a crack at that in the future, but for now... I think an integrated approach makes more sense. The alternative means a lot of complexity for limited gain (for me), mainly because I don't want to do the "MC handling" part until I'm sure the conversion worked. That makes it clumsy to make it truly generic (other than in the code itself).
However... If anyone has any concrete suggestions for how to work around this, I'm all ears.
-
I thought about trying to write something truly "generic" that would just handle the MC part of the equation, and then let you specify the "processor" yourself as the user. And, I might take a crack at that in the future, but for now...
I think I came up with a good plan for this. It almost certainly won't be "first", but it should be soon.
-
I made awesome progress on this over the weekend...
Good things are coming.
-
An update on this... I have all the back-end work done now, and I'm just wiring it up to an interface now. I'm hoping to have something ready by next week sometime.
Basically, I've built a general purpose file ingester for MC. It can ingest new files via a variety of means, including copying metadata from an existing file in the library (clone) and replace (which swaps the new file in as a stand-in replacement in the library). I think it'll come in pretty handy for many people.
Then, the idea is to make a processor that does the file conversion, and sends the results to the ingester. But, you could just use the ingester directly to accomplish other handy tasks (like re-ripping tracks and replacing them).
-
0.8.3 -- Internal Build
1. Changed: Extended beta timeout through the summer (expires on or after 9/1/2013).
2. Changed: Settings dialog resizes properly.
3. Changed: Logging improvements.
4. Changed: Internal changes to enable the MCFileIngester processor.
0.8.4 (02/02/2013) -- BETA
http://glynor.com/files/MCAutoQueue/MCAutoQueue-0840.zip
1. NEW: MCFileIngester Processor included (see below).
-
This build includes a brand new processor that can be used to ingest newly created files into MC, while "cloning" or "replacing" an existing source file. I'm going to call it currently an Alpha-quality release, but it is fully functional in all core ways, and the Ingestion process has been well-tested in all of the various modes.
Here's a screenshot of the current version:
(http://glynor.com/files/MCAutoQueue/MCFileIngester-screenshot-small.png) (http://glynor.com/files/MCAutoQueue/MCFileIngester-screenshot.png)
The new ingester system is quite powerful. It can be driven from the command line fully, and it has a number of flexible modes.
Basics:
1. You give it a source file to work with from MC's Database. The Source File can be thought of as the "existing file" (typically the old one). It will be the source for any metadata cloning done.
2. You give it a New File to ingest. This can be set manually in Standard Mode with a path, but can also be calculated automatically using one of the various modes of operation. Note that it doesn't matter if the New File has already been imported into MC or not (by Auto-Import, for example). MCFileIngester will handle it properly either way.
3. You set the Ingest Mode:
a. Standard: Normal mode. The new file is selected manually.
b. Change Extension: The new filename is generated by changing the extension of the Source Filename.
c. Stack Swap: The new file has already been imported, was stacked with the source file, and set as the stack top (see below).
d. Using MC Fields: All other settings are retrieved via special pre-defined fields in MC's Database.
4. If applicable to the mode selected, you choose an Ingest Type and set any relevant options.
Ingest Types:
1. Clone: This ingests the New File as a new, separate entry in MC, and clones all of the existing metadata over from the (old) Source File. The Source File is left untouched.
2. Stack With Source: This ingests the New File as a new, separate entry in MC, and then Stacks it with the given Source File. You can optionally clone the source metadata and add the new file as the Stack Top.
3. Replace: This ingests the New File as a replacement for the given Source File. All metadata (including [Date Imported], [Number of Plays], etc) is cloned over to the new file, and then the old file is removed. You can optionally also remove the (old) Source File from disk when complete.
For the Clone Operations, you can optionally limit the metadata clone only to "Play Stats". This includes the following fields:
[Date Imported], [Skip Count], [Last Skipped], [Number Plays], [Last Played], [Rating]
Using The UI:
The UI is there primarily to allow you to set defaults and global options, and to learn the Command Line Interface. As you change options in the GUI, the Command Line Example generator updates to provide you with the equivalent command line parameters. In addition to learning the CLI, you can also use the GUI to actually process new files, and to set the program defaults.
Using the GUI to set defaults will make it much easier to use the application without complex command lines if you simply want to do one kind of Ingestion over and over (or primarily). You can simply open the GUI, set whatever settings you want to be used as the defaults, and then close the application. It will ask you to confirm that you'd like to set new defaults. Say Yes, and from then on, it will default to those settings, and you can omit the relevant command line options (except to override them). The only thing it will not save is the Source Filename (which must be set for each file, obviously), and the New Filename for Standard Mode.
There are also a number of Global Options that can be set from within the GUI. These are mostly self-explanatory, but I should explain the Show Progress behavior. There are three Show Progress choices:
Always: Shows the Ingestion progress dialog whenever an Ingestion is running.
If Errors Occur: If the Ingestion progress dialog is minimized (either manually or with the --runmin flag), it will be restored and shown if any errors occur.
Never: Always keep the Ingestion progress dialog minimized, regardless of errors.
These apply primarily when using the --autorun --runmin and --autoexit options. Also note that the AutoExit option is only triggered if Never is selected as the Show Progress behavior if error occur during ingestion.
Using the Command Line:
Here is the basic information on the command line formatting. The best way to learn the various command line options is to play with the GUI and observe the Command Line Example generator. However, this is a listing of all of the command line options:
m|mode= - the Ingest Mode (Standard, ChangeExtension, StackSwap, or UsingMCFields) to use.
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.
s|source= - the source filename (must be a full filename) to process.
n|new= - the new filename (must be a full filename) to process.
x|newext= - the extension to use to generate new filenames (for ChangeExt IngestMode).
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 ingester.
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 Ingestion process. The Command Line Example generator adds these two flags when the command line is "ready" to be processed (it has enough valid options set to run).
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 --newext) can be specified like any of these styles:
--source:"M:\Temp\script test\TheBigBangTheory-S06E10-TheFishGutsDisplacement-12851987-0.ts"
-x=mkv
/new "M:\Temp\script test\TheBigBangTheory-S06E10-TheFishGutsDisplacement-12851987-0.mkv"
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. However, note that any known flags set that are set, which are not relevant to the current Ingest Mode and Type are ignored. For example: If you provide --new:"c:\path\to\some\file.foo" but the current mode is set to ChangeExtension, then the given new filename path will be ignored and not used.
Change Log:
Change logs for the current release:
* glynor.common-ChangeLog.txt (http://glynor.com/files/MCAutoQueue/glynor.common-ChangeLog.txt)
* MCFileIngester-ChangeLog.txt (http://glynor.com/files/MCAutoQueue/MCFileIngester-ChangeLog.txt)
-
Additional details about the Ingest Modes:
StackSwap Mode:
StackSwap mode is a clever way of selecting through MC itself which file you want to use to "replace" another file in the Library. To use MCFileIngester to replace files, it needs to know essentially these two important filenames:
Source File: This is the file you want to replace. It has valuable metadata that you want to retain, but you want to replace this file with a new version or copy.
New File: This is the new copy. It has no valuable metadata.
StackSwap allows you to specify the New File visually, from within MC, so that you can make sure the proper files are matched up before running them through the replacement system. You do this by adding the New File to a stack with the specified Source File, and then making it the Stack Top.
So, for example, if you have this file in your MC Library for some time:
M:\Audio\Music\F\Foals\Antidotes\2\01 - Hummer.mp3
And then one-day, you decide to re-rip this album to FLAC files. Now you have new FLAC Files that might be somewhere like this:
M:\Incoming\Foals\Antidotes (Disc 2)\01 - Hummer.flac
And you want to swap in the FLAC version for the MP3 version in the Library. You don't have to worry about the metadata or filename of the new file, you just get it imported into MC (which it already will be if you used MC to re-rip the file) and then you can do this:
1. Stack the two files together, and set the new FLAC version as the Stack Top. It doesn't matter what metadata the FLAC version has, or what the filename is, you can just stack them together and make the one you want to "keep" (the New File) as the Stack Top.
2. Call MCFileIngester.exe in StackSwap mode, and give it the old Source File (the one with the good metadata that you want to keep, but get rid of the file) as the --source: parameter, like this:
MCFileIngester.exe --autorun --autoexit -m:StackSwap -s:"M:\Audio\Music\F\Foals\Antidotes\2\01 - Hummer.mp3"
This will find the file given, and then replace itself with the file currently listed as its Stack Top. If any other files are currently Stacked with the given Source File, they remain in the stack (and the New File remains the Stack Top).
UsingMCFields Mode:
The special UsingMCFields mode allows you to specify all of the needed parameters for MCFileIngester to run, except the Source filename, from within the MC Library itself. You specify these parameters by adding a set of special fields to your MC Library, and then setting these fields appropriately on the given Source File(s) to achieve the desired results.
This is best understood using the Command Line Examples generator in Field-Based style. If you set the Command Line Example generator to Field-Based style, then it will list the proper command line to initiate UsingMCFields mode, and then provide the correct Fields and values that would need to be filled in MC to accomplish the same thing that is currently shown in the GUI. Play around with it a bit and it should become clear what fields you need to add to MC and fill in.
You do not need to add the "full set" of possible fields to MC. If you'll never use a particular option, such as [MCnet-DeleteSourceFile], then you don't need to create that field in MC. The field names are hard-coded to keep me sane.
Here is the full list of special Fields, and what they may contain:
[MCnet-IngestMode] - String type field specifying the Ingest Mode: Standard, ChangeExtension, or StackSwap
[MCnet-IngestType] - String type field specifying the Ingest Type: Clone, Stack, or Replace
[MCnet-NewFilename] - String type field specifying the full New Filename for Standard Mode
[MCnet-NewExtension] - String type field specifying the New Extension for ChangeExtension mode
[MCnet-CloneOnlyStats] - Integer type field, 0 for false, 1 for true.
[MCnet-StackAddAsTop] - Integer type field, 0 for false, 1 for true.
[MCnet-StackCloneSource] - Integer type field, 0 for false, 1 for true.
[MCnet-DeleteSourceFile] - Integer type field, 0 for false, 1 for true.
Excluding Fields from Metadata Cloning:
When you use MCFileIngester to clone metadata from a source file to another 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 (http://yabb.jriver.com/interact/index.php?topic=76147.msg598263#msg598263).
Demonstration Video:
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).
(http://glynor.com/img/screenshots/MCAutoQueue/MCFileIngester-Standard_Replace_Playlist-Video-Thumb.png)
MCFileIngester - Standard Replace Playlist Demo
Click to play video. (https://vimeo.com/85110224)
-
0.8.5 (02/03/2013) -- BETA
http://glynor.com/files/MCAutoQueue/MCAutoQueue-0850.zip
1. Updated MCFileIngester to 0.7.1
MCFileIngester 0.7.1 Changes:
1. NEW: Implemented Command Line Examples generator.
2. Fixed: Tray Icon Ingest and Cancel Ingest Context Menu items work now.
3. Changed: Back end improvements for Playlist Source Type (not yet implemented)
4. Fixed: Source and New Filename browse buttons properly remember the last-used directories.
5. Fixed: Minor improvements to the defaults setting system.
-
0.8.5.1 (02/04/2013) -- BETA
http://glynor.com/files/MCAutoQueue/MCAutoQueue-0851.zip
1. Updated MCFileIngester to 0.7.2
MCFileIngester 0.7.2 (02/04/2013) -- ALPHA
1. NEW: Implemented Logging extensions (enables Log rotation and purging).
2. NEW: Implemented Playlist Source type. Source can now be either a single file, or a Playlist of files in MC (for batch processing outside of MCAutoQueue).
3. Fixed: Row counter column on Ingest Progress dialog was not working properly.
4. Fixed: Improved performance of loading the Ingest Progress dialog.
5. NEW: With Source Type set to Playlist, the Source and New Comboboxes pre-fill with a list of all of the available Playlists in MC.
6. Fixed: Logging errors in Standard Replace mode.
-
0.8.6.0 (06/05/2013) -- BETA
http://glynor.com/files/MCAutoQueue/MCAutoQueue-0860.exe (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
-
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 (http://www.videoredo.com/en/ProductTVS.htm) 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:
(http://glynor.com/files/MCAutoQueue/MCVideoRedoer-screenshot-small.png)
Click to embiggen. (http://glynor.com/files/MCAutoQueue/MCVideoRedoer-screenshot.png)
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 (http://yabb.jriver.com/interact/index.php?topic=76147.msg598263#msg598263).
Change Log:
Change logs for the current release:
* glynor.common-ChangeLog.txt (http://glynor.com/files/MCAutoQueue/glynor.common-ChangeLog.txt)
* MCVideoRedoer-ChangeLog.txt (http://glynor.com/files/MCAutoQueue/MCVideoRedoer-ChangeLog.txt)
-
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 .. ;)
-
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).
-
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.)
-
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 .. ;)
-
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.
-
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).
-
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.
-
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).
-
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.
-
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.
-
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.
-
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
-
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:
<?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.
-
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.
-
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.
-
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.
-
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:
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.]
-
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.
-
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.
-
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.
-
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.
-
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"
-
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).
-
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.
-
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.
-
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.
-
Thanks for the update.
-
New demo for MCFileIngester (http://yabb.jriver.com/interact/index.php?topic=76147.msg528833#msg528833).
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).
(http://glynor.com/img/screenshots/MCAutoQueue/MCFileIngester-Standard_Replace_Playlist-Video-Thumb.png)
MCFileIngester - Standard Replace Playlist Demo
Click to play video. (https://vimeo.com/85110224)
-
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.
-
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.. ;)
-
New demo for MCFileIngester (http://yabb.jriver.com/interact/index.php?topic=76147.msg528833#msg528833).
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 (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.. ;)
-
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 (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. ;)
-
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.
-
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.
-
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. :-\
-
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.
-
NOTE: This system is deprecated (it only lasted publicly for one day). See below for instructions. (http://yabb.jriver.com/interact/index.php?topic=76147.msg598263#msg598263)
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:
<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:
(http://glynor.com/img/screenshots/MC19/MC19-LastPlayed_Editable-small.png)
Click to embiggen. (http://glynor.com/img/screenshots/MC19/MC19-LastPlayed_Editable.png)
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).
-
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.
-
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.
-
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 (http://yabb.jriver.com/interact/index.php?topic=76147.msg598102#msg598102).
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:
<?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:
<?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>
-
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
-
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 (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.
-
I was basically going to make that suggestion. Perhaps automate it with this?
-
Cool. I got alspoll all squared away.
-
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?
-
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.
-
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.
-
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?
-
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?
Both of those are already on my list for a future addition. Unfortunately, I've been messing around with a new internal system for them in order to implement those features, and the going has been slow. My plan is to make this a real 1.0 after I finish up some additional documentation (I have been working on it), and then target that for a future release.
For now, no.
However, you do have a couple options:
1. Turn off Auto-Import and just don't have it delete them, and then you can move them later.
2. Use the options other than replace. One that might be particularly useful are the Stack options: These allow you to clone all metadata over from the original files, and add the new ones in a stack with the originals (probably enabling the Add as Stack Top option in MCFileIngester). That way you won't really see the original files anymore (they'll be "hidden" underneath of the new ripped copies) but you can get to them if you want to later.
Since MCFileIngester works using a Playlist as the source, it should be reasonably simple to Control-A and add whatever tag you want to mark them as completed as soon as the process finishes running.
My plan for the future is to add a couple items:
1. It will automatically add a tag to the new files with a filename reference to the old file. I haven't decided for sure how to do this, but it will probably use some custom field I invent for the purpose (because I don't want to risk overwriting any existing user-data). If the ingest fails for whatever reason, some kind of error message will be written to this field instead.
2. There will be the ability to write a value to a user-definable field when the process succeeds.
3. The move instead of delete thing you mentioned. I'm trying to decide how to do this... My current thinking is to have it set to move them to a user-definable directory, and have it recreate N-number of "levels" of the original file's directory structure when it does. So, for example:
Original File: M:\Audio\Music\A\The Avett Brothers\Emotionalism\09 - All My Mistakes.mp3
Move Replaced Files to: M:\Audio\Replaced Music\
Also Move X levels of directory structure: 2
Would result in:
M:\Audio\Replaced Music\The Avett Brothers\Emotionalism\09 - All My Mistakes.mp3
If you had it set to 1 instead, it would result in:
M:\Audio\Replaced Music\Emotionalism\09 - All My Mistakes.mp3
And so on and so forth. I'm not sure what to do in these cases when the provided number of subdirectories doesn't exist (I'd say probably just omit them).
As I said, though... No promises on timing, and it could be a very long time. The existing system should be able to meet your needs, even without these fancy additions (even though they'd be nice).
-
Thanks for your detailed answer.
You are right, it is very easy to fill a custom field in the source playlist and move the files concerned later with an adequate expression.
That's the way i will go for now.
It's a great app for replacing lower quality files with better (good) ones!
-
Automating MCVideoRedoer AdScan on a Batch of Files in a Directory
Finally got down and dirty with the command line action to address the tag line of this post:
http://yabb.jriver.com/interact/index.php?topic=76147.msg552751#msg552751 (http://yabb.jriver.com/interact/index.php?topic=76147.msg552751#msg552751)
I've worked out that to auto run Adscan & exit from MCVR, then this is the command line format to use:
"C:\Program Files (x86)\MCAutoQueue\Processors\MCVideoRedoer.exe" -a -e -source="D:\Recorded TV\Video File.ts" -adscan
By using this command, I can set up a batch file script to execute MCVR upon a specified file and exit the interface, without involvement from human hands.
Great but how to spec up a directory of files and run this as a batch-wise process?
I've worked out by wandering around the interweb that I can use the following command line steps to produce a text file (in this case list.txt) of the .ts video files in a given directory:
D:
cd "D:\Recorded TV"
dir /b/s *.ts>list.txtThis gives a list of the filenames including the directory path in the folder D:\Recorded TV, as per:
D:\Recorded TV\Video File 1.ts
D:\Recorded TV\Video File 2.ts
D:\Recorded TV\Video File 3.ts
What I've done at this stage is to open up the file list.txt and copy the leading text of the MCVR command above do a search and replace on the first few characters at the start of each filename, e.g. D:\. Then I've done the same with the trailing text of MCVR command by searching and replacing the final key characters of each line, e.g. .ts.
Then I've saved this file as .bat and simply executed it. MCVR is now churning away happily.. nice .. :)
Hopefully what I've described makes sense. Any thoughts on how to do this a smarter way, so that it reduces the process down to a single button press?
-
Great but how to spec up a directory of files and run this as a batch-wise process?
The whole idea of MCAutoQueue is to automate this process for you.
Any file that MC can tag can be automated via MCAutoQueue, and you can schedule them to happen completely automatically using Tag On Import rules.
-
So, using your example, you'd do this:
1. Make a new custom user field in MC called [NeedsProcessing], as described in the opening post. If you're only going to do AdScan processing, for now at least, then it only needs one allowable value. This can be whatever you want, but I'd make it "AdScan".
2. Make the Smartlist described in Step 2 in the opening post. Make this exactly as described in the original instructions.
3. Open up MCAutoQueue, and click on the Settings button.
4. Under Playlist in MCAutoQueue's settings, pick the Smartlist you made in Step 2.
5. Put "NeedsProcessing" in the Field to Process (I think that's the default, so you can probably just leave it).
6. Make a new Processor (if one doesn't already exist that will serve the purpose), and give it these parameters:
Processor Key: AdScan (or whatever you used in Step 1 above)
Command To Run: "C:\Program Files (x86)\MCAutoQueue\Processors\MCVideoRedoer.exe"
Argument: -a -e -source=[Filename] -adscan
MC Style: Unchecked
Update MC: Checked
Timeout: Default is probably fine.
7. Now, if you tag some files in MC with [NeedsProcessing] = AdScan and refresh the list in MCAutoQueue, it will list those files and be ready to run that command on each of them.
8. You can schedule MCAutoQueue to run automatically in Windows using the Task Scheduler. Just add a new scheduled task to recur as often as you'd like (I do mine daily in the middle of the night). For the Action, use:
(http://glynor.com/img/screenshots/MCAutoQueue/MCAutoQueue-Scheduled_Task-small.png)
Click to embiggen. (http://glynor.com/img/screenshots/MCAutoQueue/MCAutoQueue-Scheduled_Task.png)
Now, if you want to AdScan files, all you have to do is tag them in MC as [NeedsProcessing] = AdScan. The next time MCAutoQueue is scheduled to run, it'll do it for you. When they're done, it'll automatically re-tag [NeedsProcessing] = Complete. If MCVideoRedoer happens to fail, it'll tag it [NeedsProcessing] = Failed instead.
If you want to automatically do this for any new files in a particular Auto-Import directory, you can simply add a Tag On Import rule to add the [NeedsProcessing] tag for you automatically.
And, whammo, it runs automatically at the time you specify, every day, and AdScans your files.
-
glynor, sorry for being so slow on the uptake but as Prof. Higgins commented, "by George, I think
s ..he's got it!"
https://www.youtube.com/watch?v=uVmU3iANbgk (https://www.youtube.com/watch?v=uVmU3iANbgk)
I went for a variation on this step:
8. You can schedule MCAutoQueue to run automatically in Windows using the Task Scheduler. Just add a new scheduled task to recur as often as you'd like (I do mine daily in the middle of the night). For the Action, use:
.. and set this up within MC to keep matters as in house as possible (see 1st pic).
The other thing I did was to set up a separate smartlist to help pick TV shows from the most recent time period of my choosing (4 days in this case):
[Media Sub Type]=[TV Show] [Date Recorded]=<4d ~sort=[Date Imported]
where I applied your advice to set up the view to show NeedsProcessing as a data column and entered the string "AdScan". You can see from the output (2nd pic) that the result has been a success.
Thanks for the help. MCAQ rocks.. ;)
-
So, now that I've got that out of the way.
Is it possible to automatically enter "AdScan" in [NeedsProcessing] once a TV recording has finished? I'd really like to just be able to know that all shows have had AdScan run and I can then pick and choose which ones I want to edit at a later time. I'm not really bothered if every show has been scanned for ads.
If so, how would one go about configuring MC to do that?
-
I've got a second query that relates to setting up a batchwise process to clean up recording files using VideoReDo's Quick Stream Fix function. For the cost of some processing time over night, I'm keen to see files tidied up for audio and video sync errors (if they exist) that can result from signal errors during transmission ...
My reading of this post:
http://yabb.jriver.com/interact/index.php?topic=76147.msg553198#msg553198 (http://yabb.jriver.com/interact/index.php?topic=76147.msg553198#msg553198)
gives me the expectation that I should be able to do a Quick Stream Fix before Adscan as part of the one command. Is that correct?
Therefore the MCAQ argument text would read:
-a -e -source=[Filename] -qsffirst -adscan
To test the above plan, I included "QSF" as a valid string in the [NeedsProcessing] library field and ran the above argument (sans -adscan) with the Processor Key set for "QSF" (see pic 1). Unfortunately, MCAQ wasn't happy with that idea. See pic 2 for the error message and the attached text file for the associated dump data.
What did I get wrong? Let me know what you think.
[Edit: Also, I see in the MCAQ gui that you've made provision for a log file. Would that help and where do I find it to send through?]
Thanks .. ;)
-
Therefore the MCAQ argument text would read:
-a -e -source=[Filename] -qsffirst -adscan
...
What did I get wrong? Let me know what you think.
Well, you found a bug, but not the one you think you did...
The core problem is: --adscan and --qsffirst are mutually exclusive options. Actually, more correctly, --adscan itself is a special mode that precludes all other options in MCVideoRedoer, but specifically, it can't work with the QSF mode at all.
The bug you found is that the messaging is (apparently) broken. If you try to do this from within the GUI, you'll find it won't let you (unless that too is broken, I'll have to check). The command line options are supposed to detect this and provide good messaging if you try to combine the two, but apparently that is broken right now. It also dawns on me, reading through my documentation previously in this thread, that I didn't explain that explicitly (or, at least, not in a place that is easy to find).
So... I'll explain now.
What QSF First mode does is:
1. Transcodes the source file to a temp file (in your actual system temp file location, by default), with a random-generated filename, using the special QSF "mode" of VideoReDo. This creates a new copy of the source file, it does not "fix" the existing file in-place (and cannot).
2. Then, it essentially swaps-in this temporary QSF-ed file and uses it as the source file for the rest of the processing.
3. This temp QSF-ed file is then deleted when the processing completes.
What AdScan mode does is:
1. Takes the source file and runs it through VideoReDo's Ad Detective feature.
2. It then saves the results of this to a VPrj file (a VideoReDo Project File). This file does NOT "contain" a copy of the video, it is just a little "text" file, which points to the original source file.
3. It then imports this VPrj file into MC so that you can track them and use MC to "queue" your manual review of the detected ads.
The idea is that later you can run these VPrj files back through MCVideoRedoer and it'll then "finalize" your video out to a new file, cutting out the specified ads.
You can't do both of these things, if you think about it.
The QSF First makes the temp file, and then deletes it. The temp file is only useful as a means-to-an-end to make the transcoded "final copy". The problem is that if we did both, then the VPrj file would point to the temporary QSF file in your temp directory, which would be deleted when it finishes the run. Even if I worked around that, it would have to create a new file on disk, and this would be one that MC doesn't know about at all.
Now, I considered making QSF First mode handle things specially when AdScan mode is enabled, and to actually overwrite the original source file. But, this would be dangerous. QSF does sometimes (though not often) make a broken file worse. If the source file is sufficiently broken, VideoReDo's QSF transcoding can actually excise substantial portions of the source video, screw up aspect ratios, and other stuff like that. This only ever happens if the source file is pretty badly hosed, so it isn't the end of the world, but I can't be sure that you'd be okay with losing your source file (even if it is broken). Making it worse and overwriting the source without being told to is bad-form.
There are other possible alternatives, but they can get pretty complex.
A better method would be to just do this part when you complete your AdScan (running it through again to cut the actual commercials out). That phase would be the time that would make sense to do the QSF (if needed).
Of course, there is a downside. If the file is sufficiently broken, then AdScan will fail (either entirely, or by not detecting ads correctly). QSF could fix this, if done first, but there's not a clean way to do this through MCVideoRedoer currently.
I'll think about it, but nothing soon.
-
Is it possible to automatically enter "AdScan" in [NeedsProcessing] once a TV recording has finished? I'd really like to just be able to know that all shows have had AdScan run and I can then pick and choose which ones I want to edit at a later time. I'm not really bothered if every show has been scanned for ads.
If so, how would one go about configuring MC to do that?
I'm actually not very experienced with MC's TV Recording functions. Does it use, or have it's own corollary to, the Auto-Import Tag on Import system? If so, then it is a simple matter.
If not, then it would probably be more complex (and a huge bummer).
Let me know if the latter, though, as I can probably come up with a workaround (as I'll need one anyway if/when I switch to MC for my PVR functions). Really, though, the recordings should obey the Tag On Import rules defined for the folder where the recordings happen (assuming that directory is watched), or it should have its own version of the same.
-
Well, you found a bug, but not the one you think you did...
Yep. I looked at the code for a bit, and it looks like it is actually broken in a bit more complex way, but everything I said above is still true. When I fixed QSF First mode a few months back (which was broken fairly recently and I fixed it in build 0.9.2) I also, accidentally, disabled some of the sanity checking done around combining AdScan and QSF Mode. This was hidden because the UI separately blocks you from actually setting the options this way, but you cleverly figured out how to do it via command line.
Clever boy. ;) ;D
So, the reason you got that crash is almost certainly related to the logic of combining QSF Mode and AdScan mode (which shouldn't be possible, but currently is if you use the command line options).
I'll push out a new build at some point with this fixed. But, for now, yes, it'll crash if you try to do this. And my "fix" won't actually make it work, it'll just make it turn QSF mode off and do the AdScan as requested (with a warning).
Also, I should mention...
[Edit: Also, I see in the MCAQ gui that you've made provision for a log file. Would that help and where do I find it to send through?]
Yes. Both MCAutoQueue and MCVideoRedoer create log files, which can be helpful if you're getting unexpected behavior. They're saved here, if enabled: C:\Users\<USERNAME>\AppData\Roaming\glynor\
-
So, now that I've got that out of the way.
Is it possible to automatically enter "AdScan" in [NeedsProcessing] once a TV recording has finished? I'd really like to just be able to know that all shows have had AdScan run and I can then pick and choose which ones I want to edit at a later time. I'm not really bothered if every show has been scanned for ads.
If so, how would one go about configuring MC to do that?
I'm actually not very experienced with MC's TV Recording functions. Does it use, or have it's own corollary to, the Auto-Import Tag on Import system? If so, then it is a simple matter.
If not, then it would probably be more complex (and a huge bummer).
Let me know if the latter, though, as I can probably come up with a workaround (as I'll need one anyway if/when I switch to MC for my PVR functions). Really, though, the recordings should obey the Tag On Import rules defined for the folder where the recordings happen (assuming that directory is watched), or it should have its own version of the same.
I've headed over to the TV board to pursue this because I reckon that's the best place to discuss:
http://yabb.jriver.com/interact/index.php?topic=88459.0 (http://yabb.jriver.com/interact/index.php?topic=88459.0)
I did find an answer but (no surprise) I'd like to see some function improvement.
Thanks for all the feedback. Very useful stuff.. 8)
-
http://glynor.com/files/MCAutoQueue/MCAutoQueue-0990.exe
MCAutoQueue, MCFileIngester, and MCVideoRedoer 0.9.9 (05/26/2014) -- BETA
1. Changed: Updates to shared components.
glynor.common 1.0.0 (05/26/2014)
1. NEW: Logging system overhauled. Now provides Log Levels and improved exception reporting.
2. Fixed: Some user options weren't preserved when upgrading.
3. NEW: Stock Options system overhauled. Report any trouble with basic options like Logging and AutoRun.
4. Changed: Shared code reorganized (reduces the number of auxiliary dlls installed).
MCnet 1.0.0 (05/26/2014)
1. Fixed: Logging improved across many components.
-
glynor, here's a VRD upgrade related question.
How can I get MCAQ to work with VideoReDo version 5?
I've done a VRD upgrade on my workhorse machine where TV is recorded and want to shift ver4 to another PC.
Can this be covered by a user tweak?
Thanks in advance. Cheers.. ;)
-
I haven't tried v5 yet. But in their welcome message they mention:
9) A new COM interface with a clearer API that should make it easier for developers to access the functionality of VRD via scripts or software.
That's pretty good because their COM interface was pretty creaky. But it also means that MCVideoReDoer probably needs to be re-written entirely.
-
I haven't tried v5 yet. But in their welcome message they mention:
That's pretty good because their COM interface was pretty creaky. But it also means that MCVideoReDoer probably needs to be re-written entirely.
Thanks for letting me know. I'll rejig the setup, reinstall v4 to the work unit and load up v5 elsewhere. I'll get by until they and you have had time to suss things out. Sounds like it will take some time.
Cheers .. 8)
-
It's actually good. I built a whole new framework that I want to use to rework those apps better, but then I kinda lost steam. Motivation. ;D
-
Is this working with the handbrake CLI? If so what is the command line for input and output?
-
You could certainly make a script to use it with Handbrake CLI. I haven't made one myself.
-
I have had this working using the FileIngester for a long time, but now, all of a sudden, I am getting the following (in the FileIngester):
INFO Connecting to running MC instance...
INFO Successfully connected to Media Center.
INFO Replacing file: D:\Recorded TV\NCIS_ Los Angeles - S04E24 - Descent.ts
INFO With file: T:\TV\NCIS_ Los Angeles\Season 04\NCIS_ Los Angeles - S04E24 - Descent.ts.mp4
ERROR Replace New File Failed: Replacement type mismatch: The [Media Type] of the files must match.
T:\TV\NCIS_ Los Angeles\Season 04\NCIS_ Los Angeles - S04E24 - Descent.ts.mp4 ()
D:\Recorded TV\NCIS_ Los Angeles - S04E24 - Descent.ts (Video)
Parameter name: overrideTypeMatching
ERROR ERROR: Replacement FAILED.
Obviously something changed in my setup, but I can't think of what it would be! Any help would be greatly appreciated! I did check that the source was a 'Video' media type.
-
Look at the last 2 lines. Whatever produced that error message things that the file on the T: drive is NOT type Video. See the () ? The file on the other drive shows (Video).
Brian.
-
That's weird. It's a mp4 extension, and isn't even imported into MC yet when this is run. I will look into it, but not even sure where to start. If I run the Ingester directly (outside of my scheduled task), I get the same problem.
Weird thing is that it was working just fine 1-2 weeks ago!
-
Maybe I fixed it, we'll see tonight. I noticed that .mp4's were set to open with Windows Media Player, so I changed it to default to MC. The Ingester worked when I ran it manually. I'll know more tonight. Thanks for the help!
-
Look at the last 2 lines. Whatever produced that error message things that the file on the T: drive is NOT type Video. See the () ? The file on the other drive shows (Video).
Brian called it.
That error is due to a sanity check I put into MCFileIngester. It will not replace files if the [Media Type] for the files does not match, so that you don't accidentally overwrite a video with a MP3 or something silly like that. In this case, the MP4 imported with an empty [Media Type] (which is why the parenthesis are empty after the MP4 filename in the error).
It is the MP4 that has the wrong [Media Type], not the source file (that's what the error log shows).
That's pretty odd. I'm not sure what could make them import with an empty media type, if they aren't broken files. Are you sure the transcoding isn't spitting out busted MP4s?
-
Maybe I fixed it, we'll see tonight. I noticed that .mp4's were set to open with Windows Media Player, so I changed it to default to MC. The Ingester worked when I ran it manually. I'll know more tonight. Thanks for the help!
This should not have anything to do with the file association of MP4s on the system. It is that MC thinks that MP4 is broken (or, at least, that it does not contain video).
I thought of one other case that could, maybe, cause this. Do you have a non-standard Video Playback "engine" set up for the MP4 file type in MC under Tools > Options > File Types? This should be set to Automatic almost certainly.
-
Whatever produced that error message
PS. The thing that produced the error message is an application I wrote: MCFileIngester (http://yabb.jriver.com/interact/index.php/topic,76147.msg528833.html#msg528833), which is part of MCAutoQueue (the point of this thread). Unfortunately, it is Windows-only, but you should check it out. Pretty cool though, and I have it running daily in my scripts to this day, but I also use it as a "utility" frequently to replace big swaths of files or manually converted items.
These automated scripts haven't been doing much of anything useful for the better part of a year, as I haven't had useful cable TV since we sold the old house (soon, thankfully, soon my moving adventure will be complete). So, nothing is getting recorded and so nothing is getting autoconverted. But, they're still running!
And I used it not that long ago to deal with some files I re-purchased.
things that the file on the T: drive is NOT type Video.
MCFileIngester doesn't decide what Media Type the file has on its own. It asks MC and retrieves the [Media Type] of the file in question, after importing it (if it isn't already imported).
In any case, muzicman0, if you can reproduce an issue where MC definitely has both files properly tagged with [Media Type]=Video and it is still throwing that error, provide the log and a screenshot of the file properties of the offending file in MC. It is possible that JRiver changed (or accidentally busted) something about the way it behaves in a recent version, though I'd be surprised. My video MP4 files are still auto-importing with the right [Media Type], so...?
If you are having files import weird, you'll want to look at your transcoding workflow. Possibly the MCFileIngester part of the script is running on them before they are quite finished being written by the transcoder? And so they import and MC can't analyze them (until later when they're finished)? Maybe look at the timestamps in the log and compare them to file modified dates or something? Dunno.
-
Here is the script that is being run:
if not exist %3 mkdir %3
"C:\Program Files\Handbrake\HandBrakeCLI.exe" -i %1 -t 1 --angle 1 --start-at duration:7 -o %2 -f mp4 --decomb="bob" -w 854 -l 480 --crop 0:0:0:0 --modulus 2 -e x264 -q 20 -a 1 -E av_aac -6 stereo -R Auto -B 320 -D 0 --gain 0 --audio-fallback ac3 --encoder-preset=veryslow --verbose=1
ping 127.0.0.1
"C:\Program Files (x86)\MCAutoQueue\Processors\MCFileIngester.exe" --autorun --autoexit -m:Standard -n:%2 -t:Replace --deletesource -s:%1
As far as I can tell, MC isn't importing the newly compressed videos before the ingester runs. Why it worked before, and then stopped, I have no idea. No special .mp4 handling.
What I can say is that I ran the ingester manually on an already converted video (which by the way plays back fine, so doesn't appear to be a bad file) and it ran. Then I ran the whole scheduled task (which runs the above script on video files under certain circumstances), and it also finished just fine.
The problem was 100% reproducible prior to changing the mp4 to open with MC, and now it appears to work. I agree that it shouldn't cause the issue, but for some reason, it might have.
I will know more tomorrow morning once the script runs on all files. There are probably 10-13 files that it will run on...if they all work, then I will call this solved.
Again, thanks for all the help!
-
Well...bummer, it failed again last night.
I think maybe I have it figured out though. I ran it manually again, and it failed. I opened the new mp4 in MC (which would have imported it), then it completed fine. I will try to add an explicit auto import MCC command to the script before running the ingester, and see if that works.
-
As far as I can tell, MC isn't importing the newly compressed videos before the ingester runs.
MCFileIngester imports any non-imported "replacement/new" files before it does the replacement. So it can get the [Media Type] from MC regardless. So you don't need to auto-import them. Looking at your script, I'm pretty sure you're just running MCFileImporter before HandbrakeCLI is all the way done with the files.
You probably want to add a better "sleep" command between those two items in your script (Handbrake and MCFileIngester) to make sure it doesn't happen while Handbrake is still releasing resources. Also, I'm not sure what the Ping is in that script, but maybe it was some kind of effort to create this delay (without having to use a sleep command from a resource kit or whatever)? If so, you need to do more than a single ping like that.
This page describes options:
http://www.robvanderwoude.com/wait.php
I'd add a 30 second delay or something like that, to make sure all the writing in Handbrake is totally done before you do the File Ingestion.
If that doesn't work, I could conceivably add a command line option to ignore the Media Type check. The underlying "ingester" framework is ready for that (that's what the overrideTypeMatching parameter referenced in the error is about), but I'd need to add the command line option. I could, maybe, but it would be safer to not use that option (and doing the replacement on half-imported files could cause all sorts of trouble).
I suspect the behavior of Handbrake has changed somewhat. It is possible it could be due to disk latency, even, as the disk fills up, or something like that.
-
Disk latency is an idea that I had thought about. The ping is just simply for delay...I was a network engineer for Disney, so that's just where my mind went as I was writing the script.
I will add the extra delay to see if that helps and let you know.
All other things, IE: the handbrake version is the same. The drive is by no means full (957 GB free of 5.34 TB), but it is a network NAS, so maybe that is slowing things down. It's just that it has been working for a long time before the last few weeks.
-
It seems to work after adding the auto import, but it is more likely due to adding more delay in (I added a little delay between the auto import and ingester). I will probably play it safe and add just a touch more delay. If everything runs well tonight, I will call this solved.
-
I'm trying to get MCAutoqueue to work with FFMPEG. I keep getting a Processor Not Ready Error or: ERROR Queuing Error: Processor undefined in config:
I'm using Windows 10. I tried running it as an admin but when I do, it can't find MC (2017-03-14 13:21:51.1639 INFO below)
2017-03-14 13:21:26.1669 ERROR Queuing Error: Processor undefined in config:
2017-03-14 13:21:26.1669 INFO Queued File (0): V:\Series\Boomerang\Season02\Boomerang - S02E03.m4v
2017-03-14 13:21:40.3566 WARN Exit Status (1): Queue Cancelled by user or there was nothing to process.
2017-03-14 13:21:40.3566 INFO ----------------------------------------
2017-03-14 13:21:40.3722 INFO MCAutoQueue (by glynor) v0.9.9 Exiting
2017-03-14 13:21:40.3722 INFO ----------------------------------------
2017-03-14 13:21:51.1639 INFO ----------------------------------------
2017-03-14 13:21:51.1639 INFO MCAutoQueue (by glynor) v0.9.9
2017-03-14 13:21:51.1826 INFO ----------------------------------------
2017-03-14 13:21:51.4326 INFO Connecting to running MC instance...
2017-03-14 13:21:51.4483 INFO No running instance of MC found. Launching...
2017-03-14 13:22:21.7238 FATAL Unable to connect to MC!
2017-03-14 13:22:21.7395 FATAL System.Runtime.InteropServices.COMException (0x80080005): Retrieving the COM class factory for component with CLSID {572802D5-FBF6-4C30-89CA-BDF2CE4AEC2B} failed due to the following error: 80080005 Server execution failed (Exception from HRESULT: 0x80080005 (CO_E_SERVER_EXEC_FAILURE)).
at System.RuntimeTypeHandle.CreateInstance(RuntimeType type, Boolean publicOnly, Boolean noCheck, Boolean& canBeCached, RuntimeMethodHandleInternal& ctor, Boolean& bNeedSecurityCheck)
at System.RuntimeType.CreateInstanceSlow(Boolean publicOnly, Boolean skipCheckThis, Boolean fillCache, StackCrawlMark& stackMark)
at System.RuntimeType.CreateInstanceDefaultCtor(Boolean publicOnly, Boolean skipCheckThis, Boolean fillCache, StackCrawlMark& stackMark)
at System.Activator.CreateInstance(Type type, Boolean nonPublic)
at System.Activator.CreateInstance(Type type)
at MCnet.COM.MCCore.GetMC()
Thinking it might be the CLI I'm pushing to ffmpeg I tried File ingester and I get the same error of Processor not Ready.
Running file ingester as standalone works fine.
Any Ideas as to what may cause this?
I went in and changed all the permissions on the .exe. and made sure they run as admin but it didn't help..
I turned off MSE and it din't help either.
Thx
-
Processor not ready and Processor undefined in config typically means that you have a value in the field you are reading that isn't defined.
For instance, in mine, I use the playlist AutoCompress, and a Field called 'Needs Processing'. MCAutoQue will read all of the files that are in the playlist AutoCompress and check those files for the 'Needs Processing' field (or tag).
Within MCAutoQue I have 3 keys set up (Compress, Failed, and Compress_Movie).
- Compress - this is the bulk of what I do, which compresses TV episodes that I have already watched, and want to archive.
- Failed - This will be the case if either of the other 2 keys fail. The script assigned to this key will email me that something went wrong, and provide me with some details.
- Compress_Movie - This uses a custom compiled FFMPEG that uses NVENC (Nvidia Hardware compression) to compress recorded Movies.
IF, however, the 'Needs Processing' field is blank (which in my case isn't actually possible), or has a value that doesn't match one of the above (and it is case sensitive, so Compress is different than compress) then you will get the error 'Processor undefined in config'.
If you could send a screen shot, I could probably tell you a little bit more of what is happening.
Of course, if MCAutoQue is unable to connect to MC, then other things might be going on. MC or MCServer does need to be running. It may actually require MCServer, not 100% sure. You can tell if MCServer is running by looking at the tray next to the clock on the PC, and if the MC icon is there, then server is running.
-
I got rid of the empty tags but no success.
The field name under [Needs Processing] is the processor Key right?
I'm probably missing a minor detail but don't know what it is ...Few snapshots attached. Thx for your help!
-
You did the same thing I did when initially setting up. Your field in MCAQ is 'NeedsProcessing', but in MC, it is actually 'Needs Processing'. Note the space.
-
You did the same thing I did when initially setting up. Your field in MCAQ is 'NeedsProcessing', but in MC, it is actually 'Needs Processing'. Note the space.
And the worst of it is...I kinda remember reading your post on this....I knew it was a stupid thing :) Adding that one space did it!!!
I think I'll love this...
Thanks!!!!
-
If anyone can help with the following, I would be forever grateful.
I have 2 custom fields in MC that I use with MCAQ. One is a path that includes filenames, and one is just the path. It's a calculated field that uses season, series name, etc. Works great unless there is an illegal character in the title, for example, a trailing '.' (as in S.H.I.E.D.), or somehthing like NCIS: Los Angeles.
The way I handle this now is by using a bunch of if then else type expressions in the calculated data. But every time I add a new show that has a bad character, I have to spend 15-20 minutes figuring out how to fix it.
There has to be a way (using REGEX??) to strip out illegal filename/path characters. Anyone have a clue how to do this?
Currently, the 'PathForAutoQue' library field is:
T:\TV\If(isequal([Series], Marvel's Agents of S.H.I.E.L.D., 1), Marvel's Agents of S.H.I.E.L.D, If(isequal([Series], NCIS: Los Angeles, 1), NCIS_ Los Angeles, If(isequal([Series], 24: Legacy, 1), 24_ Legacy, [Series])))\Season PadNumber([Season],2)\[filename (name)].mp4
PathForAutoQue(only path) is:
T:\TV\If(isequal([Series], Marvel's Agents of S.H.I.E.L.D., 1), Marvel's Agents of S.H.I.E.L.D, If(isequal([Series], NCIS: Los Angeles, 1), NCIS_ Los Angeles, If(isequal([Series], 24: Legacy, 1), 24_ Legacy,[Series])))\Season PadNumber([Season],2)\
-
I have the conversion part working great with FFMPEG but now need to get FileIngester processor to run so MC points at the new m4v file instead.
I've been reading this post over and over and can't figure out how to chain the 2 tasks...Anyway to do this without an external batch file?
thx
-
No. I intentionally designed it to only run a single task per processor, as it would have made the completion logic too complex to have it chain tasks.
Plus, you can just use a BAT file or, my preference, a VBS script.
-
None of my MC applications require MC to be running (and certainly not the server version) to work. They'll try to connect to a running instance first, and then launch the version registered with COM if no running instance is found.
They also don't require admin privileges. You should run it "normal". This includes MCAutoQueue, certainly.
Errors like the failure to launch shown above are usually due to issues with MC being registered with COM. This could be because you were running it with elevated privileges, which can change the shell you're running under. But the more common scenario is that you uninstalled a version of MC since the last install. Run MC's installer again over top of your existing installation and it should fix it up.
-
No. I intentionally designed it to only run a single task per processor, as it would have made the completion logic too complex to have it chain tasks.
Plus, you can just use a BAT file or, my preference, a VBS script.
I prefer vbs scripts as well, but I have also noted that in Windows 10, sometimes it will act like it doesn't know what 'program' to open the script with. Once you set it, it will remember. Never had that problem on Win 7. And I can't figure out what causes it...some installations it works from day 1, and other installations you have to explicitly tell it how to open the script.
So, ultimately, I went with a batch file, since it did what I needed it to do.
-
Everything went well last night, so it appears that the extra time I added did the trick.
-
Here is the script that is being run:
if not exist %3 mkdir %3
"C:\Program Files\Handbrake\HandBrakeCLI.exe" -i %1 -t 1 --angle 1 --start-at duration:7 -o %2 -f mp4 --decomb="bob" -w 854 -l 480 --crop 0:0:0:0 --modulus 2 -e x264 -q 20 -a 1 -E av_aac -6 stereo -R Auto -B 320 -D 0 --gain 0 --audio-fallback ac3 --encoder-preset=veryslow --verbose=1
ping 127.0.0.1
"C:\Program Files (x86)\MCAutoQueue\Processors\MCFileIngester.exe" --autorun --autoexit -m:Standard -n:%2 -t:Replace --deletesource -s:%1
I managed to get everything working with the task scheduler for the compression and filerenaming using MCAQ and file ingester but one thing I'd like to do is to get output.m4v as a final output so I don't have to re-run comskip...:
In other words input.ts -> output.m4v instead of input.ts -> output.ts.m4v...I assume I need a script similar to what EDIT: Astromo muzicman0 posted as per the above code but I never built a vbs script before and couldn't find anything on the web to help...
Any tips would be appreciated....I'm almost there :)!
Thanks!
-
There are probably better ways to do this, but look at the following link...specifically the 'Replace - Replace a substring using string substitution', and just rename the file using the same .bat file.
http://www.dostips.com/DtTipsStringManipulation.php
You could also do it within MC, I imagine there are string manipulation tools within MC expression language.
Basically, though, since you know that the end of the filename is always .ts.m4v, you can replace that string in the filename.
-
muzicman0 how or where do you specify %1 for the filename input in your vbs? That's probably the route i should take but as you can see....scripts are a mystery to me...
thx
-
muzicman0 how or where do you specify %1 for the filename input in your vbs? That's probably the route i should take but as you can see....scripts are a mystery to me...
thx
%1 is the first argument, %2 is the second, etc.
So, in MCAQ, just fill in the arguments in the argument line. For me, it was:
[Filename] [PathForAutoQue] [PathForAutoQue(onlypath)]
IIRC, it will default to putting quotes around each argument so you don't have to do that explicitly.
-
I just finally updated to MC22, and am now getting an unhandled event and MCAutoQue crashes. Is there something I can do to fix this?
-
Not sure if this will help, but here are the details of the crash:
See the end of this message for details on invoking
just-in-time (JIT) debugging instead of this dialog box.
************** Exception Text **************
System.Runtime.InteropServices.COMException (0x800401F3): Invalid class string (Exception from HRESULT: 0x800401F3 (CO_E_CLASSSTRING))
at System.Runtime.InteropServices.Marshal.CLSIDFromProgID(String progId, Guid& clsid)
at System.Runtime.InteropServices.Marshal.GetActiveObject(String progID)
at MCnet.COM.MCCore.GetMC()
************** Loaded Assemblies **************
mscorlib
Assembly Version: 4.0.0.0
Win32 Version: 4.6.1087.0 built by: NETFXREL4STAGE
CodeBase: file:///C:/Windows/Microsoft.NET/Framework/v4.0.30319/mscorlib.dll
----------------------------------------
MCAutoQueue
Assembly Version: 0.9.9.42487
Win32 Version: 0.9.9.42487
CodeBase: file:///C:/Program%20Files%20(x86)/MCAutoQueue/MCAutoQueue.exe
----------------------------------------
System.Windows.Forms
Assembly Version: 4.0.0.0
Win32 Version: 4.6.1087.0 built by: NETFXREL4STAGE
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Windows.Forms/v4.0_4.0.0.0__b77a5c561934e089/System.Windows.Forms.dll
----------------------------------------
System
Assembly Version: 4.0.0.0
Win32 Version: 4.6.1087.0 built by: NETFXREL4STAGE
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System/v4.0_4.0.0.0__b77a5c561934e089/System.dll
----------------------------------------
System.Drawing
Assembly Version: 4.0.0.0
Win32 Version: 4.6.1087.0 built by: NETFXREL4STAGE
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Drawing/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll
----------------------------------------
glynor.Common
Assembly Version: 1.0.0.42486
Win32 Version: 1.0.0.42486
CodeBase: file:///C:/Program%20Files%20(x86)/MCAutoQueue/glynor.Common.DLL
----------------------------------------
System.Configuration
Assembly Version: 4.0.0.0
Win32 Version: 4.6.1087.0 built by: NETFXREL4STAGE
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Configuration/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.Configuration.dll
----------------------------------------
System.Core
Assembly Version: 4.0.0.0
Win32 Version: 4.6.1087.0 built by: NETFXREL4STAGE
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Core/v4.0_4.0.0.0__b77a5c561934e089/System.Core.dll
----------------------------------------
System.Xml
Assembly Version: 4.0.0.0
Win32 Version: 4.6.1087.0 built by: NETFXREL4STAGE
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Xml/v4.0_4.0.0.0__b77a5c561934e089/System.Xml.dll
----------------------------------------
NLog
Assembly Version: 2.1.0.0
Win32 Version: 2.1.0.0
CodeBase: file:///C:/Program%20Files%20(x86)/MCAutoQueue/NLog.DLL
----------------------------------------
System.ServiceModel
Assembly Version: 4.0.0.0
Win32 Version: 4.6.1087.0 built by: NETFXREL4STAGE
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.ServiceModel/v4.0_4.0.0.0__b77a5c561934e089/System.ServiceModel.dll
----------------------------------------
System.Data
Assembly Version: 4.0.0.0
Win32 Version: 4.6.1087.0 built by: NETFXREL4STAGE
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_32/System.Data/v4.0_4.0.0.0__b77a5c561934e089/System.Data.dll
----------------------------------------
System.Runtime.Serialization
Assembly Version: 4.0.0.0
Win32 Version: 4.6.1087.0 built by: NETFXREL4STAGE
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Runtime.Serialization/v4.0_4.0.0.0__b77a5c561934e089/System.Runtime.Serialization.dll
----------------------------------------
MCnet
Assembly Version: 1.0.0.42487
Win32 Version: 1.0.0.42487
CodeBase: file:///C:/Program%20Files%20(x86)/MCAutoQueue/MCnet.DLL
----------------------------------------
glynor.Common.Controls
Assembly Version: 1.0.0.42487
Win32 Version: 1.0.0.42487
CodeBase: file:///C:/Program%20Files%20(x86)/MCAutoQueue/glynor.Common.Controls.DLL
----------------------------------------
Microsoft.GeneratedCode
Assembly Version: 1.0.0.0
Win32 Version: 4.6.1087.0 built by: NETFXREL4STAGE
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Xml/v4.0_4.0.0.0__b77a5c561934e089/System.Xml.dll
----------------------------------------
************** JIT Debugging **************
To enable just-in-time (JIT) debugging, the .config file for this
application or computer (machine.config) must have the
jitDebugging value set in the system.windows.forms section.
The application must also be compiled with debugging
enabled.
-
MC22 is not properly registered with COM. Which seems to happen sometimes of late after updating.
In any case, install your current build of MC again "over top" and it should fix you up.
-
Excellent! That fixed it. Thanks as always!
-
Is it possible to use the FileIngester to just move a file? I would like to take a file that is imported from my OneDrive (recorded at an off site location), and then after I watch it, have it moved to its archive location. I could just write a batch file and use MCAutoQue to do it, but I am not sure that it will keep it's tags (most importantly number of plays).
-
Sorry for the delay in responding... I was on a camping trip for a few days, and saw this come in, but couldn't effectively respond!
This absolutely should be possible. MCFileIngester won't move files on disk by itself. But, it can "fix the records" for files you've moved in a variety of ways. You can have it Replace files within MC's database with new copies of those files, and all metadata (including Date Imported and Playlists) are preserved.
So, what you could do is: Write a script that does the moving portion of the task (in VBScript or just a batch file or whatever). At the end of the script, call MCFileIngester and have it replace the old Library entry with the new one.
Precisely how you do this would depend on what options you use in MC's Auto-Import setup, and where you want the files to live. The most important consideration is what you have set for the Fix Broken Links setting in MC. If this is set to On (Protect Network Files) or On, then you'll probably need to COPY (rather than move) the file to the archive location, and then use MCFileIngester to Replace the file in MC with the new copy in the Archive Location (with the Delete Source File when Done option enabled).
That's because otherwise, MC may see that the Source File is missing while the file is being moved and then remove the entry for it from the database ("Fixing" the broken link), before MCFileIngester can run and "fix" the broken link itself. If the Fix Broken Links option is off, then you don't need to worry about this as much. Though, frankly, copy and then delete when done is probably safer than moving, just on general principle.
Tip: It doesn't matter if you have MC set to Auto-Import on the Archive Location or not. MCFileIngester doesn't care if the "new" (replacement) files are imported or not when it runs.
So, it shouldn't be hard to write that script at all, assuming that your Archive Location file naming is deterministic.
-
Thanks for the reply! Hope camping was fun. My wife and I just got back from tent camping in Sequoia National Park.
I went ahead and did some testing since I posted, and it appears as though if I move a file with my batch file, when MC imports it, all the tags are maintained, including the 'NeedsProcessing' tag, so it ended up being much easier than I thought.
I actually have kind of a cool set up. I am using a few HDHomeRun Primes at work (our video wall software can get the streams directly from the Primes), so I set up MC to record cable TV here (luckily it is Copy Freely), then a script runs overnight that compresses the files using FFMPEG (and Nvidia HW acceleration for speed), then writes it to my OneDrive. By morning time, everything has been downloaded from OneDrive on my server, then MCAutoQue moves the file to my Recorded TV folder so that they will appear in my Recorded TV view. Once they are watched, then MCAutoQue will move them to the correct archive drive. I have been testing this for a week, and so far at least, it has worked without a hitch.
-
Thanks for the reply! Hope camping was fun. My wife and I just got back from tent camping in Sequoia National Park.
Beautiful. My wife and I were there many moons ago when it wasn't yet a National Park.
I went ahead and did some testing since I posted, and it appears as though if I move a file with my batch file, when MC imports it, all the tags are maintained, including the 'NeedsProcessing' tag, so it ended up being much easier than I thought.
Yeah. That's Fix Broken Links. If you move files from one watched volume to another, it can usually find them and fix the database without too much trouble. There are exceptions, but for your usage where both folders are watched and you're just moving from volume to the other that would be the simplest method.
I actually have kind of a cool set up. I am using a few HDHomeRun Primes at work (our video wall software can get the streams directly from the Primes), so I set up MC to record cable TV here (luckily it is Copy Freely), then a script runs overnight that compresses the files using FFMPEG (and Nvidia HW acceleration for speed), then writes it to my OneDrive. By morning time, everything has been downloaded from OneDrive on my server, then MCAutoQue moves the file to my Recorded TV folder so that they will appear in my Recorded TV view. Once they are watched, then MCAutoQue will move them to the correct archive drive. I have been testing this for a week, and so far at least, it has worked without a hitch.
Awesome. I'm glad it is working for you!
I've been running it non-stop on a schedule for more than a year now. I should probably rev it and make a v1.0 but I've been too lazy because it is working so well. And I really wanted to make better error handling before making it v1.0 officially, but... Meh.
-
Beautiful. My wife and I were there many moons ago when it wasn't yet a National Park.
Must have been a previous life.
https://en.wikipedia.org/wiki/Sequoia_National_Park
-
Yeah. We were actually in the Sequoia National Forest, not the National Park part. The National Forest is south of the National Park portion. I'd assumed (incorrectly it turns out) that they converted the National Forest into a "real" Park at some point.
They'll probably change it now and strip-mine it. >:( :'(
-
Yep, the whole area is beautiful, but I have to admit, I think I prefer Yosemite. So many amazing places!
-
I haven't used it for quite some time and it looks like it is not working with the 64 bit version?
MCAQ is also throwing an exception on startup..
I'd like to start using it again to compress my viedo files..
thx
-
I'm still on v23, but I am using MCAutoQue nightly with the 64 bit version.
-
It is definitely still working for me on the latest v24 64-bit. Generally this has something to do with MC's COM API not being properly registered in Windows, which MC should fix when running with UAC elevation on installation. Try reinstalling the latest build of MC 24, and let it auto-load MC when it finishes the install (don't uncheck the launch it box).
If that doesn't work, try uninstalling (keep all your settings saved, those are irrelevant for this), then reboot, then reinstall.
If that still doesn't work, maybe try reinstalling the latest MCAutoQueue (you don't have to uninstall it first, just overtop), but that would only help if something in that installation is corrupt (and it is pretty simple, so that's doubtful).
-
I finally upgraded to 24, and had the same issue. I uninstalled 23, and then reinstalled 24, and it fixed it for me. (it probably didn't matter, but I also reinstalled MCAutoQue as well).
-
OK I'll try this thanks guys.
-
Hey Glynor I'm having issues with a script I created to convert .ts files to .m4v using ffmpeg this part works fine but the fileingester step no longer works for me for some reason...
I'm passing the following CLI: --autorun --autoexit -m:ChangeExtension -x:m4v -t:Replace -s:[Filename]
This will open the ingester but no file shows up for processing.... If I manually change it to "Sngle File" vs "Playlist" then it will show up and work...
This same command line used to work just fine before so I'm not sure what changed.. See pics for details.
Thx for your help.
-
I tried on a different PC and it worked fine.... I ended up uninstalling and reinstalling on another drive and it started to work again.. Somthing to do with permissions I guess in windows 10 and c:/program files (x86) ?
-
https://glynor.com/files/MCAutoQueue/MCAutoQueue-0992.exe
MCFileIngester 0.9.11 (03/31/2021) -- Unreleased
1. Fixed: Command Line Options and Saved Application Settings were conflicting causing Source Types to work incorrectly.
2. New: --file Command Line Option for specifying Source Type: File.
3. Fixed: Ingester could be loaded with invalid settings, and errors were not reported (queue would show up blank).
4. New: Default Settings can be saved manually with the Save current settings as new defaults control.
5. New: Prompt to save new settings when they've been modified can be turned off permanently.
6. Fixed: Application non-responsive and slow to load when called with command line options.
7. Changed: Ingester validation and configuration error reporting overhauled.
8. New: Ingester Status is displayed on the main form.
9. New: Ingester "busy" spinner when the Ingester is loading.
10. New: Ingester source loading is deferred until the ingester is ready to run. MC isn't loaded until required.
11. New: Orphaned JRSidecar files for deleted files are also automatically deleted.
12. Fixed: Various performance improvements.
MCFileIngester 0.9.12 (04/23/2021) -- BETA
1. Fixed: AutoRun and RunMinimized weren't working.
2. Fixed: Ingester dialog flashed briefly on-screen even when auto-running and set to run minimized.
3. Fixed: Ingester validation was re-running when not needed before loading the ingester.
4. Changed: Command line errors now cause a fatal error instead of attempting to continue.
5. Changed: Many logging improvements.
MCnet 1.0.2 (04/23/2021)
1. Changed: Ingester validation and configuration error reporting overhauled.
2. New: Ingester validation and loading can be run asynchronously in a background thread.
3. Changed: Ingester Status values expanded to better capture state and allow asynchronous operation.
-
Yup. I actually finally got off my butt and updated this. At least MCFileIngester, anyway. MCAutoQueue itself and MCVideoRedoer are unchanged in this release (aside from linking to my updated Libraries).
The whole thing also still works quite well with MC27. MCFileIngester did have a number of painful bugs and annoyances that I discovered over my years of using it, and I've finally quashed them. I'll note, though, none of the bugs ever caused any data loss in MC itself (it is quite safe in that regard if used properly). But it didn't handle error conditions well at all, and command line options interacted poorly with saved default settings (and then failed and didn't explain why well even in the logs). All of that got thoroughly cleaned up. I decided not to move everything to version 1.0 status quite yet though because I have One More Thing I want to do (https://handbrake.fr) (but needed MCFileIngester fixed first).
We shall see. In any case, this new version of MCFileIngester is much better. If you have it lying about yet (and especially if you find it as useful as I do), grab the new version.
PS. I should note: I have no idea if MCVideoRedoer still works at all. I don't install VideoRedo anymore and haven't touched it at all. I know it doesn't work with VRD6. That came out right at the tail end of when I was still actively working on this and they'd completely re-done their COM API (so much so that it would have taken a complete re-write of the underlying interop Library to fix, and I never bought v6). It may still work with VideoRedo v5 if you have that lying about.
-
This will open the ingester but no file shows up for processing.... If I manually change it to "Sngle File" vs "Playlist" then it will show up and work...
This is probably one of the bugs I was quashing. I hit a very similar issue. When using the Command Line options, it would go all sideways if you set MCFileIngester to use Playlist Source Type by default, and then tried to use Single File mode via Command Line (or the reverse).
Sorry for the long, long delay, but it is finally fixed.
-
Just to report here that Ingester will lose rating for matroska videos as MC will update from tags after the process and that resets the rating field. It is MC bug
-
Interesting! I haven't seen that, but I don't use ratings extensively on my video collection (though I do use some ratings for certain collections). So, just to confirm does it happen if you do a Replace Mode ingest of a new MKV on an existing file, it does this? Or does it happen in Clone Mode?
Does it only happen with newer versions of MC27?
I might be able to work around that...
-
MCFileIngester.exe --autorun --autoexit -m:Standard -n:"TODO's\Swap Files\New" -t:Replace --deletesource -s:"TODO's\Swap Files\Old" --playlistUse case for example: Replacing old DVD matroska rip with matroska BD rip. MC I guess will do automatic refresh from tags at the end which will overwrite title from matroska tag if it exist and also resets rating field (I suppose it tries to take rating from matroska tags)
-
Hmmm.... Yes, MCFileIngester manually runs the equivalent of Update Library from Tags on the replaced files as the very last step it does for each file. This is needed in order to update the automatically calculated tags (such as duration, bitrate, etc) if the new file doesn't have the same characteristics as the original.
It technically shouldn't be pulling [Rating] from the tags though, as it always runs Update Tags from Library first, flushing what it has out to the Library, which should write them to the JRSidecar files and the Library, first. Only after this is finished does it do that last step of updating from tags.
I wonder, do you have Sidecars disabled? I wonder if this is the difference and why I never noticed it before?
In any case, I may be able to fix it by manually cloning certain metadata over before it does the "in place" Library file swap Replace Mode does. I already have it doing that for at least one tag (which one, escapes me right now in the depths of time), but I might need to add [Rating]. I'll try to run some tests, but if you happen to have easy test-cases, let me know if:
1. Clone mode behaves similarly, or if Rating is properly cloned in that case.
2. If you have Sidecars disabled.
Thanks again.
-
Hmmm.... Yes, MCFileIngester manually runs the equivalent of Update Library from Tags on the replaced files as the very last step it does for each file. This is needed in order to update the automatically calculated tags (such as duration, bitrate, etc) if the new file doesn't have the same characteristics as the original.
It technically shouldn't be pulling [Rating] from the tags though, as it always runs Update Tags from Library first, flushing what it has out to the Library, which should write them to the JRSidecar files and the Library, first. Only after this is finished does it do that last step of updating from tags.
I wonder, do you have Sidecars disabled? I wonder if this is the difference and why I never noticed it before?
In any case, I may be able to fix it by manually cloning certain metadata over before it does the "in place" Library file swap Replace Mode does. I already have it doing that for at least one tag (which one, escapes me right now in the depths of time), but I might need to add [Rating]. I'll try to run some tests, but if you happen to have easy test-cases, let me know if:
1. Clone mode behaves similarly, or if Rating is properly cloned in that case.
2. If you have Sidecars disabled.
Thanks again.
I don't use sidecars so that is the reason you don't notice this reset. As MC don't write MKV tags to files it gets empty value for rating when it is doing update from tags but if you are using sidecars the rating is there for MC to insert to destination file.
I'll test clone mode soon but I think that the behaviour is the same because of same reasons as above
-
If it works right in Clone mode (and I suspect it will because it doesn't have to do the Update Library from Tags step on those), then it should be possible to work around the issue. And, if it still does it there, it might be just because I have it set up to do the update from tags step anyway (which isn't really needed).
Another thing to test, does it still happen if you have Update Tags when File Info Changes disabled?
In any case, MC shouldn't re-import tags from disk (and overwrite existing Library Fields with data) when you run that command, but since it apparently does, I have ideas.
-
Also clone seem to do update from tags so it updates name & rating from matroska tags. Unchecking "Update Tags when file info changes" doesn't make any difference probably as MC cannot write any matroska tags which is also the beef of the problem in MC.
So both Clone and Replace will do refresh from tags afterwards and mkv file will have rating always reset