Trying out the new beta app for Vizio, works great except for one pretty major flaw related to Direct Play. In a nutshell, the player refuses to select the correct audio tracks, and presumably defaults to whichever audio stream comes first within the container. For instance, the playback settings will report that audio is switched to Track 2, but the player is actually using Track 1. The described behavior has been observed on every file in my library with multiple audio tracks. The issue is not present when using Direct Stream. Tried toggling the supported audio formats in the settings, no luck.
Thanks for the report! I’ve filed an issue. I’m pretty sure I know what’s happening here, but we’ll look into it and hopefully have a fix in soon.
@ruuk Direct play does not appear to work on files with multiple audio tracks anymore.
Note: by “selecting” direct play we hereby understand the configuration where direct play is enabled and direct stream is disabled.
Observed behavior: on being forced to playback a file with multiple audio tracks using direct play, the client either returns an unexpected playback error (if direct play is selected before playback) or enters endless buffering (if direct play is selected during playback). This behavior is not present when direct playing files with a single audio track.
I am willing to provide a short sample file, should you consider it to be helpful.
Client Version: 5.0.3
Chipset: SX7B (2)
Server Version: 1.19.3.2831
If there are multiple audio tracks, and the selected one is not the first one, we need to direct stream so that there is only the selected track. It’s on our list to see if we can actually avoid the direct stream and have the correct track selected when direct playing.
It does sound like there is a bug though, since if you have Allow Direct Play enabled and Allow Direct Stream disabled, it should just full on transcode instead of failing. I’ll file an issue and we’ll look into that.
Just to be clear, there is no way to force a direct play. We’ll always direct play if possible, direct stream if we can’t, and transcode streams that can’t be direct streamed. These settings just allow disabling direct play/stream.
I was not aware of the expected transcoding at the time of testing. My server had Disable video stream transcoding enabled, which caused this particular failure. I can confirm that disabling the aforementioned option allows the transcoding to start properly.
I would like to know what you think about the feasibility of the use case I’ll outline below.
Given: a container with a subtitle track, two audio tracks and a video track.
Outcome: playback with subtitles enabled, audio set to track 2, video stream remains unaltered (subtitles not burned-in server-side).
As far as I am concerned, subtitles through direct stream are currently unsupported on Vizio, unless burned into the video stream. Given the current state of the Plex client in question, should we expect the aforementioned outcome to be possible down the road?
Currently as it is now, we can avoid a burn in on ASS, PGS, and SRT, so if it’s one of those subtitles, you can have that outcome now with direct stream [edit: sorry, if you need to direct stream, you need to burn] (though with ASS and PGS, you lose formatting, so in some cases forcing a burn is necessary).
I don’t know how feasible other subtitle formats are. They are likely more difficult to implement than the ones we have now were, and that’s probably going to be a bit in the future (if we can and do add support for them), after we’ve gotten the app on par with the other clients.
We might be able to do direct play with for the multi audio track case in the future, it just remains to be seen whether it will work with the Vizio player - if it doesn’t then there’s nothing we can do there.
When Direct Playing
-> When multiple audio tracks are present
–> When the first audio track is selected, the third is played, but the server reports the first track is being played
–> When any other audio track is selected, the system transcodes to AAC but plays the chosen track correctly.
This may be related. If not, I can submit a separate bug report:
All audio tracks are being transcoded by the client/tv to DD 5.1 and output via ARC.
–> TV’s Digital Audio Out is set to Bitstream
–> Verified with several discs and many audio codecs and channel formats
@akoreneff: it sounds like the app thinks it can play the first track but the TV actually can’t. The TV then ignores that track and plays the first track it can (in this case the third track).
Make sure that Settings->Audio->DTS (DCA) is disabled in the app. If it is or you disable it and you’re still having issues, I’ll need some info on the file in questions.
For that, on the browser client, go to the details page for the video in question, click the More button •••, select Get Info and then select View XML in the lower left of that dialog and share the XML with me.
1st track is DTS-HD MA (if this is selected, it plays track 3 which the server transcodes to AAC and the TV transcodes to DD)
2nd track is DTS (if this is selected, it plays track 2 which the server transcodes to AAC and the TV transcodes to DD)
3rd track is AC-3
4th track is AC-3
Turning off DTS in the client causes the server to transcode the 1st track to AAC, which the TV transcodes into DD.
Definitely some buggy behavior, but better than the wrong track playing.
It sounds like everything is working as expected then.
DTS shouldn’t be enabled. It’s only there for pass through to devices that support it, and it’s likely to be removed as an option in the future after I verify with Vizio that pass through doesn’t work for DTS (as the evidence seems to suggest).
Transcoding audio will almost always be to AAC. AAC is supported by the TVs and has better quality at the same bitrates as AC3. The app has no way of knowing that an AC3 capable receiver is attached, so there’s no way we can switch based on that.
I too am having a similar issue. Movie with DTS-ES 6.1, and 2x AC3 audio tracks, which the first is the commentary track confirmed by manually selecting it during playback. With DTS (DCA) Audio enabled, the audio plays and reports DD on the TV, but it is actually playing the commentary track. With it disabled, the audio plays the correct track (without commentary), but transcodes it down to stereo as reported by the TV.
Also, can we add back in the Info button from earlier builds somehow? It allowed me to sort of track down what was occurring during these types of situations. Thanks!
From what you’ve said it sounds like it’s behaving (mostly) as expected within the the limits of the TV. DTS should never be enabled because the TV does not support it. When it’s disabled the app can make the correct decision and have the server transcode the the audio. If a DTS track is selected it will be transcoded to AAC and if an AC3 track is selected it will be direct streamed.
If it’s transcoding to stereo that might be wrong, but I don’t have enough information to know what’s going on.
