"IOException: The device is not ready" when loading .cue

[ghost]

Summary

When I try to an error message box appears instead of booting the game.

Repro

Just click File => Open ROM... or simpy press Ctrl+O and then open "Sonic 3D Blast.cue" and then this error message box appears on screen.

Output

A core accepted the rom, but threw an exception while loading it:
System.IO.IOException: The device is not ready.
  at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
  at System.IO.FileSystemEnumerableIterator`1.CommonInit()
  at System.IO.FileSystemEnumerableIterator`1..ctor(String path, String originalUserPath, String searchPattern, SearchOption searchOption, SearchResultHandler`1 resultHandler, Boolean checkHost)
  at System.IO.DirectoryInfo.InternalGetFiles(String searchPattern, SearchOption searchOption)
  at BizHawk.Emulation.DiscSystem.CUE.CueFileResolver.Resolve(String path)
  at BizHawk.Emulation.DiscSystem.CUE.CompileCueJob.OpenFile(FILE f)
  at BizHawk.Emulation.DiscSystem.CUE.CompileCueJob.Run()
  at BizHawk.Emulation.DiscSystem.DiscMountJob.<RunBizHawk>g__LoadCue|15_0(String cueDirPath, String cueContent)
  at BizHawk.Emulation.DiscSystem.DiscMountJob.RunBizHawk()
  at BizHawk.Emulation.DiscSystem.DiscMountJob.Run()
  at BizHawk.Emulation.DiscSystem.DiscExtensions.CreateImpl(Nullable`1 type, String path, Action`1 errorCallback)
  at BizHawk.Client.Common.RomLoader.LoadDisc(String path, CoreComm nextComm, HawkFile file, String ext, String forcedCoreName, IEmulator& nextEmulator, GameInfo& game)
  at BizHawk.Client.Common.RomLoader.LoadRom(String path, CoreComm nextComm, String launchLibretroCore, String forcedCoreName, Int32 recursiveCount)

Host env.

• BizHawk 2.8, Win10 Enterprise 21H2, Intel x64

[CasualPokePlayer]

The nature of the error would imply this is not at all related to the actual game per se, as it ends up erroring in internal OS code when trying to resolve the .cue files. Could you post the exact .cue file? Also, where exactly did you place this .cue file?

[ghost]

The nature of the error would imply this is not at all related to the actual game per se, as it ends up erroring in internal OS code when trying to resolve the .cue files. Could you post the exact .cue file? Also, where exactly did you place this .cue file?

I placed the .cue file in a directory where I place all the games that I want to play in the future and the content of the .cue file is:

FILE "F:\SEGA SATURN\101-150\125 SONIC 3D BLAST (U).BIN" BINARY
TRACK 01 MODE1/2352
INDEX 01 00:00:00
TRACK 02 AUDIO
PREGAP 00:02:00
INDEX 01 06:17:21
TRACK 03 AUDIO
INDEX 01 07:10:24
TRACK 04 AUDIO
INDEX 01 07:21:30
TRACK 05 AUDIO
INDEX 01 09:52:22
TRACK 06 AUDIO
INDEX 01 13:03:13
TRACK 07 AUDIO
INDEX 01 16:21:55
TRACK 08 AUDIO
INDEX 01 19:47:42
TRACK 09 AUDIO
INDEX 01 22:58:06
TRACK 10 AUDIO
INDEX 01 25:45:42
TRACK 11 AUDIO
INDEX 01 29:18:05
TRACK 12 AUDIO
INDEX 01 31:52:44
TRACK 13 AUDIO
INDEX 01 35:03:12
TRACK 14 AUDIO
INDEX 01 37:57:03
TRACK 15 AUDIO
INDEX 01 41:04:34
TRACK 16 AUDIO
INDEX 01 44:00:39
TRACK 17 AUDIO
INDEX 01 46:49:56
TRACK 18 AUDIO
INDEX 01 49:43:31
TRACK 19 AUDIO
INDEX 01 52:32:54
TRACK 20 AUDIO
INDEX 01 55:01:21
TRACK 21 AUDIO
INDEX 01 57:53:46
TRACK 22 AUDIO
INDEX 01 58:21:17
TRACK 23 AUDIO
INDEX 01 58:48:14
TRACK 24 AUDIO
INDEX 01 58:55:71
TRACK 25 AUDIO
INDEX 01 59:16:11

[nattthebear]

in a directory where I place all the games that I want to play

Is that directory F:\SEGA SATURN\101-150? Probably not. The .cue references an absolute location that doesn't exist.

[CasualPokePlayer]

Remove the F:\SEGA SATURN\101-150\ and make sure the 125 SONIC 3D BLAST (U).BIN file is next to the .cue file.

[ghost]

Remove the F:\SEGA SATURN\101-150\ and make sure the 125 SONIC 3D BLAST (U).BIN file is next to the .cue file.

Why BizHawk doesn't show me a clear error message box?

[nattthebear]

It does. Drive F: is not ready, and you'd get the same if you tried to access it in Windows Explorer.

[CasualPokePlayer]

BizHawk is not a human, it doesn't understand that you're "asking" to access drive F because you got your dump from some shady site and didn't put it in there yourself (if you otherwise dumped it yourself like you are "supposed" to this would not be an issue, even then how people find these weird fubared dumps is beyond me) and doesn't understand the exact solution.

(EDIT: ignore issue reopen, finger misclicked)

[YoshiRulz]

I agree that "The device is not ready" is not a helpful message for the end-user. We should encapsulate directory enumeration and throw "file not found" in that case. (And then handle missing files in .cue parsing better.)

[ghost]

I corrected the .cue file according to your suggestion and now BizHawk plays the game fine. Looks like that I made a mistake while dumping this game. I am not so good at dumping my games and I don't like that I have to repeat this process for every game that I want to play on my PC but not that I have another choice. With a proper error message box I wouldn't open this issue at all in first place.

Except not helpful errors BizHawk is indeed an excellent software to play and cheat my retro games on my PC once BizHawk can play them.

[Morilli]

We should encapsulate directory enumeration and throw "file not found" in that case. (And then handle missing files in .cue parsing better.)

fwiw the core does usually throw a DirectoryNotFoundException when using an invalid path, and the error message is helpful. This specific IOException only happens when the path specified links to an existing, but not accessable device (for example a physical disk slot that has nothing inserted).

[ghost]

We should encapsulate directory enumeration and throw "file not found" in that case. (And then handle missing files in .cue parsing better.)

fwiw the core does usually throw a DirectoryNotFoundException when using an invalid path, and the error message is helpful. This specific IOException only happens when the path specified links to an existing, but not accessable device (for example a physical disk slot that has nothing inserted).

This puts me in blackout to see a so detailed error message box if "directory not found" is the only problem here.

Especially C# like exceptions which are irrelevant for users that are not .NET developers.

When I see such errors this drives me to open another issue here to paste the detailed error here.

I think that this must still be improved.

If "directory not found" is the only problem that prevents the user from playing his or her game then the error message box should be three words only: "Directory not found" and that's all though this is advised to specify the directory that BizHawk attempted to open and failed because BizHawk didn't find it after these three words in the second line.

This is my opinion.

Sounds logical isn't it?

[nattthebear]

I agree that "The device is not ready" is not a helpful message for the end-user.

I disagree strongly. That is the canonical message that MS Windows gives end users if, for instance, you try to access a floppy drive with no disk in it. It's distinct from path or file not found; more like "Drive not found" but a bit more complex because the drive might exist but just isn't ready. Boiling down all IOExceptions to just a generic "not found" hurts user debugging.

[CasualPokePlayer]

Stacktraces are immensely useful for bug reports. While here there isn't an actual bug per se (at most, not useful super useful error messages), it was still helpful to see the stacktrace as we can use that to immediately track down the potentially problematic code.

[nattthebear]

It would be nice to have the full pathname of the faulting file here.

[ghost]

I agree that "The device is not ready" is not a helpful message for the end-user.

I disagree strongly. That is the canonical message that MS Windows gives end users if, for instance, you try to access a floppy drive with no disk in it. It's distinct from path or file not found; more like "Drive not found" but a bit more complex because the drive might exist but just isn't ready. Boiling down all IOExceptions to just a generic "not found" hurts user debugging.

I am a windows user for many years and with windows applications and programs that I was using over the years every time that a file or folder or directory or path was not found I saw an error message box that explicitly state it.

I don't remember that I was seeing the words "device" or "ready" at all.

Besides error message should not be so big, so long and so detailed just because a file was not found.

In such cases the error message should be at most 2 lines.

[nattthebear]

I don't remember that I was seeing the words "device" or "ready" at all.

As google shows, it's quite common even now that floppies are dead due to removable USB media: https://letmegooglethat.com/?q=device+not+ready

[YoshiRulz]

🤏 This close to clicking the lock button.

Malformed .cues are a common problem for our users and it's apparent that the UX could do with a rework. Debating exactly which text is shown in the error dialog is missing the point; the app shouldn't give up and slap a "this is your problem now" in the user's face when it could recover and analyse, maybe list some options. So I'd ask everyone to save their comments unless it's to suggest an improved UX design.

[ghost]

I don't remember that I was seeing the words "device" or "ready" at all.

As google shows, it's quite common even now that floppies are dead due to removable USB media: https://letmegooglethat.com/?q=device+not+ready

I am not dealing with floppies at all.

[nattthebear]

I am not dealing with floppies at all.

It's hard for me to take this as anything other than you deliberately ignoring everything I've said and linked to. As is shown in many of the results there, the problem happens for floppies, CDs, usb sticks, network drives... all sorts of things. And I even said "removable USB media" in my comment, referencing the stick drives.

At the end of the day, we've had these cue error messages from nonsensical pirated cue files for years, yet users get along fine. We're not ripping up all of discohawk just because of one person decided to make many comments on a github issue.

And no, I don't believe you ripped this game yourself, otherwise you would know what your own F: drive was.