Any way to disable LG's "Jamless Play" on the drives?

[puertorican]

Jamless Play is the feature that returns garbage data instead of making MakeMKV retry on a failed sector. This results in HashCheck errors. LG drives are the only ones that gives this error because Jamless Play kicks in and returns garbage data. Using LiteOn or Panasonic drives doesn't return hash errors. Instead, they retry the bad sectors, but it seems the LG is the better drive when it comes to reading, except that in some cases, the Jamless Play feature kicks in and returns garbage data.

I wonder if a customized firmware could disable this and make the drive actually retry on failed sectors.

[kja70]

Just ran into this issue as well. Anyone find any workarounds/techniques for avoiding bad data coming back from the drive?

[rkjnsn]

I looked at the firmware I currently run on my drives (BU40N 1.00, BU40N 1.03, BP60NB10 1.02, and WH16NS60 1.02), and they all appear to support a vendor command to do just that (no customized firmware needed). You use the READ BUFFER opcode with vendor mode 0D.

The full 10-byte CDB (command descriptor block) is

Code: Select all

3C 0D 01 00 00 00 <mode> <persist> 00 00

mode: DD for off, EE (or any other non-zero value) for on.
persist: FF to save the setting to flash, 00 (or any other value) for only until the next disc load.

The command returns 4 bytes, DD 00 00 00 after turning it off or EE 01 00 00 after turning it on. (Reply is the same regardless of the persist setting.)

So (on Linux, with sg3_utils), the following will disable jamless play temporarily:

Code: Select all

sg_raw -r 4 /dev/srN 3C 0D 01 00 00 00 DD 00 00 00

And persistently (across discs and power cycles; I think it's persisted in a flash region which should also survive firmware flashing, but I haven't tested that):

Code: Select all

sg_raw -r 4 /dev/srN 3C 0D 01 00 00 00 DD FF 00 00

To undo the previous (persistently re-enable):

Code: Select all

sg_raw -r 4 /dev/srN 3C 0D 01 00 00 00 EE FF 00 00

(Note: A non-persistent enable (mode = EE, persist = 00) can only undo a non-persistent disable. The drive only builds the jamless-play tables on disc load (and disc load reverts to the persistent setting), so there's no way to have it persistently disabled but enable enable it for a single disc.)

This likely works on other LG firmware versions, too, but I haven't looked at them.

[kaysee]

I have used ASUS firmware on LG drives to handle this. Have you tested these commands for controlling jamless play? I wonder about variations for different LG models.

[rkjnsn]

Have you tested these commands for controlling jamless play?

I have tested that after running the persistent disable command, it stores "JMDS" (presumably "jamless disabled") in the flash, no longer constructs the jamless playback tables (which tell the read logic where the .m2ts files are on the disc) on disc insertion, and leaves the flag that controls the stall recovery in the read loop disabled. I have also verified that without the persist option, the command disables the stall-recovery flag without writing to the flash. I have not, however, done a full battery of read tests with a bad disc inserted.

[barnstarmer]

Thank you rkjnsn.

I can confirm that the

Code: Select all

sg_raw -r 4 /dev/srN 3C 0D 01 00 00 00 DD FF 00 00

command does disable jamless playback on BU40N 1.03 MK firmware. ddrescue now receives correct error codes from the drive during the recovery process.

[kaysee]

Thank you rkjnsn.

I can confirm that the

Code: Select all

sg_raw -r 4 /dev/srN 3C 0D 01 00 00 00 DD FF 00 00

command does disable jamless playback on BU40N 1.03 MK firmware. ddrescue now receives correct error codes from the drive during the recovery process.

Nice. None of the firmware for the LG slim drives has had jamless play disabled (that is, all firmware options have been LG, not ASUS firmware). I will have to try this with a BP50NB40 that has BU40N 1.03 MK firmware next time I am using ddrescue.

[zordiack]

Hi, I have a Verbatim drive with BU40N inside with 1.03 MK firmware and I only recently learned about this Jamless Play nonsense with these drives. So yesterday I came across this thread and was exited to try out the firmware so I executed the following command in Linux (and got a reply and no errors):

Code: Select all

sg_raw -r 4 /dev/srN 3C 0D 01 00 00 00 DD FF 00 00

However, I still have hash check issues with ddrescue when I tested a rip with a working blu-ray. So if I directly copy the title with MakeMKV 2.0.0, it does not complain and goes without hash check errors. But if I run ddrescue -> .iso operation (without any noted bad sectors) and then use freemkv 1.8.5 to decrypt the .iso and try to open that decrypted .iso with MakeMKV, it will give me hash check errors. The .iso route produces a working .mkv file in the end despite the hash check errors, but I am concerned is the data ok this way as hash checks fail.

I am just left wondering, at what point does the error come from in the .iso decryption route vs. direct copy with MakeMKV? Or is the drive still outputting some bullshit sectors even though Jamless Play should be disabled and why does it work with MakeMKV directly?

BR, zordiack

[keydb_helper]

However, I still have hash check issues with ddrescue when I tested a rip with a working blu-ray. So if I directly copy the title with MakeMKV 2.0.0, it does not complain and goes without hash check errors.

This sounds positive enough...

But if I run ddrescue -> .iso operation (without any noted bad sectors) and then use freemkv 1.8.5 to decrypt the .iso and try to open that decrypted .iso with MakeMKV, it will give me hash check errors.

My recollection is that MakeMKV only validates content hash values when processing an encrypted Blu-ray as the content hash table is an AACS feature. MakeMKV performs this validation regardless of whether the encrypted Blu-ray input is a physical disc, ISO, or folder structure.

The original table is absolutely specific to the encrypted form of the content. So if you decrypted the ISO with an external tool, I'm not sure how MakeMKV could identify hash errors without a content hash table.

Does MakeMKV give any hash errors if you try to directly process the AACS protected ISO generated via ddrescue?

Or is the drive still outputting some bullshit sectors even though Jamless Play should be disabled and why does it work with MakeMKV directly?

I haven't looked into this much but I am interested in rkjnsn's findings. Hopefully your issue lies somewhere in the post-ddrescue processing pipeline as it would be really neat to have Jamless Play persistently disabled.

[tomty89]

The original table is absolutely specific to the encrypted form of the content. So if you decrypted the ISO with an external tool, I'm not sure how MakeMKV could identify hash errors without a content hash table.

The decrypted ISO from freemkv contains the AACS directory (and its content). AFAIK it literally just decrypts the encrypted data / M2TS and avoids touching other parts of the image. (Coincidentally or not, it seems that nothing on the market can modify, as in e.g. deleting a directory and its content, a UDF 2.5 with "metadata partition", especially not one from a read-only BD.)

if you try to directly process the AACS protected ISO generated via ddrescue?

That might not be possible btw, especially when it's an AACS 1.0 / regular BD image, because IIRC MakeMKV will not try to use KeyDB or HK for that (but just stalls). (Maybe it will if it's one with MKB v82.)

