NaCl Posted April 13 Greetings, I'm running into a situation where when calling imgburn from commandline it randomly ignores/clobbers the dest name w/only the [DISC_LABEL]. For instance: "c:\Program Files (x86)/ImgBurn/ImgBurn.exe" /MODE READ /SRC W /DEST "u:\test\ISOs\NEW01\nimbie02\[DISC_LABEL]_W_7RJ2118T.iso" /EJECT /CLOSE /START Where [DISC_LABEL] is internally detokenized to be the label of the disc. This w/irksome random frequency ends up being clobbered to just whatever the [DISC_LABEL] evaluates to. It's only an issue when whatever asshats that may have mastered a TV series don't know their job and use the same disc label for each disk in a given season. In my most recent instance, STAR_WARS_CLONE_WARS_S1_BOX. When imgburn opens, while it's 'initialising disc...' the output file is filled in _correctly_...in this case u:\test\ISOs\NEW01\nimbie02\STAR_WARS_CLONE_WARS_S1_BOX_W_7RJ2118T.iso but then when it goes to the read progress screen the output is, again not always but when the bug occurs, u:\test\ISOs\NEW01\nimbie02\STAR_WARS_CLONE_WARS_S1_BOX.ISO Can you please either _fix_ that or provide another token; [RANDOM_STRING] or _something_? Note that I _have_ tried adding [DATETIME] and the same exact issue occurs. Thanks! Share this post Link to post Share on other sites
NaCl Posted April 13 (edited) And here's one where it's actually working. "c:\Program Files (x86)/ImgBurn/ImgBurn.exe" /MODE READ /SRC W /DEST "u:\test\ISOs\NEW01\nimbie02\[DISC_LABEL]_W_PP7TWSPD.iso" /EJECT /CLOSE /START See image... Please fix. Edited April 13 by NaCl Share this post Link to post Share on other sites
LIGHTNING UK! Posted April 13 The name passed via CLI is used once and then thrown away. So... the only way I can see this happening is if the drive isn't ready or gets refreshed, thereby making the program generate a new name. What's controlling your Nimbie (loading discs etc) ? Share this post Link to post Share on other sites
NaCl Posted April 13 The name passed via CLI is used once and then thrown away. So... the only way I can see this happening is if the drive isn't ready or gets refreshed, thereby making the program generate a new name. What's controlling your Nimbie (loading discs etc) ? imgburn via bsrobots20.dll Share this post Link to post Share on other sites
LIGHTNING UK! Posted April 13 Ok, but what state is the unit in when you load it via CLI? Is there a disc in the drive? Is ImgBurn loading the disc for you? If I'm going to dig my Nimbie out and take a look at it, I need to make sure I can reproduce the issue - I can't under normal circumstances. Anything you can do narrow down the issue would be appreciated. Share this post Link to post Share on other sites
NaCl Posted April 14 (edited) Ok, but what state is the unit in when you load it via CLI? Is there a disc in the drive? Is ImgBurn loading the disc for you? If I'm going to dig my Nimbie out and take a look at it, I need to make sure I can reproduce the issue - I can't under normal circumstances. Anything you can do narrow down the issue would be appreciated. Oh ok! Pardon me. Disks are in the hopper, none in the drive. I have a cygwin environment w/bash shell script that generates and calls the supplied command. Imgburn loads up, I see it searching for robots, then the Nimbie does the eject tray, close tray, eject tray bit, then drops a disc onto the tray, tray closes, anydvd hd does its thing, then imgburn does its read init, and then things start going. Edited April 14 by NaCl Share this post Link to post Share on other sites
LIGHTNING UK! Posted April 14 Thank you for that valuable info... especially regarding the use of AnyDVD. This is unlikely to be a bug in ImgBurn and more of a bug in the process as a whole. As I said previously, the program uses the cli given filename once and then discards it. If the drive is refreshed for any reason (probably due to AnyDVD taking it offline or whatever), it’ll get a new name. I expect that’s what’s happening here. I will see what I can do. Share this post Link to post Share on other sites
