| Summary: | The QtMultimedia backend is severely broken | ||
|---|---|---|---|
| Product: | [Applications] Elisa | Reporter: | João Figueiredo <jf.mundox> |
| Component: | general | Assignee: | Matthieu Gallien <matthieu_gallien> |
| Status: | RESOLVED FIXED | ||
| Severity: | major | CC: | 66and55, be.0, chemobejk, dtombaugh, jackhill3103, jf.mundox, john.kizer, nate, reubenparfrey, robby.engelmann |
| Priority: | HI | Keywords: | qt6 |
| Version First Reported In: | 24.01.85 | ||
| Target Milestone: | --- | ||
| Platform: | Compiled Sources | ||
| OS: | Linux | ||
| See Also: | https://bugs.kde.org/show_bug.cgi?id=503408 | ||
| Latest Commit: | https://invent.kde.org/multimedia/elisa/-/commit/f110ef437587dceda1ca0e89b83576a1da092765 | Version Fixed In: | 24.02.2 |
| Sentry Crash Report: | |||
|
Description
João Figueiredo
2023-12-28 18:34:03 UTC
*** Bug 479651 has been marked as a duplicate of this bug. *** 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. A possibly relevant merge request was started @ https://invent.kde.org/multimedia/elisa/-/merge_requests/543 *** Bug 483894 has been marked as a duplicate of this bug. *** Feel free to cherry-pick the fix after 24.02.1 is tagged, which should be today. *** Bug 485262 has been marked as a duplicate of this bug. *** *** Bug 485579 has been marked as a duplicate of this bug. *** *** Bug 486092 has been marked as a duplicate of this bug. *** 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. 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) 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! (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. (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. (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. 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 |