With the introduction of the new feature that syncs all audio tracks to iOS rather than just the selected track, my attempts to sync all take an unnecessarily long time.
All of my media is encoded with both a stereo AAC track and a 5.1 AC3 track, using mp4 containers. This ensures that the file will direct play to the vast majority of clients (certainly all of the ones I care about - PMP, RasPlex, iOS, Windows 10).
With the old behaviour, syncing would just include the AAC track, and would happen very quickly. With the new behaviour, sync attempts to also include the AC3 track, which triggers the transcoder.
This makes each individual sync take substantially longer, for no additional benefit at the end, since there’s no benefit to attempting to include the AC3 5.1 track for playback on my iPad or iPhone.
Is there any way to configure the new sync behaviour such that it doesn’t included unwanted audio tracks? I expect a lot of people encode their media in a similar way to me, so this issue is likely to affect a substantial number of people.
EDIT: Moved to Ask a Ninja, as the Mobile Sync section doesn’t seem to get much activity.
Confirmed that this is still the case with 0.9.15.2.
Is nobody else seeing this behaviour? I find it hard to believe it would be just me!
Yep same here. Needs to be fixed soon!
No one? It seems that the Plex fora are either overwhelmed with support requests or severely understaffed… Or both 
Moved to Ask a Ninja, hopefully somebody can help!
Another bump for this, as it is still happening in the latest PMS.
Looking through the logs, it would appear that the MDE is getting tripped up by the presence of any AC3 track and triggering a transcode to AAC, without first verifying whether a suitable AAC track is already present. Specifically, just before the transcoded kicks in, the log shows “MDE: E06 - Title: no direct play video profile exists for http/mp4/h264/ac3”. However, the file in question is already MP4/h264/AAC/ac3.
Another bump for this, as its been a couple of months and the issue is still happening. Confirmed with latest PMS (0.9.16.3) and latest Plex for iOS (4.0.15).
iOS 9.3 now apparently supports AC3 decoding, which makes this bug even more squash-worthy. I think it would just take an update to the iOS profile at this point to let PMS know that devices with 9.3+ support AC3.
I’m having the comical situation now where a file with both an AAC and AC3 track is being transcoded to add a further, redundant audio track. So the device winds up having three playable audio tracks by the time a file is synced.
@softsign That’s interesting, I hadn’t heard that! A quick Google didn’t bring anything obvious up about this change though, could you point me in the right direction?
@softsign said:
iOS 9.3 now apparently supports AC3 decoding, which makes this bug even more squash-worthy. I think it would just take an update to the iOS profile at this point to let PMS know that devices with 9.3+ support AC3.
I’m having the comical situation now where a file with both an AAC and AC3 track is being transcoded to add a further, redundant audio track. So the device winds up having three playable audio tracks by the time a file is synced.
@benadderson
Pretty sure it’s E-AC3, not AC3 actually. iOS 9.3 brings more immersive audio with Dolby Digital Plus support | iMore
To clarify, its both E-AC3 and AC3. The E-AC3 spec requires an E-AC3 decoder to handle standard AC3 as well (with the exception of a few unusual sample rates).
See Annex E, 2.3.1.6: https://web.archive.org/web/20140110224522/http://www.atsc.org/cms/standards/A52-2012(12-17).pdf
Bumping this again, as the issue is still present in PMS v0.9.16.6 & Plex for iOS v4.1.
Given this has been around for a few months now, it would be great if we could get some sort of comment from somebody at Plex. Based on those posting in the PMS release thread, maybe @“Chris C”, @chrisallen or @mfeingol can help? Or @elan perhaps?
Its not that this is a show stopper for me, otherwise I’d have been making more noise about it. It would just be reassuring to know that this issue has been taken on board, and whether there are plans afoot for a fix, or possibly a workaround we can use in the meantime. One that doesn’t involve a mass re-encode of our libraries for sync purposes 
@“Chris C” , @chrisallen, @mfeingol, @elan, @jam, @hsousa, @sergiou87, maybe even @atrus and @@sa2000
Come on guys, we have asked politely for months now. Please attend to this thread and this crippling issue!
@FrederikFK and @benadderson Apologies for the delay in replying to this thread. While it is not trivial to conditionally allow devices running iOS 9.3 or higher to sync AC3 streams as is, and transcode for devices running iOS 9.2.x or lower, I have filled an internal issue so we can investigate a solution. I don’t have anything else to add right now, but I will follow this up with the team to see what we can do.
Thanks! I would actually prefer if the AC3 track didn’t sync at all (only the AAC stereo track) 
@chrisallen Thanks. I agree with @FrederikFK that syncing only the AAC would be perfectly fine. If conditionally syncing AC3 streams to iOS devices that support them can be solved in the future then great, but for now AAC only is more than good enough! 
@chrisallen Any chance of an update on this issue?
I’ve got a few trips coming up over the next few months, so it would be great if we could get something done about this, even if its only an interim solution in the first instance.
