#1005 error and slow Nimbie loading/rejecting

[darcyruppert]

Hello,

I've been testing an IROMLAB/Nimbie workflow on a collection of CD-Rs at the museum I work at. I have successfully created disc images, but each batch manifest reports success as FALSE, with a 1005 error in the Isobuster log. Each disc also takes a long time to process, seemingly because of long pauses before loading and rejecting discs. I've attached an example batch log, where you can see that 10 minutes pass between the " Loading disc " notification and the actual load command:

2024-03-25 11:01:51,852 - INFO - Loading disc 2024-03-25 11:11:38,832 - INFO - load command: C:\Program Files\dBpoweramp\BatchRipper\Loaders\Nimbie\Load\Load.exe --drive=F --rejectifnodisc --logfile=C:\Temp\6NhBdJv1RuQ8.log --passerrorsback=C:\Temp\GEaKXfQnfws5.err

Rejecting the disc is similar, with 5 minutes passing between notification and command. In total it takes 20 minutes to process 1 disc. Creating disc images in Isobuster by itself takes roughly 3 minutes. I'm not sure if the "success=FALSE" and 1005 error are related to the long processing time, but I don't have any other leads. I've also attached my config as a txt file.

batch.log

config_txt.txt

[bitsgalore]

What IsoBuster version are you using? I came across some unexplained 1005 errors (which usually indicate the user manually interrupted the imaging, which obviously isn't the case here) while working with IsoBuster 5.x on a spinoff project for floppy discs:

https://github.com/KBNLresearch/ipmlab/issues/15

Since I ended up using something else there for the floppy imaging I never followed this up. For our operational optical disc workflow we're still using IsoBuster 4 (don't remember the exact version), and I haven't tested it with version 5. This might explain part of the issue.

But it doesn't explain the 5 minute delay after the reject command is issued:

2024-03-25 11:14:48,518 - INFO - *** Rejecting disc ***
2024-03-25 11:19:47,143 - INFO - reject command: C:\Program Files\dBpoweramp\BatchRipper\Loaders\Nimbie\Reject\Reject.exe --drive=F --logfile=C:\Temp\WTDADT3dFhdq.log --passerrorsback=C:\Temp\LyWgDsJyTDTz.err

This makes me wonder if this might be some hardware issue (most likely related to the Nimbie's optical drive).

Also, I remember we had some similar problems (at least unexplained delays) years ago after we had first set up our operational workflow. From what I recall, those were related to the drive configuration in dbPoweramp (explained here). I can't find exactly how we fixed that, but from what I remember we managed to get things working by re-configuring the drive.

Let me know if this helps!

[bitsgalore]

Come to think of it, I think the problem we had at the time was caused by the presence of multiple configured drives, which somehow caused the load/unload/reject driver tools to get "stuck" on the wrong drive. So make sure that only one drive is configured, and also make sure "Prevent auto-run on all CD drives" is checked.

[bitsgalore]

Other thing that crossed my mind - I think I actually solved our slow response issue of the Nimbie drivers at the time by disabling any unused optical drives (including the PC's internal one) from the Windows device manager. See screenshot in below post:

https://forums.tomshardware.com/threads/how-to-stop-cdrom-drive-from-work-after-sleep-mode.3630050/post-21877311

Also note that after disabling one device, Windows may re-map existing devices (like the Nimbie's optical drive) to another logical drive letter (e.g. from "F" to "E" or something).

So I'd suggest that after disabling any devices, you:

1. reboot your machine (with the Nimbie switched on)
2. check for any changes to the logical drive mappings,
3. update your configuration (Iromlab config file + dBPoweramp config) accordingly, if needed.

[darcyruppert]

There was a second drive configured -- after unconfiguring I was able to process three discs in 12 minutes! Thanks for your help.

I am still running into the 1005 error, so I may try uninstalling Isobuster (I'm running 5.3, the most recent version) and installing 4.0.

[bitsgalore]

@darcyruppert Good to hear the Nimbie drivers are now working properly. As for Isobuster: I would try running the most recent 4.x version (I think this was 4.7, not entirely sure what we're using for our operational workflow but I can ask). You mention 4.0, but that version is probably too old (Iromlab uses a couple of features that were added later).

I know IsoBuster's author did some pretty major refactoring of the code for the 5.0 release, so it could be that this introduced some unwanted effects. At some point I'd like to upgrade Iromlab to IB 5, and by that time I'll give this a more in-depth look. But this won't happen anytime soon.

[darcyruppert]

@bitsgalore Ah yes, I was just noticing that myself and thinking of downloading 4.9: https://www.isobuster.com/news/isobuster_4.9_release_notes

But let me know if there's a version that's most compatible with Iromlab. I've also been having some issues using Isobuster 5.3 on old Mac discs with HFS file systems, so I've been thinking of experimenting with older versions.

[bitsgalore]

@darcyruppert 4.9 should be fine. Let me know if you keep getting this issue and I'll try to think of something!

[darcyruppert]

Will do, thanks so much!

[bitsgalore]

For future reference, I just added a section on disabling unused optical drives to the Iromlab setup documentation:

https://github.com/KBNLresearch/iromlab/blob/master/doc/setupIromlab.md#disable-unused-optical-drives

And also a reference to this in the User Guide's Troubleshooting section:

https://github.com/KBNLresearch/iromlab/blob/master/doc/userGuide.md#loading-unloading-or-rejecting-a-disc-takes-a-very-long-time

[CyberGonzo]

I know IsoBuster's author did some pretty major refactoring of the code for the 5.0 release, so it could be that this introduced some unwanted effects. At some point I'd like to upgrade Iromlab to IB 5, and by that time I'll give this a more in-depth look. But this won't happen anytime soon.

If there's anything I can do in the short term, do let me know. IsoBuster 5.4 is due ( https://www.isobuster.com/news/isobuster_5.4_beta_release_notes ) in a little while. If I can fix or improve something before IsoBuster 5.4 (final) is released, now is the moment ;)

[bitsgalore]

@CyberGonzo Thanks for the heads-up and the offer! I just sent you a quick email with an outline of our plans with Iromlab, and how IsoBuster fits into this.