FindVUK tool - get VUK of all Blurays supported by DVDfab applications

[MasterMeNL]

Originally Posted by nalor

Basically it sounds like a problem with your system when it's not even possible to copy those files with windows explorer.

Honestly I don't know how I can help in this case.

Maybe try to use a virtual windows with access to your drive? And see if you can copy the files there?

Gesendet von meinem H8324 mit Tapatalk

When doing it in a Windows 10 VM one of the following happens:

* Native SCSI passthrough: same problem occurs when copying these files as native Windows;
* Emulated drive: access works, DVDFab works, FindVUK complains about it not being a Blu-ray drive and refuses to work (appears there is no way to ignore this check). If I remember correctly it complained because QEMU (the VM) emulates the drive as a CD-ROM drive and not a Blu-ray drive.

I also did some testing on Linux with wine-4.0-rc4

* 32-bit wine, 32-bit DVDFab: DVDFab works, procdump crashes;
* 64-bit wine, 32-bit DVDFab: DVDFab works, procdump64 works, FindVUK step one works completely, step two fails because "Drive is NOT a Blu-ray drive! Exit now!";
* 64-bit wine, 64-bit DVDFab: DVDFab crashes

It appears wine does not support probing for all device info currently, and returns some dummy info which happens to be not a Blu-ray drive:
002a:fixme:ntdll:server_ioctl_file Unsupported ioctl 2d1400 (device=2d access=0 func=500 method=0)

As the UnitKeyDEC is found successfully the most important functionality works fine. I have not found a way to skip the part 2 Blu-ray drive check. Could you add an option or argument to skip the check and assume the drive is a Blu-ray drive or allow for hardcoding drive features in the config file? Possibly changing the check mechanism could fix this. DVDFab reports for example, even with wine, "Disc media: Blu-ray (BDMV)". Alternatively I don't mind hacking the source a bit and submitting a patch, but as far as I can see FindVUK is closed source.

Initially I'd say a version that skips the check would be good for testing, could you upload a version that makes this possible?

Thanks.

[nalor]

Originally Posted by Mr Wolf

Thanks! I wasn't sure you received my PM.

By the way, is there a KEYDB.cfg database available, were all the keys found by FindVUK are uploaded?
Is there any problem to share my KEYDB.cfg on the forums? (for copyright reasons, I mean)

Hi!

Basically the easiest way to share your data is to 'synchronize' with FindVUK -> it uploads all entries from your local file missing in the online database.

I've created a small homepage for the online database here:
http://fvonline-db.bplaced.net/

Now it lists the date of the last update and download links for the most interesting languages.


Hope it helps!

[Aperson]

Originally Posted by MasterMeNL

During part one there is the "Get basic AACS data" step. It prints out "AACS folder on disc is reachable - ValidateVUK is possible" and then the entire drive freezes. I have a 2011 SH-B123L. I noted that trying to copy MKB_RO.inf or MKB_RW.inf manually from the AACS folder causes the drive to lock up completely too, requiring Windows 10 to reboot. When running Linux on the same hardware copying these files works fine, but of course FindVUK does not work there. I have tried setting PauseBeforeValidateVUK to 1 but this did not change anything.

DVDFab itself can rip properly without locking up the drive, so I suspect the validation is causing issues. Could you add an option to disable/skip validation even if the AACS folder exists? Or is there something else I could try?

This sounds like the same issue I encountered when attempting to use FindVUK in a VMWare or QEMU VM with SCSI drive passthrough, I have not found a workaround, but I do know that DVDFab works because it does raw SCSI commands to the drive rather than accessing the filesystem. I don't remember fully, but I think that drive passthrough with a VirtualBox VM on a Linux host might've worked,

[nalor]

Originally Posted by MasterMeNL

When doing it in a Windows 10 VM one of the following happens:

* Native SCSI passthrough: same problem occurs when copying these files as native Windows;
* Emulated drive: access works, DVDFab works, FindVUK complains about it not being a Blu-ray drive and refuses to work (appears there is no way to ignore this check). If I remember correctly it complained because QEMU (the VM) emulates the drive as a CD-ROM drive and not a Blu-ray drive.

Can you simply execute the 'FindVUK - ShowDriveDetailsForAllDrives' batch file inside qemu-windows and send me the result? I will simply add an exception for the qemu virtual drive - just need the details of it.

There's already such an exception for the virtualbox drive in the code as this is the one I've been using in the past and that I've tried with FindVUK.

Thanks!

[Mr Wolf]

If it can be any help, I'm using FindVUK and DVDFab in a Windows 7 VMware Workstation virtual machine (in a Windows 7 host).
This is my configuration:


I never had any issue accessing the blu-ray drive within the virtual machine.

[MasterMeNL]

Originally Posted by nalor

Can you simply execute the 'FindVUK - ShowDriveDetailsForAllDrives' batch file inside qemu-windows and send me the result? I will simply add an exception for the qemu virtual drive - just need the details of it.

There's already such an exception for the virtualbox drive in the code as this is the one I've been using in the past and that I've tried with FindVUK.

Thanks!

Here are the details for the emulated QEMU drive:

2019-01-12 14:55:43 # 4 # [I] main / Drive_GetAllDetails(legacy) / Check drive features for drive >E<
2019-01-12 14:55:43 # 90 # [I] main / Drive_GetAllDetails(legacy) / Vendor >< ProductId >QEMU QEMU DVD-ROM< ProductRevision >2.5+< ScsiDeviceType >CD/DVD-ROM device< ConnectedTo >Atapi< Bus
2019-01-12 14:55:44 # 171 # [I] main / Drive_GetAllDetails(legacy) / Device has wrong mediatype - it is a >CD-ROM< but we need a DVD MediaType

As a side note, Wine does not implement this specific way of querying, the output of the showdrivedetails command under Wine 4.0-rc4 is:

0009:fixme:ntdll:server_ioctl_file Unsupported ioctl 2d1400 (device=2d access=0 func=500 method=0)
14:57:32 - Cannot enumerate storage device - stop getting drive details for this drive

I think it would be interesting to test this further as this is likely the only reason it currently does not work under Wine. For this there needs be a way to bypass the drive check completely as it will currently error under Wine. Alternatively autodetection of Wine is possible through the wine_get_version symbol in ntdll as described in https://www.winehq.org/pipermail/win...er/069387.html. What might be easier for a quick test is to assume the drive works if an error occurs during enumeration of the storage device instead of bailing out.

Thank you!

[nalor]

I've added the QEMU drive to the list of special drives - but my interest to support Wine is really low.
Since the first release nobody ever asked about wine and there are other alternatives to use FindVUK under linux, so I don't think it's necessary to specially support wine.

But QEMU support is included in the upcoming release

[legluondunet]

As a Linux user too, I will be very interesting to use FindVuk on Linux with Wine.
But the main issue is that DVDFab 11.x version does not launch with Wine.
For the moment I installed Windows 7 on Virtualbox and I can use Findvuk with DVDFab last version.
This soluce is less stable than a real Windows install, but it works.
But I don't understand why I have to "hack" the blu ray I BOUGHT to read them on Linux.
We are living in a strange world.

[nalor]

Released 1.23 - includes a few small fixes/enhancements.

[nalor]

Released 1.24 - fixed the problem that passkey got killed unfriendly every time ...