INTERACT FORUM
More => Old Versions => JRiver Media Center 20 for Windows => Topic started by: Matt on November 10, 2014, 09:54:16 am
-
We recently changed how CUE files are handled so that we can nicely handle CUE files that point to multiple files.
This had the unfortunate side effect that CUE files will be reimported, because the filename changed.
After reimport, new files will have a ;1, ;2, etc. after the filename. The old files without the trailing number should be removed.
Just search for "cue" and remove the files from the library. Then run the import again on your CUE directory.
Sorry for any trouble this causes.
-
We recently changed how CUE files are handled so that we can nicely handle CUE files that point to multiple files.
This had the unfortunate side effect that CUE files will be reimported, because the filename changed.
After reimport, new files will have a ;1, ;2, etc. after the filename. The old files without the trailing number should be removed.
Just search for "cue" and remove the files from the library. Then run the import again on your CUE directory.
Sorry for any trouble this causes.
Hi, can you please elaborate (for those of us who aren't as well-versed in cue file usage and management)? Or point to a good resource?
How did the filename change? Does MC actually rename a filename?
What filename are you writing about? song filenames? cue files?
What does the ;1, etc. denote and why should the old files be removed?
Are you saying we should manually remove all *.cue files?
There is a lot not clear to me, and the wiki entry for cue files doesn't really help. As I mentioned, if there is a recommended link that would be quite helpful.
-
How did the filename change? Does MC actually rename a filename?
We don't rename the file. It's just that the filename we keep in the database has changed.
It used to be:
C:\1.cue
C:\1.cue
C:\1.cue
And now it's:
C:\1.cue;1
C:\1.cue;2
C:\1.cue;3
What does the ;1, etc. denote and why should the old files be removed?
It's the track number and the counter is necessary so each entry has a new filename.
Are you saying we should manually remove all *.cue files?
Yes, if they don't have the number at the end of the filename.
-
We don't rename the file. It's just that the filename we keep in the database has changed.
It used to be:
C:\1.cue
C:\1.cue
C:\1.cue
And now it's:
C:\1.cue;1
C:\1.cue;2
C:\1.cue;3
I don't have any file in my library that was ".cue" they imported with ".flac" previously, and now ".flac;1" etc.
While people will certainly want the new cue file handling for new imports, I think anyone that has been using MC until now will want to use their previous files which are properly tagged, while the new cue imports are likely not. Easier to remove the new duplicates than disrupt a working system.
-
While people will certainly want the new cue file handling for new imports, I think anyone that has been using MC until now will want to use their previous files which are properly tagged, while the new cue imports are likely not. Easier to remove the new duplicates than disrupt a working system.
Please remove the old entries. Keeping them will lead to trouble.
-
Hi what is happening with CUE files , I upgraded to build 37 this morning now my library has literally thousands of empty entries.
I have folders where the CUE text file still exists but the individual files have been split out using CUE Tools etc. It was the way I preferred it at one stage.
Where I have this when I select an album and look at files , I have the split out files and a whole set of blanks , no <Name. no <File Path> just blank entries.
Now what do I do , if I play the album I get music , blank , music and so on
My whole library is trashed or so it seems . There looks like a lot of work to put it back straight.
What do I delete the Text CUE files or what , I am nervous not to delete the wrong thing.
Mike
-
Please read the thread, starting at the top. You should find what you need there.
-
I am still not clear , I have a duplicate of virtually every file in my library with no Name field and no Path field , just blank. in File View I see about 120k files which is around double what is actually there./
JRemote shows almost any album with Track1, a blank line , track2 , blank line etc.
Are you suggesting that I physically remove all *.CUE files form my Hard Drive and re run auto import ?
The above does not fit what I see. I have an example folder with no CUE file , but it too has been duplicated with no Name or Path.
They are easy to sort out and delete BUT where did they come from. The Date Imported is this morning shortly after I upgraded.
I think maybe some detailed step by step guide as to how to sort out the mess. At the moment my library is a complete mess of empty entries.
Is this the same issue or am I missing something ??
Mike
-
Try Matt's instructions.
-
Are you suggesting that I physically remove all *.CUE files form my Hard Drive and re run auto import ?
Removing the cue files from your drive won't do anything once they have been imported.
Matt's suggestion was not applicable to my library, since I don't have a single .cue file listed in my library, it's all .flac;1 or similar.
I just did a test, and while it's not mentioned in the changelogs, it seems that cue files which have been removed are no longer being re-imported every time auto-import runs.
So you have a number of options:
1. Filter out the newly imported cue files using a smartlist (http://yabb.jriver.com/interact/index.php?topic=93148.msg642234#msg642234), and then delete them. As of build 37, it seems like this will now work.
2. Restore a previous library backup before the cue files were imported, and disable cue files in your auto-import config.
This will prevent you using cue files in the future though, since everything would be re-imported again if you were to re-enable the option.
There should be a checkbox when restoring a backup to disable auto-import temporarily, so that you can adjust the auto-import config before it runs again and re-imports all your cue files.
3. Delete the cue files from your drive, and restore a previous backup prior to the cue files being imported. Now the duplicates are gone and the cue files no longer exist.
4. Put up with the disruption to your library, use the cue files instead of the tracks, and delete your original files, discarding any and all changes you have made to them. (ratings, date imported, updated tags etc.) This is the JRiver recommended method.
The above does not fit what I see. I have an example folder with no CUE file , but it too has been duplicated with no Name or Path.
Do your tracks have embedded cue files?
-
Hi
Yes I see what you're doing , for now I have reverted to an old version and restored a BU but I think I still have some xxxxx;2 type files.
I do have some folders with split tracks and a text CUE file and some with even the Big CUE file so I must have some CUE or APE file which are a whole album those obviously I shouldn't delete
From Matt's comment its the OLD files we need to delete not the newly created ones , its sounds like the new way is with thee semi colon; number format
Matt please confirm
I think we need Matt to give us the definitive way of clearing the mess. I think I am going to lose any enormous amount of "Tag Maintenance" by this .
I seem to have done nothing else all week but sort out my Library( Wifey quote !!). Good job I'm retired !!
A bit of warning of the fall out from this may have helped
Isn't everybody having this grief , it only seems like a few commenting
Cheers
Mike
-
I went crazy all day yesterday sorting out my libray. I stumbled on the link referenced in solution 1
1. Filter out the newly imported cue files using a smartlist (http://yabb.jriver.com/interact/index.php?topic=93148.msg642234#msg642234), and then delete them. As of build 37, it seems like this will now work.
My library is now back to normal. I also unchecked the cue file option in auto import.
Thank You!
-
Isn't everybody having this grief , it only seems like a few commenting
I think it depends on a lot of factors.
I haven't ripped anything as FLAC+CUE for a long time, it's only my very oldest rips when that was the only way to get gapless playback which are like that. And most of those have since been split into individual files.
I suspect most people won't have been ripping to FLAC+CUE for a long time either. Most apps rip to individual tracks by default.
Only certain types of cue file are affected, I believe, not all of them.
Not everyone is always up to date right away, and not everyone visits the forums.
I agree that features like this which are potentially going to make very destructive changes to the library should have safeguards in place to undo their changes.
I went crazy all day yesterday sorting out my libray. I stumbled on the link referenced in solution 1
My library is now back to normal. I also unchecked the cue file option in auto import.
Thank You!
You're welcome. I'm glad that helped.
-
I think we need Matt to give us the definitive way of clearing the mess.
Pick all your old CUE files and remove them from the library. Then import the CUE files again.
Structurally you want to remove any entry that doesn't have a semi-colon and number in the filename. The new entries all will have the semi-colon and number.
-
Chiming in here again...
I have spent far too much time cleaning up my library this week, after spending a lot of time getting it to the state I wanted it in. I reverted MC back a few versions and restored an old lib backup. Then had to go through the whole lib to clean it up and kept finding really weird issues, some even related to cover art that would not "stick", despite being in my library. (Finally, had to grab an image from the internet and use that instead).
I think for Jim and Matt the instructions and situation are very obvious and clear, but it is not necessarily for those of us who are not intimately involved with the inner workings of MC and how it might handle all the variations in files.
I don't believe the Matt's instructions have covered the situation of .cue files + individual tracks. Or maybe they have - I don't really know.
Plus, I am fairly sure that once I do upgrade to the next stable version, my library will be hosed again, because of these cue files and how they are handled.
Also, please consider that if someone keeps asking the question, then the previous response was likely not clear to them (even though it might be extremely clear to the person providing the answer). Often times, the answer needs to be rephrased or made more explicit.
Thank you.
-
Well, I have spent several days sorting out my library. I had many FLAC+CUE files which I have now split and re-imported, losing all of my personalised tagging in the process, of course. I now have now removed all CUE files from my library.
Could I politely request that next time you implement such a destructive improvement, you give us prior warning?
There should be a checkbox when restoring a backup to disable auto-import temporarily, so that you can adjust the auto-import config before it runs again and re-imports all your cue files.
+1
-
Thanks everyone , It seems I have a way forward but at what cost , if I follow Matt's way I will lose all the personalised tagging I have worked so hard to create and maintain.
If I delete the newly created xxx;2 files etc with a Smartlist , as per 6622638 then I lose the ability to use CUE files ever again, if I reactivate CUE files in Auto Import it will happen all over again I assume.
Its the proverbial rock and a hard place , I suppose I bite the bullet and re do the tagging JUST to stay standard and to avoid any addition issues going forward, and to maintain the ability to use single file CUE Files.
My vote is this change was not a smart one , no matter how good the new feature is , it certainly seems to have created a lot of work for me. Ultimately I suspect that I will split all my CUES and get around it that way.
I suspect using single file CUEs is not common or the outcry would have been a lot more vigorous. What is seen as best practice , a single file or a split file into tracks. MC manages the gapless playback fine so either works for me. But a lot of my music came in as single files and it saves effort to keep it that way.
Mike
-
Just search for "cue" and remove the files from the library. Then run the import again on your CUE directory.
I don't get this, if I remove them everything will only look fine until the next import. Sure I can disable importing cue files, but is that how we are supposed to handle this?
-
If I delete the newly created xxx;2 files etc with a Smartlist , as per 6622638 then I lose the ability to use CUE files ever again, if I reactivate CUE files in Auto Import it will happen all over again I assume.
If you simply remove the newly imported cue files (file.ext;1) they don't appear to be getting re-imported any more.
This means that you can continue to have cue files enabled in auto-import, and only new cue files should be imported from now on, rather than re-importing all your existing cue files.
I don't get this, if I remove them everything will only look fine until the next import. Sure I can disable importing cue files, but is that how we are supposed to handle this?
Build 37 seems to have fixed the issue with the cue files being re-imported after removal from the library now.
-
If you simply remove the newly imported cue files (file.ext;1) they don't appear to be getting re-imported any more.
This means that you can continue to have cue files enabled in auto-import, and only new cue files should be imported from now on, rather than re-importing all your existing cue files.
Build 37 seems to have fixed the issue with the cue files being re-imported after removal from the library now.
This doesn't work for me, I have updated to version 20.0.37, deleted the cue files. And then when I import the duplicates re-appear.
-
This doesn't work for me, I have updated to version 20.0.37, deleted the cue files. And then when I import the duplicates re-appear.
Strange. That was happening for me in build 35, but in build 37 once they're removed they stay gone.
It wasn't on the changelist though, so I'm not sure why that is.
-
I really think there should be an option to use oldschool import handling. I´ve got a library of maybe 3000 albums of which maybe 1000 - 1500 now have double entries.
The Album covers Genre and Year and even name of the Album (I hate the Japanese Edition YOI21345 album number etc) have been fixed for maybe a third of the albums.
If I would start to manually fix this I think it take about a month.
I sure could mount the drive and run a Ren x:\Music\*.cue *.ufo but that would´t be a good solution.
I split flac files with Medieval Cue splitter.
-
If I would start to manually fix this I think it take about a month.
I sure could mount the drive and run a Ren x:\Music\*.cue *.ufo but that would´t be a good solution.
When I first switched to JRiver MC, I had to do that rename.
The cue file support was broken for years. There are a number of threads in each version's Forum asking for the sort of rewrite that was finally done recently.
-
Hi I am affected by this issue, however I could not follow Matt fix.
Step "search for cue" does not work.
I have duplicate of the form
track1.flac
track1.flac;1
track2.flac
track2.flac;2
track3.flac
track3.flac;3
on about a hundred of album.
And those duplicate are not flagged by keyword "cue".
To explain a bit better the situation, the cue where not there to actively split a large image into tracks.
They where there for archival purpose, the same way I keep the extraction log.
In some other case they used to split an image file, but the image has been splitted into track using your format conversion tool.
Is there a way i can clean those duplicate ?
-
I worked for weeks writing my tags; thank you very much for destroing my library. :'(
-
Reload a backup. MC makes them automatically. File/Library/Restore.
-
Reload a backup. MC makes them automatically. File/Library/Restore.
Of Course:
downgraded to 20.0.27, restored the library and disabled automatic update.
Please understand that manually retagging hundreds of flac+cue files is not an option.
-
Re-read the first post carefully. You should be able to correct the problem.
-
Yessir, I did read very carefully and while English is not my mother Language I understood perfectly the instructions in the first post.
The problem is not cancelling the old files, but that this way I'd have to edit again the tags of the new files.
-
I don't think so.
-
Unfortunately you are wrong. :(
(http://www.marcobenedetti.it/Audio/JRiverTEst.jpg)
-
Unfortunately you are wrong. :(
You're right, I also tried to reimport my CUE-Files. But all tagging infos are lost then; even using "Update Tags (from Library)" before deleting the old CUE Files doesn't help. But I thought this is as it should work?! Wasn't Matt stating somewhere that all the Tag-Infos will be lost if they are not stored in the CUE-File itself? Or did i miss a chance to have MC write/correct CUE Files? That would of course do the trick!
edit 2014/24/11:
I found Matts statement. He was replying to Hoyt's reply:
I understand that will fix the issue. See my point about MC20.31 invalidating my library that worked previously. I don't think a proper solution is to redo everything. I think a proper solution is for MC to honor the existing library first, then worry about other functions, like the way cue files are managed. That should not trump existing libraries.
With this:
I'm sorry for the inconvenience. If it's any consolation, it's a one-time thing.
For me this sounds as if everything has to be tagged again. But only once ;) Luck is on my side: I only have to redo Name and Artist for 1000 files :o Every file has a different artists because those files are part of Non-Stop Mixes. Sadly nothing is stored in the CUEs :(
-
I have just run a windows search of all my cue files 14,579 of them and you think it is feasable to check which ones are being reimported and to save the ones that are needed for image files and many more circumstances that mc will not support. I cannot believe that I am alone having this problem. I do have more thing to do than to restore my mc system disruption " even if possible" created by an update.
-
For now I disabled importing of cue files completely, it was the only way for me to get rid of the duplicates. As I have all my albums stored as separate FLAC files and a cue file for archival purposes. I would have hoped that the cue file would basically be ignored if you had separate FLAC's containing embedded tags.
But the more I'm reading this thread, the more confused I get. Am I understanding this correctly, that Media Center will now put priority in reading tags from the Cue instead of the embedded tags in FLAC?. Will it even make changes to the cue files, if you edit some tags in MC? (I hope not, as I want the cue files to stay original for archival purposes. As I often use custom more personalized genres etc.. in the tags embedded in FLAC's).
-
Just to state the instructions one more time:
Delete any CUE files from your library. Then reimport. The new files will have a semicolon and number in the filename.
You'll have to reset the tags if you've customized your CUE files. I'm sorry.
-
Quote from: 6233638 on November 11, 2014, 09:05:50 am
While people will certainly want the new cue file handling for new imports, I think anyone that has been using MC until now will want to use their previous files which are properly tagged, while the new cue imports are likely not. Easier to remove the new duplicates than disrupt a working system.
Please remove the old entries. Keeping them will lead to trouble.
Dear Matt,
can you please be more specific about the troubles involved with keeping the old files and deleting the new ones?
On my side, following your instructions I'd lost my custom tags for hundreds of disks, but I have a life ;) : I will not re-tag.
Deleting the new files, (after isolating them in a smartlist, as suggested by 6233638), could be an acceptable solutions, if the troubles involved are not so serious; anyway it's a better solution than stopping updating JRiver.
-
Dear Matt,
can you please be more specific about the troubles involved with keeping the old files and deleting the new ones?
On my side, following your instructions I'd lost my custom tags for hundreds of disks, but I have a life ;) : I will not re-tag.
Deleting the new files, (after isolating them in a smartlist, as suggested by 6233638), could be an acceptable solutions, if the troubles involved are not so serious; anyway it's a better solution than stopping updating JRiver.
You want to delete the old records. It's important that the new records be the ones in the library or else you'll have all sorts of trouble.
-
Just to state the instructions one more time:
Delete any CUE files from your library. Then reimport. The new files will have a semicolon and number in the filename.
You'll have to reset the tags if you've customized your CUE files. I'm sorry.
Hmm, I have deleted the cue files (using the smartlist as suggested above), and then re-imported. But the duplicates are still re-appearing, currently running MC 20.0.41.
One curious thing is that even though I have approx 500 albums with cue files, the duplicates only appear for 14 of the albums. Could this be some kind of bug, because why does this keep happening with just those albums?.
-
Here is what is needed:
The ability to save tags (file properties) for CUE files and single-FLAC file combinations to a SIDECAR file.
Then the user can re-import using the new corrected CUE file support.
Then the user can move the tags (file properties) from the SIDECAR file into JRiver MC20.
If someone at JRiver can spend a little time creating a utility to do this, it would save thousands of hours for JRiver customers in total (not an exaggeration - note the number of threads on this, and remember only 10% of people post about problems they have).
-
Here is what is needed:
The ability to save tags (file properties) for CUE files and single-FLAC file combinations to a SIDECAR file.
Then the user can re-import using the new corrected CUE file support.
Then the user can move the tags (file properties) from the SIDECAR file into JRiver MC20.
If someone at JRiver can spend a little time creating a utility to do this, it would save thousands of hours for JRiver customers in total (not an exaggeration - note the number of threads on this, and remember only 10% of people post about problems they have).
This seems like a good solution, but I would like to add a comment:
This was a breaking change. It seems like it was probably made for a really good reason, but to implement it without a way to migrate, preserve users work, and maintain library integrity was not a good user experience, by any means.
I have not seen the problem or the intended solution documented very well. I see 4 use cases, and I don't know what the intent of the latest fix has been on these four:
UC1: One large flac file w/a cue file indexing the tracks contained inside the large cue file
UC2: More than one large flac file (e.g., one for each side of a vinyl rip) with a single cue file indexing the tracks contained inside the files.
UC3: One large Flac file + indiv. song flacs + the cue file that indexes the large flac file
UC4: Indiv song flacs + a cue file.
I suppose there is another permutation or two lurking there, but I think the idea is clear. I have seen all the above Use Cases discussed and actually think they all apply to me, but I haven't seen an explanation of what the latest fix is meant to address.
A solid, detailed entry in the wiki is likely warranted for this. There are many threads with information scattered about. Recently there was a request for quick hits (or something like that). I think this is a solid contender. I would certainly roll back MC, restore a library backup and then upgrade to the latest build if I knew:
1) the migration was handled properly, and
2) there was a clear explanation as to how the change impacted the above scenarios so I knew what I might need to do going forward.
Thanks.
-
I have not seen the problem or the intended solution documented very well. I see 4 use cases, and I don't know what the intent of the latest fix has been on these four:
UC1: One large flac file w/a cue file indexing the tracks contained inside the large cue file
UC2: More than one large flac file (e.g., one for each side of a vinyl rip) with a single cue file indexing the tracks contained inside the files.
UC3: One large Flac file + indiv. song flacs + the cue file that indexes the large flac file
UC4: Indiv song flacs + a cue file.
I think that list itself is a good argument against using CUE files at all.
Matt described what to do in the first post. At least some of the confusion is coming from people who don't want to do what he suggested there.
-
I think that list itself is a good argument against using CUE files at all.
Matt described what to do in the first post. At least some of the confusion is coming from people who don't want to do what he suggested there.
Jim, respectfully, I disagree. People don't want to lose the time they spent on organizing their libraries. That's why I think KStuarts suggestion is a really good one.
And what you assume is people not wanting to follow Matt's advice, can also be attributed, in some cases, to not understanding how the change impacts the use cases I listed above.
-
Just search for "cue" and remove the files from the library. Then run the import again on your CUE directory.
I did this but the search only returned about 6 results. I think I have close to a hundred albums showing duplicates, and not all of them have cue files in their folders.
Is there any way to turn back everything to as it was before the update and then wait it out for a fix?
Thanks!
-
Matt described what to do in the first post. At least some of the confusion is coming from people who don't want to do what he suggested there.
I have gone back and carefully followed Matt's instructions mentioned in the first post. Again.
It doesn't work. And I think its pretty clear it is not working for a lot of other people.
cue files are removed. Directory is reimported. I don't have any cue files with a ;1, etc.
I still have duplicate entries of songs.
I (and many others) would appreciate clarity and a fix.
Again, Matt's instructions may work for one of the use cases I mentioned above, but it is not working for a lot of people and causing a lot of thrash. Whether one thinks the existence of those use cases are an argument for the elimination of cue files is besides the point. Your customers have them and it is causing problems.
The guidance so far has not worked for a lot of people as evidenced by the number of threads and comments since the change.
-
Is there any way to turn back everything to as it was before the update and then wait it out for a fix?
File > Library > Restore. MC makes automatic backups.
-
Hi
My 2 penneth
In my library the main problem lies where there is an album folder with individual track flac files AND a CUE file (realistically redundant, I understand from EAC ?) , then I get duplicates. It would seem a big flac file and Cue index file doesn't cause trouble , although I have been too busy to dig that deep yet.
Matt's comment was to remove the old files and leave the xxx;1 etc files as the new format or the old ones will cause trouble going forward.
Following 6233638 advice (and script) using a smart list isolates the new ones for easy deletion (I believe ?) and leaves the old ones so that doesn't strictly follow Matt's requirements
So I have laboriously done the following
Go to each folder on the HDD and remove any CUE , TXT or Accurip files , or any other extraneous files.
Leaving Just the individual track flac files and a jpeg Folder file
Then in MC find the album and sort by [Date Imported] ASC . This gives the new xxx;1, xxx;2 files separated out at the bottom . I then delete the older duplicate flac files JUST from the library , i.e. the top option on the delete dialogue.
Now when I run Auto Import it looks like the duplicates are fixed.
I may add in a library of my size this is an absolute pain in the ...
Also as the sting in the tail , any customisation or corrections to tags are lost , so for example if a album is originally DG in German , then the Symphonien comes back and I lose my previous correction to Symphony etc . The trouble of tagging filkes to make the library look pretty is no small undertaking
Without exaggeration I must have spent 24 hours at the keyboard fixing this in the last few weeks, I am not amused.
Ultimately I am going to follow Arindelle's advice in "Why CUE Anyway?" today and split all my Big Flac & CUE into tracks and get rid of the cue files altogether -- yet more work ...
I am just a mug who misunderstands or is there a more automatic way to achieve what I been doing manually.
To add insult to injury , my Library is on my Media PC connected by Wi Fi around the house. If I make corrections on my main computer remotely on a "linked" library and then sync with the main library the changes are not made -- I found out the hard way as ever..... For example deleting files remotely does not reflect after syncing in the main library, some Tag changes do but not all . I am confused as to why ....
So I have to sit at the Media PC and make the corrections directly. Any ideas on this one ??
Mike
-
I think that list itself is a good argument against using CUE files at all.
That's like a technical support rep saying:
" I think that is a good argument against using Windows. Buy a Mac and change to our Mac version."
::)
-
In my library the main problem lies where there is an album folder with individual track flac files AND a CUE file (realistically redundant, I understand from EAC ?) , then I get duplicates.
Yes this is exactly my problem too, for an Albums stored as CUE+Separate FLAC files. MC now imports the FLAC files AND the CUE file, causing the duplicates.
JRiver should change the import behavior to ignore the CUE files in these situations. The cue file is really only usable for albums stores as CUE+one single large file.
-
I've hesitated adding something up to now.
I want to ask people with problems a question. [people that have individual files by track +cues]
Are your fields written to disk in the file itself or not? Meaning embedded in each flac file?
In options Library&Folders=>Manage Library Fields, are all of your important tags set to "Save in file tags when possible" Most custom fields and standard fields can be embedded in the files. Not only do you have a triple backup of the metadata this way, but you also would have, I believe for many of you, an easy way to not lose any of your tags during these upgrades. Now I may be wrong as I can't test this (or maybe I could ...), but it is worth doing regardless.
If you haven't done that with all the fields that are important to you, you can do it now. Please note that any new fields marked to write to the file will NOT be written to the file until the next time that file is modified. So you would have to copy the tags from the library to the file through library tools to be sure.
So, if one goes and restores a backup with all their tags intact before the problem came into play, make sure that the tags do indeed exist on the files .
Then you have choices! if you
- Proceed to just upgrading and keeping the cues, you can select everything and write back the tags from the files now to the library. Delete duplicates is fast.
- Or you can remove thre tracks from the library and reimport everything - all the embedded information (other than certain fields like playback stats, date imported) would remain intact.
- OR (which I would probably do personally) remove the cue files, embed any missing tags to the files, and simply upgrade. (at least for the FLAC file folders) Set the options to not import cue files in autoimport also might be a good idea. (make sure the embedded tags are now in the library
Some people may actually need the cue files however, so the first two might be better for them.
Regardless, always always have multiple backups of both the JRiver library and the physical files when you do massive changes like this (not meaning to be patronizing again, but some people might not do this)
The other post Why Cue files? has indicated a couple of reasons why cue files are still viable and needed for playback and organization/control: SACDs ripped to ISO files would be an example; people that have older DLNA devices that can't handle gapless playback might be another. Otherwise I can't see why they should be imported to the library for FLAC files, even for wav files. There might be a reason to keep them in the folder however (burning, splitting etc.)
Maybe this will help? If anyone sees any problems or omission with my logic, please post back.
Ultimately I am going to follow Arindelle's advice in "Why CUE Anyway?" today and split all my Big Flac & CUE into tracks and get rid of the cue files altogether -- yet more work ...
Just to clarify a bit. That post was actually to confirm what I thought I knew about cue files was actually still the case as I have not used them for over five years - I'm very reluctant to offer advice of people keeping their cue files or not - there could be reasons, but I think for the majority of people, its just because they started ripping that way and don't want to change or that people just didn't know any better. No judgements to be inferred, no patronizing from me. Not everyone wants to "geek" like some of us, after all. The only thing I'm pretty convinced about is that cues have no use for playback and organization of tag information for individual flac files.
If I had one big flac or wav file I would definitely split them whether or not there was an issue with cue files -- FLAC is the best container for metadata ...... but that is my opinion ;)
I am just a mug who misunderstands or is there a more automatic way to achieve what I been doing manually.
To add insult to injury , my Library is on my Media PC connected by Wi Fi around the house. If I make corrections on my main computer remotely on a "linked" library and then sync with the main library the changes are not made -- I found out the hard way as ever..... For example deleting files remotely does not reflect after syncing in the main library, some Tag changes do but not all . I am confused as to why ....
So I have to sit at the Media PC and make the corrections directly. Any ideas on this one ??
Hey Mike! I can think of ways that would make this reasonably painless for you, maybe you want to post the last paragraph in another thread. Otherwise we go way off topic. You can find all files without going into each folder either through windows explorer search or temporarily importing them as data into JRiver. CTRL+DEL ;) You can google+download "Teamviewer" and access your server from the client . Very simple to set up and free. Pretty busy through the weekend though, its gobble, gobble time :)
-
Could someone please explain why many of my albums have "xxxxxxx.flac;1"?
I understand it's something to do with the cue files (which I have in case I ever wish to burn back to CD for any reason) but I have over 54,000 files in my collection which I've painstakingly tagged correctly and now many of them have these duplicates.
SOME of my albums use the .cue file - where I have one long track, it's great to have the option to 'skip tracks' so I do use them for this occasionally.
What do I need to do (not that I really have time to reconfigure everything I'd already configured...) in order to remove these dupes? Let's assume I DON'T want to delete the cue files or move them out into separate folders...
-
Funkmeister, please read the first couple posts by me. It explains.
-
Matt, the issue is that it's found additional tracks I don't want. How can I remove the ones with ;1 after them? I do not want the cues for those imported, I want the original files.
-
Matt, the issue is that it's found additional tracks I don't want. How can I remove the ones with ;1 after them? I do not want the cues for those imported, I want the original files.
Normally you want the tracks with the ;1. They're the new and correct records. But if you don't want some that are imported, just delete them from the library.
-
Normally you want the tracks with the ;1. They're the new and correct records. But if you don't want some that are imported, just delete them from the library.
Perhaps I've not explained clearly enough...
I've imported flacs. Very happy. There is a cue file in the folder which, until now, had been ignored. Now I have all the original flacs AND the 'new' flacs imported from the cue file (which are, I'm guessing, the new ones appended ;1?). So now most of my albums have each track twice - the original flac and the 'cue-flac' (which links to the original flac...which was already imported).
How do I set JRiver to ignore cue files? I've disabled auto-import as I can't have it mucking around with my albums in this manner... You say 'just delete them from the library' but I have fifty-four thousand tracks in JRiver. Going through each album one-by-one and deleting the new dupes one at a time will take an incredible amount of time.
-
Normally you want the tracks with the ;1. They're the new and correct records. But if you don't want some that are imported, just delete them from the library.
For people with pre-existing libraries, they are almost certainly incorrect records, since the CUE file will not have any of the tagging changes or playback statistics that the file it's pointing at has.
It could be years out of date at this point.
-
Perhaps I've not explained clearly enough...
I've imported flacs. Very happy. There is a cue file in the folder which, until now, had been ignored. Now I have all the original flacs AND the 'new' flacs imported from the cue file (which are, I'm guessing, the new ones appended ;1?). So now most of my albums have each track twice - the original flac and the 'cue-flac' (which links to the original flac...which was already imported).
How do I set JRiver to ignore cue files? I've disabled auto-import as I can't have it mucking around with my albums in this manner... You say 'just delete them from the library' but I have fifty-four thousand tracks in JRiver. Going through each album one-by-one and deleting the new dupes one at a time will take an incredible amount of time.
If all your cue files are non functional for your collection, meaning you have separated the individual files within the cue.
Then all you need to do is delete all the cue files permanently from your hard drive. Use Drives & Devices/Explorer in JRiver to open all your files at one time, go to the cue extension files, highlight and delete. Done
-
Ok here's something I have tried.
1) Create a smartlist for duplicate of disc#, track# & base folder.
[Media Type]=[Audio] ~dup=[Disc #],[Filename /(path/)],[Track #] ~sort=[Album],[Track #],[Disc #],[Name],[Media Type],[Album Artist (auto)]
2) Remove from library
3) Re import
Result:
JRiver MC re imported both individual flac & cue file.
Duplicate of the form track1.flac, track1.flac;1 are back again.
Because it is not a one time inconvenience (as suggested by first post) but a persistent behavior, I have to conclude cue file import is broken for my use case (UC4 in the use case list)
for now disabling cue file import and doing above 3 step do the trick, but the import of cue probably still need to be smarter.
-
We recently changed how CUE files are handled so that we can nicely handle CUE files that point to multiple files.
This had the unfortunate side effect that CUE files will be reimported, because the filename changed.
After reimport, new files will have a ;1, ;2, etc. after the filename. The old files without the trailing number should be removed.
Just search for "cue" and remove the files from the library. Then run the import again on your CUE directory.
This is not helping me. I need to know how to find these cue files that I seem to need to delete without deleting the cue files that I do need. I don’t know what kind of library you have but mine does not seem to be the same.
Turning off cue file import is not a solution.
I have written in many of the threads what my problem is and what is not helping. Please solve this problem.
-
Ok, after a week of not being able to look at this I have now and I think I have my head around what was changed.
So if I may I will describe in terms I understand and hopefully gain some confirmation (so that I can clean up my MC libary once and for all).
- Up to a recent MC build MC did not handle cue files correctly, particularly cue files that pointed to multiple external tracks on a drive/folder (or multiple tracks inside a SACD etc).
- Recently MC (as of build xx) implemented correct CUE file support.
- This CUE file support involved creating (within the MC Library) pointers to individual tracks by appending a semicolon and a number in the MC library database. i.e. [filename.ext];1 or [filename.ext];2 etc.
- Importantly no changes are undertaken on the actual drive/folder level (i.e. out side MC) - the only changes that took place are within the Library Database of MC.
- Once the new build was installed by an end-user (either manually or automatically if enabled) then the auto-import function of MC will see the CUE files correctly and with the information contained in the CUE files will import into the MC library the relevant tracks the CUE files are pointing to.
- This will create duplicates of many tracks in the MC. This is because the old imports (when MC saw individual tracks) will be in the MC library and then the track info (from the CUE files) pointing to the same tracks will be duplicated in the MC Library.
- so far so good (or should that read so far so bad?). Hopefully someone can confirm that the above is correct?
- The most important consideration here is that nothing has changed to any files on the drive/folder - all changes have occurred within the MC library database and therefore all remedies as well needs to take place in the MC library database.
This is where I got confused and still am.
In Matt's remedy he says: "Just search for "cue" and remove the files from the library. Then run the import again on your CUE directory."
- Searching for "cue" in MC for me yields zero results. This would be my expectation given that my understanding that CUE files themselves are not imported, simply the track info contained within the cue files. for example 'track.flac' and then newly referenced in the library as 'track.flac;1'
- Certainly I'm seeing many duplicates and this is consistent with my understanding as above. e.g. 'track.flac' and 'track.flac;1' and sampling some of the dups there is a CUE file in the relevant album folder. I do not have a 'CUE directory' as suggested by Matt.
- However I have hundreds of such dups and there is no obvious way (so far as I can see) of creating a list (e.g smartlist) detailing those tracks that are duplicated in this way, and thereby of having a way of deleting the tracks (in the Library) that simply have only the old basename.
- The easiest (and most ruthless) way I can see is simply creating a fresh library and doing a full reimport.
- However I'm very reluctant to do this as I will lose all my 'recent imported' data which I rely on very much. In any event even I can delete the old referenced tracks my 'recent imported' view will be all wrong (i.e. it will not show my original import time, only the new one (via the cue file process).
- I assuming all my tags will still be fine as I generally embed them in the actual files (but not sure if other issues may arise on a full reimport).
Grateful if some kind kind soul could go through my ramblings above and give me feedback of any errors and what my next steps should be?
cheers
Edward
-
@elvisvcapice
A windows search for *.cue is fine if ALL your cue files are split to track.flac and the cue is redundant in ALL cases, I am sure most users have big flac single file and cue that they wish to keep that way I certainly have eg pink Floyd
Doing your suggested search select zap could do a lot of damage.
Matt says we should keep the sxxx.flac;x files , no one has suggested a quick way of keeping these files, only to delete these files.
I slog on manually trying to repair my library
Mike
-
I'm looking into these problems now and an automated way to fix them.
As I see the CUE support, there are basically three cases:
1) Every track/title in its own file. (The CUE sheet is practically redundant here.)
2) Every track/title in the same file, with a CUE sheet to properly identify the titles inside the one file.
3) Disc compilations, two (or more) audio files each representing an entire disc with *one* CUE sheet covering both files that splits it into tracks.
Possible a mixture of the cases may exist as well, but that seems a bit far-fetched to me.
From a quick analysis, the duplicate entries seem to only exist in case 1), while 2) works now as it worked before, and 3) was broken before but works now.
Can someone confirm this matches what they are seeing?
-
1) is what I have been seeing.
-
Hi Hendrik
You are dead right I have a mix of 1 and2
I have never seen 3 . Multiple disc, say box set, tend to be split into separate folders CD1 , etc and then follow either 1 or 2
My problems have been only on type 1, I am fixing by manually clearing the redundant cue file and then removing the dups from the library manually, this is quite a chore. I am preserving the xxxx.flac;1 files as Matt suggested
Mike
-
If I can fix the last problem in my code, the next build should manage to fix it automatically once you run a new import over the problem files.
The idea is as such:
(1) If both formats exist (with and without the ;1, usually because you were running a version of MC20 without the fix), delete the new format entry, and then go to (2)
(2) If the old format exists during import (without the ;1), take its data and adjust the filename to include the ;1
Of course, if you manually transitioned to the new format already and got rid of the old format, nothing will happen for you.
PS:
In step (1), nothing is actually deleted, the entries are moved to the "Removed" database and can be recovered if need be.
-
Hi Hendrik
You are dead right I have a mix of 1 and2
I have never seen 3 . Multiple disc, say box set, tend to be split into separate folders CD1 , etc and then follow either 1 or 2
My problems have been only on type 1, I am fixing by manually clearing the redundant cue file and then removing the dups from the library manually, this is quite a chore. I am preserving the xxxx.flac;1 files as Matt suggested
Mike
Mike why don't you just write the library to the tags on disk and remove the cues from the library (for number 1) that is painless and automatic. Painless, fast, future-proof. Restore to a "before" state. Library tools write tags from library. Remove or delete all cues; then reconfig autoimport not to reimport them if you choose to keep them. Run manual autoimport to make sure. Then upgrade to current version.
I just don't get it maybe ?! :-[
-
Note that deleting the CUE files after MC already imported the files is not something I can advise to do, at least not after the migration to the new format.
It might end up with duplicates again, or even worse, forget your old entries existed and do a fresh import of the plain audio files, and only read their tags, not any of your customizations, since it would try to go back to the "old" format without the cue token at the end of the filename, and then lose the association to the library entry.
-
If I can fix the last problem in my code, the next build should manage to fix it automatically once you run a new import over the problem files.
The idea is as such:
(1) If both formats exist (with and without the ;1, usually because you were running a version of MC20 without the fix), delete the new format entry, and then go to (2)
(2) If the old format exists during import (without the ;1), take its data and adjust the filename to include the ;1
Of course, if you manually transitioned to the new format already and got rid of the old format, nothing will happen for you.
PS:
In step (1), nothing is actually deleted, the entries are moved to the "Removed" database and can be recovered if need be.
May I ask why in case of (1, which is CUE pointing to individual track flac files) you would not choose to ignore the CUE and import/leave the files without the ;1? If both currently exist the CUE is redundant and leaving them in the library like that, will that not save changes to the tags only to the library because MC does not write to CUE files? If the CUE is ignored, the ;1 removed it will leave the FLAC files which support tagging and all that?
But maybe I misunderstand something which is why I ask.
Thanks for looking into it though!
-
@arindelle
Not too sure I understand. Tags on the flac file are a preset collection aren't they. If I create custom tags then these are"soft" in library files.
I can see it working for fixed tags but not custom which is where one of my headaches lie
Also deleting cue files from the HDR means knowing which are redundant as per case 1 above. I have mix of case 1 & 2' so mass deletion would lose stuff I don't want to lose.
Am I missing something.
Mike
-
@arindelle
Not too sure I understand. Tags on the flac file are a preset collection aren't they. If I create custom tags then these are"soft" in library files.
I can see it working for fixed tags but not custom which is where one of my headaches lie
Also deleting cue files from the HDR means knowing which are redundant as per case 1 above. I have mix of case 1 & 2' so mass deletion would lose stuff I don't want to lose.
Am I missing something.
Mike
I'm only referring to music files here.
No these fields are not preset per se. All custom tags I have created and that I choose to tag to disk with JRiver have been written to the file - there may be exceptions (calculation fields perhaps). There are certain Vorbis comment tags you have to leave alone and not use. http://xiph.org/vorbis/doc/v-comment.html (http://xiph.org/vorbis/doc/v-comment.html). There are also tags that are mapped in JRiver so to use them in other players might cause a "mapping issue". Most text string information in my experience is not affected. Eg. creation of a field "[Work]" for Classical music is definitely written to the file. I don't change data types for out of the box fields, I create new fields which "autopopulate" from standard fields all of the time though.
I would HIGHLY recommend to make sure ALL of your custom fields are being written to disk tha you want to save or are not be calculated from other fields already saved to disk. (check your options under Manage Library Fields; and do a test to make sure they are written to disk. I have found that some fields recently created will not be automatically written to older files unless they have been edited or played. So a sync via library tools -- Update tags from library might be required). Its funny, but a lot of people create complicated fields based on expressions and don't know about this little checkbox.
My tagging is worth more to me than the music itself in a way. Much more time to retag than to re-rip. I have a backup of my files, an archive safely stored of the backup drives; and separate backups of the JRiver library in all locations. Unless all 6 backups fail or get destroyed I will never lose either my tags. (for info - guys that are real "Smithsonian types" go a step further and rip to single file wav with a cue - which is never used for playback put away in a vault???. Then they rip to flac for tagging and playback .. thats a bit more than I need.
Note that deleting the CUE files after MC already imported the files is not something I can advise to do, at least not after the migration to the new format.
@Hendrick, is there something I missed ?
This is what I meant by restore to a "before state" (read before cue file handling was changed) With all the metadata in the files, their would be no loss of tagging info other than playback information and date imported (and fields not marked with write to disk when possible - which of course should be checked first, especially for custom fields as mentioned above).
The only reason I could think of not wanting to do this on individual tracks is reliance on DLNA renderers (older) that only play gapless via cue files? SACD handling is improved and I doubt that people have 90k SACDs. Not sure about wav containers, but they should hold as much information as cue files anyways.
-
If you've had problems, please try build 44 or above:
http://yabb.jriver.com/interact/index.php?topic=93840.0
Back up your library first from File/Library.
-
If you've had problems, please try build 44 or above:
http://yabb.jriver.com/interact/index.php?topic=93840.0
Back up your library first from File/Library.
Sweet! My albums (cue+separate FLAC files) now import fine without duplicates :)
-
Hello!
When problem with .cue file pointing to two .flac will be fixed?
Sample cue and result in JRiver
PERFORMER "ABBA"
TITLE "Arrival"
REM StigLarsson ZYX Airy3
FILE "Arrival A.flac" wave
TRACK 01 AUDIO
TITLE "When I Kissed The Teacher"
INDEX 01 00:00:00
TRACK 02 AUDIO
TITLE "Dancing Queen"
INDEX 01 03:02:09
TRACK 03 AUDIO
TITLE "My Love, My Life"
INDEX 01 06:54:13
TRACK 04 AUDIO
TITLE "Dum Dum Diddle"
INDEX 01 10:48:03
TRACK 05 AUDIO
TITLE "Knowing Me, Knowing You"
INDEX 01 13:42:13
FILE "Arrival B.flac" wave
TRACK 06 AUDIO
TITLE "Money, Money, Money"
INDEX 01 00:00:00
TRACK 07 AUDIO
TITLE "That's Me"
INDEX 01 03:06:14
TRACK 08 AUDIO
TITLE "Why Did It Have To Be Me"
INDEX 01 06:24:00
TRACK 09 AUDIO
TITLE "Tiger"
INDEX 01 09:46:06
TRACK 10 AUDIO
TITLE "Arrival"
INDEX 01 12:43:03
-
When problem with .cue file pointing to two .flac will be fixed?
It looks fine in that screenshot. It's pointing to two different files. What's the problem?
-
It looks fine in that screenshot. It's pointing to two different files. What's the problem?
I mark it with red.
-
With two .cue other problems, need to fix track number for second file with hands...
With Foobar2000 - all ok in both cases...
1.
PERFORMER "ABBA"
TITLE "Arrival"
REM StigLarsson ZYX Airy3
FILE "Arrival B.flac" wave
TRACK 06 AUDIO
TITLE "Money, Money, Money"
INDEX 01 00:00:00
TRACK 07 AUDIO
TITLE "That's Me"
INDEX 01 03:06:14
TRACK 08 AUDIO
TITLE "Why Did It Have To Be Me"
INDEX 01 06:24:00
TRACK 09 AUDIO
TITLE "Tiger"
INDEX 01 09:46:06
TRACK 10 AUDIO
TITLE "Arrival"
INDEX 01 12:43:03
2.
PERFORMER "ABBA"
TITLE "Arrival"
REM StigLarsson ZYX Airy3
FILE "Arrival A.flac" wave
TRACK 01 AUDIO
TITLE "When I Kissed The Teacher"
INDEX 01 00:00:00
TRACK 02 AUDIO
TITLE "Dancing Queen"
INDEX 01 03:02:09
TRACK 03 AUDIO
TITLE "My Love, My Life"
INDEX 01 06:54:13
TRACK 04 AUDIO
TITLE "Dum Dum Diddle"
INDEX 01 10:48:03
TRACK 05 AUDIO
TITLE "Knowing Me, Knowing You"
INDEX 01 13:42:13
-
@arindelle
Can I write to file retrospectively
I didn't realize you could , I ll check asap
Mike
-
What do you mean by "write to file restropectively"? What file?
You can restore your library from a backup. MC makes them automatically. File > Library > Restore.
-
Hello!
When problem with .cue file pointing to two .flac will be fixed?
Sample cue and result in JRiver
From Hendrik:
"Before 20.0.44, it used to create those because of bugs, but I fixed that.
Unfortunately, due to the nature of those bugs in the old code, not every problem in the library can be fixed automatically, sometimes the user needs to remove this one erroneous track if it doesn't clear up automatically when running an import."
So remove that track and I don't think it'll come back.
-
@arindelle
Can I write to file retrospectively
I didn't realize you could , I ll check asap
Mike
@Mike
if you mean can you write the tag info in the library to the file, retroactively sure (as long as the fields are marked to write to the file if possible). Select the files Right click=>Update Tags from Library. Retrospectively, I'm not sure ;D
Even if Matt and Hendrick fixed this .. I think it still might be a good idea for an additional backup to insure the tags are all written to disk anyway.
-
Well, I have spent several days sorting out my library. I had many FLAC+CUE files which I have now split and re-imported, losing all of my personalised tagging in the process, of course. I now have now removed all CUE files from my library.
Could I politely request that next time you implement such a destructive improvement, you give us prior warning?
+1
I have tens of thousands of FLACs to work through. I can't roll back to a previous library because I had just moved all my files to new external drives.
I can quickly search for *.cue files and remove them. But is there a way in JRiver to search for files ending in *.[ # ] to find the tens of thousands of duplicates this change created?
The problem is, when this first happened I didn't go to the forum and thought the dupes were my fault. I spent 3 days manically picking through each file. Then when auto-import ran again, they all came back.
-
If you update to 20.0.44, chances are good that it will fix a lot of it automatically.
We're sorry about the trouble this caused, and we reverted some behaviour so that changes are minimal, if present at all, but unfortunately we can't turn back the clock for those that were affected by this.
20.0.44 tries to mitigate the problem by automatically removing duplicates and trying to preserve the data, but it's not always easy to automate such a process.
-
You can also restore an older library backup. File > Library > Restore.
-
Thanks to all who worked on this. Much appreciated.
It is possible that I missed the announcement that these fixes were planned. Had I known I would have held off manually re-working my library, and (hopefully) saved a bunch of hours.
Was it announced somewhere that these fixes were in the works? If so, where, so I can check there in the future if the need arises?
Thanks again!
-
Me too however...
@arindelle
Looks like all the defaults were marked save to file. All my custom ones that are strings I have checked now, you were right calculated ones don't have the option.
I have now run update tags from library.
Looks like normality is returning
Thanks everybody for all the help, a pretty messy time for all
Mike
-
If you update to 20.0.44, chances are good that it will fix a lot of it automatically.
We're sorry about the trouble this caused, and we reverted some behaviour so that changes are minimal, if present at all, but unfortunately we can't turn back the clock for those that were affected by this.
20.0.44 tries to mitigate the problem by automatically removing duplicates and trying to preserve the data, but it's not always easy to automate such a process.
An awesome fix! I've found a few dupes remain, but looks like 20.0.44 got 99%. Thanks so much! I've put in many many hours removing dupes over the past couple of days, but I was facing a couple of weeks of more work (for a variety of reasons, rolling back to a previous version wouldn't work for me). So I am delighted!
-
thanks - thank you - thanks !! :D
Build 44 really fixed things up for me.
A quick restore from a backup and back in business.
I was fearing having to do a full reindex and losing all my stats (last played, favs, date imported etc).
Edward
-
thanks - thank you - thanks !! :D
Build 44 really fixed things up for me.
Thanks for letting us know.
Hendrik sure is a genius.
-
I tried to restore to get my recent albums back, but I have lost my playlists, so i restored the today's backup.
How to restore Recent Albums info, but not lost the recent playlists?
Antonio