Print

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

[pauly139]

Since updating to build 168 MC16 is now reporting my AVI files as 'bad' when trying to import them. I know they are fine as they play with WMP. Also, if I stop MC Server from running, and then try and import them they import into the library fine, and play in MC16 with no problem.

This has now happened with around 20 AVI files.

[TunaOnToast]

I have the same problem. Not only with AVI files but also with MKV files.
If I run Auto Import I get this message:



If I rename the file(s) and run Auto Import again, the files import into the library just fine.

[pauly139]

Thanks for the renaming tip - it works for me too.

[glynor]

This is a big problem for me.  It is because of the change I discuss here:
http://yabb.jriver.com/interact/index.php?topic=66222.msg444901#msg444901

A good idea, but not very thoughtfully implemented quite yet.  Right now, if MC detects that a file is "bad" on import, it puts it into a bad-file "purgatory" that is difficult to access and very difficult to remove the files from.  I discovered last night after posting that even if you make the special smartlist that shows the "bad" files, select them and delete them from the "library", MC still won't import them (and they show right back up in that Smartlist).

You can force MC to re-import them manually by:

1. Creating the special smart playlist.
2. Selecting your incorrectly-detected "bad" files and dragging them to the MC title bar.
3. Choose Import from the pop up menu.

This imports them correctly assuming they aren't really broken, but then you still need to do a Update Library (from Tags) on the files to get the Media Type, bitrate, and other details to fill in.  And, of course, this makes auto-import completely useless for any files that might be partially written when they are first "detected" by MC's Auto-Importer.  This would include:

* Video and audio recordings still in progress (none of my TS files from Sage will auto-import anymore).
* File downloads still in progress (especially AVIs where the header is at the tail of the file).
* Any file that is broken originally, but which you then "fix" via some external application.
* Any file that MC erroneously fails to import, even once (maybe due to a bad filter, or bad user configuration).

Like I said in the previous post... This is generally a good idea.  It can probably substantially speed up imports for users that have a bunch of broken files lying around that they've never bothered to track down and kill.  And (if you didn't have to manually create the Smart Playlist), it could make it much easier to actually find and kill those files after the fact.  But... MC needs to check to see if the file has changed since it decided that the files were "bad" and, if so, try to reimport them.  It also needs a better, more intuitive, and simpler for novice users way to retrieve these broken files from purgatory manually.

[Matt]

But... MC needs to check to see if the file has changed since it decided that the files were "bad" and, if so, try to reimport them.

It is trying to do this.  It looks for changes to the file size or date modified on the next run of auto-import.

I'll try the import while copying method and see if I can reproduce the issue.  Let me know if there are any other tricks to reproduce the problem.

[Matt]

I learned something on this one.  When a big file copy starts, the file on disk works like this:

At start:
File size: Final size, for example, 20 GB
Date modified: Now

At finish:
File size: Final size, for example, 20 GB
Date modified: Date of source file

I was surprised that the modified date starts at now and then moves backwards at the end.

Media Center was only checking for advances in the date modified (as opposed to changes) so when the system moved the time backwards, it wouldn't re-analyze the file.  We'll change this.

We're also wondering if it'd be better for import to ignore any file that it can't get exclusive read access to, meaning nothing has the file open for writing.  I'm leaning towards not doing this, but would be happy to hear opinions.

[MrC]

I learned something on this one.  When a big file copy starts, the file on disk works like this:

I was surprised that the modified date starts at now and then moves backwards at the end.

I think this is an Explorer thing (file creation and date set by Windows; Explorer resets dates after completion), giving folks the modified dates they'd expect when copies are made.  To me, this default behavior is wrong, but certainly can see the argument for it.

Welcome back, btw.

[glynor]

Media Center was only checking for advances in the date modified (as opposed to changes) so when the system moved the time backwards, it wouldn't re-analyze the file.  We'll change this.

We're also wondering if it'd be better for import to ignore any file that it can't get exclusive read access to, meaning nothing has the file open for writing.  I'm leaning towards not doing this, but would be happy to hear opinions.

It seems like this might solve the problem for me.

I did discover last night that it isn't JUST in-progress files that I'm having trouble with.  ANY file I copy/move into a watched folder that is of sufficient size that MC checks it part-way through the copy gets blacklisted, which is an even bigger problem.  But this might solve that.

