gco / rubyripper

Automatically exported from code.google.com/p/rubyripper
0 stars 0 forks source link

rrip_cli command issues #445

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
1) Please describe the steps to reproduce the situation:

a. Put CD into tray, close tray, run 'rrip_cli'
b. Try to 'Edit the disc info' by typing in '2' and pressing 'Enter'

2) What is the expected output? What do you see instead?

Expect to get to editing the line I picked.  Instead it asks me again.  For 
example -

Scanning disc with cdrdao
Audio-disc found, number of tracks : 10, total playlength : 78:16
Fetching freedb info...
choice misc 8412580a Led Zeppelin / BBC Sessions disc 2
choice rock 8412580a Led Zeppelin / BBC Sessions ([Disc 2]
choice Keep defaults / don't use freedb

FREEDB INFO

DISC INFO
Artist: Led Zeppelin
Album: BBC Sessions disc 2
Genre: Blues-Rock, Hard Rock
Year: 1997

TRACK INFO
1) Immigrant Song
2) Heartbreaker
3) Since I've Been Loving You
4) Black Dog
5) Dazed and Confused
6) Stairway to Heaven
7) Going to California
8) That's the Way
9) Whole Lotta Love Medley
10) Thank You

What would you like to do?

1) Select the tracks to rip
2) Edit the disc info
3) Edit the track info
4) Cancel the rip and eject the disc

2
Please enter the number of your choice:  [1] 1) Artist: Led Zeppelin
2) Album: BBC Sessions disc 2
3) Genre: Blues-Rock, Hard Rock
4) Year: 1997
5) Mark disc as various artist
99) Finished editing disc info

2
Please enter the number you'd like to edit:  [99] BBC Sessions
Album :  [BBC Sessions disc 2] 
Please enter the number you'd like to edit:  [99] 
FREEDB INFO

DISC INFO
Artist: Led Zeppelin
Album: BBC Sessions
Genre: Blues-Rock, Hard Rock
Year: 1997

After a couple rounds of this with a different disk I got used to how it was 
working incorrectly.  Basically (and this holds for all choices) when it asks 
me to input a numbered option I type it in and enter it.  But then it asks me 
for the same thing again.  If I enter the number and hit enter again it takes 
that to be my change vs. my choice.

So, in the above example, the first time I tried it I entered '2' (Edit the 
disk info), it asked me to 'Please enter the number of your choice: [1]' 
followed by a list that isn't formatted correctly (the first option is on the 
same line vs. starting a new line) so I entered '2' (Album: BBC Sessions disc 
2) and it asks me 'Please enter the number you'd like to edit: [99]' (more 
incorrect formatting).  If I enter '2' again it will take that to be the change 
I wanted and 'Album:' will now read '2' so I figured out to enter 'BBC 
Sessions' instead of a numbered choice to get what I wanted (see above example 
right before 'FREEDB INFO' to see me typing in the name instead of a number 
like it asked for in order to make it work).

3) What version of rubyripper are you using? On what operating system? The
gtk2 of commandline interface?

I'm using rubyripper 0.6.0 (downloaded using Synaptic and the getdeb 
repository) on Ubuntu 10.04 (but using the fully downloaded KDE desktop so I 
guess now it's Kubuntu) on an AMD 64-bit dual core PC.  This was using the 
rrip_cli command.

4) Is this not already fixed with the latest & greatest code? See for
instructions the Source tab above.

I do not believe so.  I've also read various forums in order to learn how to 
use rubyripper and nobody ever mentioned this odd command line behavior.

5) Does the problem happen with all discs? If not, please attach
the output of cdparanoia -Q with a disc that gives trouble.

Yes.  The rrip_cli text interface seems to be one 'Enter' behind or something.  
It might be due to the formatting, it could be that text and the keyboard 
reading is in reverse order?

6) Please explain why this change is important for you. Also, how many
users would benefit from this change?

Assuming this isn't affecting just me, it would help anybody who has tried to 
run rubyripper using the command line in order to avoid the llooooooonngg wait 
for the rrip_gui interface to rip one CD (every CD ripped through the gui 
requires the cdrom drive to timeout of 2 minutes to protect the hardware 
because it hits that 'The drive is spinning for more than 30 minutes.' limit).  
My distro has Ruby1.8 so, judging from the forums I've read, that seems to 
cripple the gui's ability to rip a CD without lengthy delays.  Doesn't affect 
the command line version.

