Print

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

[sdmarquart]

Hello All. I "Analyze Audio" all of my files. For the most part, they are FLAC files stored on a NAS. I've noticed that sometimes after "analyzing" files it will create a duplicate of the file in the folder. It will have "(1)" in the file name. Not sure why this is happening. I have 2 separate MC21 libraries. After I analyze audio, I copy the files from the folder in NAS to another computer (on my network) with a different library and the duplicates show up. Then, I have to delete them.

This only started happening the last month or so and wanted to see if this is something anyone else has experienced??

Thanks,
Spence

[Vocalpoint]

Hello All. I "Analyze Audio" all of my files. For the most part, they are FLAC files stored on a NAS. I've noticed that sometimes after "analyzing" files it will create a duplicate of the file in the folder. It will have "(1)" in the file name. Not sure why this is happening. I have 2 separate MC21 libraries. After I analyze audio, I copy the files from the folder in NAS to another computer (on my network) with a different library and the duplicates show up. Then, I have to delete them.

This only started happening the last month or so and wanted to see if this is something anyone else has experienced??

I do not believe any file operations occur during Analyze Audio - except to have MC write it's analysis data to the file being examined. You may want address this to the dev team to get a better understanding of what this process actually does with the file. It may be creating a temp copy or something to do it's changes.

If it is creating dupes with (1)'s in the name - that is a symptom of a true dupe in a source folder. Happens to me as well occasionally - when I actually copy a file into a folder containing another file with the identical name. But in my case - it's always an actual copy routine that creates the dupes - not Analyze Audio.

So it's either a permissions issue where MC can't clean up after itself (if that is what it needs to do) during Analyze audio. Or one of your multiple MC libraries is looking at two locations at the same time and "sees" two copies of the same file. Or maybe you are copying the files to the same place with one of your copy routines.

VP

[sdmarquart]

I do not believe any file operations occur during Analyze Audio - except to have MC write it's analysis data to the file being examined. You may want address this to the dev team to get a better understanding of what this process actually does with the file. It may be creating a temp copy or something to do it's changes.

If it is creating dupes with (1)'s in the name - that is a symptom of a true dupe in a source folder. Happens to me as well occasionally - when I actually copy a file into a folder containing another file with the identical name. But in my case - it's always an actual copy routine that creates the dupes - not Analyze Audio.

So it's either a permissions issue where MC can't clean up after itself (if that is what it needs to do) during Analyze audio. Or one of your multiple MC libraries is looking at two locations at the same time and "sees" two copies of the same file. Or maybe you are copying the files to the same place with one of your copy routines.

VP

Thanks VP! I can definitely see while "analyzing" files a temp file with "(1)" at the end of the file being made. Sometimes it disappears and others it stays as another copy. Really no rhyme or reason to it except that it happens while "analyze audio" is occurring. It's not a huge deal since I just check folders after analyzing. I figured it was happening to others too?

Spence

[glynor]

I just tested analyzing a bunch of different file types, including MP4/M4A files, FLAC files, MP3 files, and even some multichannel OGM files. In no instance did MC create any temp files in the directory where the files were located.

It may have in MC's own temp storage, I didn't watch those locations, but definitely not alongside the files themselves.

[sdmarquart]

I just tested analyzing a bunch of different file types, including MP4/M4A files, FLAC files, MP3 files, and even some multichannel OGM files. In no instance did MC create any temp files in the directory where the files were located.

It may have in MC's own temp storage, I didn't watch those locations, but definitely not alongside the files themselves.

Thanks Glynor. I just added two new albums to my music folder. Dropped them into JRMC21. I always add cover art. While adding art, it made 4 copies of files in one of my folders. So, it seems to be related to adding art and not "analyzing". I have my settings to "embed" art in file. Maybe it's a cover art settings thing??

[Arindelle]

Not sure but you mentioned two libraries, right? If they are basically cloned libraries of the same media, with the same paths being watched, are you analyzing audio on import??. If so either uncheck the option on both and manually run analysis (better and faster in my opinion), or if you want analysis on auto, choose only one library (machine) to run it on autoimport. If by chance you are configged that way,  see if this takes care of it. If using one library in a client/server config this will not happen.  A friend of mine had this issue ... not sure about the cover art though.

[millst]

I've had this same problem of getting duplicates in my library. I, also, have my files stored on a NAS. This may not be your exact problem, but even if it's not, perhaps, this will help others. 

For me, I believe the key was to disable JRiver's automatic file scan. I think I also turned off the "Update for external changes" checkbox and turned on the "Ignore files previously removed from library" checkbox in auto import.

I think the root of the problem is that it takes a while for the network to come back up when my computer wakes up. JRiver was performing its auto scan and not finding the files since the mapping was broken. I still don't understand why it would add the same files as dups at a later time, but it's not happening anymore so I'm happy.

-tm