After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 132007 - Rip concurrently from different drives with two s-j instances
Rip concurrently from different drives with two s-j instances
Status: RESOLVED OBSOLETE
Product: sound-juicer
Classification: Applications
Component: general
unspecified
Other Linux
: Normal enhancement
: ---
Assigned To: Sound Juicer Maintainers
Sound Juicer Maintainers
: 165521 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2004-01-20 16:08 UTC by Tim-Philipp Müller
Modified: 2021-05-17 15:47 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Tim-Philipp Müller 2004-01-20 16:08:13 UTC
I just tried the following: 
 
- open up sound-juicer and start extracting a CD in drive 1 
- open up a second sound juicer instance 
- (the 2nd instance would read in the contents of CD in drive 1) 
- changed preferences to use drive 2 
 
Result: _Both_ instances of sound-juicer now re-read the CD content from 
drive 2, not only the 2nd instance (and instance 1 stops extracting with 
the dialog hanging). 
 
It would be great if it was possible to run 2 separate instances of 
sound-juicer and extract two CDs from two different drives with it at the 
same time. 
 
Cheers 
-Tim
Comment 1 Matthew Paul Thomas (mpt) 2005-04-03 19:56:17 UTC
*** Bug 165521 has been marked as a duplicate of this bug. ***
Comment 2 Steven Wagner 2007-06-10 04:08:58 UTC
I vote for this feature too.
Comment 3 Tim-Philipp Müller 2007-06-10 10:52:57 UTC
Not really sure if this feature is still required. Back then reading and encoding a CD easily took an hour something, if not more. These days, ripping is so fast that parallel rips aren't really needed any more IMHO (at least on hardware bought in the last 5 years).
Comment 4 Steven Wagner 2007-06-11 17:38:06 UTC
Tim - If you multiple the number of cds you have by a factor of x, the time to rip all cds is x times longer. If you add x number of cd drives, the job becomes x times shorter. This weekend I was ripping 20 cds, and I could have gotten the job done twice as fast if I had been able to use both of my cd-rom drives.
Comment 5 mdpoole 2008-01-22 12:24:35 UTC
Changing the drive that another instance is ripping from is a pretty serious violation of the principle of least surprise.  Is this really an enhancement rather than a bug fix, especially if the first instance hangs?

(I've also wanted parallelization on recent hardware; I tend to buy CDs in bursts, and it would be nice if I could halve the time it takes to format-shift them.  Many -- perhaps most -- machines come with multiple optical drives these days, so there will be a lot of others in the same boat.)
Comment 6 Ross Burton 2008-01-22 12:57:33 UTC
This would work nicely with the patch to automatically detect drives to rip from, instead of there being a preference.

Also, I disagree that most machines come with multiple optical drives these days, I'd say they come with a single DVD+RW writer which can do everything.
Comment 7 Caihok+nofeeCh 2010-08-11 06:35:41 UTC
I just ran into the same problem.
I too tend to buy a batch of Cds every now and then and using only one drive to convert them seems a waste of time really.
So is there anybody left apart from me wo would still want this feature?
as Sound Juicer already finds all my drives without configuration, it should not be too hard to change the drive for one particular session, should it?
Comment 8 GNOME Infrastructure Team 2021-05-17 15:47:13 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/sound-juicer/-/issues/24.