Server Version#: 4.156.0
Player Version#: 2025.30.0
Device: ipad pro m4 11”, ipadOS 26.1
I can provide a server log if necessary, but that feels unnecessary - this smells like it’s a client bug.
This may be related to my other bluetooth audio bug report. I have no way to gauge if they’re linked or which is cause and effect, however, so I’m reporting them both separately.
When playing a video with bluetooth audio enabled (e.g. headphones), an alarm or phone call or similar will cause playback to automatically be paused. However, after the alarm is dismissed or the phone call is ended, video playback will resume at a greatly accelerated frame rate (I’m guesstimating 5x or more) for a video duration that roughly corresponds to the duration of the alarm. For example, if the alarm is left to run for a minute, about a minute’s worth of the video will be played at fast-forward speeds.
Once the fast-forward part of the show is over, video playback will resume at normal speeds, though the progress bar, elapsed time, and remaining times will be frozen, and the other bug will mean that there’s no audio once the video playback returns to normal. The simplest way to restore sanity is to close the video and restart.
There doesn’t appear to be a workaround for this.
Steps to reproduce:
- Set a timer or alarm. For testing, a 1-minute timer is usually sufficient.
- Start any video playing. Doesn’t seem to matter which codecs, etc. are involved.
- Wait for the alarm to trigger. The OS will show a notification at the top of the screen and play the alarm sound.
- For the sake of demonstration purposes, leave the alarm blaring for a while. The bug will be triggered for any alarm duration, but the fast-forward effect is far more evident if you leave the alarm going for 30 seconds compared with 1.
- Dismiss the alarm’s notification with the OS’ “x” UI button, which will also silence the alarm.
- Video playback will run at a fast-forward sort of frame rate, and will return to normal after about as much of the video has been fast-forwarded as the alarm played for.
This appears to be more or less perfectly reproducible. If it’s not 100%, it’s really damn close. These days, if one of my alarms goes off, I’m pretty much resigned to having to clean up the mess manually, which is a real pain if I’m watching something while exercising.
This is not a result of iOS 26; the exact same behaviour was seen under iOS 18. This is also isolated to the plex app - no other apps on the device behave this way under the same circumstances.
This only appears to happen when playing audio through a bluetooth device. I can’t reproduce it at all when playing through the device’s speakers.
It’s been this way since the revamp of the plex app. The old version never did anything like this.
It’s been months of hoping that a bunch of bugs that were introduced would get fixed with no results, so I’m finally getting off my bum to report them myself. I’m also attempting to separate them where possible, though some may have common causes even they present differently.
