grip freezing up computer while encoding.
 

im having major issues with grip when trying to rip a cd. Normally when i have ripped in the past it will rip a track and as the next track is ripping the previous one will encode. Now im having it so all the tracks rip way before it is finished encoding and about halfway through encoding the computer locks up and i have to reboot via the power button. Also i have to constantly remodify the permissions to /dev/hdc and hdd to rw so that grip and find the cd and start ripping. It is grip version 3.2.0 on fedora core 3. thanks for any help in advance.

ok i tried a third time and again the computer froze. I noticed the light on the cdrom blinks while it is ripping and then about halfway the light stops and the computer freezes up. here is the result of /var/log/messages | grep /dev/hdc *hdc is my burner*

[root@localhost jeff]# cat /var/log/messages | grep hdc
Aug 14 13:39:53 localhost kernel: ide1: BM-DMA at 0x14c8-0x14cf, BIOS settings: hdc:DMA, hdd:DMA
Aug 14 13:39:53 localhost kernel: hdc: SONY CD-RW CRX320E, ATAPI CD/DVD-ROM drive
Aug 14 13:39:53 localhost kernel: hdc: ATAPI 52X DVD-ROM CD-R/RW drive, 2048kB Cache, UDMA(33)
Aug 14 16:14:48 localhost kernel: ide1: BM-DMA at 0x14c8-0x14cf, BIOS settings: hdc:DMA, hdd:DMA
Aug 14 16:14:48 localhost kernel: hdc: SONY CD-RW CRX320E, ATAPI CD/DVD-ROM drive
Aug 14 16:14:48 localhost kernel: hdc: ATAPI 52X DVD-ROM CD-R/RW drive, 2048kB Cache, UDMA(33)
Aug 16 16:22:50 localhost kernel: ide1: BM-DMA at 0x14c8-0x14cf, BIOS settings: hdc:DMA, hdd:DMA
Aug 16 16:22:50 localhost kernel: hdc: SONY CD-RW CRX320E, ATAPI CD/DVD-ROM drive
Aug 16 16:22:50 localhost kernel: hdc: ATAPI 40X DVD-ROM CD-R/RW drive, 2048kB Cache, UDMA(33)
Aug 16 16:22:50 localhost kernel: hdc: command error: status=0x51 { DriveReady SeekComplete Error }
Aug 16 16:22:50 localhost kernel: hdc: command error: error=0x54
Aug 16 16:22:50 localhost kernel: end_request: I/O error, dev hdc, sector 865280
Aug 16 16:22:50 localhost kernel: hdc: command error: status=0x51 { DriveReady SeekComplete Error }
Aug 16 16:22:50 localhost kernel: hdc: command error: error=0x54
Aug 16 16:22:50 localhost kernel: end_request: I/O error, dev hdc, sector 0
Aug 16 16:22:50 localhost kernel: hdc: command error: status=0x51 { DriveReady SeekComplete Error }
Aug 16 16:22:50 localhost kernel: hdc: command error: error=0x54
Aug 16 16:22:50 localhost kernel: end_request: I/O error, dev hdc, sector 0

any help would be appreciated. This is frustrating. Freezing up makes me feel like im using a windows box.

i think this might have to do with my computer freezing up.

Aug 21 15:05:23 localhost smartd[2364]: Device: /dev/hda, 13 Currently unreadable (pending) sectors
Aug 21 15:05:23 localhost smartd[2364]: Device: /dev/hda, 12 Offline uncorrectable sectors

am i correct? wat is smartd? i assume the d is for daemon. thanks for any replies in advance.

while googling around i found this and imagine it could also contribute to the problem.

"Due to debugging code left accidently in the FC3 udev package, SIGCHLD signals are blocked in udev, which prevents getting the proper exit status in udev.rules. This means no cdrom symlinks are created and pam_console does not apply desktop user ownerships to any cdrom devices."

im just not sure.

i get these messages when i did the system check in k3b. Would they affect the performance of grip you think?


cdrecord does not run with root privileges
It is highly recommended to configure cdrecord to run with root privileges. Only then cdrecord runs with high priority which increases the overall stability of the burning process. Apart from that it allows changing the size of the used burning buffer. A lot of user problems could be solved this way. This is also true when using SuSE's resmgr.
Solution: Use K3bSetup to solve this problem.
Unable to find cdrdao executable
K3b uses cdrdao to actually write CDs.
Solution: Install the cdrdao package.

i was able to make it through a ripping without the computer crashing. I was successfuls after updating my whole system. I noticed, while using top simutaneously, that lame took up 70% or so of the cpu on average while ripping and after half way through the cd it was staying at 98 percent pretty steady. is that normal or not? also i noticed at one point next to lame in top it sayd (defunct) what does that mean? also i've noiced that the ripping finishes a lot faster then it has in the past. i could be mistaken but before the encoding was normally only a track or two behind. Does anyone know the reason behind this?

I have seen a similar post somewhere (I don't remember where). The solution was to edit the grip setup. Increase the size of the buffer, and decrease the speed of the rip so that rip doesn't run faster than buffer can supply signal.

i don't see an option to increase the buffer in grip. Is that something i'd have to do through the system? Also i don't see an option to adjust speeds but you can adjust both the rip and encode nice level. Right now both are at zero. Doesn't nice have to do with priorty? So maybe if i gave the encode a little more priority they would finish closer together? I know nice has a range like -20 to 20 i believe. Which means higher priorty? -20?

I believe you CAN edit the buffer size by editing options your CD ripper (cdparanoia, cdda2wav ...) uses. This can be done from within Grip if I remember correctly.