Good analysis. Let me add a few observations as I've been looking at this (and awaiting some solution) for several weeks. I can't comment on .m4v's, but I have tried a number of test files as .mp4's and .mkv's.
- I have 2 streaming sticks. One is connected to a tv that can decode DD and DTS. The other is connected to an old tv that can only deal with pcm. One stick is current with OS 10 build 4208. The other is still on OS 9.4 because I've blocked it from the internet. Both have RMP 5.5 build 9.
- all .mp4's and .mkv's are built containing .h264 video. Most are AC3 (Dolby Digital 5.1) audio. Some are AAC (Dolby Surround) audio.
- all files played fine under OS 9.4 and continue to do so on the un-updated stick. As the old tv requires a pcm input, the stick is obviously transcoding both DD and DS to PCM without issue.
- under default stick configuration, the stick with OS 10 no longer properly plays (pops/clicks) files with DD encoding. DS encoded files play fine. It is no longer properly transcoding DD (AC3) audio.
- on the TV capable of receiving a DD/DTS signal, I have had some amount of luck changing the AUDIO/HDMI selection to "DD, DTS". Under this setting, DD encoded files that result in pops/clicks under "AUTO", also play fine. This change does not improve the playback on the TV that requires PCM. This leads me to believe that something is different under OS 10 in how Roku reads the HDMI handshake and acts on what it determines the playback device is capable of.
Based on the above, I've laid the problem on the OS 10 rollout and not on RMP as the RMP version is unchanged between the two sticks, but that may be a false observation and I'd welcome additional tests/observations. Also, others have reported occasional audio dropouts. I have no test cases on this as I have not experienced it.
The Roku documentation is not really clear what amount of transcoding various Roku models are *supposed* to be capable of. I can only base my observations on what my Roku model did before under 9.4 vs. what it does/does not do under OS 10. I'd welcome the documentation being more clear.
As to RMP, there are at least a couple of issues I've been able to define:
- Audio track selection differs between .mp4 and .mkv. For .mkv files, if the file contains both a DD and a DS audio track, RMP selects the track identified in the file as "default", so a file *can* be built with a default DS track and an additional DD track that will play without pops/clicks. For .mp4 files, if the file contains both a DD and a DS audio track, RMP selects the DD track, regardless of the order of the tracks and regardless of which is defined as "default", so it is *not* possible to build a file that will play without pops/clicks.
- RMP doesn't enable manual audio track selection for either file. That option is grayed, which is problematic if you happen to have a file with, say, a base audio track and an alternate like a commentary. Others have said that track selection is enabled if both tracks are DS, but I have not tested this.
I've had a support ticket open for more than a month on this, but have heard nothing on it so far. I loaded build 4208 on the one stick yesterday. That latest build did *not* address the issue. I hope we'll get an update at some point on this, given the number of comments it's generated.
@RokuDanny-R , it would be helpful to see a separate community category for playback of local content. The issues dealing with local content are somewhat different than those dealing with streaming playback.
