You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When playing a bluetooth track that contains duration and position (progress timestamp) data, the progress bar is frequently not accurate, finishing largely before a song is over, or not completing when a song does.
To Reproduce
Connect to PILOT Drive via bluetooth
Play an audio track that contains duration & position data
Note that the progress bar is frequently not accurate, indicating the song is done much before it actually is.
Expected behavior
The progress bar matches the proper timestamp
Actual behavior
The progress bar is inaccurate to the actually playback timestamp
Screenshots
The progress bar about to complete
The completed progress bar
The actual song progress, not even halfway (jump scare)
Host information:
OS: Fedora
Version: 37
Browser information:
Browser: Mozilla Firefox
Version: 110
Smartphone:
Device: Pixel 6a
OS: Android 13
Additional context
This behavior is seemingly random, and the progress bar seems to be hit or miss, but when it's off it's way off. My guess is that this is due to the setInterval implementation and the inaccuracies of async time keeping
The text was updated successfully, but these errors were encountered:
Describe the bug
When playing a bluetooth track that contains duration and position (progress timestamp) data, the progress bar is frequently not accurate, finishing largely before a song is over, or not completing when a song does.
To Reproduce
Expected behavior
The progress bar matches the proper timestamp
Actual behavior
The progress bar is inaccurate to the actually playback timestamp
Screenshots
The progress bar about to complete
The completed progress bar
The actual song progress, not even halfway (jump scare)
Host information:
Browser information:
Smartphone:
Additional context
This behavior is seemingly random, and the progress bar seems to be hit or miss, but when it's off it's way off. My guess is that this is due to the setInterval implementation and the inaccuracies of async time keeping
The text was updated successfully, but these errors were encountered: