Print

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

[6233638]

As a test, I created a new FLAC+CUE rip of an album, and moved it to my auto-import directory.
 
Media Center is importing both the CUE file as individual tracks (filename.flac;1) and the FLAC file itself (filename.flac) as an hour-long track.
 
Shouldn't it be skipping the source FLAC file when it is referenced in CUE files that are coming in through the same import?

[Matt]

You want to configure the import to only look at CUE files.  Otherwise it'll import the FLAC. 

[6233638]

Well no, I want auto-import to continue importing regular FLAC files too.
 
It seems like CUE files should have special handling to ignore the files that they are referencing to avoid duplicates on import.

[ssands]

Well no, I want auto-import to continue importing regular FLAC files too.
 
It seems like CUE files should have special handling to ignore the files that they are referencing to avoid duplicates on import.

I really think this exactly hits it. I have some rips where there are individual flacs / track with a cue, and other rips where there is one long multi-track flac with a cue. It's great that MC uses the cue to parse the big flac into tracks, but the duplicate tracks are a pain, and the changes to one's library (which many of us seem to spend a long time on) are painful.

So, there seem to be two situations here:
How to preserve the work many have done setting up their libs, and
Best practices going forward on cue file usage.

(I kept thinking it's just me having issues here, but it does seem like there is enough of us that are struggling with this.)

[berstuck]

I couldn't find a better solution than simply using cuetools to split my album length files up into tracks.  Pain in the ass on a large library, but at least you only have to do it once!

[InflatableMouse]

It seems like CUE files should have special handling to ignore the files that they are referencing to avoid duplicates on import.

Agreed.

[elderavelas]

The changes made for CUE handling caused problems and no benefit for me. It was fine the way it was. Why did you change it?

[TheColdOne]

Possible fixes

Pseudo algorithm (heavy):
if cue file exists then
..if corresponding tracks all exist as individual files then
....break
..else
....load the tracks and append the ;<tr.no>
else
..load the flac files in the folder


My personal pick (light):
if 'FILE' count > 1 and 'TRACK' count > 1
..load the tracks and append the ;<tr.no>
else
..load the flac files in the folder

[6233638]

The changes made for CUE handling caused problems and no benefit for me. It was fine the way it was. Why did you change it?

They fixed a number of problems with CUE file handling which meant that CUE files which were previously doing nothing or not working correctly now work as intended and get imported. That's a good thing.
 
That change itself is not a problem, it's that people have built up their libraries with these CUE files which previously did nothing, and now that they work, they're all being imported at once.
To me the issue is really that there are a number of other changes which should have been made alongside this fix for the CUE files to prevent the disruption that a lot of people have seen, and I don't personally think the advice the JRiver team has been giving to deal with it has been satisfactory. I'm sure it was not their intention, but to me it reads as though they're saying "put up with it".
 
If they can fix the issue where CUE files are constantly re-imported into the library after being removed, which seemed to be resolved on my system with build 37—though apparently not for others—then it is a relatively minor issue to fix. I've already posted a smartlist to isolate the newly imported CUE files from this change, which allows you to remove them all in a couple of steps. They just need to stay gone once you do that.
 

However, the change I'm requesting in this topic is not really related to that.
 
I'm asking that the source file is ignored when importing FLAC+CUE (or anything +CUE) when they are brought in together in the same import session (this part is key) and likely only in the same directory.
That won't have any effect on the newly fixed (and re-imported) CUE files, since it's only CUE files which are being imported in that case, as the FLAC or other files are already in the library, but this change would avoid creating duplicate/redundant files with new imports.
 
Duplicates may have previously been avoided when importing FLAC+CUE if the CUE file was not doing anything though, which is why I think this special import handling for CUE files is important now.
 

I think that trying to assess whether new CUE files reference any other files pre-existing in the library, rather than the same import session, is a far more complicated proposition and one which is potentially damaging depending on what the expected behavior is for any duplicates that are detected.
 
I would also add that build 27 seems to be the current "stable" version, and issues like these are why the stable and "latest" versions are kept separate from one another.
I would hope that these issues are resolved before a build newer than 35 is moved to the stable update branch.
Of course, it's entirely possible that things like this don't get caught in advance and do make it out. Obviously it already made it past the beta team before getting to the "latest" branch.

[elderavelas]

6233638,

your smartlist worked. I was able to delete the newly imported duplicates and they no longer appear.
I am using build 37.
Thanks!

EDIT: The duplicates appear again after restarting MC.
EDIT 2: I've got rid of the CUE files, as I do not need them, deleted the newly imported duplicates and now they seem to be gone forever.

Anyway, deleted items should not be imported again, as I have this option enabled. This seems to be a bug for CUE importing. It does not check if the track being imported has been deleted.

[kstuart]

EDIT 2: I've got rid of the CUE file

Better is to rename the .cue files to something like .cue.blah (I have found uses for the cue files years later).

[6233638]

Better is to rename the .cue files to something like .cue.blah (I have found uses for the cue files years later).

It would be better if removed .cue files stopped being re-imported, so that it was not necessary to rename or delete them.

[hoyt]

It would be better if removed .cue files stopped being re-imported, so that it was not necessary to rename or delete them.

I go to an album on Gizmo and hit play and everything plays twice.  I spent 60 minutes deleting these duplicate tracks and then install a new version and they all show up again.  Meanwhile, my play counts are wrong because the versions with ;1, ;2, etc are getting marked as played, but then I remove them so the albums won't all play in duplicate.  I have CUE files set to not import, yet they keep importing screwing up my library.  I don't see any notes in .39 about this, so I assume it's still broken?

[JimH]

Did you read what Matt suggested here?
http://yabb.jriver.com/interact/index.php?topic=93246.0

[hoyt]

Did you read what Matt suggested here?
http://yabb.jriver.com/interact/index.php?topic=93246.0

Yes, I have removed the extraneous entries three times.  The problem is that these random ;# files keep showing back up.  Matt suggests removing the "old" entries, but it's not the old ones that are the problem.  It's the new ones...  MC needs to honor the library that's been in existence and not corrupt it, or force a rebuild of it because the import logic changed.

If this was MC 0.01 beta, then sure that's fine, but it's not.  The majority of engaged users here have a pre-existing library that's carried over from version to version.

[JimH]

Did you tell MC not to import CUE files?

[Matt]

Yes, I have removed the extraneous entries three times.  The problem is that these random ;# files keep showing back up.  Matt suggests removing the "old" entries, but it's not the old ones that are the problem.  It's the new ones...  MC needs to honor the library that's been in existence and not corrupt it, or force a rebuild of it because the import logic changed.

If this was MC 0.01 beta, then sure that's fine, but it's not.  The majority of engaged users here have a pre-existing library that's carried over from version to version.

The ones with the ;# are the new ones and the ones you want to keep.  Remove the other ones.

[hoyt]

Did you tell MC not to import CUE files?

Yes.  I did that after the second time these files reappeared.

[hoyt]

The ones with the ;# are the new ones and the ones you want to keep.  Remove the other ones.

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.

[Matt]

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.

I'm sorry for the inconvenience.  If it's any consolation, it's a one-time thing.

[6233638]

Having cue files now be all or nothing, since we can no longer remove them from the library if we're using auto-import, seems like it has implications beyond this specific issue.

[TheColdOne]

I'm honestly feeling disheartened you keep telling people this poor solution to the problem. I'm fairly certain that implementing my pseudo script above in auto-import would fix this issue, and instead you ignore it.

[JimH]

I'm honestly feeling disheartened you keep telling people this poor solution to the problem. I'm fairly certain that implementing my pseudo script above in auto-import would fix this issue, and instead you ignore it.

Nobody is ignoring this problem.

[TheColdOne]

Nobody is ignoring this problem.

Thanks for the reply Jim, hopefully it gets sorted out. I should have put in that the filetype of the files should be ignored, since FLAC conversion is usually done after the rip so they display as wav, and as such aren't imported with the ;<tr.no>

[6233638]

Looks like the issue for people with problems caused by the new CUE file imports will be able to remove them using this expression, and they should stay out of the library now:
 

2. Fixed: Removed CUE files would get reimported by auto import.

 
However, this does not address the issue of duplicates/redundant files being created for new imports of FLAC+CUE, where you have both the individual tracks in the CUE File (say 12x 5 minute tracks) and the source FLAC file. (the 60-minute long gapless track which the CUE File references)

[InflatableMouse]

I have to admit its annoying. I was importing some new stuff yesterday and all folders had flac+cue and both got imported. Having to clean this up afterwards feels unneccesary. Especially since I don't understand why this had to change. I understand there was an issue with importing but if this is the solution it feels like the cure is worse than the disease, so to speak.

I'm sorry if I sound like I'm ranting, I'm not.

[MikeO]

I gave up moaning !!!

I couldn't agree more , I am day 5 of a process of cleaning up stray CUE files just to avoid the duplication.

hopefully its a once off exercise. I am looking on the bright side , its allowing me to clean up folder names and other grot while I'm at it !!

I do feel the cure is worse than the ailment...

Mike

[hoyt]

If I tell MC to ignore cue files, I expect it to ignore cue files.  If it's not capable of doing that, it should not keep duplicating my library.  The problem came when JRiver made a non-passive change that affected everyone with no way to undo it.  The problem continues because the communication is that we should clean up our libraries.  

[Fangio]

I feel your pain; it took me about a week to sort out my mess of a library. I removed all .CUE files, as I don't want any time bombs left behind.

[hoyt]

I feel your pain; it took me about a week to sort out my mess of a library. I removed all .CUE files, as I don't want any time bombs left behind. It was, apparently, a necessary change, but ...

If JRiver is going to drop this on us without an option to do that clean up when we choose, there needs to be an automatic migration path for the metadata from the .flac file to the .flac;# entry.

[JimH]

There have been several changes for this.  Are you using 20.0.41?

None of these changes were in the Stable build that is on the Download Page.  They were all on the Latest build, and you may expect this build to have more problems than the Stable build:
http://wiki.jriver.com/index.php/Updates

MC makes automatic backups of libraries.

[6233638]

Unfortunately, a lot of people are conflating separate issues here.
 
Previously dormant CUE files that are now being imported is a separate issue.
Since they are no longer being re-imported every time auto-import runs (as of build 40) it should be relatively easy to fix with a smartlist and <5 minutes of work.
 
 
The issue here is that for new imports, Media Center still treats FLAC+CUE (or anything +CUE) as separate items and imports both.
For that import session, Media Center should be checking to see if it is importing CUE files which reference other files in the same import session.

An example would be an hour-long FLAC file, with a CUE file that splits it into several tracks:

FLAC:
C:\Music\Album.flac

CUE:
C:\Music\Album.flac;1
C:\Music\Album.flac;2
C:\Music\Album.flac;3
C:\Music\Album.flac;4
C:\Music\Album.flac;5
C:\Music\Album.flac;6

Here, the CUE file is clearly referencing C:\Music\Album.flac, and so that file should be ignored. (probably moved to the "deleted items" list to prevent it being imported next time auto-import runs?)

This check would only be run against the current imports, not the entire library.
Checking for duplicates/referenced files in the entire library each time auto-import runs seems like it would be impractical, and greatly slow down the import process.
 
 
Personally, it's not like I'm importing albums with such frequency that this is a major problem for me, as I can let both import and then manually remove the FLAC file.
However not everyone is going to have the patience for that, and it seems like it shouldn't be that complex to implement as long as it's only acting on the current import session.

[hoyt]

There have been several changes for this.  Are you using 20.0.41?

None of these changes were in the Stable build that is on the Download Page.  They were all on the Latest build, and you may expect this build to have more problems than the Stable build:
http://wiki.jriver.com/index.php/Updates

MC makes automatic backups of libraries.

Yes, I installed .41 this morning, I think I was on .39 prior to that.  During the last few releases, the CUE files will seem like they're gone, then they magically get imported again.  I expect there to be problems, just like I figured you expected us to provide feedback.  However, no one from JRiver ever said "this is a problem that we're addressing and what we plan to do in the next stable release is to address it in a manner that doesn't mean redoing everything."  So far, the message has been to change the library to match the new behavior.  I posted on 11/17.  That day I deleted ;# entries.  I took this screen shot prior to deleting them again this morning.  Notice they were imported again on 11/19.  

Are you pointing this out because at the next stable build this will be addressed differently?  If so, great and I'll keep deleting these ;# entries until it's actually fixed.  That message hasn't been clear.

[6233638]

hoyt, if you never want a ;# item in your library, disable CUE files in auto-import.
If you are trying to remove duplicates caused by dormant CUE files being imported, use the smartlist to remove them.
If you are importing new "FLAC+CUE" files, you probably want the ;# files and not the FLAC. (the issue that this topic is about)

[JimH]

We believe it is fixed.

[hoyt]

hoyt, if you never want a ;# item in your library, disable CUE files in auto-import.
If you are trying to remove duplicates caused by dormant CUE files being imported, use the smartlist to remove them.
If you are importing new "FLAC+CUE" files, you probably want the ;# files and not the FLAC. (the issue that this topic is about)

I've had the cue entry unchecked in the auto-import since .31 when the issues started.  Then I built the smart list to remove the ;# tracks, these items have been removed from my library multiple times.  Yes, it's easy to remove, but usually I notice that they appear again when I'm on Gizmo and I can't remove them without access to the MC desktop view.

Sorry for hijacking your thread.  I figured the issues are related because I end up with two entries and you end up with two entries no matter how we have it configured.  Maybe the issue of re-importing removed ;# files is finally resolved, but this other thread indicates it's not.  I'm waiting a few days to see what .41 actually does with the cue files:

http://yabb.jriver.com/interact/index.php?topic=93530.0

[JimH]

The issue here is that for new imports, Media Center still treats FLAC+CUE (or anything +CUE) as separate items and imports both.

Why not only import the CUE file in directories where you have both?

[6233638]

Why not only import the CUE file in directories where you have both?

Because I never manually import anything, I let auto-import handle it.

• Some albums are FLAC+CUE
• Some albums are individual FLAC tracks

So I can't disable FLAC importing or else #2 doesn't work.

[JimH]

If they're in different directories, you could apply different rules for auto-import.  I know you know this.

[6233638]

I only have one directory for music.

[JimH]

You might consider splitting at least some of the collection.

It might also make the program faster.  Directories with 100,000 files might be slow.

[6233638]

Sorry if that wasn't clear.
 
Everything ends up in \Audio\Music\[Artist]\[Album]\ etc.
Auto-import runs on \Audio\
 
Improving auto-import on the program's end, rather than expecting users to create custom rules and use separate import directories for different file types, would be a lot more beneficial to everyone, rather than only advanced users.

[InflatableMouse]

I have to agree with 62. I'm in the same boat and tend to let auto import handle things for me. Sometimes I do import manually, but having to open the filetypes, scroll through the list and untick what I want/don't want is tedious. And sometimes I import an entire tree of subfolders, some of which have flacs/cue's, others just flacs. I would have to manually figure out which have a cue and which don't, make notes and import each individually. It's a drag and not very user friendly.

The solution 62 gives is simple and effective. I don't see how that could affect anyone negatively. I don't think importing both is an elegant solution.

Please give it some more thought.

Thanks.

[pluto7]

Ok this is the problem that I am now experiencing.
1. I updated to version 20041
2. (created smartlist)  [Date Imported]=<3d -[File Type]=[sacd] [=IsEqual(Right(RemoveCharacters([Filename,0], 0123456789, 2), 1), ]=1
3. remove CUE files from your auto-import rules
4. delete the files in the smartlist


And I still have the same problem, mc keeps importing the files in the background.

I am again back to mc 20030. I am not interested in updating anymore, this has taken more than 16 hours of my time. If there is no solution made to this problem than I will stay at the version 20030. it is not an option for me to update mc and have years of work being ruined because somebody suddenly had the idea to enable all of the cue files that were not working before and then in turn let the customer resolve the problem that is created by this update. I have too many files to correct and check, it is literally impossible to this. JRiver had a lot of hiccups which I had to correct when importing audio files. This cue file problem (update)is bringing back all of the errors that I so tediously have corrected. Considering that I have hundreds of thousands of files, it is not an option for me to repeat all of my work because of an cue file update. Please remove this update!!!!! I was an very content customer and have praised the software to all of my friends., it was even recommended to me by Classe. I am very disappointed in jriver, for creating such an problem for their customers. If you wish to correct problems with your software I am all for it, but don’t ask your customers to trash there hard work for some crazy cue file problem that I could and did live with before. To say you don’t need cue files maybe so but they are there in my folders and I cant just remove them, personally I cant find an reason to do so.

[pluto7]

Usually updates are made to correct problems not to create them, if they then do so they again are corrected. I am not responsible to solve this problem you as software maker are. If the cue file is seen as a problem because they were not seen in mc, then ok fix it but not in this manner. If there is no other way then drop it don’t update. Don’t ask this of your customers. I had no problems that were serious enough to concern myself with the cue files. The problems arising from this update is for me a very serious problem.
   There is no clear solution in a chronological order given on one thread, in how to solve this as a customer with a little know how of mc20. the solutions given are not working or not an doable option. I am standing here with pure unbelief that jriver would or could do something like this, and you have created the best audio software available, some how I cant rhyme this. Anyway I am happy and sad to say that 20030 is the end for me. Happy that I have jriver and sad that it has ended. I will continue futher with building my database with audio files in the manner that I have been doing in the past, for me jriver functions just fine until update 20033. I don’t have an backup of mc 20032 install exe, but maybe somebody will be kind enough to send me that.

[pluto7]

using  [Date Imported]=<3d -[File Type]=[sacd] [Filename]=";" is creating a list of the doubles created by the cue files, I am not seeing any cue files.

[TheColdOne]

Unfortunately, a lot of people are conflating separate issues here.
 
Previously dormant CUE files that are now being imported is a separate issue.
Since they are no longer being re-imported every time auto-import runs (as of build 40) it should be relatively easy to fix with a smartlist and <5 minutes of work.
 
 
The issue here is that for new imports, Media Center still treats FLAC+CUE (or anything +CUE) as separate items and imports both.
For that import session, Media Center should be checking to see if it is importing CUE files which reference other files in the same import session.

An example would be an hour-long FLAC file, with a CUE file that splits it into several tracks:

FLAC:
C:\Music\Album.flac

CUE:
C:\Music\Album.flac;1
C:\Music\Album.flac;2
C:\Music\Album.flac;3
C:\Music\Album.flac;4
C:\Music\Album.flac;5
C:\Music\Album.flac;6

Here, the CUE file is clearly referencing C:\Music\Album.flac, and so that file should be ignored. (probably moved to the "deleted items" list to prevent it being imported next time auto-import runs?)

This check would only be run against the current imports, not the entire library.
Checking for duplicates/referenced files in the entire library each time auto-import runs seems like it would be impractical, and greatly slow down the import process.
 
 
Personally, it's not like I'm importing albums with such frequency that this is a major problem for me, as I can let both import and then manually remove the FLAC file.
However not everyone is going to have the patience for that, and it seems like it shouldn't be that complex to implement as long as it's only acting on the current import session.

This ^^ pretty much what I was trying to say with my pseudo code. Thanks for putting it into words ^_^

[pluto7]

(Previously dormant CUE files that are now being imported is a separate issue.
Since they are no longer being re-imported every time auto-import runs (as of build 40) it should be relatively easy to fix with a smartlist and <5 minutes of work.)
I have too many files, to check them all for faults created by the cue file chaos is for me impossible withina  reasonable time.

I have build 20041 and I still have problems with reimported files. not importing cue files for imported files  is not an option since many of my files are dependant on the cue files. I have a lot of image files. I feel like I am writing to an brick wall I am not seing any responses to the problem at hand. are you at all interested in helping? if you dont know what you are doing let us at least know that. waiting for an decent response to my alerts. your friendly user of jriver.

[Sesam]

6233638 has a good point, the previous suggestions from JRiver aren't practical. Most users problems would be solved if Media Center handled like this:

- Album stored as Cue+one large FLAC. Only the Cue is imported, the FLAC is ignored because it was referenced in the cue.
- Album stored as Cue+separate FLAC files. The Cue should be ignored, and only the FLAC files imported.

This would solve all my problems. Like many users I use Auto-import and don't want for other reasons to set MC to ignore previously deleted files.

[6233638]

- Album stored as Cue+separate FLAC files. The Cue should be ignored, and only the FLAC files imported.

I had not considered that this might also be an issue, as I have personally only used FLAC+CUE when I wanted to keep everything as a single file.
 
That seems like it would be just as important as avoiding the FLAC file when it's a single file being split into many tracks.