Please report mcicda (CDROM audio) test results

Saulius,

Saulius Krasuckas wrote:
> It would be nice to indicate disks containing tracks of different types
> (sessions) in the log and to extract some info from the data track.
> Drive info would be also interesting to see in the log.

It is on purpose that I did not write too specific info to the log. I
don't want logs posted to the Internet to contain (too much) sensitive
information, violating your privacy. No CDDB ID.
> Then we would know for sure :)

As far as MCICDA is concerned, it doesn't look like it knows about
multi-sessions.  All it offers is to play music.  Therefore the mcicda
tests is not the right place to look for a disc utility that'll show
you information about your drive and disc.
> me_s2-clean-updated/winmm:mcicda.html

Ah, that's you, good to know.
You can help me debug the ME-only errors in winmm:midi
  midioutXyz returns rc=MMSYSERR_INVALPARAM

Paul Vriens found out that the binary he compiled does not produce
such errors on WinMe, while testbot's binary does. What about your machine?
In testbot job #4990, you'll find a MSVC compiled 150KB binary. Please
run the MIDI tests with it on your WinME machine.

wintest.exe midi
Non-ME output is:
midi.c:298: Test failed: no PARAM error, now setting BytesRecorded too large

testbot would instead trigger
ok(0,"PARAM error, setting BytesRecorded\n");

Thank you,
 Jörg Höhle

[Saulius Krasuckas]

* On Fri, 3 Sep 2010, [e-mail] wrote:
> Saulius Krasuckas wrote:
> > Then we would know for sure :)
>
> As far as MCICDA is concerned, it doesn't look like it knows about
> multi-sessions.  All it offers is to play music.  Therefore the mcicda
> tests is not the right place to look for a disc utility that'll show
> you information about your drive and disc.

OK, I understand the reason in a case of disc, but couldn't differences 
between drives influence the operation result?

To add more to my question I'm quoting your yesterday letter:

* On Thu, 2 Sep 2010, [e-mail] wrote:
> > Your paranoid android.
> > mci.c:714: Test failed: Expect message 0001 from play to 250 wait notify
> > mci.c:721: Test failed: got 0004 instead of MCI_NOTIFY_xyz 0000 from command after close
> > mci.c:782: Test failed: not enough time elapsed 58ms
> > mci.c:838: Test failed: mci status position: 58
>
> Sadly, that's the well-known transient flakyness that I blame on
> vmware's timers (or perhaps native bugs?).
>
> Did anybody with a real machine ever get any similar failures?
> That would be more revealing to analyse.

And didn't investigate, but what is your (and anyone other's) opinion 
about testing CD emulators (like Daemon-Tools or WinCDEmu) on real 
machines?  Could they be reliable tool for testing MCICDA, etc. ?
> > me_s2-clean-updated/winmm:mcicda.html
>
> Ah, that's you, good to know.
> You can help me debug the ME-only errors in winmm:midi
>   midioutXyz returns rc=MMSYSERR_INVALPARAM

OK, switching to private mode :)

S.