Awful audio/video desync in latest version
Since the recent string of updates intending to fix the "No Valid Bitrate" issue, I've been experiencing audio desyncs occurring a few minutes into any video, including at point skipped ahead to in the timeline. The video feed seems to run ever so slightly slower than the audio, causing very noticeable discrepancies between the audio playing and the visuals on screen.
During these updates I had rolled back to a previous version (I believe 0.40.10) where the issue did not appear to be present, figuring it may be growing pains.
This morning the app updated to 0.41.20 and I experienced a similar issue, though this time the audio suddenly cut out for a few seconds while the video continued. After the audio turned back on again, it was desynced with the video by the duration of the cut-out. After reloading the video and skipping back to where the desync started, it immediately desyncs again, this time as if the video was slower than the audio.
I've again rolled back to 0.40.10 and the issue is no longer present.
Can you share a few videos where this happens consistently? And device info? Does the issue happen consistently on newer version, and does not happen on 0.40.10?
https://www.youtube.com/watch?v=oABtbFNOicQ is the video that this happened with this morning; major desyncing starts at about 4:55 where the audio of characters talking did not match up to the subtitles being displayed.
https://www.youtube.com/watch?v=NFmW7UvcSyw and similar videos from this streamer is an example from months ago where the streamer in the lower right corner would be speaking but the audio would be out of sync with their mouth.
These desyncs do not happen when watching the videos in the browser and do not happen in version 0.40.10.
I have double-checked and this issue started in version 0.40.12 - the next available version up in the version picker after 0.40.10.
"device": {
"current_locale": "en_US",
"display_aspect_ratio": "16x9",
"display_mode": "720p",
"display_size": {
"h": 720,
"w": 1280
},
"display_type": "HDTV",
"friendly_name": "39\" Insignia Roku TV",
"graphics_platform": "directfb",
"internet_status": true,
"model": "5000X",
"model_details": {
"Manufacturer": "TPV",
"ModelNumber": "5315X",
"ScreenSize": 39,
"VendorName": "Insignia",
"VendorUSBName": "Insignia"
},
"model_display_name": "INSIGNIA NS-39DR510CA17",
"model_type": "TV",
"os_version": {
"build": "9914",
"major": "14",
"minor": "6",
"revision": "4"
},
"ui_resolution": {
"height": 720,
"name": "HD",
"width": 1280
},
"user_country_code": "CA",
"video_mode": "1080p"
},
I appreciate narrowing down the version where this happens I was trying to reproduce, but no luck I've looked into the diff between the versions https://github.com/iBicha/playlet/compare/v0.41.10...v0.41.12 but nothing looked off that could cause this. If you don't mind, I suggest that you try to reproduce, and once the desync happens (preferably on the latest version) then try to export the "full state" using the web app (check the info screen in web app, there's a "Export full state" button) this should export the registry (local storage), logs and app state, in a zip file. Please be aware the registry would contain profile you're currently logged into, so don't share it publicly. I suggest sending this by email (email is found on info screen in web app) and obviously feel free to redact things you don't want to share. Perhaps by looking at the logs, the different settings, etc maybe I'll get an idea on why this happens
I'm also wondering if the difference between the two versions is a coincidence, and that there's another factor we're not seeing, or if the bug is actually introduced in v0.41.12
Hey sorry for the delay in getting back to you.
I noticed that the diff you pulled is for 0.41.10 .. 0.41.12 but the version I cited as working was 0.40.10 and the version in which the issue presents itself for me is 0.40.12.
Aha, thanks for correcting me, so the diff I needed to look at is https://github.com/iBicha/playlet/compare/v0.40.10...v0.40.12
That kinda makes more sense, this version moves from using HLS stream from iOS client to a DASH stream from TV client, so perhaps there's a subtle difference there that Roku devices, or specific models are not handling correctly.
What's catching my attention is the "graphics_platform": "directfb" from your device, which is way less common for roku devices (it's usually "opengl") reference https://developer.roku.com/en-ca/docs/specs/hardware.md
"opengl" means the device has hardware graphics accelerated support, so it's capable of decoding and drawing video frames faster.
This could explain why this happens, the device is a bit older model than the rest, and might be struggling to draw the frames fast enough, which explains the delay.
Now why this happens for the DASH, and not the HLS, I guess different codecs have different decoding requirements. The problem with HLS is that most of the time it will play for a short period of time before seeing an error, so I can't get back to use it (right now it's only used for live videos, which seems to be ok)
Something you can try to validate some of these theories, is to try and disable the higher qualities from the settings. E.g. uncheck the 1080p quality and see if that helps. If there's no change, trying disabling both 1080p and 720p, just to troubleshoot this further. If this does help, it means the device can't keep up with higher bitrates.