A duration of 3600 can mean one hour or sixty hours depending on the unit a developer assumes. That mistake can affect card labels, progress bars, skip buttons, and completion rules at the same time.
Choose one internal unit for your application. Seconds are a common choice for player state. If another system uses milliseconds, convert at a clearly named boundary rather than scattering multiplication across the interface.
Separate raw values from labels
Keep a numeric value for calculations and create the display string from it. A label such as “1 hr 5 min” is not suitable for saving a resume position. Avoid parsing your own localized display text back into a number.
Validate values from external data. Negative durations, non-finite numbers, and very large values need a defined fallback. Unknown duration is different from a genuine zero-length file. Do not divide by zero when drawing a progress indicator.
Round for the task. A search card can show whole minutes, while a player may need seconds. The underlying value should remain unchanged so those views can agree.
Use a boundary test table
Check 0, 59, 60, 3599, and 3600 seconds. Add an unknown value and a fractional value. Test a playback position slightly beyond the recorded duration, because publisher metadata and the actual media file can differ.
Where the media player discovers a more accurate duration, decide which screen uses it and whether the catalog value remains visible elsewhere. A clear conversion policy is easier to explain than a progress bar that jumps when a file finishes loading.
For Podnivo-specific fields, confirm the unit in the current API contract before creating adapters.