mirror of
https://github.com/jellyfin/jellyfin.git
synced 2026-01-23 23:20:51 +01:00
LRC Lyrics stop being read past 1 hour #6596
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#6596
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 @mihawk90 on GitHub (Dec 21, 2024).
This issue respects the following points:
Description of the bug
I mentioned this previously in #11518, however this issue was closed when #12543 because it (probably) did fix the original issue. Also, the situation has changed slightly so I'm making a separate report.
I recently re-scanned some files that still had old cached lyrics data, and I noticed that now instead of the lyrics being recognised as unsynced, they are indeed recognised as synced, but cut off at the 1 hour mark.
As mentioned in the linked comment this was previously broken already, but it cut off when the minutes got into 3-digits, now however it cuts off at any timestamp after 1 hour.
I'm not sure if this is an issue with the LrcParser library or with JF itself. However, I have reason to believe this is an issue with JF's import, see Additional Information section below.
Reproduction steps
What is the current bug behavior?
The lyrics cut off at the 1 hour mark, i.e. the last line before 1 hour is still shown, the first line after 1 hour is not.
What is the expected correct behavior?
Lyrics should be shown in their entirety.
Jellyfin Server version
10.10.0+
Specify commit id
No response
Specify unstable release number
No response
Specify version number
No response
Specify the build version
10.10.3
Environment
Jellyfin logs
FFmpeg logs
Client / Browser logs
No response
Relevant screenshots or videos
"Edit Lyrics" menu:

Additional information
ffprobeof the sample file:I also checked the LRC file generated by JF in the metadata directory. I noticed it's rewriting the timestamps, but it seems the format being written is not actually recognised:
Note the difference in timestamps from
mm:ss.ffftoh:mm:ss.f.I wouldn't think the library would rewrite the timestamps, but then again I don't really have any reason to think why it wouldn't.
@gnattu commented on GitHub (Dec 21, 2024):
Our music tag parsing library is formatting timestamp in DDdHH:MM:SS format but the LrcParser we are using is matching the pattern with only minutes and seconds which caused this.
There’s no "absolutely correct" behavior in this case because the LRC format wasn’t well-defined. Its original format only supports [mm:ss.xx] timestamps, which doesn’t consider long songs as a potential use case and how to handle such songs now becomes implementation-specific. It looks like popular implementations choose to extend minutes part beyond double digits when necessary.
@mihawk90 commented on GitHub (Dec 21, 2024):
So it is a dependency issue, alright.
Guess that must have changed recently though given that it used to work up to 99 😅
And yes I agree it's not a typical usecase. These are live sets and I'm using the lyrics tag as a tracklist. Of course that's not what they were designed for and I get that, but a CUE sheet would fill the library with tons of short duration tracks, so this felt more reasonable.
@mihawk90 commented on GitHub (Jan 24, 2025):
Fixed in 10.10.4 (tested and confirmed on the same file)