Print

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

[Matt]

Funkmeister, please read the first couple posts by me.  It explains.

[Funkmeister]

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]

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.

[Funkmeister]

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.

[6233638]

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.

[elviscaprice]

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

[Pho3NiX]

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.

[pluto7]

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.

[edwarduk]

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

[MikeO]

@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

[Hendrik]

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?

[InflatableMouse]

1) is what I have been seeing.

[MikeO]

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

[Hendrik]

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.

[Arindelle]

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

[Hendrik]

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.

[InflatableMouse]

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!

[MikeO]

@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]

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

[JimH]

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.

[Sesam]

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

[alex_st]

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

[Matt]

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?

[alex_st]

It looks fine in that screenshot.  It's pointing to two different files.  What's the problem?

I mark it with red.

[alex_st]

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

[MikeO]

@arindelle

Can I write to file retrospectively

I didn't realize you could , I ll check asap

Mike

[JimH]

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.

[Matt]

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]

@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 

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.

[mpf101]

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.

[Hendrik]

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.

[JimH]

You can also restore an older library backup.  File > Library > Restore.

[ssands]

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!

[MikeO]

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

[mpf101]

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!

[edwarduk]

thanks - thank you - thanks !! 

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

[Matt]

thanks - thank you - thanks !! 

Build 44 really fixed things up for me.

Thanks for letting us know.

Hendrik sure is a genius.

[altsouza]

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