[Libcdio-devel] Re: [MPlayer-cygwin] Re: cdda and vcd options for mingw/cygwin

[R. Bernstein]

Erik Lunchpail writes:
 ... [libcdio CVS compiled under cygwin]
 > Firstly, it just fails because there's no version.texi
 > in doc from CVS, which I just copied from a release
 > tarball.

At the time, probably that was the simplest most straight-forward thing
to do. I just looked at the way this is handled in the CVS for the
automake project; it seems they just check this file into CVS, even
though it is generated automatically when documentation changes. Seems
odd to me, but I'm assuming automake developers know what they are
doing. (Hmmm... given the hassles I have with automake, I could be
very wrong here.) I've just checked version.texi into CVS. At least
for the time being,

...
 > low_interface.h:33:23: sys/ioctl.h: No such file or
 > directory ...
 > fixed with some #ifndef's,

Actually, I've just removed them altogether in the CVS. This was for
device-specific stuff that's handled in libcdio. I'm not sure *all* of
it was even needed in GNU/Linux cdparanoia. There may be some breakage
on some platforms, but since this is immediately after a release, now
is a good time to break things.

 > 
 > scan_devices.c:34:17: pwd.h: No such file or directory
 > scan_devices.c: In function `cdio_cddap_find_a_cdrom':
 > scan_devices.c:118: warning: implicit declaration of
 > function `getpwuid' ...

I think also fixed in CVS. cdparanoia has/had a great deal of
GNU/Linux and Unixisms to be user friendly. This stuff is used to tell
you that user Erik might not have permission to access the CD-ROM
drive.  (Hmmm... this code might be nice to add in libcdio proper for
those platforms where it is meaningful).

 > scan_devices.c: In function `test_resolve_symlink':
 > scan_devices.c:161: warning: implicit declaration of
 > function `lstat' ...

Also fixed in CVS, I think. What's going on here is that cdparanoia in
Unix is trying to tell you what real name of the device is for the
user-friendly name that you gave it. I had noticed that this was
irrelevant on 'Doze.

It is interesting though is that on my boxes that I have cygwin
installed, although the above is optional and not needed, in fact I
had all of the headers and functions.

 > I forget what i did with this, it was a while ago.

A pity you didn't report the problems while ago when you got
them. Especially given at how easy it seems to have been to fix this
(if indeed they are now fixed and other things haven't been broken);
had it been mentioned previously it probably would have been in the
0.72 release. If the next release is like the last it will probably be
at least a couple of months before another release.

 > Even with the troublesome block uncommented, and the
 > cdda_interface library created, it ends with many
 > unresolved symbols, some of which i resolved by with
 > additional library linking.

The warning message associated with lstat() and other "implicit
declaration"s (from your previous post and not shown above) suggests
there would been a linking problem. I think though there won't be a
problem now or most of the problems will have been fixed. I haven't
tested this on cygwin though.

 > 
 > Ok next, vcdimager:
 > 
 > Again, version-vcd-info.texi, vcd-vcdxrip.texi not in
 > docs, fixed by coping from a release. 

Fixed in CVS -- the same way as above.

 > At the time
 > there might have been a compile error but i forget,
 > seems to work fine now if you add the .texi files.

Okay, nice to know.

 > 
 > > 
 > > This may seem a bit obvious, but if you have
 > > problems andyou keep it pretty much
 > > to yourself it's probably not going to get fixed let
 > > alone do all that much good
 > > to others who might have the same problem ;-)
 > 
 > Granted, yet my skillset does not lie in programming,
 > in any language. My approach is, if I can't fix it, I
 > comment it out, which is laughable at best, especially
 > to those with programming knowledge. So my best bet is
 > to bring attention to the problem so that I can get a
 > "plumber to fix the plumbing", rather than fiddle with
 > pipes while up to my knees in water :)

Okay. But as suggested above, if you had just given enough detail of
what you saw (whether you understood it or not) and directed it to
someplace where it's likely to get addressed, *maybe* it will get
addressed - like it may have just been. You originally wrote:

>   Unfortunately, I just can't get it [libcdio] to work under
>   mingw. 

Forgive me for taking you to task on this, but as someone who
wrote/distilled libcdio more for the general good rather than my
specific needs, I find this kind of attitude a little bit annoying and
endemic.  What you write is undoubtably true - no question. But on
further inspection, first you profess not having much programming
skill and second you made no attempt to direct it at the time the
place most appropriate for it to be fixed. (I suggest that mailing
list for mplayer on cygwin just isn't the most suitable place to get
libcdio problems fixed - especially as mplayer currently doesn't use
it yet.)

So let me also suggest this is may be more a reflection on you than it
is on libcdio which at present does work at least for me on cygwin.
(This might not have been clear to anyone reading your initial post.)

 > 
 > > In mplayer? In the CVS source I looked at and I just
 > > updated I don't see mkdir
 > > and it seems a bit odd that a CD-DA plugin for
 > > Mplayer would be trying to create
 > > a directory, no?
 > 
 > s/cdda.c/cddb.c (grep mkdir in libmpdemux, it's the
 > only file that returns)

Sigh. You touched on another slightly sore nerve. But it's not really
not your fault. Bear with me. There is a library right now that
handles cddb fine on cygwin. It's called libcddb
(http://libcddb.sourceforge.net). Because it uses Unix regular
expressions it needs the cygwin runtime - but it still works.

It is a bit sad to me that most of the media players that have CDDB
support, like Mplayer, don't use this library. In fact, from what I've
seen say on xine (with respect to say. RSTP code), there are some who
relish the opportunity to write their own code to learn how to do it;
too often it is just cut-and-paste code from somewhere else.

My point is that had libcddb been used, you probably wouldn't have had
this problem and you might even get better, more complete CDDB
handling than what Mplayer currently provides. (libcddb for example
handles the latest CDDB protocol and has Unicode or multi-language
text support which I don't think Mplayer currently has.)

 ... [vlc media player]
 > It seems to me to be the most viable solution at the
 > moment for cdda and vcd playback for mingw builds, but
 > as stated above, I really don't have the tools to make
 > a fair assessment. It would be nice to see support for
 > those options in the mingw builds in the near future.

If libcdio, vcdimager libcddb were used in mplayer (which they are not
right now), it'd be just 3 less things to address/fix since they
work. To be fair, in the case of VCD playing what's in mplayer isn't
broken as much as not very complete with respect to any of the VCD
standards

 > Understandably, functionality and stability are the
 > main focuses for mplayer, 

Again if that's really true then again libcdio/libcddb/vcdimager would
the method of choice. Although stability may be a bit tough to assess,
these libraries definitely currently have more functionality in their
areas of expertise than the corresponding mplayer equivalent. And all
3 come with regression tests and documentation in there little
domain. If there is even an fully automated regression test suite for
mplayer, I doubt that those various small aspects that libcdio,
libcddb and address are tested as thoroughly as they are in the
libcdio/libcdd/vcdimager packages. Ditto for documentation.  In fact I
contributed fixes for what little there is for VCD. It really isn't
all that much or detailed. Not that I think that for most people it
has to be. But it doesn't hurt when someone needs or wants the extra
info or develop more code.

 > unfortunately the
 > side-effects are "slow-going" additions to the windows
 > build ie. cdda, vcd, gui(which most windows users
 > can't do without.)

Good point. You know, as a would-be developer for mplayer VCD/CDDA, I
find this troubling too. Good-quality VCD playback means handling
still-frames, menu selections, navigation events
(next/return/default). I'm not sure that at the mplayer has API for
much of this yet. The lack of a suitable (or more precisely ongoing
development of a suitable) API has been a real PITA in vlc.