Only with this past weeks update to the app on Android TV has Live TV been available for me to test on my MiBox. While doing so, I noticed video/audio sync issues with a few shows, but not others. Using the HD Homerun Android App, I realized the problematic shows were airing on channels with poor antenna signal. These channels were sub-channels (56.2, 24.4), as such they were lower-quality video and lower-quality signal. The HD Homerun Android App did have problems with the video feed on these channels, and it was manifest in the video appearance. However, there was no video/audio sync issues.
My expectation is that Plex would perform similarly, passing video feed issues from the server to the client, but not generating new video/audio sync issues. To be specific about the video/audio sync issue, the audio played normal. The video became very slow at times, probably corresponding to the corrupt video on the low-quality signal.
Anyone else experience this? Are my expectations incorrect?
So, this bit me last week watching football, there was cloud cover and so my signal was weak. I experienced this same sort of audio/sync issue and had to stop watching via plex. Any help?
What client are you running? We’ve been having a two-person discussion about this issue (in particular with the Bravia Android TVs) over in another thread. Just recently, I noticed something interesting about the captures produced by Plex and how they relate to audio sync issues for me.
For the channel where I see this frequently, my signal strength is generally around 80-85%, and my signal qualify is generally 95%+, so I’m not so sure that it’s a factor, although I’m willing to entertain any possibility at this point. I’m moving my HDHomeRun Extends upstairs this weekend to put them closer to the antenna and shorten the Coax run to about 25 feet from the attic to the HDHRs, so I am curious to know whether that will have an impact…
Thanks. I’ll keep an eye on that thread also. I am using a HDHR Connect with a plenty powerful enough linux box. The TV side is a MiBox. There’s only 50ft of cable between my antenna and the HDHR Connect.
I think this problem comes down to two things primarily. The poor support for the MPEG-TS container now used for DVR on some Android/Android TV devices, and apparent issues in either the incoming streams or MPEG-TS files produced by Plex for DVR and Live TV consumption.
Perhaps this weekend, I’ll try recording a show through Plex and simultaneously capture the raw stream that Plex is consuming. I’m fairly sure I can consume the same stream simultaneously. Then, I’ll pick off the .ts segment files created during the Plex DVR recording for analysis. I can compare the Plex captured/assembled .ts against the raw capture to see if they both produce the AC3 decoder errors during remux to .mkv. If they do, then the burden shifts to SiliconDust/our setups. If the Plex recording does exhibit the problem but the raw capture doesn’t, then the issue swings back to Plex. If the raw capture is good, but the Plex recording is bad, then I’ll go ahead and remux all of the segments individually to determine whether they produce the same errors. If the segments don’t produce the errors, but the assembled recording does, then we can probably conclude that the problem is introduced when Plex assembles the segments. Otherwise, the problem can be isolated to either the Plex stream capture process or the mysterious transport stream remux that Plex does to the segments during recording, which I’ve seen mentioned in a few places.
Anyway, I’ll keep you posted, and I’ll capture my Plex logs for the same time period so that I can post my findings.
Sorry, I never got around to it. My server hardware has actually been upgraded in the last week, but the sync issues are still present on my client and the logs I’m collecting for all post-process remuxes still indicate the bad ac3 blocks. I’m working from home today, so I’ll run through the procedure I get off a conference call in the next hour. I should have some information and logs to post in the next few hours.
Hmm, not sure whether this is good news or bad news. I get the same AC3 decoder errors when I remux a direct capture off of the HDHR Extend. I’ll reach out to their support and follow-up. Probably it’s good news, because I think they’re more likely to turn around a fix than Plex is.
I’ll capture a longer section of video, and then place the captured .ts into my library to ensure that the audio sync problems are present. If they are, then we can say for certain that the problem is with the HDHR and not with Plex in this regard.
I am using the HDHR Expand here in Europe and I get audio out of sync issues on recorded shows, but so far it seems only with Plex Web in Chrome and it works fine in Plex iOS and Plex Fire TV. So maybe it’s rather a playback issue.
Generally my signal strength is 85% or higher and my HDHR sits right next to the wall outlet/antenna (cable). Not sure where I would see these AC3 decoder errors (thankful for any pointers).
I initially thought that’s a problem of my post processing script (using ffmpeg) and disabled it. But turns out the out audio sync issues are present in the original TS file of the Plex recording, but again I only get the out of sync issues with Chrome/Plex Web so far.
Playing with
Chrome/Plex Web = audio is out of sync.
Playing the TS file with VLC = audio is fine.
Playing on Plex iOS (iPhone) = audio is fine.
Playing on Plex Fire TV Stick = audio is fine.
Plex Media Player for Windows = audio is fine. Hmm, seems really isolated to Chrome.
Plex Server Version 1.9.3.4290
Plex Web Version 3.21.2
I still have some additional tests to run and debug logs to obtain for SiliconDust support, but the issue is actually more complicated than it appears. In my experience, when a transcode is a required for a client, audio sync is maintained because the transcoder is required to drop the corrupted blocks, which corrects the audio sync loss.
So for me, iOS maintains sync during playback, not necessarily because of the player, but more likely because a transcode is required. Likewise, sync is maintained on all clients when I do a post-process remux, so long as I re-encode the audio. VLC is a robust player, so I attribute the ability to maintain sync there to the player. What I’m trying to say is that the player is a factor, but the fundamental issue is the captured stream from the HDHR (I also use an Extend). Plex is a complicating factor, because it processes/remuxes the file for some clients and not for others.
I intend to put together a new post with all of the details I’ve collected and the feedback I receive from SiliconDust’s support.
This issue was non-existent when Plex DVR offered “remux to .mkv”, but again, I attribute that to the processing of the incoming stream, rather than the various client players. The easiest way to eliminate the issue for DVR is to do a post-process remux with an audio re-encode (even a remux to an mpeg-ts container and the same audio codec will address this for DVR, provided you don’t do an audio copy). I’ll be sure to tag you and all interested members when I can post some comprehensive details.
I am having a similar issue. On a particular set of channels that are harder for me to get that are in VHF when I try to watch live TV or DVR the audio stutters. The pictures stays crisp but the sound goes in and out for just a split second. I just logged into the tuner and it says that my signal strength is 100% and quality fluctuates between 60s and 80s. I noticed last night if I stream directly from the HDHomeRun to my television everything seems normal. On the other channels I get a similar signal and quality but I don’t have problems recording or watching live TV. The station transmitting VHF shouldn’t matter should it?
