INTERACT FORUM
Windows => Television => Topic started by: ErikN on August 24, 2018, 06:10:06 pm
-
I changed from MC21 to MC24 a few weeks back. I've encountered a few new problems two of which I think I can describe in enough detail to be useful. I started with 24.0.41 and am now on 24.0.45.
1) Occasionally a file handle is held by MC24 preventing both MC itself as well as any other program from deleting a media file until I close MC.
A common sequence
1.1: Record a number of shows throughout the day
1.2: Use F6 bulk rename to move shows to a transcode directory
1.3: Bulk transcode to mp4 + new sidecars using an external script
1.4: Move mp4 versions into folders (auto-imported)
1.5: If mp4 versions look good, delete originals from within MC
The deletion in step 1.5 works 70% of the time. However, in the bad 30% exactly one of the files will fail with a message similar to "Media center is unable to delete the file. Retry?". Retrying does not help. It can be removed from MC's library but the file still exists on disk. If I try deleting from windows, windows complains that it cannot delete because the file is in use within MC. MC works just fine in other regards and I can play media files etc. As far as I can tell, the problematic file cannot be deleted until I close MC.
2) A TV recording's title resulted in a filename with a period. When I used F6 rename (like in 1.2 above) MC acted like it moved the file but then showed the red "(-)" warning.
The show title was "Bigger than T. Rex". The on-disk filename was something like :
NOVA - Bigger than T.Rex.ts
NOVA - Bigger than T.Rex_ts_sidecar
The recording was not in progress. Moving the file from within MC changed the path in MC's view but the file actually remained in its original location. I imagine this is why MC showed the warning.
I guessed that the problem was related to the period in the filename. From within MC, I changed the filename back to the original location, renamed the file to remove the period, and then could successfully move the file to a new directory.
If the whole "period" thing wasn't a red herring, I imagine either MC should handle the period or, as with some other title characters, replace it with an underscore.
I hope this is useful.
-
I see a different instance of what is probably the same problem as #1 occasionally. I haven't had time to collect enough data to report it though.
I brief, what I see is that when I use "Filename (path)" when tagging on a Recording Rule, I can get a message saying a directory doesn't exist, and that directory is incorrect for the rule. In fact, it seems to be pointed at the Windows System directory, which my recordings certainly never go to! I Skip the file to close the message, and typically get three messages per recording. The result is that three file components of a JTV format recording aren't moved, and the recording is broken and unplayable.
While I haven't collected definitive data, the cause seems to be that the files involved are still in use by MC, and hence locked, so tagging using "Filename (path)" at the end of the recording fails, and the files aren't moved. I think I have seen this happen at the beginning of the recording as well, but I have yet to confirm that.
I suspect that problem #2 is just another variation of problem #1.
The MC F6 (Rename, Move and Copy Files) function can handle a "." in a filename without any problem. For example, I have recordings of "Marvel's Agents of S.H.I.E.L.D" which can be moved without issue. I just tested moving a recording to a new location and back again, and it worked fine. I was moving a JTV format recording, but a TS format recording should also move properly. The red (-) to the left of a file just shows that MC can't find a file in the location that it thinks it is in. Basically a "file not found" indicator. If you had Auto Import turned on and MC set to fix broken links, MC would have removed that entry at some time and then re-imported the actual file from the original location again.
I have certainly noticed that MC just doesn't release files sometimes, leaving then locked. But the issue is so random that I can't reproduce it reliably.
PS: I tried to attach images to illustrate my example above, but I see we still can't attached images due to the recent security breach still being investigated and fixed. Never mind, the above should be clear enough.