Print

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

[Allen Brier]

I am new to JRiver. However, I have been ripping my entire library of CDs (over 1000) to FLACs mostly without a problem. However, I have run into a problem where JRiver mis-identifies some CDs as the same or different artists and rips songs into existing folders. JRiver does not overwrite the existing file, but creates a new file with a (1) or (2) or (3) suffix. For example, I ripped a Bob James CD and no problem. When I went to rip a second Bob James CD, JRiver mis-identified it as the first one, and created files with existing names, with the added suffix (1), etc. This has also occurred with one artist's CD writing into the folder of another artist's folder.

What the heck is going on and how to I "reset" JRiver to read the proper information from the CDs?

[mwillems]

I am new to JRiver. However, I have been ripping my entire library of CDs (over 1000) to FLACs mostly without a problem. However, I have run into a problem where JRiver mis-identifies some CDs as the same or different artists and rips songs into existing folders. JRiver does not overwrite the existing file, but creates a new file with a (1) or (2) or (3) suffix. For example, I ripped a Bob James CD and no problem. When I went to rip a second Bob James CD, JRiver mis-identified it as the first one, and created files with existing names, with the added suffix (1), etc. This has also occurred with one artist's CD writing into the folder of another artist's folder.

What the heck is going on and how to I "reset" JRiver to read the proper information from the CDs?

This is a bug that happens to me sometimes as well in marathon ripping sessions (new CDs will sometimes be misidentified as the CD I just ripped).  99% of the time, exiting JRiver and restarting will fix the problem.  I haven't been able to reliably reproduce it, so I haven't pushed it here.  If you know a way to make it happen reliably, I'm sure the devs would be interested.

[Allen Brier]

I tried rebooting the machine. I tried turning off the machine. I also tried ripping to a new folder. Nothing worked. It is still ripping to a previous CD's folder, and just updating files with (1), (2), (3), etc. I have suspended my ripping project until I get some answers. Hope I don't have to turn to some other software to rip the rest of my CDs.

[Allen Brier]

Does anyone else have this problem?

[gvanbrunt]

Here is what I think is happening:

CD's don't have metadata on them. MC looks that information up from a database. I think that database may have the wrong information for the second CD. Which is why it is identifying and placing the tracks in the previous folder. Not due to the bug that was mentioned, but because the DB has the wrong information for that CD.

You will have to correct the data by hand for that one. Then select all the tracks and right click. Select Library Tools->Submit Track Info to Online Database.

That will at least stop this from happening to the next guy.

[Vocalpoint]

Does anyone else have this problem?

I did. Reported it just a few days ago.

VP

[Vocalpoint]

I think that database may have the wrong information for the second CD. Which is why it is identifying and placing the tracks in the previous folder.

Disagree. This is a "refresh" problem somewhere down the line - not a misread from the online datastore.

The queue (or whatever stores the metadata) should be completely nulled out before the next disk is inserted (or metadata retrieve) occurs. Clearly it's not.

VP

[gvanbrunt]

VP,

I'm not saying the bug doesn't exist. I'm saying in this case I don't think that is what is happening for that one CD. The OP has rebooted, and has not tried other CDs etc at least from the information posted.

[Vocalpoint]

I'm saying in this case I don't think that is what is happening for that one CD. The OP has rebooted, and has not tried other CDs etc at least from the information posted.

Noted.

This is a newer issue tho as I do not recall having any issues like this within the v20 cycle. I only have seen it now that I am on v21.

I have had many other annoying issues with rips in with MC which is why I usually rip in dbPoweramp.

But - every now and then I try MC again to see if things improve. 

VP

[ferday]

It's not a universal problem is all I should say

I just finished a 30-CD ripping marathon and not a single issue of any kind.  Nor have I had an issue with ripping, ever (since mc17)

I know that isn't helpful but it does mean it's not as simple as fixing a "bug" either

[Vocalpoint]

I know that isn't helpful but it does mean it's not as simple as fixing a "bug" either

Must be something I am doing wrong then. But with three completely different hardware setups over the past 3 years (with three different optical drives) - I still cannot get a rip session going without some weirdo thing rearing it's ugly head.

Whether it's something like this current issue or now MC (as of 21.0.24) needing to suddenly do "re-reads" on every Track One of every brand new disc I try to rip or my ongoing UI struggles....like the MC rip UI being completely out of sync with what I am actually doing - I am at a loss to understand how something like ripping a disc (which logically be a "given" in 2015) still manages to cause headaches.

I would also mention that just because you are not seeing issues - that does not mean MC is working properly in the ripping department. I will defend my theory that MC does work well for some folks with certain specific setups/optical drives and does not with others. Like pretty much every one I have tried.

Conversely I can state - that dbPowerAmp is about as bulletproof as I have ever seen as it simply never fails to deliver regardless of what disc I am ripping, what machine I am ripping it on or any other parameter/scenario I can think of. I  keep hoping MC would be this way by now as I would love to use just one app to rip.

VP

[Allen Brier]

As I mentioned before, I have been ripping my entire catalog of over 1000 CD's (probably have ripped 600 - 700 now), and this has happened a few times with a few other CD's as well. I have tried wiping out all of the "recent" rips on the screen, rebooting, changing the target folder (but not target drive yet), etc. On this particular set of Bob James CD's, it has ripped 4 different CD's into the same folder, with previous file names (except that it add (1), then (2), then (3), etc. to the end of the filename). You can tell it is a different song, because the file size is different.
I guess I will have to manually change the filenames and add appropriate folders for each CD with it's name. Maybe it won't happen again for a while. For the most part, ripping has been trouble free, but ever so often...

[Allen Brier]

Still, does anybody have an explanation or a solution?

[Allen Brier]

Still doing this errant behavior. Anyone have any ideas?

[KingSparta]

nothing is perfect, and the info submitted by users is sometimes wrong.

there was someone at JRiver that would fix these errors from time to time, but I am not use if he still works there.

as for any other problems I could not add anything since It has been sometime since I have ripped cd's.

[JimH]

CD's don't have metadata on them. MC looks that information up from a database. I think that database may have the wrong information for the second CD. Which is why it is identifying and placing the tracks in the previous folder. Not due to the bug that was mentioned, but because the DB has the wrong information for that CD.

That's a reasonable guess.  MC just uses the data in YADB.  Usually it's good, but sometimes it may not be.

If it happens, please report the details.  Try correcting the data and submitting it.

[Allen Brier]

My guess is that JRiver somehow doesn't get the information from YADB (possibly due to a dropped data connection from the Internet) and defaults to previous information due to a bug in the program. When that happens, JRiver will keep using the data received before the glitch. If I don't watch closely, the newly ripped data will go to the last folder with good data, and each track will be re-ripped, with a number in parenthesis after it (since Windows thinks it is the same file, so it adds the suffix.
For example:
01 - One by One
01 - One by One (1)
01 - One by One (2)
01 - One by One (3)
02 - My Funny Valentine
02 - My Funny Valentine (1)
02 - My Funny Valentine (2)
02 - My Funny Valentine (3)
and so on. Each will be a different file size since it is actually from a track on a different CD.

"Usually" after rebooting JRiver, the problem goes away. As far as I can tell, it is definitely a bug in JRiver.

...BTW, who does fix issues identified in this forum???