I also really think we need a better way to get files out of the purgatory.  Right now, it is a major pain, and not something for the feint-of-heart.  For example, this is what I have to do to get them to import properly right now:

0. Make sure you've created the special smartlist that shows the blacklisted files.
1. Find the improperly-blacklisted files in this smartlist.
2. VERY IMPORTANT: Select them and do Update Library from Tags.  If you import them without doing this, they import with no [Media Type] tag, and, while they import, they won't show up under ANY view scheme (not even Documents).  They do show up under my special, custom "All Files" view scheme, but you apparently can't even filter them for [Media Type] = Undefined (or whatever you get in the panes for this).  I'm not sure why, but they don't seem to respond to ANY filters.  So you just have to scroll through an ALL FILES type list, and look for them manually.
3. Fill Properties from Filename to at least fill the [Name] tag with the filename, otherwise all this tagging info is blank as well.
4. Finally, import them by dragging them to MC's titlebar and choosing Import from the popup menu.

Yeah... So this isn't good.  We need a quick way to tell MC: "These files shouldn't have been blacklisted.  Import them now as if they're new."

Right now, you have to manually hack it, and it is VERY easy to mess a step up and lose them completely in the Library.  This is even worse than having them not imported at all, because then you can't get to them, can't find them, and it is very difficult to tag them once they're in the library.

Also, what's up with the Also Show menu in the Tag AW?  I can't seem to add anything to the Tag AW on the Recently Imported Smarlist.  I want to "Also Show" [Media Type] but the menu is weird and seems broken.

[glynor]

The fix doesn't seem to have worked, at least not for my TV recordings.  I'm not sure how this even can work though, now that I think about it.

I think MC is too quick.  I'll post "evidence" and an explanation later.

[glynor]

We're also wondering if it'd be better for import to ignore any file that it can't get exclusive read access to, meaning nothing has the file open for writing.  I'm leaning towards not doing this, but would be happy to hear opinions.

I can think of situations where it could be convenient to have MC analyze and even use files that are "open" in other applications.  Now, it depends how granular you can be.

If by "open" it would count things like a JPEG open, but saved, in Photoshop, this wouldn't be good.  But, I don't know if Photoshop keeps a lock on open files.  I think it does, though, based on things I've seen editing files on our SAN at work.

[glynor]

The fix doesn't seem to have worked, at least not for my TV recordings.  I'm not sure how this even can work though, now that I think about it.

I think MC is too quick.  I'll post "evidence" and an explanation later.

So, I just did a few tests with the new build.  MC was left running for each of these tests (which were done all on my server machine with local disks).

1. I recorded a short piece of a show in SageTV, and watched how the file modified date reacted in Windows Explorer.
2. I copied a big (6.19GB) MPEG-4 TS file from my desktop into a watched folder (M:\incoming\)
3. I'm currently recording a longer piece of a show, and I ran Update Library from Tags on it in MC, while listed in the "rejects" Smartlist, and while the file was still actually recording (it still is as I write this).

Here were the results:

1. TheGoldenGirls-S04E10-StanTakesaWife-5625698-0.ts

To reiterate, I recorded a small piece of this show, letting the recording end on its own and get saved by Sage.

The file failed to auto-import during, and after recording.  I gave it a good hour from when it finished recording without doing anything other than leaving Media Center open and checking for new items to show up in my "recently imported" view in MC.   The file never auto-imported on its own.  I then manually Ran Auto Import Now, and it reported that one was skipped because it was bad, blah blah blah.  While the file was recording, the Date Modified started out matching the Date Created on the filesystem.  This didn't change until the file was done recording, and then it jumped to the end timestamp of the show.  See the following screenshot:


Click to enlarge.

This screenshot is showing this recording after the recording finished (much later) in both Windows Explorer and my "Rejected Imports" list in MC.  As you can see, the Date Modified is 9:30PM, which is when that episode of Golden Girls ended (btw, give me a break, I just picked something ending soon and hit record).  While the recording was in progress, the Date Modified on the filesystem matched the Date Created at 9:23PM.  But as soon as it was done, and I hit refresh in Windows Explorer, it was listed as 9:30pm.  MC continues to list a Date Modified for this file (in the Smartlist) of 9:23PM, even now (I just hit refresh).  The Date Imported is interesting, because you can see that MC is basically picking up the files very quickly after they are first created.  It lists the same time as that Date Created from Windows Explorer (which matches what time it was when I said "go").  I'd bet MC actually always "detects" them extremely quickly but I have no way to test this, but I think that's part of the problem.