[keydb_helper]

The decrypted ISO from freemkv contains the AACS directory (and its content). AFAIK it literally just decrypts the encrypted data / M2TS and avoids touching other parts of the image.

The decryption is the part which prevents the direct usage of the hash table. Consider the data 'layers' of AACS:

Bus Encrypted Content (Optional in AACS 1.0, Mandatory in AACS 2.x, not what you want in an ISO file)
|
|
Encrypted Content (Hashed without being decrypted to produce the content hash table, present in ddrescue ISO file if generated after disabling bus encryption)
|
|
Unencrypted Content (Directly playable in VLC or most other media players, not relevant to content hash table, present in your decrypted ISO file)

As the content in your decrypted ISO has already been decrypted, the content hash table cannot be utilised as there isn't much point comparing the calculated hash of decrypted content to the stored hash of the original encrypted content.

(If you don't mind making some assumptions, you can effectively re-encrypt the output of some decryption tools to verify via the content hash table but this is thwarted if any dynamic editing like subtitle tweaks has been applied)

That might not be possible btw, especially when it's an AACS 1.0 / regular BD image, because IIRC MakeMKV will not try to use KeyDB or HK for that (but just stalls). (Maybe it will if it's one with MKB v82.)

MakeMKV will utilise the keydb for any encrypted BD/UHD ISO file. This works even if MakeMKV won't generate a disc dump file from a physical disc of the same MKB revision. I just verified this behaviour with protected ISO files for both MKBv1 and MKBv81. MakeMKV happily processed both ISO files as the keys for these discs are in the public keydb.

MakeMKV might take a minute or so to parse the keydb and select the relevant key, so I understand why you'd think it has stalled.

Edit: If you haven't already, I'd try MakeMKV v1.18.4 as v2.0.0 apparently has issues with ISO file input

[tomty89]

MakeMKV will utilise the keydb for any encrypted BD/UHD ISO file. This works even if MakeMKV won't generate a disc dump file from a physical disc of the same MKB revision. I just verified this behaviour with protected ISO files for both MKBv1 and MKBv81. MakeMKV happily processed both ISO files as the keys for these discs are in the public keydb.

MakeMKV might take a minute or so to parse the keydb and select the relevant key, so I understand why you'd think it has stalled.

Edit: If you haven't already, I'd try MakeMKV v1.18.4 as v2.0.0 apparently has issues with ISO file input

