When I try to rip the UHD E.T Extra-terrestrial (ET40TH_UPK5), I got stuck in the initial analysis phase (after decryption that seems ok) when makemkv tries to get all the pieces of videos and audio. In the list of events displayed in the makemkv window , I have lots AV sync error and I finally get stuck on file 00134 with. I have no other info from makemkv, the disk is still read but after 30mn waiting I did not get the end of the analysis.
I get the disk replaced but still the same behaviour.
And my multimedia player can read it from start to end of the film.
Anyone else get the same problem ?
E.T. extra-terrestrial UHD disk (ET40TH_UPK5) : never stop analysing the disk, too many sync errors
Re: E.T. extra-terrestrial UHD disk (ET40TH_UPK5) : never stop analysing the disk, too many sync errors
Have you tried gently cleaning the disc? Often even brand new discs benefit from cleaning.
Re: E.T. extra-terrestrial UHD disk (ET40TH_UPK5) : never stop analysing the disk, too many sync errors
Thanks for your reply, and yes I always clean the disk before ripping it. But does not change the error.
-
YannArtoie
- Posts: 7
- Joined: Tue Mar 05, 2024 4:55 pm
Re: E.T. extra-terrestrial UHD disk (ET40TH_UPK5) : never stop analysing the disk, too many sync errors
I think I may have found an issue with the UHD disc **ET40TH_UPK5** (French release, EAN 3701432065694). It looks related to the issue discussed in this thread.
**Environment**
* MakeMKV 1.18.4
* macOS
* Pioneer BDR-UD04 1.14 (LibreDrive)
To exclude a defective disc, I first created a complete sector-by-sector image using GNU ddrescue.
Results:
* Disc size: ~97 GB
* 0 read errors
* 0 bad sectors
The UHD also plays perfectly from beginning to end on my standalone UHD player.
However, MakeMKV fails while analysing the disc.
The first errors are reported on **00134.m2ts**:
* Hash check failed for file 00134.m2ts
* Too many hash check errors
* Too many AV synchronization issues
* Failed to decode audio/video data
Later in the log I also get:
```
The source file '/BDMV/STREAM/00543.m2ts' is corrupt or invalid at offset 502468608, attempting to work around
```
`00543.m2ts` is the main movie stream.
After that, MakeMKV appears to enter a loop continuously writing `tp=` lines to the log. The log eventually grows to more than **60 GB** if left running.
Additional information:
* SHA-256 of `00134.m2ts`:
`5c35608d6c5cabba02fc46d13fe61e5390d36db5abc0c2c902b00df125661ed2`
* I can also provide:
* AACS ContentHash tables (`ContentHash000.tbl`, `001`, `002`)
* the full ddrescue log
* additional MakeMKV logs
* small extracts from the affected M2TS files if needed.
Because the disc can be read completely without any physical read errors and plays correctly on standalone hardware, I'm wondering whether this could be related to the content hash verification or to the way this particular disc was authored.
If you would like me to collect any additional diagnostic information, I'd be happy to do so.
**Environment**
* MakeMKV 1.18.4
* macOS
* Pioneer BDR-UD04 1.14 (LibreDrive)
To exclude a defective disc, I first created a complete sector-by-sector image using GNU ddrescue.
Results:
* Disc size: ~97 GB
* 0 read errors
* 0 bad sectors
The UHD also plays perfectly from beginning to end on my standalone UHD player.
However, MakeMKV fails while analysing the disc.
The first errors are reported on **00134.m2ts**:
* Hash check failed for file 00134.m2ts
* Too many hash check errors
* Too many AV synchronization issues
* Failed to decode audio/video data
Later in the log I also get:
```
The source file '/BDMV/STREAM/00543.m2ts' is corrupt or invalid at offset 502468608, attempting to work around
```
`00543.m2ts` is the main movie stream.
After that, MakeMKV appears to enter a loop continuously writing `tp=` lines to the log. The log eventually grows to more than **60 GB** if left running.
Additional information:
* SHA-256 of `00134.m2ts`:
`5c35608d6c5cabba02fc46d13fe61e5390d36db5abc0c2c902b00df125661ed2`
* I can also provide:
* AACS ContentHash tables (`ContentHash000.tbl`, `001`, `002`)
* the full ddrescue log
* additional MakeMKV logs
* small extracts from the affected M2TS files if needed.
Because the disc can be read completely without any physical read errors and plays correctly on standalone hardware, I'm wondering whether this could be related to the content hash verification or to the way this particular disc was authored.
If you would like me to collect any additional diagnostic information, I'd be happy to do so.