To be clear, this file exists, and plays in other players currently.  MC will not auto-import it and it remains on the "bad files" list.

2. big file copy test.ts

This second test is simple.  I took a big old 6.19 TS Movie recording, already in MC (for a long time, it was recorded in 2009), and copied it to the desktop.  I waited for it to finish copying, and then I renamed it "big file copy test.ts".  I then copied this file into M:\incoming\, which is a watched folder in MC.

The file failed to auto-import during, and after copying.  It did not "automatically" AutoImport, and it (still) rejects when I manually choose Run Auto Import Now.  The file modified timestamp on the filesystem worked as described by Matt above.  Originally matched the time I started the copy running, then switched back to the file's original created date when the copy finished.

Here's another screenshot like the one above, for this copied file test now:


Click to enlarge.

So, this is much like the opposite of above.  The date MC first "saw" it was apparently tonight at 10:43PM, and it lists that as the Date Imported in the rejected files list.  Interestingly, MC lists the Date Modified as one minute prior.  I don't know if that means anything.  I may have started the file copy right at a "minute transition".  Either way, refreshing the list doesn't change this.  And, as you can see, now that the file copy is done, Windows explorer lists it as July 10, 2009, which is when it was originally recorded.

And, yep, the copy plays.

3. Conviction-5621767-0.ts

Here's, perhaps, the most interesting.  I recorded this file for longer, and did some tests on it while it was actively recording in SageTV.  Like I said before, this file is still recording right now (but it won't be long now till the movie is over).

The file is listed in my Rejected Imports list in MC, and fails to auto-import even if I run it manually, just as before.  However, I selected the file in this list in MC and did a Update Library (from tags) on it.  MC then detected it properly as a Video file, and filled in the Duration, Bitrate, Dimensions, and made a thumbnail of the file.  Here it is in MC after running that command, still showing the rejects playlist:



So, I opened this file in Media Player Classic HC.  It plays just fine, while being actively recorded by Sage.

So, then I drug the file from the Rejects list in MC up to the titlebar, chose Play, and we get:



The file, while still being recorded by SageTV, plays fine in MC.  I can skip ahead and back, and see no apparent problems playing the file in MC.  As soon as I play the file, of course, MC imports it because I have that option enabled.  But, it imports with absolutely no tags set at all except those picked up by the Update Library command, including [Name].

So, then I went back to #2 (the big file copy test) and did Update Library (from Tags) on it in MC's Rejects list.  It too got a Thumbnail, dimensions, and the rest.  So then, without trying to play it (I'm sure it will play), I tried manually Run Auto Import Now.  Nope, still won't import, and still is listed in the Rejects list.

[glynor]

So, honestly, I'd have to say that Auto Import seems thoroughly broken for right now, at least for Video and other "big files".  I can't think of many situations where Auto-Import would pick up files for me that weren't small audio files or files created by MC itself.  I mean, if it still can't get that file copy, and the files do have changed file modification times in Windows, and heck they actually even play in MC, and it still won't import them?

I think the standard has to be, if the files work, and they're in a watched folder, and MC won't import them.... Then Auto Import is broken.

[glynor]

PS.  I just tried turning off the Automatically Import files when played option and playing that big file copy test file by just double clicking on it in the Rejects List.  It played in MC fine.

MC then, finally, removed it from the Rejects list.  However, it didn't import it.  I waited a good 10 minutes, and kept checking my recently imported view for new files.  It never showed.  I then did a Run Auto Import Now, and it found it:

Code: [Select]

Updated 1 file that had external changes.

In-depth details:
Imported:
    M:\Incoming\big file copy test.ts


Updated:
    M:\Incoming\big file copy test.ts
But it didn't even really pick it up on it's own, I had to "go look for it" and that was after fixing it by running both Update Library from tags on it and playing it in MC.  Oh, and they import with the [Name] tag still blank (and [Album] too, instead of being filled with the date, but that annoys me anyway).

