The seek bar is rubber banding very often, making it difficult to use. This issue is permanent for me, haven’t tried all settings yet but this likely isn’t related to some setting. I’ve been using bluetooth headsets, when I tried turning bluetooth off and restarted the app, it worked as usual. Turning bluetooth back on and restarting causes same issue to appear.
Link to video:
Debug log:
This is more or less normal with Jellyfin.
The opus trancoded content does not handle correctly seeking, so when transcoding seeking is in fact a restart of the transcode at the new point. This can take some delay depending on network and Jellyfin power.
Thanks for the quick response! I do understand the delay, but i wonder if it’s nessesary to lock the seeking; while the video doesn’t have any sound to it, but even after the music plays (probably the end of the delay you spoke of), it still decides to drag itself back to its new starting position repeatedly until it’s willing to move again
Not sure to understand your comment.
You can’t seek during the starting of the playback since the media is not loaded so there’s no positions to seek or move to. It just keep displaying the data it have during the load to avoid displaying 0:0 at that moment.
The rubber banding behavior keeps happening even after the playback has loaded in, it just keeps resetting to the previous position
Here’s another link with sound, maybe it’ll help c:
This is not really more clear since the video does not show the touches.
To resume: Since there’s transcoding to seek there’s a restart of the playback this takes times to load and to refresh the UI too.
If you try to seek instantly after another seek it will fail.
Please try to better describe with words what you are exactly doing, but keep in mind that it’s transcoding you can’t seek fast dozens of times, and there’s no actual need to do that either.
Seeking is important to me when i want to listen to highlights in certain music c:
I’ll try to explain it better with another video where I seek with timestamps, also i made sure that my finger is only at the seekbar while its moving!
Link to new video: https://photos.app.goo.gl/DohaxqZcMaBt1rQGA
//
First occurrence:
00:01 - playback start, music is now playing
00:02 - attempting to seek
00:03 - released seek, playback resets to previous position?
I don’t mind waiting until music playback begins but once playback has begun, I expect the player to be ready to seek regardless of codec. Alternatively have some indicator to suggest that seeking is locked
//
Second occurence:
00:07 - playback starts, music is now playing
00:08 - attempted to seek (for an extended duration)
00:12 - released seek, playback resets to previous position!
While i do need to seek within a short timeframe after the playback starts (1~2 seconds), once i start seeking, it doesn’t matter how long i wait, it just returns back to its previous position
There’s no sound in that one so it’s hard to confirm what you write.
When you say playback reset to previous position you mean the sound or just the seekbar position that will then move later to the proper position?
the sound also goes back to the previous position, not only the seekbar, e.g. if i start seeking at 00:30, drag the seekbar to 4:35, and then release at 00:45, then the music will jump back and start playback at 00:30
Can you make a log that does exactly that and only that ?
I can’t reproduce that behavior in any transcoding cases.
I didn’t get it perfectly, but i did reproduce the bug a few times across the music
Ok so was able to reproduce with an updated Jellyfin server.
This is a Jellyfin side bug 
You probably have the same errors on your server logs.
[11:52:15] [ERR] [35] Jellyfin.Api.Helpers.TranscodingJobHelper: Error deleting partial stream file(s) D:\Prog\Jellyfin\data\transcodes\bf2fe7b64117b4a979485ff7c68cf5c1.opus
System.IO.IOException: The process cannot access the file 'D:\Prog\Jellyfin\data\transcodes\bf2fe7b64117b4a979485ff7c68cf5c1.opus' because it is being used by another process.
at System.IO.FileSystem.DeleteFile(String fullPath)
at Jellyfin.Api.Helpers.TranscodingJobHelper.DeletePartialStreamFiles(String path, TranscodingJobType jobType, Int32 retryCount, Int32 delayMs)
[11:52:15] [INF] [35] Jellyfin.Api.Helpers.TranscodingJobHelper: Deleting partial stream file(s) D:\Prog\Jellyfin\data\transcodes\bf2fe7b64117b4a979485ff7c68cf5c1.opus
[11:52:16] [ERR] [35] Jellyfin.Api.Helpers.TranscodingJobHelper: Error deleting partial stream file(s) D:\Prog\Jellyfin\data\transcodes\bf2fe7b64117b4a979485ff7c68cf5c1.opus
System.IO.IOException: The process cannot access the file 'D:\Prog\Jellyfin\data\transcodes\bf2fe7b64117b4a979485ff7c68cf5c1.opus' because it is being used by another process.
at System.IO.FileSystem.DeleteFile(String fullPath)
at Jellyfin.Api.Helpers.TranscodingJobHelper.DeletePartialStreamFiles(String path, TranscodingJobType jobType, Int32 retryCount, Int32 delayMs)
[11:52:16] [INF] [35] Jellyfin.Api.Helpers.TranscodingJobHelper: Deleting partial stream file(s) D:\Prog\Jellyfin\data\transcodes\bf2fe7b64117b4a979485ff7c68cf5c1.opus
[11:52:16] [INF] [35] Emby.Server.Implementations.Session.SessionManager: Playback stopped reported by app Android 13 playing ???????. Stopped at 0 ms
[11:52:17] [INF] [53] Emby.Drawing.ImageProcessor: Creating image collage and saving to D:\Prog\Jellyfin\cache\temp\9d18cd42db7b4bc497f1057140514cdb.png
[11:52:17] [INF] [21] Emby.Server.Implementations.Session.SessionManager: Playback stopped reported by app Android 13 playing ???????. Stopped at 0 ms
[11:52:17] [INF] [63] Jellyfin.Api.Helpers.TranscodingJobHelper: D:\Prog\Jellyfin\ffmpeg\ffmpeg.exe -analyzeduration 200M -ss 00:01:09.000 -i file:"\\diskstation\music\media\music\????\??????? (single) (1991)\01 ???????.flac" -threads 0 -vn -ab 128000 -ac 2 -ar 48000 -id3v2_version 3 -write_id3v1 1 -y "D:\Prog\Jellyfin\data\transcodes\bf2fe7b64117b4a979485ff7c68cf5c1.opus"
To resume, Jellyfin fails to stop and delete the previous transcoding session, then do not correctly understand the change in the start time and reuse the session so cache filename that is still the previous one with ffmpeg unable to write to it either hence the previous start value.
Each time the seek fails and rollback the deletion fail log is shown.
I’ll try to see if I can force Jellyfin to use a new session each time to avoid this.
Well actually it’s an agressive optimisation on my side that no more works on Jellyfin. I suppose I can’t blame them this time 
Should be fixed in next release, seek will probably be a little slower but no more fail in those cases.
thats unexpected (but really cool), usually developers tends to throw a curveball to the platform that causes the issue rather than making a patch to fix those issues…
thanks aaaalot for putting the effort of making up for their bugs c:
For once this is not really their bug Just something that no more works but was maybe not supposed to work.
What I’d love them to fix is opus transcoding at proper bit rate