Grip - irrational behaviour, looking for similar experiences and fixes

kaine · 01-26-2007, 09:59 AM

Hey..

Will begin by saying that I have googled, and just searched the forums before posting. Though I have found many grip-related posts, none of them cover the specific occurences that I have recently experienced.

Currently converting a considerable CD library into .ogg files for a home hub/music server for a home WAN, and after trying many different app combinations, I have found that Grip was simply streets ahead, by way of speed of process and configuration.

200+ CDs into the process, and I'm beginning to experience one of two problems at any given time:

1. CD tray will not eject after rip, therefore I have to wait for encoding to finish & close the app for the CD tray eject button to work. This slows down the process enormously, as I am unable to keep ripping and stack up tracks for the encoder to process.

2. The app will rip and encode at low speeds, (1.5x for both processes) when previously it would rip at anything up to 13x and encode a 5+x. This obviously slows progress. Note: during this project, I have nothing else running at all and encoder is given max priority.

I have a good knowledge of the config and I'm confident that everthing is set correctly. Equally, no other app installs od hardware changes have occurred since embarking on this encoding process. These problems arise without intervention and only desist occasionally, again, without intervention.

Have other users found similar oddities, and if so, found any fixes or solutions?

Look forward to your collective input,

Kaine.

bigrigdriver · 01-26-2007, 10:20 AM

I can't help with the variable rip/encode speeds, but I beleive I can help with the eject problem.

In your user directory, look for a hidden file named .grip. In that file, look for these two settings:

eject_after_rip 1
eject_delay 0

That should fix the eject problem.

kaine · 01-26-2007, 11:42 AM

Thanks bigrigdriver,

Found the file, though it appears that the setting you specify is already as you suggest that it should be:

Quote:

GRIP 2
grip_version 3.2.0
cd_device /dev/cdrom
force_scsi
ripexename /usr/bin/cdparanoia
ripcmdline -d %c %t:[.%s]-%t:[.%e] %w
wav_filter_cmd
disc_filter_cmd
mp3exename /usr/bin/oggenc
mp3cmdline -o %m -a %a -l %d -t %n -b %b %w -N %t -G %G -d %y
dbserver freedb.freedb.org
ripfileformat ~/mp3/%A/%d/%t_%n.wav
mp3fileformat ~/mp3/%A/%d/%t_%n.%x
mp3extension ogg
m3ufileformat ~/mp3/%A-%d.m3u
delete_wavs 1
add_m3u 0
rel_m3u 0
add_to_db 0
use_proxy 0
proxy_name
proxy_port 8000
proxy_user
proxy_pswd
cdupdate
user_email kaine@local1
ripnice 0
mp3nice 0
mp3_filter_cmd
doid3 1
doid3v2 1
tag_mp3_only 0
id3_comment
max_wavs 99
auto_rip 0
eject_after_rip 1
eject_delay 0
delayed_encoding 0
delay_before_rip 0
stop_between_tracks 0
beep_after_rip 0
faulty_eject 0
poll_drive 1
poll_interval 1
use_proxy_env 0
db_cgi ~cddb/cddb.cgi
cddb_submit_email freedb-submit@freedb.org
discdb_encoding UTF-8
id3_encoding UTF-8
id3v2_encoding UTF-8
db_use_freedb 1
dbserver2
db2_cgi ~cddb/cddb.cgi
no_interrupt 0
stop_first 0
play_first 1
play_on_insert 0
automatic_cddb 1
automatic_reshuffle 1
no_lower_case 0
no_underscore 0
allow_high_bits 0
allow_these_chars
num_cpu 1
kbits_per_sec 450
selected_encoder 6
selected_ripper 0
play_mode 0
playloop 1
win_width 747
win_height 542
win_height_edit 600
win_width_min 200
win_height_min 80
vol_vis 0
track_edit_vis 0
track_prog_vis 0
volume 255
disable_paranoia 0
disable_extra_paranoia 0
disable_scratch_detect 0
disable_scratch_repair 0
calc_gain 0

I would assume that altering the eject and delay check boxes in the app config panel would write to this file, and as I have the correct settings in the app, the correct settings are reflected in this .grip file. Right?

Kaine.