mirror of
https://github.com/jellyfin/jellyfin.git
synced 2026-01-23 23:20:51 +01:00
[Issue]: Wrong play time shown #5504
Labels
No labels
area:database
awaiting-feedback
backend
blocked
breaking change: web api
bug
build
ci
confirmed
discussion needed
dotnet future
downstream
duplicate
EFjellyfin.db
enhancement
feature
future
github-actions
good first issue
hdr
help wanted
invalid
investigation
librarydb
live-tv
lyrics
media playback
music
needs testing
nuget
performance
platform
pull-request
question
regression
release critical
requires-web
roadmap
security
security
stale
support
syncplay
ui & ux
upstream
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: starred/jellyfin#5504
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @stefan1983 on GitHub (Mar 5, 2024).
Originally assigned to: @gnattu on GitHub.
Please describe your bug
Hey there,
I am using Jellyfin 10.8.13 on a Linux server 5.10.0-0.deb10.16-amd64 Debian 5.10.127-2~bpo10+1 (2022-07-28) x86_64.
When using the web browser or any client to play my music, I always get a wrong play time shown. Especially when using gapless tracks (live albums) those are completely off:
Web player:

Finamp (counts further):

Is there anything I can do on server side?
The files don't have any issues when playing somewhere else (foobar2000, IINA, VLC...).
That are just standard MP3 or FLAC files.
Reproduction Steps
Just play music in the web or any available jellyfin compatible app (iOS / macOS).
Jellyfin Version
10.8.13
if other:
No response
Environment
Jellyfin logs
FFmpeg logs
No response
Please attach any browser or client logs here
No response
Please attach any screenshots here
No response
Code of Conduct
@stefan1983 commented on GitHub (Mar 5, 2024):
Attached the log file:
Log.txt
@stefan1983 commented on GitHub (Mar 5, 2024):
I would be able to deliver sample files if needed.
@stefan1983 commented on GitHub (Mar 5, 2024):
I just found out that it is specific to macOS Safari. When using another browser, there is no such issue.
Currently I am using Safari Version 17.3.1:
@gnattu commented on GitHub (Mar 5, 2024):
It seems to be related to jellyfin/jellyfin-roku#1629, and it happens to certain media files where the playback time is encoded weirdly.
@Chaphasilor commented on GitHub (Mar 9, 2024):
@stefan1983 you could try re-encoding your files with ffmpeg or Audacity. If @gnattu is correct and it's a problem with the track itself, that might help 🤔
@stefan1983 commented on GitHub (Mar 11, 2024):
So, after re-encoding to m4a files (ALAC) I was able to see the correct play time in the jellyfin apps.
But I am still wondering though why the original FLAC files didn't show any issue when playing outside of jellyfin (foobar2000, IINA, VLC...).
@gnattu commented on GitHub (Mar 11, 2024):
Well, at this point, we cannot do much here.
For some tracks/formats (FLAC/VBR MP3), we have to set
AVURLAssetPreferPreciseDurationAndTimingKey : trueon Apple platforms; otherwise, seeking would result in incorrect timing (off by a few seconds or completely off). This option will have a performance impact, so it is disabled by default.This option can be set by native players, but I'm not sure if there is any way to set it for browsers. Perhaps we can implement an audio-remuxing mechanism to remux FLAC into fmp4 containers and stream it, which could potentially solve this issue not only for Apple platforms but also for the Roku case I've linked.
@jellyfin-bot commented on GitHub (Aug 20, 2024):
This issue has gone 120 days without an update and will be closed within 21 days if there is no new activity. To prevent this issue from being closed, please confirm the issue has not already been fixed by providing updated examples or logs.
If you have any questions you can use one of several ways to contact us.
@BBaoVanC commented on GitHub (Aug 21, 2024):
This is still an issue, please do not close.