@SamriHL
Yes sure, whatelse do you expect?
[Edit]
Sry, . OK maybe I misread, as often happening, but as far I understood you, crossflashing the BH60NS60 to Asus firmware helped solve BD-RE/BD-R burning issues.
[Edit]by reflashing with Asus firmware-crossflah from other Asus unit, with the encryption data from (from problematic unit's previous-firmware?) moved to.
Maybe before the reflash, where an Asus firmware was already crossflahed onto BH16NS60 ,one of the methods, Teddies hexedit method or EEPROM data mover, or wrong hexediting caused problems, or s.th. else wrong.
--------
Afaik MartyMc Nuts method with the specially modified Clean firmwares, afaik it does also the data moving, it also contains BH16NS60 1.00 specially modified Clean-firmwares. So Afaik it is also for converting official-UHD-drives to UHD friendly. What method does it use a official-UHD-->UHD-friendly conversion (e.g. if using to crossflash BH16NS60 to BW-16D1HT 3.02/3.01/3.00 firmware?
Maybe if it uses one of those method here, too, Teddies hexrange or EEPROM data mover built-in, or else, not to touch? maybe if one of that method (or wrong hex range in a such occasion, not to touch,built-in in causes burning issues (see phenomenon, see below)
[Edit]
Sry I forgot, I'm wrong, the new method does not move or touch the laser calibration data.
Still the new flashing method it mustn't touch a wider hexrange with official-UHD drives to UHD-friendly for crossflashing/conversion (within same manafacturer line or to ASUS).
Afaik still the original not newly official LG flasher (patched) is used, maybe it uses smaller hexrange from normal UHD-fiendly firmwares which might cause problems for official-UHD-conversion, because the first hexrange is 0x1E0000 to 0x1E84FF, and not 0x1E8000 to 0x1E84FF (smaller hexrange). Maybe the patched LG flasher doesn't watch this.
I'm only speculating.
-------------
[Edit] By the way:
https://forum.redfox.bz/threads/converting-uhd-friendly-drive-into-uhd-real-and-viceversa.74544/
The EEPROM data mover certainly seems to output different result (different file checksums) than using with Teddies hexrange method upper link(!) (on a UHD-official->to UHD-friendly-conversion!) Just to clarify!
And I know how to do the hexediting.
(But I cannot program apps, programs, etc at all)
Just test with both methods, should get same result, then run a file compare check between both resulting files, you should see that phenomenon.
But the difference was outside of the DV value hexrange as far I remember, as I had exported the CB-DV encryption data to seperate files from both methods afterwards, and checksum from both exports least identical (from both files from both methods, but not from the main firmware data (so outside of the hexrange).
(The EEPROM data mover- and hexediting method had been tested, because MartyMcNuts new probably safer method hadn't existed yet)
---
That different behavior between both methods was not to see at all, with standardly-pricipially-already-UHD-friendly-drives firmwares that would need other guide instead
https://forum.redfox.bz/threads/dumping-downgrading-firmware-on-uhd-friendly-devices.74479/
(or now MartyMcNuts new safer method for most probably all those cases)
--
You said you had had no issues with your BH16NS60 drive Converted/crossflashed from the first place.
In which way did you crossflash your NS60 drive? Please kindly could you give a link or description from where instructed doing it, or explain how done it?
E.g. did you use this guide?
https://forum.redfox.bz/threads/converting-uhd-friendly-drive-into-uhd-real-and-viceversa.74544/
Or EEPROM data mover method, or MartyMcNuts method, or other way?
Please could you tell which one of those.
Or if other, then how? Thx
Yes sure, whatelse do you expect?
[Edit]
Sry, . OK maybe I misread, as often happening, but as far I understood you, crossflashing the BH60NS60 to Asus firmware helped solve BD-RE/BD-R burning issues.
[Edit]by reflashing with Asus firmware-crossflah from other Asus unit, with the encryption data from (from problematic unit's previous-firmware?) moved to.
Maybe before the reflash, where an Asus firmware was already crossflahed onto BH16NS60 ,one of the methods, Teddies hexedit method or EEPROM data mover, or wrong hexediting caused problems, or s.th. else wrong.
--------
Afaik MartyMc Nuts method with the specially modified Clean firmwares, afaik it does also the data moving, it also contains BH16NS60 1.00 specially modified Clean-firmwares. So Afaik it is also for converting official-UHD-drives to UHD friendly. What method does it use a official-UHD-->UHD-friendly conversion (e.g. if using to crossflash BH16NS60 to BW-16D1HT 3.02/3.01/3.00 firmware?
Maybe if it uses one of those method here, too, Teddies hexrange or EEPROM data mover built-in, or else, not to touch? maybe if one of that method (or wrong hex range in a such occasion, not to touch,built-in in causes burning issues (see phenomenon, see below)
[Edit]
Sry I forgot, I'm wrong, the new method does not move or touch the laser calibration data.
Still the new flashing method it mustn't touch a wider hexrange with official-UHD drives to UHD-friendly for crossflashing/conversion (within same manafacturer line or to ASUS).
Afaik still the original not newly official LG flasher (patched) is used, maybe it uses smaller hexrange from normal UHD-fiendly firmwares which might cause problems for official-UHD-conversion, because the first hexrange is 0x1E0000 to 0x1E84FF, and not 0x1E8000 to 0x1E84FF (smaller hexrange). Maybe the patched LG flasher doesn't watch this.
I'm only speculating.
-------------
[Edit] By the way:
https://forum.redfox.bz/threads/converting-uhd-friendly-drive-into-uhd-real-and-viceversa.74544/
The EEPROM data mover certainly seems to output different result (different file checksums) than using with Teddies hexrange method upper link(!) (on a UHD-official->to UHD-friendly-conversion!) Just to clarify!
And I know how to do the hexediting.
(But I cannot program apps, programs, etc at all)
Just test with both methods, should get same result, then run a file compare check between both resulting files, you should see that phenomenon.
But the difference was outside of the DV value hexrange as far I remember, as I had exported the CB-DV encryption data to seperate files from both methods afterwards, and checksum from both exports least identical (from both files from both methods, but not from the main firmware data (so outside of the hexrange).
(The EEPROM data mover- and hexediting method had been tested, because MartyMcNuts new probably safer method hadn't existed yet)
---
That different behavior between both methods was not to see at all, with standardly-pricipially-already-UHD-friendly-drives firmwares that would need other guide instead
https://forum.redfox.bz/threads/dumping-downgrading-firmware-on-uhd-friendly-devices.74479/
(or now MartyMcNuts new safer method for most probably all those cases)
--
@BRCSI cross flashed one of my NS60 drives to Asus 3.01 firmware with out any issues it reads 4ks& Blurays and writes them with no problem and it works with anydvdand all dvd function fine everything test just fine my other NS60 drive I have not got around to even trying it yet.
You said you had had no issues with your BH16NS60 drive Converted/crossflashed from the first place.
In which way did you crossflash your NS60 drive? Please kindly could you give a link or description from where instructed doing it, or explain how done it?
E.g. did you use this guide?
https://forum.redfox.bz/threads/converting-uhd-friendly-drive-into-uhd-real-and-viceversa.74544/
Or EEPROM data mover method, or MartyMcNuts method, or other way?
Please could you tell which one of those.
Or if other, then how? Thx
Last edited: