Describe the bug
SMPlayer slows down noticeably when playing through a playlist with many videos. There is an increasing delay/hang between each track as the playlist progresses. The more videos in the playlist, the worse it gets.
To Reproduce
Steps to reproduce the behavior:
- Open SMPlayer
- Load a folder or playlist containing a large number of video files (20+ recommended)
- Let the playlist play through automatically, or skip through tracks quickly
- Observe the growing delay/pause between each video as the playlist advances
Expected behavior
Each video in the playlist should start playing immediately (or near-immediately) after the previous one ends, with no noticeable delay between tracks.
Screenshots
N/A — the issue is a performance/timing problem rather than a visual one.
Your Enviroment
- SMPlayer version: 25.6.0 (revision 10369, 64-bit)
- OS: Windows 11
- Multimedia engine you're using with SMPlayer (preferences -> general):
[ ] MPlayer
[x] MPV
Logs
Log file attached. Key thing to note for the developers: the log shows that every time a new video starts, SMPlayer repeats the same internal tasks many times over unnecessarily — for example, one function that checks your Favorites list runs about 12 times in a row per video, and several UI refresh routines fire multiple times at the exact same moment. This wasted work adds up across a long playlist and causes the slowdown.
[slow new version.txt](https://github.com/user-attachments/files/25593317/slow.new.version.txt)
Additional context
The slowdown scales with playlist length — it does not plateau or stabilize. Users with a larger Favorites list may experience it more severely, as one of the repeated operations involves scanning that list. Short video playlists (e.g. clips, social media content) are particularly affected since track transitions happen frequently.
Source code analysis
After reviewing the source code, the root cause appears to be in basegui.cpp around lines 461–462, inside createActions():
connect(core, SIGNAL(mediaPlaying(const QString &, const QString &)),
favorites, SLOT(getCurrentMedia(const QString &, const QString &)));The mediaPlaying signal is connected to multiple listeners simultaneously (favorites, tvlist, radiolist), each of which triggers a chain of expensive UI updates — initializeMenus → updateBookmarks → updateWidgets — that themselves fire further redundant redraws. What should be a single "new video started" event snowballs into 12+ repeated Favorites list scans and a full menu rebuild on every single track change.
A possible fix would be to debounce the UI refresh using QTimer::singleShot(0, ...), which would defer the update to the end of the current event loop tick and collapse all redundant calls into one. Alternatively, caching the result of getCurrentMedia so it is computed once per track change rather than once per connected listener would also help significantly.
Regression note
This issue is not present in SMPlayer 19.10.0 (revision 9238, Qt 5.6.0, MPV 0.29.0). That older version handles playlist track transitions without any noticeable delay and can advance through an entire directory of clips in under a minute. The regression appears to have been introduced sometime after that release. Unfortunately, 19.10.0 does not support newer MPV builds with gpu-next and HDR (Crashing and ui broken when directing output driver to new MPV version with user defined option or replacing MPV files with new MPV version), so rolling back is not a viable long-term solution. If there is a way to use a newer MPV build with the older SMPlayer version in the meantime, that would also be appreciated.
Describe the bug
SMPlayer slows down noticeably when playing through a playlist with many videos. There is an increasing delay/hang between each track as the playlist progresses. The more videos in the playlist, the worse it gets.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
Each video in the playlist should start playing immediately (or near-immediately) after the previous one ends, with no noticeable delay between tracks.
Screenshots
N/A — the issue is a performance/timing problem rather than a visual one.
Your Enviroment
[ ] MPlayer
[x] MPV
Logs
Log file attached. Key thing to note for the developers: the log shows that every time a new video starts, SMPlayer repeats the same internal tasks many times over unnecessarily — for example, one function that checks your Favorites list runs about 12 times in a row per video, and several UI refresh routines fire multiple times at the exact same moment. This wasted work adds up across a long playlist and causes the slowdown.
[slow new version.txt](https://github.com/user-attachments/files/25593317/slow.new.version.txt)
Additional context
The slowdown scales with playlist length — it does not plateau or stabilize. Users with a larger Favorites list may experience it more severely, as one of the repeated operations involves scanning that list. Short video playlists (e.g. clips, social media content) are particularly affected since track transitions happen frequently.
Source code analysis
After reviewing the source code, the root cause appears to be in
basegui.cpparound lines 461–462, insidecreateActions():The
mediaPlayingsignal is connected to multiple listeners simultaneously (favorites,tvlist,radiolist), each of which triggers a chain of expensive UI updates —initializeMenus→updateBookmarks→updateWidgets— that themselves fire further redundant redraws. What should be a single "new video started" event snowballs into 12+ repeated Favorites list scans and a full menu rebuild on every single track change.A possible fix would be to debounce the UI refresh using
QTimer::singleShot(0, ...), which would defer the update to the end of the current event loop tick and collapse all redundant calls into one. Alternatively, caching the result ofgetCurrentMediaso it is computed once per track change rather than once per connected listener would also help significantly.Regression note
This issue is not present in SMPlayer 19.10.0 (revision 9238, Qt 5.6.0, MPV 0.29.0). That older version handles playlist track transitions without any noticeable delay and can advance through an entire directory of clips in under a minute. The regression appears to have been introduced sometime after that release. Unfortunately, 19.10.0 does not support newer MPV builds with
gpu-nextand HDR (Crashing and ui broken when directing output driver to new MPV version with user defined option or replacing MPV files with new MPV version), so rolling back is not a viable long-term solution. If there is a way to use a newer MPV build with the older SMPlayer version in the meantime, that would also be appreciated.