Print

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

[psg]

XP Pro / MC 10 build 173 / 3 USB 2.0-connected drives / async rip & encode - 3 rip, 4 encode procs

I should probably post this later, after I'm done with the 1500 plus CD's that I'm ripping ...  because I am so pissed-off and frustrated that it's going to be VERY hard to not have this post be a mad rant.

Has JRiver ever tested Media Center with multiple drives when trying to rip a large number of CD's?   From where I sit, it's buggier than a baitshop.

Here are the problems I am having:

YADB lookups fail constantly, with a "Cannot connect ...",  even when the disc IS in the database. (The problem isn't with my connectivity --- I have dual T1's here!)

MC ignores the Option setting to choose the first result if there are multiples

On several occasions, all three drives have shown the same artist/album/track info

MC crashes, leaving the ripped but unencoded files in limbo ... I need to manually figure out what's been done and what needs re-ripping

MC seems to want to look CDs up twice before starting the rip.  Frequently the first lookup succeeds, but the second time fails, then the idiot thing wipes out the correct CD info, and rips to Unknown/Unknown.

MC ignores the "Do Nothing" Audio CD setting

=========================================

The biggest problem is when it works well for 5 or 6 CDs in a row, and has a big backlog of WAV files to encode, and then crashes .... I've got to go back and start over!

It's very clear to me that for whatever reason, MC's threading is completely FUBARed.  YADB connection attempts are blocking screen updates, and sometimes other drives' CD changes.  Sometimes wrong YADB data gets associated the wrong drive's CD.

I have three recommendations:

First, test the damned thing in this configuration!  I'm not making this stuff up.

Second, make an option to "Never start rip without tag data", and be certain MC obeys the setting.

Third, in the case where MC is set for asynchronous rip/encode, start a whole other program to drive the encoding process.  Maintain a task queue for it the simple, stupid, bulletproof and effective way; a plain old text file.  That way, if MC crashes, the encoding process will continue, so work done previously will not be lost.

Fourth, as an additional precaution, if you must rip into the Temp directory before encoding, at least maintain the Artist/Album directory structure underneath Temp, so that ripping work isn't lost.

===============================================

I realize that it's unlikely you'll re-architect MC to fix this stuff, but if you have any interest in having me do any tests to help you fix or diagnose the problems, contact me via email.

Paul

How to fix this:

[Krazykanuck]

I feel your pain.

I am running MC11 build 158. The problems you laid out are still there.
Because MC11 is still beta I assumed that things would eventually get fixed. I didn't realize that these are not new problems to MC11.
I have posted a few times about the YADB lookup issue.
Both my optical drives are internal IDE and I have the same ripping and encoding problems.

Can somebody pipe in here and at least let us know if these are recognized as issues and if they are being looked at.

Thanks

[psg]

And I saw your posts on the forum, and realized that they hadn't addressed the issues in V11.

In fact, if you search, you'll see that these issues go back to 2003 and before.


<SIGH>

[MarSies]

Hi psg,

You are so absolutely right. Because of diskcrashes I have to re-rip my CD collection again. It is more then a struggle to do this with MC. The ripsection makes me go crazy.

All the errors you laid out I recognize. You also left out or haven't encountered more issues. Also problems that have been in the past came back. For example, after a rip session the covers of already ripped CD's are again picked up from the net, why?

I have posted many of these type of issues on the forum. From my point of view a lot of new things are being build instead of fixing some basic functionality.

A good test would be if JRiver would ask a PC dummy to rip 50 CD's and ask him/her if it works out. I think I know what the result will be.


MarSies .....

[psg]

Yes, I noticed the covers seemed to be getting fetched over and over, so I turned that off, figuring that I could do them in a batch later.

It does make me a little crazy that JRiver is adding features, rather than fixing these old bugs.

But I have managed to get all the way through "Dwight Yoakum", leaving only about 50 - 100 more to go.

[MarSies]

psg,

I notice that the processor usage is much and much higher then it used to be with the latest versions of MC. Did you notice this or is it just me.

I bought the new Plextor PX-716A DVD burner and it is much slower then the older PX-504A. I thought that it would be faster. On the other hand my Plextor PleXwriter Premium continues to work fine. How much depends on the hardware and how much on the software?

Marsies .....

[bbrip]

Ripping with MC is indeed a pain, however look at the alternatives: The only one with good secure rip results is EAC - and that is far worse in terms of speed and stability!!

ALL other rip software I have tried did not cope with bit-by-bit secure ripping requirements that I am demanding as a serious audiophile.

So - no choice other than going through the pain with MC - but I agree that the YADB database lookup is not perfect. Why does JRiver not use CDDB as all others do ?  I am even prepared paying a few bucks more if it were for the higher licensing fees !

[JimH]

CDDB will never happen here.  We had a lot of trouble with it when we did use it.

[Helmchen]

XP Pro / MC 10 build 173 / 3 USB 2.0-connected drives / async rip & encode - 3 rip, 4 encode procs

Your problems are 3 encode processes and 1 or 2 rip processes.
eliminate them and everything will work faster and more reliable.

to have more than one encode process only speeds things up when you have a multiprocessor machine - one encode process per cpu. if there are two processes running on one cpu, this will slow down encoding, because the cpu has to switch between the tasks very often.

reduce the rip processes too, too many of them will be a pain for your harddisk as it has to write to many different places which slows your hardrive down dramatically. The best # of rip processes is that they're able to rip a little bit faster than encoding, so that the one encoding process always has someting to encode.

with your 4 encodes and 3 rips you do a good stress test but i can hardly believe that anything works well on your machine, especially if you use lame mp3 encoding.

reducing the system load could help to get better YADB-results too. the problem here is not the bad connection, it could easily be the non-existing cpu-power to handle it.
Do you mean 1 line with double T1-speed, or 2 lines with T1-speed?

regards
Helmchen

[Krazykanuck]

I have found that MC has a real problem if you do anything other than single thread the processes. By that I mean rip/encode/rip/encode.....
As soon as you even try to rip from two devices with still a single encode process you start to have problems.
The YADB lookup is a problem with its issues occuring before the rip/encode process even starts.

[evanr76]

When there are more than a page's worth of tracks queued for ripping from multiple drives, the Rip window goes crazy constantly updating the status field percentages and flipping back and forth between pages.  I am guessing this is because the status field brings itself into focus whenever it is updated.  Fix: do not focus the status field on status updates.