Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[muzicman0]

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).

[glynor]

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.

[muzicman0]

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.

[glynor]

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.

[JimH]

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

[glynor]

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. 

[muzicman0]

Yep, the whole area is beautiful, but I have to admit, I think I prefer Yosemite.  So many amazing places!

[imeric]

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

[muzicman0]

I'm still on v23, but I am using MCAutoQue nightly with the 64 bit version.

[glynor]

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).

[muzicman0]

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).

[imeric]

OK I'll try this thanks guys.

[imeric]

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.

[imeric]

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) ?

[glynor]

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.

[glynor]

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 (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.

[glynor]

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.

[lepa]

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

[glynor]

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...

[lepa]

Code: [Select]

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)

[glynor]

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.

[lepa]

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

[glynor]

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.

[lepa]

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