Menu
▾
▴
#38 CDemu should (optionally) take its time to load or unload an image
The shell scripts I use to load my games go along these lines:
umount /media/cdemu
cdemu unload 0
sleep 2 (<-- important)
cdemu load 0 DISC
mount /media/cdemu
/pathto/game
Since "cdemu" isn't the main program itself but just a controller for cdemu-daemon, it makes sense for it to stop running as soon as the command is issued, rather than waiting for the ~1.7 seconds it might take to complete.
However, in some scripts, this'll create issues in specific cases where it's too slow to keep up with the rest of it. In my case, these kinds of scripts will often fail on every odd run (even runs will be fine since the image will have finished being loaded from the first command, and not successfully unloaded before the next run) without my "sleep" workaround earlier, with this output:
"ERROR: Failed to load image: g-io-error-quark: GDBus.Error:net.sf.cdemu.CDEmuDaemon.errorDaemon.AlreadyLoaded: Device is already loaded! (36)"
I think it'd be ideal if there were some kind of launch option, for just cdemu's "load" command if not everything else, for the program to wait until cdemu-daemon has completed its task before terminating. I'm guessing the general way this'd be implemented is if the client (cdemu) would wait for some kind of return code from the server (cdemu-daemon) in these specific cases.
I hope I've made some sense.
Actually, the D-BUS method invocation finishes (i.e., the server returns the status code to the client) after the requested command is complete.
The problem you are facing is that the "unload" command is not a "hard" (forced) unload, but rather it emulates the behavior of pressing the eject button on the physical device. That is, if the tray is locked (via PREVENT/ALLOW MEDIUM REMOVAL command; for example, when device is mounted), the unload command generates an EjectRequest media event and finishes (that why you're seeing an "early end"). This event is then picked up by the OS, which unlocks the device, and unloads it (by issuing START/STOP UNIT command).
So my guess is that in the failed cases, the unmount command is the one that did not finish fast enough and the device was still locked when unload is issued. Which in turn causes the subsequent load fail, because the unload cycle starts happening asynchronously to the script.
Perhaps issuing an eject to the device (eject /dev/srX) instead of unmount and unload would work better in this case? It requires you to know the device mapping, though...
Running "eject" on the virtual device works perfectly, thanks for the help.
"Unload" command seems like it works as intended, but I wonder whether that might cause confusion with anyone else. I wouldn't want CDemu's function as a CD drive emulator hurt over things like this.