So, I'm not really sure this plan even can work as designed now...

Even if you detect the file being modified from when it was last "rejected" properly (and I think to do this, you might have to do more than rely on what the Date Modified in the system shows... what about a recording that lasts less than 1 minute, for example?)... But even if you manage to do this right, and the file will get picked up on the next "run of Auto-Import", it doesn't seem like this "run" of Auto-Import gets kicked off automatically like it should.

Since MC doesn't scan the filesystem regularly, but waits for filesystem change notifications from Windows, it probably won't ever actually see the file unless you run the Auto-Import manually.  It might eventually grab it when the next file gets copied into a watch folder, or starts recording, or whatever...  But even then, the Auto-Import would always be "behind by a step".  If nothing new appeared in a watched folder for 2 hours (or 6 days) then that perfectly good file will sit there "un-imported".

Right?

[glynor]

I just did a few additional tests, to confirm a few things...

I did a "file copy" test with a large MKV (12.5 GB) and a large AVI (7.9 GB) to confirm that the issue is not limited to TS files.  Same results as #2 above.  I followed the same exact procedure that I did with #2, up-to-and-including the playing it thing (I didn't try playing it while it was copying, MC wasn't performing very well during the copy anyway, and I'm sure that wouldn't have worked).  When I played them, they disappeared from the Rejects list, but did not auto-import.

I also tried with some smaller, but still fairly large AVI files (a 1.5GB and a 2.1GB file).  In this case, the file copy process in Windows was much faster (my drives never got out towards the tail end of their write performance curve), and MC's system seemed to work properly.  Or, at least, they never appeared on the Rejects list while copying, and they imported correctly a few seconds after the copy finished.

I next tried with a medium-sized 4GB MKV file.  This one also failed like the larger files.  So, the limit on my system seems to lie somewhere between 2GB and 4GB in file size for video files.  And, incidentally, I confirmed this part:

Since MC doesn't scan the filesystem regularly, but waits for filesystem change notifications from Windows, it probably won't ever actually see the file unless you run the Auto-Import manually.  It might eventually grab it when the next file gets copied into a watch folder, or starts recording, or whatever...

It does work this way (a "step behind" after you fix them).  I'd updated tags and played, but not yet imported, that 8GB AVI file.  So it had removed itself from the Rejects list, but not actually imported.  It didn't, until I dropped the next test file (the 4GB MKV) into the watched folder.  Then, that previous 8GB AVI imported immediately.  But, of course, the 4GB MKV that kicked this process off "failed", and got stuck in the purgatory itself.

Lastly, I did Update Library (from tags) on the 4GB MKV (so it got its details and could be played), but did not play it, and then tried one last 3GB MKV file through the process.  The 3GB file failed to import, and got added to the Rejects list, but the 4GB file (which was still listed in the rejects list) stayed right there in the list and did not import.

The key to reproducing it with a simple file copy test on my system, with my disk performance, seems to be files somewhere between 2-3GB in size.  New TV recordings on my system seem to pretty much always fail to import.  I just did a very short standard def recording (MPG, off of one of my analog tuners in Sage), that was only 1 minute 26 seconds long and 103MB and it also failed to import and got added to the list.  So, it seems like it has to do with a timer, more than a file size in particular.  How long the copy (or recording) takes to finish makes the difference, it seems.  I bet you could reproduce it with smaller files if you copied them from some really slow media, like a USB1 flash drive, optical disc, or something similar.

So... I'm done.  Sorry this was so long, but I wanted to do a comprehensive test for you.

[kensn]

could you please provide a little more detail... LOL...

[Matt]

Thanks for all the details.

When I do a big copy, I see the file get imported to the bad location, and then get moved to the main database once the copy finishes.

Just to be sure, were you testing with 16.0.174?  16.0.173 doesn't work properly for me either.

Next, is it possible the option 'Update for external changes' has been turned off in Auto Import?

I'm still brainstorming about other possibilities.

[glynor]

Just to be sure, were you testing with 16.0.174?  16.0.173 doesn't work properly for me either.

Yes.  I'm sure.

Next, is it possible the option 'Update for external changes' has been turned off in Auto Import?

