* On Fri, 3 Sep 2010, joerg-cyril.hoe...@t-systems.com 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, joerg-cyril.hoe...@t-systems.com 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.