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
I noticed while testing the app that the progress bar briefly showed "5:15 / 5:14" on the Listen page.
This could be caused by a few things, but it's probably inconsistent rounding or metadata that's inconsistent with the file (or with the player's perception of the file length).
Ideally, we'd never render an "impossible" time, but we should also account for the possibility that the metadata may truly be wrong. For example, if the downloaded metadata says the track length is 2:00 and the track is truly 10:00, we don't want to show "2:00 / 2:00" for 8 minutes.
Options:
Show the time with a ceiling (5:14 / 5:14) for a second or two, then snap back to showing an impossible time (5:17 / 5:14) if the track keeps playing past what the metadata says the length of the track is.
When the progress exceeds the length of the track, change the track length display maybe to the current progress, or maybe just a "?:??" as we admit we have no idea how long the track is.
The text was updated successfully, but these errors were encountered:
I noticed while testing the app that the progress bar briefly showed "5:15 / 5:14" on the Listen page.
This could be caused by a few things, but it's probably inconsistent rounding or metadata that's inconsistent with the file (or with the player's perception of the file length).
Ideally, we'd never render an "impossible" time, but we should also account for the possibility that the metadata may truly be wrong. For example, if the downloaded metadata says the track length is 2:00 and the track is truly 10:00, we don't want to show "2:00 / 2:00" for 8 minutes.
Options:
The text was updated successfully, but these errors were encountered: