Examining the discs more closely, they report sizes like 80GB. The most likely explanation is a deliberately broken TOC with multiple references to the same physical files. In addition to the incorrect size, the broken TOC also causes any DVD player to report a huge array of titles on the disc... only a few of which actually work. This has the effect that the only way to be able to pick the correct titles on these DVDs is to navigate through the DVD menu.
Looking at dmesg (Linux system log) confirms that faulty sectors have been deliberately added to the disc at certain points. When playing, the OS tries re-reading them again and again, and eventually reports read errors. But while it is trying to re-read, no data flows from the disc to the player, which is why the freezes happen.
Obviously, the protection scheme is either blatantly breaking the DVD standard, or utilizing some loopholes in it. Apparently the idea is that if the player reads only those sectors the DVD "playlist" requires, it will skip the faulty sectors and work just fine. The problem is that computer-based players tend to have a linear read-ahead cache - possibly already at the OS level - which doesn't account for any jump commands in the "playlist". If the cache size is such that part of it would be filled from the faulty sectors when playing the end of the chapter... I'm sure all of us see the problem.
(The explanation may have technical inaccuracies, but I think the basic idea is correct.)
The only workaround is to image the whole disc to the hard drive, ignoring read errors, and then play the image file (which will not generate any further read errors). Unfortunately, because this involves breaking (ineffective) encryption, doing it is illegal in most countries these days.
The usual ultimate irony is, of course, that only legitimate customers like us have these problems. Not sure if that is funny anymore or just sad.