Imgburn (2.5.8.0) 'randomly' ignores dest output name in read mode.

[NaCl]

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!

 

[NaCl]

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, 2018 by NaCl

[LIGHTNING UK!]

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) ?

[NaCl]

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

[LIGHTNING UK!]

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.

[NaCl]

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, 2018 by NaCl

[LIGHTNING UK!]

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.