This option is, and always has been, disabled on my system.  It used to make auto-import take FOREVER sometimes, and occasionally screwed tags up.  But, I'm willing to turn it back on if that is what is needed.  However, this really took forever when I did a Run Auto Import Now scan, since I have a very large library, and it had to "check" them all.  I'm probably talking MC15-era, but it was slow.  Am I going to see similar slowness when I run the Auto Import manually?

Also, it seems like this stuff should probably be independent of that setting.  I'm not really looking for external changes.  I just want Auto-Import to, you know, auto-import.

Parsing external changes lets you tag files in other, external, applications and have MC reflect the changes.  I never do this (MC is the be-all-and-end-all tagger in my workflow)... Though it might be convenient to have it pick up tagging changes in Photoshop, Bridge, and Lightroom, if that is possible.  I haven't played with it, but...

[Matt]

This option is, and always has been, disabled on my system.

That is why it's not working. 

For now, try enabling it.

We'll think about how we might handle this more elegantly in the future.

Parsing external changes lets you tag files in other, external, applications and have MC reflect the changes.  I never do this (MC is the be-all-and-end-all tagger in my workflow)... Though it might be convenient to have it pick up tagging changes in Photoshop, Bridge, and Lightroom, if that is possible.  I haven't played with it, but...

Tagging with another program isn't too different than recording with another program.  Both are external changes to files in the library, which is exactly what the import option is designed to handle.

[glynor]

That is why it's not working. 

For now, try enabling it.

We'll think about how we might handle this more elegantly in the future.

I'll do it tonight and report back.

While I understand that these are technically external changes (the file copies and recordings in-progress), I don't think that's really what the option was designed to do (prevent the files from importing at all).  These are changes that are occurring before the files ever get into the database in the first place, not a file that has been ingested and then changed hours/days/months later externally.  The fact that it happens with a simple file-copy operation in Windows seems to underline this point.  I understand that technically, once the files have been picked up and added to the Rejects List, then they are actually imported (just not into the normal database), but from a user-perspective, that isn't what is happening.

So, in a perfect world, I'd say this option (enabled or not) should have no bearing on the auto-importing of files for the first time.  That option should only apply to files already imported, that have then been changed (cropped, retagged, etc).

But, if it works for now, it works for now.  I'll test it and let you know.

[glynor]

We'll think about how we might handle this more elegantly in the future.

Two other little elegantness things to think about for this if you are making changes going forward...

1. In the Rejected Imports smartlist (which should be included in a default library), an button to "Recheck all files in the List" simply would be the best way to solve any files that somehow did get erroneously put on the list.  If the "check" succeeds, they should be imported correctly as-if they are brand new.  If you can't add a specific button, then Update Library (from Files) should act the same.  Right now, that command only gets you 1/3rd of the way there.

2. I'm a bit concerned that the Rejected Imports list now seems that it will contain, forever, a chronological listing of EVERY file that my system records from now until eternity, if those files never get imported (or even deleted or watched live).  This isn't the biggest deal ever, but what about if I watch one of those less savory shows late at night on Cinemax or HBO, and then my daughter wanders in there one day and says "Daddy, what is Debbie Does Dallas Again?"  The list contains even files that have been deleted.  And, if you manually delete them, they come right back when you close and re-open MC.  This list should regularly clean itself of missing files.  Also, see point #1.

[Matt]

I think you're seeing things we didn't expect because you've disabled both external updating and fixing of broken links.

We're going to make the import engine analyze a file that has been previously removed or marked as bad, regardless of the user options mentioned above.

This should fix your files getting stuck in the bad location and also remove deleted files that no longer exist on disk.

We'll also make 'Update Library (from tags)' move a previously-marked-as-bad file into the main library when it succeeds.

[glynor]

I'd love to re-enable the Fix Broken Links option.  Really, I would (it drives me nuts to have to delete all of the auto-deleted TV recordings I have).  But I need to be able to mark those drive X files as Removable.  

[glynor]

Okay... So, I'm still on 174 (though I expect not for long).  I enabled Update Library for External File Changes.  Immediately, I noticed that all of the remaining files in my Rejects List got their thumbnails and details, as though I had selected them and done Update Library from Tags.  I didn't do anything other than enable the option and switch back to the Rejects List.  The [Name] tag was still blank, though, and they did not import on their own.  They just sat there in the list.

