Bug 28068 – mplayer and xine: problems handling CD-ROM errors (VLC behaves better)

• Product: Gentoo Linux
• Status: RESOLVED CANTFIX

[Description crusaderky 2003-09-06 12:04:18 UTC]

I've got the 2.4.22 vanilla kernel and the latest mplayer and vlc. 
I have a Philips CDRW1600 IDE cd-burner (40x16x10x), that I use both for recording 
and playing, on /dev/hdc (40-pin UDMA66 cable) and a Maxtor 80GB hard disk on 
/dev/hda (80-pin UATA133 cable) (both with DMA enabled). 
 
I burn a 640mb-long AVI file (that plays perfectly from hard disk) to CD. 
I can re-download it to hard-disk at full speed (using KDE3), without any problems or 
speed losses (which could be symptoms of a non-perfect burn). 
 
If I play it with mplayer or vlc, all goes well if I don't perform any seeks, or if I do them 
about ten seconds after the movie has been started. But if I attempt to seek the file 
(that is, read the AVI index at the end of the CD) immediately after the movie start, I 
get a couple of read errors, followed by an EOF. 
 
If I start playing the movie, wait about 10 seconds, succesfully attempt some seeks on 
the whole file and then close the player, if I then start that (or any other player) on that 
same file, seeks work from the first second, probably thanks to the RAM cache. 

Reproducible: Always
Steps to Reproduce:
1.
2.
3.
Actual Results:  
read errors and EOF report 

Expected Results:  
CD-ROM should slow down, make seeks etc, while the playback hangs for a couple of 
seconds and then restarts at the correct point. 

cdrom entry in fstab: 
/dev/cdroms/cdrom0	/mnt/cdrom	auto	noauto,user,ro,noexec	0 0 
 
kernel boot parameter: "hdc=ide-scsi" 
ide-scsi module is loaded at boot. 
 
mplayer cache is set to 512k. 
 
 
/proc/ide/hdc/settings   content: 
name                    value           min             max             mode 
----                    -----           ---             ---             ---- 
bios_cyl                0               0               1023            rw 
bios_head               0               0               255             rw 
bios_sect               0               0               63              rw 
current_speed           66              0               70              rw 
init_speed              66              0               70              rw 
io_32bit                0               0               3               rw 
keepsettings            0               0               1               rw 
log                     0               0               1               rw 
nice1                   1               0               1               rw 
number                  2               0               3               rw 
pio_mode                write-only      0               255             w 
slow                    0               0               1               rw 
transform               1               0               3               rw 
unmaskirq               0               0               1               rw 
using_dma               1               0               1               rw

[Comment 1 crusaderky 2003-09-06 12:51:21 UTC]

The above report is incorrect:

When the CD has just been inserted, mplayer doesn't work, *at all*. It usually plays some seconds, then crashes, even without making any seeks.
I have to open it with vlc and wait some seconds without seeking. From that moment on, both mplayer and vlc will work perfectly and do seeks from the first second.

Also, sometimes (but not always) vlc can do seeks from the first second also on a freshly mounted cdrom.
xine behaves like mplayer, too.

This happens only on 3 cds I've just burned. Also, the drive is old and frequently gives problems.
So the problem is probably not in the kernel, as the read errors and EOFs come from the junk drive, but it's about how mplayer and xine handle these errors, while vlc behaves (almost) correctly. (note that I've changed the summary for this reason).

Maybe I don't know about some option like "retry reading up to X times when CD drive gives an error", which could be activated by default on vlc and is not on mplayer and xine.

[Comment 2 Tim Yamin (RETIRED) 2003-09-11 05:48:10 UTC]

I'm not really sure if we can do that much about this unless we can somehow replicate this on other hardware. I'm not sure if this is flaky hardware or something else...

I never really experienced anything like this here and this isn't really a Gentoo bug either. Perhaps you should post to the mplayer/.../kernel mailing lists and see if anybody's got anything like this?

Can you try this with another kernel? [gentoo-sources // development-sources]

[Comment 3 crusaderky 2003-09-11 11:10:24 UTC]

Try scratching a CD with a nail or a hard pen. Not too much, or it will become completely unreadable...

I will post this bug report to mplayer and xine mailing lists.

I don't think I have the heart to replace my kernel, but I'm almost sure that the errors are genuinely produced by my damaged hardware and, since Konqueror and VLC work with it without problems, I have to assume it's only about a --retry-on-flaws option.
This error can also occour (I suppose) when streaming from poor mms servers, that randomly kill the connection or cause timeouts. Someone should make a try somehow... and even if these servers are not reliable for streaming, they can be used with mplayer -vo mpegpes -ao mpegpes... which is something I do quite often.

[Comment 4 Markus Nigbur (RETIRED) 2003-09-24 14:25:23 UTC]

My guess is, the lens of the burner is not adjusted correctly anymore. This will cause the laser's focus to get moved slightly to one side, so data gets lost. If you know try to read the data from cd, it will run without problems, because there are gaps and lands on the organic film of the disc, but they might differ from the  correct file.

To make it short: Try another burner, if it works, it's most probably the above described problem.

[Comment 5 crusaderky 2003-09-25 01:40:16 UTC]

I know it's an hardware problem, but since it can be fixed with just a --retry-on-errors=N
option, I'd better not change my burner (until I can afford a DVD-R...)

[Comment 6 Seemant Kulleen (RETIRED) 2003-09-27 16:34:48 UTC]

closing