[SOLVED] GRip suddenly not seeing CDs

[Leo David Orionis]

Hello:

I'm in the middle of ripping all my CDs to my computer.  I rip and encode the CDs with GRip and scan the disks and album art at 300 dpi.  Then I put the CDs away in boxes forever.

Overnight GRip has stopped seeing CDs in my drive.  Yesterday everything worked fine.  Today it says "No Disc".  Nothing has changed on the computer.

I tried uninstalling GRip, turning off the computer, rebooting, installing GRip -- nothing.  Turned off the computer again, turned it on and tried again -- nothing.

K3b sees the CDs fine, but K3b is slower than GRip and names the files differently, so that's not a solution.  Anyway, it's important to keep ALL our options open.  One of the great
things about Linux is that there are many different ways to do anything, not just one way.

Just as an experiment, I installed another ripper called Asunder.  Asunder  also doesn't see the CDs.

Any ideas?  I'm still using 2009.2, and here's my fstab in case that helps (not that it's changed since yesterday):

# Entry for /dev/sda1 :
UUID=516eba05-6964-4c55-8e79-505f933edad3 / ext3 defaults 1 1
none /dev/pts devpts mode=0620 0 0
# Entry for /dev/sdb1 :
UUID=9816c652-8a75-49fc-b8fa-2c638844d16c /disk1 ext3 defaults 1 2
# Entry for /dev/sdc1 :
UUID=1a761c07-786b-4c4b-9e8a-d5577f6568db /disk2 ext3 defaults 1 2
# Entry for /dev/sdd1 :
UUID=3eeea705-32dc-4495-8558-abefda1f831d /disk3 ext3 defaults 1 2
# Entry for /dev/sde1 :
UUID=2ca051d3-4edc-47af-ba14-e1543e2ea670 /disk4 ext3 defaults 1 2
# Entry for /dev/sdf1 :
UUID=c60aea21-f71b-43fd-8370-96468f5e06fe /disk5 ext3 defaults 1 2
# Entry for /dev/sda5 :
UUID=48dfa832-b52f-4bc4-921e-636e26f79df2 /home ext3 defaults 1 2
/dev/sr0 /media/cdrom auto umask=0,users,iocharset=utf8,noauto,ro,exec 0 0
none /proc proc defaults 0 0

Any help would be much appreciated! -- Leo

[wedgetail]

I do not know GRip but I am guessing you start it using the mouse to select and click somewhere.

In an effort to get some more diagnostic it is possible that if you start GRip from a konsole/terminal window that you will see some more information that can give a clue.

[Leo David Orionis]

Thanks for the suggestion.  I started GRip from a console and got the following:

/usr/share/themes/Clearlooks/gtk-2.0/gtkrc:49: Invalid symbolic color 'bg_color'
/usr/share/themes/Clearlooks/gtk-2.0/gtkrc:49: error: Invalid identifier 'bg_color', expected valid identifier

No other messages, and disk still not found.

[wedgetail]

You can see the cd in Konqeror, I am just asking to be sure? And you can see some content?

[Leo David Orionis]

Hello again:

Yes, I can see the CD in Konqueror, and it shows up as an icon on my desktop.  I can even click on it, and drag the flacs to another window.  But this is very slow, many many times slower even than K3b.

Incidentally, just as an exercise, I wrote a Perl program to convert the file names K3b gives the FLACs to the way GRip names them:

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

#!/usr/bin/perl

# Short program to rename FLAC files created by K3b, replacing capital letters
# with lower case and eliminating any characters except letters and numbers.
# Leo David Orionis 7/7/2010

use File::Copy "mv";

# Remove any files left from previous passes.
`rm -f *.ogg`;
`rm -f *.m3u`;
`rm -f played.dat`;

# Read directories and get names of FLAC files.
opendir (DIR, ".") || die "Can't open directory.";
@files = grep(/\.flac$/, readdir (DIR));
closedir (DIR);

# Sort the list of files.
my @sortedfiles = sort @files;

# Open the index file.
open (MYFILE, '>00_index.m3u');

# Rename each file and append it to the 00_index.m3u file.
foreach $file (@sortedfiles)
{
  # Rename the file.
  $newfile = $file;
  $newfile =~ tr/[A-Z]/[a-z]/;  # Convert upper case to lower case
  $newfile =~ s/[\', \", \(, \)]//g;    # Remove other characters in file names
  mv ("$file", "$newfile");

  # Append the file to the index file.
  print MYFILE "$newfile\n";

}

# Print a blank line to the end of the index file, then close it.
print MYFILE "\n";
close MYFILE;

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

[wedgetail]

Oooooohh, now you have lost me. Tell me more what your thinking is, I am lost.  Can you just rename files and still use them??

I would like to have a look at your dmesg file:

Code: [Select]

[root@localhost log]# dmesg >/home/gert/dmesg.txt
[root@localhost log]#


You need of course to change to your own username in above, ie if you use this, the file can be placed anywhere but i have elected to send it to my /home/gert account.

Attach file to your next post, and I will have a look through

[Leo David Orionis]

Dear Sir:

1.  dmesg.txt file attached.

2.  Sorry if I confused you with my Perl program.  It has no bearing on the problem.  It's just that the two reasons I prefer GRip to K3b are (a) GRip is faster, and (b) K3b names the flac files differently.
So I thought, if we can't fix the problem, perhaps I can use K3b temporarily.  The program goes through a directory with names like 01_(You're_My_One_And_Only)_True_Love.flac,
02_Two_To_Make_It_Right.flac, 03_Could_This_Be_Love.flac, etc. and renames the files to 01_youre_my_one_and_only_true_love.flac, 02_two_to_make_it_right.flac,
03_could_this_be_love.flac, etc.  It also produces an m3u file so that the whole CD can be played by just clicking on that file.  That makes any CDs I rip with K3b consistent with the ones I ripped
with GRip.

3.  Just tried GRip again.  It works now!  And so does Asunder, the alternate ripper I installed.  What the hey?  Any ideas?

[wedgetail]

leoorionis
The attachment seems to be an extract from dmesg but not the full dmesg, how did you get it? Did you follow the instructions above?

From the dmesg you attached I have extracted a few lines from amongst all the lines which I think relates to a firewall, I have left two lines from the beginning.

:00 SRC=71.170.56.144 DST=68.101.150.246 LEN=58 TOS=0x00 PREC=0x20 TTL=113 ID=6505 PROTO=UDP SPT=33681 DPT=6881 LEN=38
Shorewall:net2fw:DROP:IN=eth0 OUT= MAC=00:1e:8c:89:77:dd:00:30:b8:c2:72:50:08:00 SRC=98.232.95.99 DST=68.101.150.246 LEN=64 TOS=0x00 PREC=0x00 TTL=50 ID=21195 DF PROTO=TCP SPT=42593 DPT=6881 WINDOW=65535 RES=0x00 SYN URGP=0

sr0: CDROM not ready yet.
sr0: CDROM not ready yet.
sr0: CDROM not ready yet.
sr0: CDROM not ready yet.
sr0: CDROM not ready yet.
sr0: CDROM not ready yet.
sr0: CDROM not ready yet.
sg_write: data in/out 56/56 bytes for SCSI command 0x12--guessing data in;
   program kio_audiocd not setting count and/or reply_len properly

From this my opinion is that you do have a problem but this is beyond me.  To me it seems there is a firewall involved but the purpose I don't understand, the number of  firewall entries in dmsg is overwhelming and to me indicates there is something wrong. Then there are times when the CDROM is not ready, why not? Excessive time delay because of firewall drops?  I don't know, you have explained if the pc and drive is separated by the firewall (on another computer or network)

Perhaps somebody with more experience can figure out what the quote means.  Much more information is needed about your system and setup and also your expertise. Since you are writing scripts I made the assumption your are experienced with Linux systems  

The beginning of a dmesg looks like this:

[root@localhost guest]# cat /var/log/dmesg
Linux version 2.6.32.12-pclos1.bfs (root@localhost.localdomain) (gcc version 4.4.1 (GCC) ) #1 SMP PREEMPT Sat May 1 08:22:13 CDT 2010
KERNEL supported cpus:
  Intel GenuineIntel
  AMD AuthenticAMD
  NSC Geode by NSC
  Cyrix CyrixInstead
  Centaur CentaurHauls
  Transmeta GenuineTMx86
  Transmeta TransmetaCPU
  UMC UMC UMC UMC
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
 BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 000000003fffc000 (usable)
 BIOS-e820: 000000003fffc000 - 000000003ffff000 (ACPI data)
 BIOS-e820: 000000003ffff000 - 0000000040000000 (ACPI NVS)
 BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved)
 BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
 BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved)
