I think I might have found the source of the issue with these files.
I noticed when RARBG first started releasing these files, MKVToolNix (v44) would produce a messed up file after re-muxing, and as mentioned in this thread, version 45 no longer causes an issue, and in fact resolves it for many players.
So I reviewed what they changed in MKVToolNix v45, and saw two noteworthy entries:
- mkvmerge: H.265/HEVC packetizer: fixed changing the NALU size length, it was using the wrong offset into the hevcC structure.
- mkvmerge: MP4 reader: if there’s no frame offset table (ctts atom) present for H.265/HEVC video tracks, mkvmerge will determine the timestamp order itself instead of relying on the timestamps in the MP4 being in the presentation order required by Matroska. Fixes #2777.
Promising that the original reporter of the issue is posting based on a new RARBG upload.
If you read through Moritz Bunkus’ Post Here. He explains the technical nature of the problem, apparently the MP4 files are missing a ctts atom (frame offset table), which in itself is not a fatal error, but appear to be relied upon in many cases.
This is why re-muxing the file with MKVToolNix v45 resolves the issue, because it’s throwing out the bogus time-stamp information, and recreates it from scratch.
Other players that are handling these files successfully must be handing the missing ctts atom differently. In the short term, what will make these files work is running them through mkvmerge so it can rebuild the raw h.265 stream with appropriate timestamps.
Also, shout out to Moritz and MKVToolsNix for being awesome, support them if you can 