So, I did Run Auto Import Now.  I must note, this process (which usually takes all of 15-20 seconds to finish) took almost 7 minutes.  It listed and ran through just over 7900 files during the "Updating for external changes" part of the process.  Now, I don't know what might have changed with most or all of those files, and like I said, I've had this option disabled for a long time.  I looked through the log, and most (90%) of the files it needed to "update" were in my Conversion Cache.  Nothing else touches those other than MC, so I'm really not sure what it needed to do to them, but anyway... It has been a long time.  Hopefully it isn't like this every time, but we'll see on that.  I'm also hesitant about that simply because I don't want it messing up my tags.  Like I said, MC's Library is "The Truth".  I'm worried that something stupid is altering The Truth, and I don't know what and I don't know why.  But, that's almost certainly just paranoia.  I just don't really need it doing that, and it makes me nervous, and it can be slow, so I keep it turned off.

But anyway...  After the Run Auto Import Now scan finished, it found and imported the four files that had been left in my Rejects List from last night's tests.  But, it imported them like this:



So, that's good, but without the [Name] tag they are pretty useless unless I take some action.  I think this just might be a side-effect of switching from not having Update Library enabled to having it enabled, based on the rest of my testing, but I'm not sure.  Either way, new files should always, at least, import with the [Name] tag filled.

I also tested the 4GB test file copy.  It worked perfectly.  I think it took a bit longer than "normal" to import, but it worked, and it had its [Name] tag filled.  I did notice that I could "tell" by the performance of MC (and noise coming from my hard drives in the machine) that the Auto-Import was running.  Switching views hesitated for a second, and then suddenly it "unstuck" and the new file was there.  For giggles, I also tested with my 3GB test MKV, and it also worked correctly.

Lastly, I tested with a recording in Sage.  This also worked mostly correctly.  The file was added to the Rejects List during the recording, and then imported automatically within a minute or two of ending.  However, this time the file did not import with the [Name] tag filled.  It came in blank... Bummer.  You really need the Name tag filled or you can't see the files in Theater View or anywhere properly.

So.... That seems to mostly fix it.  But, of course, the option shouldn't affect it, but we already discussed that (and you've probably already fixed it, I just don't have the build yet).  My deleted files are still in the Rejects List and I can't get rid of them.  But that too should be fixed with your proposed changes, I suspect.

Obviously, we need the import tagging rules to always be applied like completely new files.

[Matt]

The file was added to the Rejects List during the recording, and then imported automatically within a minute or two of ending.  However, this time the file did not import with the [Name] tag filled.  It came in blank... Bummer.  You really need the Name tag filled or you can't see the files in Theater View or anywhere properly.

...

Obviously, we need the import tagging rules to always be applied like completely new files.

You're right, of course.  Hopefully it'll be a simple enough change.

Also, the new build should remove physically deleted files you've also deleted from the library regardless of your broken links setting.

Thanks a lot for all your work on this one.

[glynor]

I haven't repeated my File Copy tests yet (later), but I did a test recording.  For the moment, build 175 seems to work the same as 174.  I have to have Update for External Changes enabled for it to work like described just above.  The files then auto-import without their [Name] tags filled.  With Update for External Changes disabled, it seems to continue to ignore them like before.

But, let me do further tests...

[glynor]

Okay... I did some further tests.  Sorry, Matt.  Doesn't look like it worked.

Build 175 acts basically just like 174 if Update for External Changes is disabled.  However, it does seem slightly less consistent.

Last night, I tried the file copy tests tons of times, and the behavior was always consistent.  However, tonight I'm not seeing that.  What I'm seeing now is:

With Update for External Changes disabled:

Sage TS Recording: Failed to auto-import.  Skipped by manual Run Auto Import Now because it is "bad".  Still listed on the Rejects List.
3GB File Copy Test: Failed to auto-import.  Skipped by manual Run Auto Import Now because it is "bad".  Still listed on the Rejects List.
4GB File Copy Test: Import worked, with [Name] properly filled.  (I know... Huh?)
4GB File Copy Test Second Try: Failed to auto-import.  Skipped by manual Run Auto Import Now because it is "bad".  Still listed on the Rejects List.