DMI 2.3 present.
last_pfn = 0x3fffc max_arch_pfn = 0x100000

This is from LivedCD 2010.1 test on one of my machines.     

[Leo David Orionis]

Dear Wedgling:

I believe I've figured out what's going on!

I'm running Windows XP Pro under VMware Player 3, because my HP Scanjet G3110 doesn't work under PCLOS 2009.  When I got home tonight, I brought up the virtual machine and checked whether the DVD drive
was connected or disconnected.  It was connected.  I disconnected it.  POOF, now GRip and Asunder work correctly.  I connected the DVD drive.  They still work.  I shut down the virtual machine with the drive
still connected; now they don't work.

So the answer seems to be, if you shut down a VMware Player 3 virtual machine with a CD or DVD drive connected to it, GRip and Asunder (and maybe other rippers) will be blocked from reading a disk in that
drive.  I assume, but have not tested, that if you have more than one optical drive you could still use GRip and Asunder with any drive that wasn't connected to the virtual machine.  I can't say why K3b isn't
affected; I would guess it's a little better written and ignores the fact that the drive is connected to a virtual machine that isn't even running.  Good on it, I say.

Thanks for all your help.  I appreciate your digging into the matter.  I think it was some of the questions you were asking that put me on the right track.

[wedgetail]

Congratulations  

I was starting to suspect you were not telling the whole story.    Using VMware in my opinion was a very important piece of information if you had mentioned that earlier you would have attracted the experts in the use of emulators. My guess also would be you have been asked to test your procedure in pclos2010-whatever desktop and then procede to emulation run again.  

I think this problem may be interesting for others running emulations.  Who knows if somebody can figure out what the problem may be.

You have not answered where you got your dmesg from.  There could be vital information in the file. Could you copy the dmesg both with and without the VM-gizmo running? I am interested investigating this a bit more.