Bug 479130 - The QtMultimedia backend is severely broken
Summary: The QtMultimedia backend is severely broken
Status: RESOLVED FIXED
Alias: None
Product: Elisa
Classification: Applications
Component: general (other bugs)
Version First Reported In: 24.01.85
Platform: Compiled Sources Linux
: HI major
Target Milestone: ---
Assignee: Matthieu Gallien
URL:
Keywords: qt6
: 479651 483894 485262 485579 486092 (view as bug list)
Depends on:
Blocks:
 
Reported: 2023-12-28 18:34 UTC by João Figueiredo
Modified: 2025-05-01 05:45 UTC (History)
10 users (show)

See Also:
Latest Commit:
Version Fixed In: 24.02.2
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description João Figueiredo 2023-12-28 18:34:03 UTC
SUMMARY
If compiling with QtMultimedia instead of VLC, when a song in a playlist ends, the audio stream simply stops. The same thing happens when skipping to the next song while the previous one is playing; in that case, playback will only resume after pressing the play button twice. Also, if the "repeat current track" option is enabled, nothing changes.

STEPS TO REPRODUCE
1. Start playing a playlist;
2. Let the first song end or skip to the next one.

OBSERVED RESULT
The audio stream stops and repeat doesn't work.

EXPECTED RESULT
Playback shouldn't stop, songs should start playing automatically when skipping, the previous one ends, or repeat is enabled.

SOFTWARE/OS VERSIONS
KDE Plasma Version: 5.91.0
KDE Frameworks Version: 5.247.0
Qt Version: 6.7.0
PipeWire Version: 1.0.0

ADDITIONAL INFORMATION
I'm using pipewire-pulse. I also tried compiling Elisa with VLC to make sure it's a QtMultimedia issue, and indeed the problem doesn't occur there. Both backends work fine with Elisa 23.08.4.
Comment 1 Nate Graham 2024-01-11 19:06:27 UTC
*** Bug 479651 has been marked as a duplicate of this bug. ***
Comment 2 Jack Hill 2024-01-14 21:45:53 UTC
Looks like the problem is QMediaPlayer::playbackStateChanged gets emitted first and then QMediaPlayer::mediaStatusChanged afterwards whilst the Qt5 backend emitted the signals in the reverse order. So the code is set up to assume the media status has changed before the playback state. We could probably just flip the logic around and assume the player status gets changed first, but this might affect the VLC backend (not sure). I guess the "correct" thing to do is to queue a function to recalculate the status that we want after both player and media status have updated.
Comment 3 Bug Janitor Service 2024-01-19 15:07:43 UTC
A possibly relevant merge request was started @ https://invent.kde.org/multimedia/elisa/-/merge_requests/543
Comment 4 Jack Hill 2024-03-18 17:25:08 UTC
*** Bug 483894 has been marked as a duplicate of this bug. ***
Comment 5 Nate Graham 2024-03-18 17:47:23 UTC
Feel free to cherry-pick the fix after 24.02.1 is tagged, which should be today.
Comment 6 Nate Graham 2024-04-09 16:39:16 UTC
*** Bug 485262 has been marked as a duplicate of this bug. ***
Comment 7 Jack Hill 2024-04-15 18:57:56 UTC
*** Bug 485579 has been marked as a duplicate of this bug. ***
Comment 8 Jack Hill 2024-04-25 14:21:54 UTC
*** Bug 486092 has been marked as a duplicate of this bug. ***
Comment 9 Be 2024-04-26 03:22:19 UTC
For anyone coming here encountering this bug in Fedora 40: the Elisa version 24.02.2 with the fix is already available in updates-testing. Run `dnf update --enablerepo=updates-testing elisa-player` to install it before it moves to the main updates repository.
Comment 10 Robby Engelmann 2025-04-29 16:27:03 UTC
Recently, this bug seems to re-appear  here being on git master snapshots:

Operating System: openSUSE Tumbleweed 20250428
KDE Plasma Version: 6.3.80
KDE Frameworks Version: 6.14.0
Qt Version: 6.9.0
Kernel Version: 6.14.4-1-default (64-bit)
Graphics Platform: Wayland
Processors: 20 × 13th Gen Intel® Core™ i7-13700H
Memory: 64 GiB of RAM (62.5 GiB usable)
Graphics Processor: Intel® Iris® Xe Graphics
Manufacturer: TUXEDO
Product Name: TUXEDO InfinityBook Pro Gen8 (MK1)
Comment 11 John Kizer 2025-04-30 18:13:12 UTC
Robby - did this occur with the original symptoms of pressing play/pause twice fixing it, or is it occurring where dragging the progress bar is necessary to start playback?

Could you check in your system journal and see what encoder is being reported as in use? I can observe an issue with some songs in my library, and on those songs it's using the encoder "Lavc61.3.", while on ones that work normally it's using "Lavf"

Thanks!
Comment 12 Dirk Tombaugh 2025-05-01 04:23:54 UTC
(In reply to John Kizer from comment #11)
> Robby - did this occur with the original symptoms of pressing play/pause
> twice fixing it, or is it occurring where dragging the progress bar is
> necessary to start playback?
> 
> Could you check in your system journal and see what encoder is being
> reported as in use? I can observe an issue with some songs in my library,
> and on those songs it's using the encoder "Lavc61.3.", while on ones that
> work normally it's using "Lavf"
> 
> Thanks!

John, I don't know about the other persons experience, but mine is that dragging the progress bar is required to start playing again. I can check my system to see what the encoder is.
Comment 13 Dirk Tombaugh 2025-05-01 04:58:52 UTC
(In reply to Dirk Tombaugh from comment #12)
> (In reply to John Kizer from comment #11)
> > Robby - did this occur with the original symptoms of pressing play/pause
> > twice fixing it, or is it occurring where dragging the progress bar is
> > necessary to start playback?
> > 
> > Could you check in your system journal and see what encoder is being
> > reported as in use? I can observe an issue with some songs in my library,
> > and on those songs it's using the encoder "Lavc61.3.", while on ones that
> > work normally it's using "Lavf"
> > 
> > Thanks!
> 
> John, I don't know about the other persons experience, but mine is that
> dragging the progress bar is required to start playing again. I can check my
> system to see what the encoder is.

OK. did some checking. In my systemd journal i only saw LAME for the encoding. So i checked and found that my LAME packages were from the opensuse repo. I switched them over to the PACMAN repo (and they are newer there). I closed Elisa and restarted it and it changed the encoding listed to LAVC and LAVF, but it did not stop playing. I'm going to have to let it run for a little bit to verify, but so far so good.
Comment 14 Dirk Tombaugh 2025-05-01 05:14:36 UTC
(In reply to Dirk Tombaugh from comment #13)
> (In reply to Dirk Tombaugh from comment #12)
> > (In reply to John Kizer from comment #11)
> > > Robby - did this occur with the original symptoms of pressing play/pause
> > > twice fixing it, or is it occurring where dragging the progress bar is
> > > necessary to start playback?
> > > 
> > > Could you check in your system journal and see what encoder is being
> > > reported as in use? I can observe an issue with some songs in my library,
> > > and on those songs it's using the encoder "Lavc61.3.", while on ones that
> > > work normally it's using "Lavf"
> > > 
> > > Thanks!
> > 
> > John, I don't know about the other persons experience, but mine is that
> > dragging the progress bar is required to start playing again. I can check my
> > system to see what the encoder is.
> 
> OK. did some checking. In my systemd journal i only saw LAME for the
> encoding. So i checked and found that my LAME packages were from the
> opensuse repo. I switched them over to the PACMAN repo (and they are newer
> there). I closed Elisa and restarted it and it changed the encoding listed
> to LAVC and LAVF, but it did not stop playing. I'm going to have to let it
> run for a little bit to verify, but so far so good.

I can't go back and edit - sorry. it wasn't in the PACKMAN repo it was in the mulitmedia repo. but that may not have been a "fix" either. still happens.
Comment 15 John Kizer 2025-05-01 05:42:51 UTC
Thanks - based on the history of this bug report, I'm guessing this is a slightly different issue with similar but slightly different symptoms.

There is a newer bug report that covers the newer issue: https://bugs.kde.org/show_bug.cgi?id=503408