Please provide any additional information below. The more usefull
information provided, the sooner the issue will be fixed.

Again, not sure if this is just my version of Ubuntu or not but I couldn't find 
the settings file where I've read it's supposed to be (~/.rubyripper/settings), 
on my computer it ended up being ~/.config/rubyripper/settings and that file 
seems to be missing a couple of settings.

So, if I might make some addition (enhancement?) suggestions, I think the 
settings file needs to include the true/false choice for freezing the disc info 
(for multiple discs) along with which numbered disc is chosen.  If that's in 
there I couldn't figure it out by the names of the various settings.

Even better, I think rubyripper should have an extra tab (an 'Info' tab in the 
'Preferences' area) that shows where it thinks the settings file is (maybe that 
could be altered by the user but maybe just announcing where it is is enough) 
along with the ability to force an update (write out a new settings file or 
write out more than one settings file like settings_mp3 or settings_rock) for 
rrip_cli to see and use (for example, 'rrip_cli -settings settings_flac_rock' 
incase the user wants specific formats written out in unique ways).  This tab 
could also list what version of rubyripper it thinks it is along with what 
version of Ruby it's using and hopefully a button for remounting the cdrom 
drive.  This last one is important because sometimes rubyripper loses the drive 
(or it auto-unmounts) and hitting 'Close tray' and/or 'Scan drive' only gives 
back the 'Cdrom drive /dev/cdrom does not exist on your system!' warning.  I'd 
really prefer to use the gui but it's way too slow.

Finally, I think there should be an option in the gui to be able to look at the 
Preferences tabs during a rip.  Even if they're all ghosted out so that nothing 
can damage the current rip, it would be nice to have the option to look through 
the various settings while this thing is ripping away so if the user notices 
something set wrong (naming conventions, destination directory, codec settings, 
etc.) he can Abort vs. not realizing he did it wrong until the rip is finished.

Anyway, thanks for a great app!

Original issue reported on code.google.com by rampagin...@yahoo.com on 18 Sep 2010 at 1:24

GoogleCodeExporter commented 9 years ago
Hi Rampagin..

You are not alone - I have the same problem.  For me it seems to be x86_64 
specific.  Running version 0.6.0 on openSUSE 11.3.  Works fine on my Atom 
netbook, but I get the problem you describe on the x86_64 machine.

Mark

Original comment by mark.rc....@gmail.com on 15 Nov 2010 at 10:51

GoogleCodeExporter commented 9 years ago
Hello, Mark,

Interesting, that's an odd problem.

I've never used Ruby so I'd like to ask why you wrote this software (which I 
love) in Ruby?� I mean the GUI version's problems are well-known and I've 
experienced all of them in terms of slowness.� I would think that using C or 
Bash shell scripting would avoid that maddening 64-bit-specific issue, at least 
for gathering data and setting flags.

I forgot to ask that the next version of rrip_cli also allow for *all* the GUI 
options to be included.� Now maybe they are and I didn't catch them but I would 
like the option to set the "Freeze disc info" flag and also set the "Disc:" 
number.

I don't know if this is a 64-bit problem, too, but I notice that if I load a CD 
into the drive and then run rrip_cli *before* the dialog box asking me what CD 
player I would like to use pops up, many times rrip_cli reads the CD and starts 
asking me questions and the CD drive unmounts and rrip_cli can't see the CD 
anymore.� This does not happen if I load the CD into the drive, wait for the 
dialog box and *then* run rrip_cli.� Have you seen that?

Anyway, thanks for emailing me, I was curious about updates to your program.

Alfred.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

"See, you deal with kids the same way you deal with adults.

 It's just they're, you know, short and broke."

                              - Dan Stark, "The Good Guys".

Alfred Urrutia                     rampagingsloth@yahoo.com

--- On Mon, 11/15/10, rubyripper@googlecode.com <rubyripper@googlecode.com> 
wrote:

Original comment by rampagin...@yahoo.com on 19 Nov 2010 at 8:31

GoogleCodeExporter commented 9 years ago
The command line interface is much improved with current git, please let me 
know if there are any problems left. Just tested the said behaviour and it 
looks fine to me (running Arch Linux 64bit here).

Notice that current git is not ready for daily use, but the preferences menu 
and track editing menu should be rock stable.

Original comment by boukewou...@gmail.com on 14 Mar 2012 at 10:11