I definitely had problem opening an encrypted backup that has no discatt.dat (yeah it wasn't an ISO but a directory / "tree of files") of a regular BD with MakeMKV while I had no problem with that of the UHD BD that comes with it. I probably didn't wait for a minute or longer but I definitely didn't need to do that for the UHD BD's backup. (I'm pretty sure I checked that the KeyDB back then have entries for both of them, because I was specifically trying to find out if discatt.dat is useless in that case. IIRC I also checked that MakeMKV worked fine with the same disc and an encrypted backup of it that has discatt.dat.)

Don't remember what version I performed the test with, but definitely something earlier than 1.18.4, as I did it quite some time ago.

P.S. By had I just mean that for reasons I can't / don't want to check again.

---

If you don't mind making some assumptions, you can effectively re-encrypt the output of some decryption tools to verify via the content hash table

Yup https://www.xreveal.com/content-hash-verifier.html

[keydb_helper]

I definitely had problem opening an encrypted backup that has no discatt.dat (yeah it wasn't an ISO but a directory / "tree of files") of a regular BD with MakeMKV while I had no problem with that of the UHD BD that comes with it. I probably didn't wait for a minute or longer but I definitely didn't need to do that for the UHD BD's backup.

Even if both discs were present in the public keydb, the UHD disc was probably decrypted via the native MakeMKV hashed keys rather than the public keydb. The hashed keys implementation is faster and probably contains more UHD than BD discs, so the timing difference between your two discs is to be expected.

If you'd ever like to test this again, you can save yourself the wait by just copying the single relevant line from the full keydb file into a temporary keydb.cfg for MakeMKVs consumption.

(The directory structure vs ISO mode of input has no bearing on the keydb/discatt/hashed keys possibilities)

IIRC I also checked that MakeMKV worked fine with the same disc and an encrypted backup of it that has discatt.dat.

If you have the discatt(d).dat file that will also be quite snappy as MakeMKV can generally skip the loading of the public keydb. MakeMKV will instead try to use its bundled AACS 1.0 keys to derive the relevant disc keys. One exception to this if you have an older version of MakeMKV which predates native support for your MKB revision. In this case the bundled AACS 1.0 keys will probably fail and the keydb should be utilised as a fallback.

[zordiack]

The decrypted ISO from freemkv contains the AACS directory (and its content). AFAIK it literally just decrypts the encrypted data / M2TS and avoids touching other parts of the image.

The decryption is the part which prevents the direct usage of the hash table. Consider the data 'layers' of AACS:

Bus Encrypted Content (Optional in AACS 1.0, Mandatory in AACS 2.x, not what you want in an ISO file)
|
|
Encrypted Content (Hashed without being decrypted to produce the content hash table, present in ddrescue ISO file if generated after disabling bus encryption)
|
|
Unencrypted Content (Directly playable in VLC or most other media players, not relevant to content hash table, present in your decrypted ISO file)

As the content in your decrypted ISO has already been decrypted, the content hash table cannot be utilised as there isn't much point comparing the calculated hash of decrypted content to the stored hash of the original encrypted content.

(If you don't mind making some assumptions, you can effectively re-encrypt the output of some decryption tools to verify via the content hash table but this is thwarted if any dynamic editing like subtitle tweaks has been applied)

That might not be possible btw, especially when it's an AACS 1.0 / regular BD image, because IIRC MakeMKV will not try to use KeyDB or HK for that (but just stalls). (Maybe it will if it's one with MKB v82.)

MakeMKV will utilise the keydb for any encrypted BD/UHD ISO file. This works even if MakeMKV won't generate a disc dump file from a physical disc of the same MKB revision. I just verified this behaviour with protected ISO files for both MKBv1 and MKBv81. MakeMKV happily processed both ISO files as the keys for these discs are in the public keydb.

MakeMKV might take a minute or so to parse the keydb and select the relevant key, so I understand why you'd think it has stalled.

Edit: If you haven't already, I'd try MakeMKV v1.18.4 as v2.0.0 apparently has issues with ISO file input

Thank you all for valuable input, I'm learning a lot of new things here

I wanted to ask a bit about the AACS encryption scheme flow. How can I make sure that bus encryption is not present when I am doing a ddrescue .iso dump? I didn't consider this at all and I just assumed that I get the second stage image if I use ddrescue (hashed without being decrypted) for AACS 1.0 (normal BD, I rarely have UHDs).

I will try opening the .iso without involving freemkv decryption, I just thought that MakeMKV would refuse to open it (and did not even try).

I will also test using MakeMKV version 1.18.4.

BR, zordiack

[rkjnsn]

The decrypted ISO from freemkv contains the AACS directory (and its content). AFAIK it literally just decrypts the encrypted data / M2TS and avoids touching other parts of the image.

This is exactly why you are getting hash errors. The content hashes are the hashes of the encrypted m2ts files. You have changed the contents of the m2ts files (by decrypting them), so naturally the hashes don't match.

How can I make sure that bus encryption is not present when I am doing a ddrescue .iso dump?

If you're lucky, your drive doesn't support bus encryption at all, in which case all rips are bus-encryption free. (My standard Blu-ray drive and my two MT959-based, non-UHD-certified BDXL drives are like this.) If your drive is UHD-certified, you'll need to open the disc with MakeMKV to activate LibreDrive before running ddrescue, which should disable bus encryption until the disc is reloaded. I have noticed, however, that my slim drives will sometimes reset when reading a troublesome disc region, which will also reset LibreDrive.

For checking after the fact, the hashes can be used to verify there is no bus encryption. Just as decrypting causes changes the m2ts content and causes the hashes not to match, applying an extra layer of encryption also causes them not to match. (I'm considering making a standalone tool to check the hashes on an encrypted ISO. I'll make a post here if I do.)