Defective UHD friendly drive

I Have an LG 16Ns55 that gives almost always this error in anydvd when inserting in it a UHD-BD:

Summary for drive G: (AnyDVD HD 8.2.7.3, BDPHash.bin 18-01-30)
ASUS BW-16D1HT 3.02
Drive (Hardware) Region: 2
Current profile: BD-ROM
Media is a Blu-ray disc.

Total size: 30822432 sectors (60200 MBytes)
Video Blu-ray label: STAR TREK BEYOND
Media is AACS protected!
Drive supports bus encryption!
Disc wants bus encryption!
Drive's signature of the Dv value seems incorrect (bus encryption)!
ERROR processing Blu-ray disc!

The strange thing is that the same drive works perfectly ripping the same disks using MAKEMKV or DEUHD

Some idea of the reason of this?

 

@mfast ANYDVD now only supports some UHD titles support is gradually added to the experimental test

 

This title is supported

If I do use another drive, this and others bd-uhd disks are read without any problem

My question is why this "defective" drive ( for Anydvd ) works perfectly with makemkv and deuhd ...

 

Did you mess with the firmware? Because the above is your problem right there. The drive's unique DV value doesn't match the signature expected, and thus decryption fails.

That needs to be fixed first, or no uhd disc will work for you. Supported by the OPD or not.

Verstuurd vanaf mijn Nexus 6P met Tapatalk

 

I did bought it used, this way I don't know this ...

However a time I was able to decrypt a disk even with Anydvd and always works flawlessy with makemkv or deuhd: Why this?

 

Thanks, it was what I do thought ..

I can say that all the ripped disk done are perfect

 

Then it has been tampered with and badly, causing anydvd to error out. The only reason it works with makemkv and deuhd is because they each employ their own decryption method and it's different from anydvd's method

Verstuurd vanaf mijn Nexus 6P met Tapatalk

 

Like said by Pete, I will wait ther new version of Anydvd and I will do know you the tests results ...

 

There's no use. Without that DV value fixed, it won't work. Regardless of any new update.

Verstuurd vanaf mijn Nexus 6P met Tapatalk

 

https://forum.redfox.bz/threads/defective-uhd-friendly-drive.75699/#post-492520

 

I think Pete said he's going to change AnyDVD in the next release to just warn in this instance but attempt decryption anyway.

EDIT: I guess you're saying the attempt will fail without the right DV value...

Is this a recursive link or something (lol)? Seems to refer back to this very thread.



T

 

Exactly and I will test this attemp for see if it works like deuhd and makemkv ...

I will do know

 

mfast the beta is here with the DV change.

Did you test the drive with it yet? How did it go?


T

 

I have tested the beta and it works perfectly: it warns of the problem but then all works, I am playing the BD-UHD disk without any problem.

Thanks a lot for your efforts

 

Excellent!

Congrats.

Good solution, @Pete


T

 

Even the beta 8.2.7.5 does continue to work perfectly ....

 

Glad to hear it.

Yeah, usually the fixes carry over from one beta to the next and on to the main release.


So looks like you're good-to-go!


T

 

Does it have an LG Logo on the cover?

If yes It looks like a crossflashed LG drive to an Asus BW-16D1HT.
E.g. could be crossflashed (even from an UHD offcicial drive WH16NS60) converted to to Asus-BW16D1HT UHD-friendly.

The are people using the EEPROM data mover even for from a real-UHD-official drives, to do the converting, although Teddy Raspin does not at all mention to use this as alternative method here, eg- also from an BE16NU50/40 not sure, because it's more easy, than with the manual editing.

The reported it to work with DeUHD. But I can't remember anyone telling that it worked with AnyDVD before, before RedFox did that nice valu ignore-update.

What I've noticed when feeding the "EEPROM data mover" program with an original WH16NS60 backup dump, to export into laser CB-data and drv value into an BH16NS55 Clean- or BW16D1Ht clean-firmware, the data mover gets another resulting file, than using the manual hexediting method for this with "dd" or hexeditor.

I'm 100% sure I did correct manual hexediting. Rechecked the hex- and decimal values with calculator etc.

When using dtandard UHD-"friendly"-drive's ori firmware (eg updated BH16NS55 or Bw-16D1HT 1.03 or 3.03)and feed it with 1.02 / 3.02 Clean firmware, JUST here the resulting file on EEPROM data mover matches to the manual hexediting method.
---

(Even when using usual firmware-downgrade hexrange editing procedure on WH16NS60 firmware by "dd" or "hexedit", the output file on EEPROM data mover does not match)
As said before EEPROM data mover has strange behavior in some special occasions

Maybe the 1st ownder from "mfast"' 's drive used the "EEPROM" data mover which might not be optimal , so maybe it's better to directly convert the firmfare, and with Teddys' hexrange manually with "dd" or a "hexeditor".

If that's the case (WH16NS60 unit), so if the previous owner used the EEPROM data mover, that may cause of that earlier AnyDVD behaviour mfast experienced, more or less/ at least sufficiently resolved by AnyDVD now!

https://forum.redfox.bz/threads/converting-uhd-friendly-drive-into-uhd-real-and-viceversa.74544/
Here Teddy doesn't mention to use any "EEPROM data mover"(!) here!! only for a standard-UHD-friendly drive!!
There must be some reason...

(standard-UHD-friendly drive=standard-UHD-friendly drive with just updated firmware to close AACS loophole.)

 

It was a LG 16ns55 and I crossflashed it to Asus for see if this was useful for the anydvd error but nothing changed.

The new beta Anydvd released did the trick: now it is perfect and accurate reading bd-uhd even with Anydvd ( rip and direct playing )