Note however: Using Update Library From Tags on these files in the Rejects List does now cause them to be "able to be" auto-imported (I don't have to now actually Play them first), but auto-import is not triggered to see them on it's own.  It has to be triggered by another filesystem event in a watched folder, or be kicked off manually.  So that worked.  They have no [Name] though.*

With Update for External Changes enabled:

4GB File Copy Test: Import worked, with [Name] blank.
3GB File Copy Test: Import worked, with [Name] blank.
Both the 3 and the 4GB Files Copied Simultaneously: Import worked for both, the 4GB one got the name, the 3GB one did not. (Glad I tried that.)
Sage TS Recording: Import worked, with [Name] blank.

Import times seem more variable than before these changes.  On the first try of the 4GB file, it took about a minute before it appeared (on the 3GB one I forgot to check).  On the simultaneous one it was very quick, like "normal".  I don't know... It is still pretty fast, so no worries.  Just noticing the variability since I'm sitting there watching them come in.  (I'm also typing while I'm waiting for things to finish recording/copying/etc, so rambling.)

So, it doesn't seem like this worked:

5. Changed: Auto-import works better with removed and bad files when the options to 'Update for external changes' and 'Fix broken links' are disabled.

It seems the same as build 174, but randomly able to pull it off.  Who knows though... I never actually saw that 4GB file that "worked" make it onto the Rejects List, so maybe it just "worked" like the 1GB files work, because my disk happened to be going quickly on that copy?

This, however, seems to have mostly worked:

6. Changed: Doing 'Update Library (from tags)' on a file in the bad database will move the file out of the bad location into the main database if it succeeds.

With Update for external changes disabled, you still need to kick off a manual Auto Import run, but I think that's related to #5, not something special about the fix in #6, which seems to have worked.

The removing missing files from the Rejects List thing seems to have worked though.  I can't mess with that option, so I'm glad.

* PS. I'm not just harping on the [Name] thing.  I know you get it, though thanks for confirming.  I'm just trying to document.  And sorry if I harped on it too much before.  I figured this wasn't intentional.  I was just "thinking out loud" while I was trying to document... And I was tired.  

[glynor]

Thanks a lot for all your work on this one.

No, thank you.  I really appreciate it.

And, yeah, hopefully the [Name] thing isn't too hard to track down.

[Matt]

Are we there yet?

Next build:
Fixed: When a file previously marked as bad was later imported, it would not have its name filled automatically.
Fixed: Having the auto-import option to 'Update for external changes' disabled could (still) lead to problems with files that were marked as bad.

Thanks again.

[glynor]

I never replied to this thread (sorry), but yes... It mostly worked.

I am still having trouble with video thumbnails related to this change.

SageTV (I'm not sure if it is by default, or due to one of the plugins I have installed) saves a cover-art JPEG file sidecar for each recording it makes.  The cover art is usually good.  I'm not sure where they source it, but whatever... They're good ones.  The files are named the same as the recording file name, except they end in .jpg (obviously).  MC has always picked these up and used them automatically when it imported the files.  Or, it did, until these fixes were made.

Now, I get a really bizarre situation.  I've been meaning to post about it, but I never got around to it.

Ever since this change was made, MC is using the cover art JPG file for whatever file most recently came off of the "rejects list" (so, usually, the most recently imported file) for a whole swath of the files that once "were" in the rejects list but had been previously imported.  I can't really tell what causes it to switch.  For example, right now in my MC library, all of my recordings have the cover art for last night's episode of The Colbert Report (except for those where I've explicitly fixed it by assigning cover art manually) all the way back to September 22, where they suddenly start either being "right" or they use some other wrong cover art file.

Why is 9/22/2011 the "magic date".  I'm not sure... Maybe that's when I updated the server to the version of MC that fixed it.  But I doubt it.  Matt's post was on 9/14, and I was burning for that fix and was testing it extensively.  And, I haven't really been checking, but it seems like that date "slips around".  I'll see 15-20 of the most recent imports all with the same cover art as the "top one" in the list, then suddenly, it'll switch to some other cover art image (one of which is right, but then it repeats down the list for a ways).

Anyway, this absolutely worked before, and something with this set of changes broke it.  I remember that much that it started then.