I have stored track progress checked for my audiobook library, but the progress varies. Even pausing for a few seconds and resuming, the track could be a couple minutes earlier or later than where I left off. It seems that the longer the track, the more the resumed place could be off.
Server Version#:1.41.9463
Player Version#:plexamp android latest
Try stopping instead of pausing.
Long press Pause to completely stop.
This is absolutely recommended if you want to continue the track on a different client/device.
I tried that today and it is doing the same thing. The time upon resuming does not change, but the audio at that point does. For example, my paused time may be 10 hours, 43 minutes and 11 seconds. When I resume, that time is the time it resumes at, but I am a minute (or more sometimes) prior in the audio. So the time compared to actual audio is not consistent. It is an mp3 file for the audio, but I’m not sure how that could happen in any audio file playback.
In MP3s, it’s possible seeking isn’t exact.
Without Plexamp logs we’re guessing at where it was trying to resume at vs where it ended up.
Thank you for taking time to look at this, been bothering me for awhile. Some info about it. I download the files to my phone before playing them, so network activity shouldn’t matter. I only use a single device to play the book. I have android auto setup to use it plexamp, but the problem happens the same whether I’m using it with android auto or not. The longer the file, the more it seems to be off, as if it is rounding and longer file means more to be rounded. You can let me know any settings you may think affects it and I’ll take a look, I’ve gone through about all I can find.
Plexamp.1.log (103 Bytes)
Plexamp.2.log (76.2 KB)
Plexamp.3.log (296.1 KB)
Plexamp.log (37.6 KB)
Plexamp.4.log (103 Bytes)
I can tell you where it’s trying to resume:
Mar 21, 2025 14:02:50.642 [0x40dcf6c0] INFO - BASS: Queueing stream (1 total, 0 handles) with identifier 1742556328464, gain 2.6 dB, overlap duration 0 ms, start offset 37057079 ms (paused: 1).
…but I can’t tell you if that’s where it ends up, obviously.
I did a little testing. I think it happens when my phone connects to my Ford android auto. I will attempt to do some planned plays and pauses, then get those logs. When I pause on my device without a connection to an external source, it seems to pause and pickup at the same place. In my car, which is my primary listening location, it is all over the place.
It really shouldn’t matter which device it is, as the car e.g. won’t give it a specific place to resume from.
Plexamp.log (133.1 KB)
Attached is a log where I played, then paused, then played, then paused. The second play was about 10-15 seconds away from my first pause. I then queued to the spot and listened, then paused at the end. This was in my car. I looked through the log and it has lots of times in it, but I didn’t think it had a mismatch on first glance. Perhaps you can see something. If this doesn’t show anything, it may be a dead end and maybe it just my set of hardware/software.
Ah, so I think you’re running into some code we have to specifically handle long-form audio where, upon pausing, it seeks back a little bit so that you don’t lose anything. It looks to be trying to seek back ~600 ms to account for the soft fades we do on pause/resume.
The format you have is MP3, so it’s possible/likely that the seeking (especially in such a large file) is somewhat non-exact, so that may be what you’re seeing.
I’ve gone ahead and disabled this feature for longform MP3 tracks for the next release as it may have been doing more harm than good.
Thanks for looking into this issue. Whether it fixes it or not, thanks for the time it took.
It should fix it, because there was definitely an indication in your log that we were seeking back after pausing.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.
