Nope, sadly not.
The PCM-Hack does the following: PT audio in IEC mode is shipped in so called IEC frames. Those frames tell what they have in it. Those IEC frames are transmitted via a 16 bit format. They are using a certain bandwidth. E.g. DTS / AC3 are send via 48 khz (44.1 khz) and 2 channels. DTS-HD / TrueHD via 192 khz and 8 channels. Channels in that regard are only used to describe the bandwidth.
You can think of a IEC package like a birthday present. The very moment the receiver knows how to unpack these, it will succesfully unpack the DTS / AC3 / EAC3 ... in it and it will play well. Now there is a problem though. The very moment the postman that ships these IEC packages does not know if those packages can be e.g. combined with certain other packages (resampled) or pushed a little (set volume), which would be a problem for the inner content of these packages.
So the good case:
Android sees the data coming in as 16 bit wise shipped packages and does neither resample them and does not change the packages volume. If that is given - everything is fine and the AVR will successfully receiver the content of the packages. In order to do that. We tell Android: Ey Android - please set your volume to 100% to not touch anything, so that we can savely unpack the IEC packages later on.
But now something evil (might happen). Beginning with Android 5 - the AudioTrack (the postman sending audio packages) has a certain shelf where it might store the packages, trying to combine the packages with others, trying to alter the packages (resampling) to better fit in the current post-car. If this happens the non interpretable content of your package gets broken.
If this happens: you will hear plain noise on your AVR in full volume - this will kill your ears.
Therefore we changed that in kodi v17. We only ship the passtrhough audio stuff if there is a special, secure post-service, that e.g. tells us: Yes, I got it - i won't touch the packet content, I won't mix it - I will even block the post-car so long until all your packages are transmitted.
The "shitty" build reintroduces the Jarvis behaviour of sending PT audio. A sidenote: The so called PCM hack in Jarvis is even more dangerous as it is now in v17. As in Jarvis plain "zeros", e.g. packages with the packaging the receiver / AVR was not able to unpack properly, were sent. Therefore it's quite common in Jarvis that you get a seconf of noise on start and after stop by default.
Any questions left?
In pictures:
Jarvis:
Krypton:
PS: Both in that picture paid the same price.