[Discover] [Bug 484886] Discover fails to find installed runtimes required by some flatpak apps
https://bugs.kde.org/show_bug.cgi?id=484886 Talya changed: What|Removed |Added CC||myjunkmailbox2...@gmail.com --- Comment #6 from Talya --- I just had a similar experience. I have org.signal.Signal installed from external repo https://signalflatpak.github.io/signal/signal.flatpakrepo. when I went to update it today, I got an error saying org.freedesktop.Platform/aarch64/23.08 was missing. running in the command line > flatpak install org.freedesktop.Platform/aarch64/23.08 results in > Skipping: org.freedesktop.Platform/aarch64/23.08 is already installed and updating org.signal.Signal in the command line worked perfectly fine. Operating System: Fedora Linux Asahi Remix 40 KDE Plasma Version: 6.1.4 KDE Frameworks Version: 6.5.0 Qt Version: 6.7.2 Kernel Version: 6.10.6-401.asahi.fc40.aarch64+16k (64-bit) Graphics Platform: Wayland -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 484886] Discover fails to find installed runtimes required by some flatpak apps
https://bugs.kde.org/show_bug.cgi?id=484886 --- Comment #7 from Talya --- Just happened again with the same app. > The application org.signal.Signal/aarch64/master requires the runtime > org.freedesktop.Platform/aarch64/23.08 which was not found Updating via command line worked perfectly fine. -- You are receiving this mail because: You are watching all bug changes.
[dragonplayer] [Bug 494054] Fedora Asahi Remix - DragonPlayer won't play any video
https://bugs.kde.org/show_bug.cgi?id=494054 Talya changed: What|Removed |Added Resolution|WAITINGFORINFO |--- Status|NEEDSINFO |REPORTED --- Comment #2 from Talya --- >~$ /bin/dragon >qt.core.qobject.connect: QObject::connect: No such signal >Phonon::VLC::MediaObject::angleChanged(int) >qt.core.qobject.connect: QObject::connect: No such signal >Phonon::VLC::MediaObject::availableAnglesChanged(int) >qt.core.qobject.connect: QObject::connect: No such signal >Phonon::VLC::MediaObject::angleChanged(int) >qt.core.qobject.connect: QObject::connect: No such signal >Phonon::VLC::MediaObject::availableAnglesChanged(int) click on "play file": >kf.kio.filewidgets.kfilefiltercombo: Could not find file filter >kf.kio.filewidgets.kfilefiltercombo: Could not find file filter >kf.kio.core: KFileFilter::fromMimeType() called with unknown MIME type >"application/mpeg4-iod" >kf.kio.core: KFileFilter::fromMimeType() called with unknown MIME type >"application/mpeg4-muxcodetable" >kf.kio.core: KFileFilter::fromMimeType() called with unknown MIME type >"application/x-extension-m4a" >kf.kio.core: KFileFilter::fromMimeType() called with unknown MIME type >"application/x-extension-mp4" >kf.kio.core: KFileFilter::fromMimeType() called with unknown MIME type >"application/x-flac" >kf.kio.core: KFileFilter::fromMimeType() called with unknown MIME type >"audio/dv" >kf.kio.core: KFileFilter::fromMimeType() called with unknown MIME type >"audio/eac3" >kf.kio.core: KFileFilter::fromMimeType() called with unknown MIME type >"audio/mp1" >kf.kio.core: KFileFilter::fromMimeType() called with unknown MIME type >"audio/mpg" >kf.kio.core: KFileFilter::fromMimeType() called with unknown MIME type >"audio/opus" >kf.kio.core: KFileFilter::fromMimeType() called with unknown MIME type >"audio/vnd.dolby.heaac.1" >kf.kio.core: KFileFilter::fromMimeType() called with unknown MIME type >"audio/vnd.dolby.heaac.2" >kf.kio.core: KFileFilter::fromMimeType() called with unknown MIME type >"audio/vnd.dolby.mlp" >kf.kio.core: KFileFilter::fromMimeType() called with unknown MIME type >"audio/x-mp1" >kf.kio.core: KFileFilter::fromMimeType() called with unknown MIME type >"audio/x-ms-asf" >kf.kio.core: KFileFilter::fromMimeType() called with unknown MIME type >"audio/x-ms-wax" >kf.kio.core: KFileFilter::fromMimeType() called with unknown MIME type >"audio/x-pn-aiff" >kf.kio.core: KFileFilter::fromMimeType() called with unknown MIME type >"audio/x-pn-au" >kf.kio.core: KFileFilter::fromMimeType() called with unknown MIME type >"audio/x-pn-wav" >kf.kio.core: KFileFilter::fromMimeType() called with unknown MIME type >"audio/x-pn-windows-acm" >kf.kio.core: KFileFilter::fromMimeType() called with unknown MIME type >"audio/x-real-audio" >kf.kio.core: KFileFilter::fromMimeType() called with unknown MIME type >"audio/x-realaudio" >kf.kio.core: KFileFilter::fromMimeType() called with unknown MIME type >"misc/ultravox" >kf.kio.core: KFileFilter::fromMimeType() called with unknown MIME type >"video/x-flc" >kf.kio.core: KFileFilter::fromMimeType() called with unknown MIME type >"video/x-ms-asx" >kf.kio.core: KFileFilter::fromMimeType() called with empty input >kf.kio.filewidgets.kfilefiltercombo: Could not find file filter select a file: >QPainter::fillRect: Painter not active (this line gets printed so many times it fills the buffer and everything that was printed before is gone) trying to select a file the second time, or trying to click the "play" button at the top: >[08c0c530] gstdecode decoder error: Error from decodebin1: GStreamer >encountered a general stream error. >[08c0c530] gstdecode decoder error: pipeline may not close gracefully -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 493404] Fedora Asahi Remix - Discover will occasionally fail to start
https://bugs.kde.org/show_bug.cgi?id=493404 Talya changed: What|Removed |Added Resolution|WAITINGFORINFO |--- Status|NEEDSINFO |REPORTED -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 484886] Discover fails to find installed runtimes required by some flatpak apps
https://bugs.kde.org/show_bug.cgi?id=484886 --- Comment #8 from Talya --- now in plasma 6.2, there isn't even an error message, the app just flickers, then returns to the list of apps to be updated as if nothing happened. (and command line works as always) -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 493404] Fedora Asahi Remix - Discover will occasionally fail to start
https://bugs.kde.org/show_bug.cgi?id=493404 --- Comment #6 from Talya --- this time slightly different behaviour, discover failed to load all updates so I closed to try again and it didn't open. here's the debug info: #0 0xfffee53a6254 in __GI___poll (fds=0xaaab3a0b3fe0, nfds=, timeout=) at ../sysdeps/unix/sysv/linux/poll.c:41 #1 0xfffee41c56f8 [PAC] in g_main_context_poll_unlocked (priority=2147483647, context=0xfffec8000f00, timeout=, fds=0xaaab3a0b3fe0, n_fds=9) at ../glib/gmain.c:4521 #2 g_main_context_iterate_unlocked.isra.0 (context=context@entry=0xfffec8000f00, block=block@entry=1, dispatch=dispatch@entry=1, self=) at ../glib/gmain.c:4212 #3 0xfffee4162084 [PAC] in g_main_context_iteration (context=0xfffec8000f00, may_block=1) at ../glib/gmain.c:4282 #4 0xfffee5b82638 [PAC] in QEventDispatcherGlib::processEvents ( this=0xaaab38fe17a0, flags=...) at /usr/src/debug/qt6-qtbase-6.7.2-6.fc40.aarch64/src/corelib/kernel/qeventdispatcher_glib.cpp:394 #5 0xfffee588f674 [PAC] in QEventLoop::exec (this=this@entry=0xe3d784c0, flags=flags@entry=...) at /usr/src/debug/qt6-qtbase-6.7.2-6.fc40.aarch64/src/corelib/global/qflags.h:34 #6 0xfffee588ac1c [PAC] in QCoreApplication::exec () at /usr/src/debug/qt6-qtbase-6.7.2-6.fc40.aarch64/src/corelib/global/qflags.h:74 #7 0xfffee5fc4830 [PAC] in QGuiApplication::exec () at /usr/src/debug/qt6-qtbase-6.7.2-6.fc40.aarch64/src/gui/kernel/qguiapplication.cpp:1926 #8 0xfffee7cde9b8 in QApplication::exec () at /usr/src/debug/qt6-qtbase-6.7.2-6.fc40.aarch64/src/widgets/kernel/qapplication.cpp:2555 #9 0xaaab33103b58 in main (argc=, argv=) at /usr/src/debug/plasma-discover-6.1.5-1.fc40.aarch64/discover/main.cpp:219 -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 493404] Fedora Asahi Remix - Discover will occasionally fail to start
https://bugs.kde.org/show_bug.cgi?id=493404 --- Comment #7 from Talya --- I think I can consistently reproduce the issue now. 1. boot and have discover auto-open 2. have discover try to fetch updates 3. close discover mid-fetching 4. discover will now continue running in the background and clicking on its icon will do nothing. -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 493404] New: Fedora Asahi Remix - Discover will occasionally fail to start
https://bugs.kde.org/show_bug.cgi?id=493404 Bug ID: 493404 Summary: Fedora Asahi Remix - Discover will occasionally fail to start Classification: Applications Product: Discover Version: 6.1.4 Platform: Fedora RPMs OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: discover Assignee: plasma-b...@kde.org Reporter: myjunkmailbox2...@gmail.com CC: aleix...@kde.org Target Milestone: --- Created attachment 173911 --> https://bugs.kde.org/attachment.cgi?id=173911&action=edit Discover failing to start when opening from task manager or application launcher SUMMARY STEPS TO REPRODUCE 1. Boot into Fedora Asahi Remix 2. Have updates pending download (you can see the "Updates available" icon 3. Try opening Discover in any method (clicking on the "Updates available" icon, clicking on Discover from the task manager, opening Discover from the Application Launcher, doesn't matter) This method is not able to consistently reproduce the bug. The bug doesn't seem to happen consistently, and I'm not certain of the pattern that causes it. OBSERVED RESULT Clicking on the "Updates available" icon will do nothing. Clicking on Discover in the task manager or trying to open Discover from the Application Launcher will result in some loading, then nothing. EXPECTED RESULT Discover starts as expected. SOFTWARE/OS VERSIONS Operating System: Fedora Linux Asahi Remix 40 KDE Plasma Version: 6.1.4 KDE Frameworks Version: 6.5.0 Qt Version: 6.7.2 ADDITIONAL INFORMATION A simple reboot seems to always solve the problem. However, the bug has returned multiple times, always with the same behaviour, so it's clear this is not a permanent solution. -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 493404] Fedora Asahi Remix - Discover will occasionally fail to start
https://bugs.kde.org/show_bug.cgi?id=493404 --- Comment #2 from Talya --- I actually already ran `plasma-discover` already and it didn't help. however: turns out it *was* running in the background, just not visible in any workspace. killing the process and running it from the terminal worked, and now it opens normally. I do wonder how did it happen though. Because it does seem to occasionally happen without a discernable pattern. my only guess is that it's whenever there's >100 packages to update, but the only reason I'm thinking so is there were this time when I managed to open it. -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 493404] Fedora Asahi Remix - Discover will occasionally fail to start
https://bugs.kde.org/show_bug.cgi?id=493404 --- Comment #4 from Talya --- I would appreciate more detailed instructions :) will let you know when I have the details. -- You are receiving this mail because: You are watching all bug changes.
[dragonplayer] [Bug 494054] New: Fedora Asahi Remix - DragonPlayer won't play any video
https://bugs.kde.org/show_bug.cgi?id=494054 Bug ID: 494054 Summary: Fedora Asahi Remix - DragonPlayer won't play any video Classification: Applications Product: dragonplayer Version: 24.08.0 Platform: Other OS: Linux Status: REPORTED Severity: grave Priority: NOR Component: general Assignee: unassigned-b...@kde.org Reporter: myjunkmailbox2...@gmail.com CC: myr...@kde.org, sit...@kde.org Target Milestone: --- Created attachment 174375 --> https://bugs.kde.org/attachment.cgi?id=174375&action=edit Screengrab of the behaviour with sample MP4 and OGV files downloaded for purpose (WEBM behaviour identical to MP4) SUMMARY DragonPlayer fails to play all video files. Tested .webm, .mp4 and .ogx. The first two resulted in the title bar displaying the video name, but the rest of the app behaved as if no media was loaded. The OGV resulted in some marvelous, Windows 95-like stutters, followed by the same behaviour as the first two. STEPS TO REPRODUCE 1. Double click a video file with DragonPlayer set as your video player of choice OR 1. Select a video file 2. Open with>DragonPlayer OR 1. Open DragonPlayer 2. Click on "Play File" 3. Select any video file OBSERVED RESULT Video not played. Other than title bar, DragonPlayer behaves as if no file was selected. EXPECTED RESULT Video plays normally SOFTWARE/OS VERSIONS Operating System: Fedora Linux Asahi Remix 40 KDE Plasma Version: 6.1.5 KDE Frameworks Version: 6.6.0 Qt Version: 6.7.2 Kernel Version: 6.11.0-400.asahi.fc40.aarch64+16k (64-bit) Graphics Platform: Wayland ADDITIONAL INFORMATION DragonPlayer version is the preinstalled one, not the Flatpak. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 501501] New: Bluetooth headset loses audio after auto-switch between playback modes
https://bugs.kde.org/show_bug.cgi?id=501501 Bug ID: 501501 Summary: Bluetooth headset loses audio after auto-switch between playback modes Classification: Plasma Product: plasmashell Version: 6.3.3 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Audio in general Assignee: plasma-b...@kde.org Reporter: myjunkmailbox2...@gmail.com CC: isma...@gmail.com Target Milestone: 1.0 SUMMARY Bluetooth headset switches automatically between "High Fidelity Playback (A2DP Sink, codec SBC)" to "Headset Head Unit (HSP/HFP, codec mSBC)" in certain contexts, such as when entering a voice call or recording a voice note in chat apps. afterwards the headset switches back, however - audio playback is fully broken after the swtich back to "High Fidelity Playback" - nothing is heard. in addition, engaging the microphone again in the same ways as before will result again in the switch to "Headset Head Unit", however, this time audio will be broken in this mode as well - playback and input both do not work. trying to switch manually between playback modes when audio is broken does not work. only solution is to restart the bluetooth headset - which gets very tedious to do every time. STEPS TO REPRODUCE 1. start your bluetooth headset and connect it. 2. playback mode is automatically selected as "High Fidelity Playback (A2DP Sink, codec SBC)" and playback is normal. 3. engage the microphone via means of starting a voice call or recording an audio message in your messaging app of choice. 4. playback mode automatically switches to "Headset Head Unit (HSP/HFP, codec mSBC)" and playback and input are working as normal (you can hear people on the voice call and they can hear you). 5. end the voice call/the voice note recording. 6. playback mode automatically switches back to "High Fidelity Playback (A2DP Sink, codec SBC)" OBSERVED RESULT playback does not work at all. repeat steps 3-4: now playback and input do not work at all (you can't hear people on the voice call and they can't hear you). EXPECTED RESULT switch between modes is seamless as many times as required, and playback and input work as needed regardless of how many switches happened. SOFTWARE/OS VERSIONS Operating System: Fedora Linux Asahi Remix 41 KDE Plasma Version: 6.3.3 KDE Frameworks Version: 6.11.0 Qt Version: 6.8.2 Kernel Version: 6.13.5-400.asahi.fc41.aarch64+16k (64-bit) Graphics Platform: Wayland Product Name: Apple MacBook Pro (14-inch, M1 Pro, 2021) ADDITIONAL INFORMATION un- and re-pairing the headset resulted in the same behaviour. headset model is WH-1000XM4. -- You are receiving this mail because: You are watching all bug changes.
[Elisa] [Bug 493777] Clicking radio station still plays the previous one
https://bugs.kde.org/show_bug.cgi?id=493777 Talya changed: What|Removed |Added CC||myjunkmailbox2...@gmail.com --- Comment #2 from Talya --- this is still an issue on Elisa 24.12.3 and Plasma 6.3.4. -- You are receiving this mail because: You are watching all bug changes.
[Elisa] [Bug 503425] New: music doesn't play after unpausing
https://bugs.kde.org/show_bug.cgi?id=503425 Bug ID: 503425 Summary: music doesn't play after unpausing Classification: Applications Product: Elisa Version: 25.04.0 Platform: Fedora RPMs OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: matthieu_gall...@yahoo.fr Reporter: myjunkmailbox2...@gmail.com Target Milestone: --- SUMMARY when pausing the music and then unpausing after a few seconds (i.e. not immediately), no music plays. the player still scrubs the timeline as if something is playing, but there's absolutely no output. jumping to any point in the timeline resolves the issue. STEPS TO REPRODUCE 1. play any music from library 2. pause 3. wait a few seconds, preferably about a minute or more. 4. unpause OBSERVED RESULT the playback "continues" but no music is actually heard EXPECTED RESULT playback resumes normally SOFTWARE/OS VERSIONS Operating System: Fedora Linux Asahi Remix 42 KDE Plasma Version: 6.3.4 KDE Frameworks Version: 6.13.0 Qt Version: 6.9.0 Kernel Version: 6.14.2-401.asahi.fc42.aarch64+16k (64-bit) Graphics Platform: Wayland Graphics Processor 1: Apple M1 Pro Graphics Processor 2: llvmpipe Product Name: Apple MacBook Pro (14-inch, M1 Pro, 2021) ADDITIONAL INFORMATION this is a relatively new bug. not entirely sure which version was the first to have it, but it might be exclusive to 25.x or even 25.04. -- You are receiving this mail because: You are watching all bug changes.
[dragonplayer] [Bug 503754] New: subtitles are not displayed even when selected
https://bugs.kde.org/show_bug.cgi?id=503754 Bug ID: 503754 Summary: subtitles are not displayed even when selected Classification: Applications Product: dragonplayer Version: 25.04.0 Platform: Fedora RPMs OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: unassigned-b...@kde.org Reporter: myjunkmailbox2...@gmail.com CC: myr...@kde.org, sit...@kde.org Target Milestone: --- Created attachment 180926 --> https://bugs.kde.org/attachment.cgi?id=180926&action=edit subtitle menu showing "track 1 - English" as selected SUMMARY subtitles are not displayed even when selected. this is true for built-in subtitles as well as SRTs that are present in the folder, for MKVs as well as MP4s. this is not an issue with the subtitles - on MPV they display perfectly fine. STEPS TO REPRODUCE 1. open an MKV file with built in subtitles or MP4 file with appropriate SRT file in the folder. 2. select the subtitles in the subtitle menu (see screenshot) OBSERVED RESULT no subtitles are displayed EXPECTED RESULT subtitles are displayed as expected SOFTWARE/OS VERSIONS Operating System: Fedora Linux Asahi Remix 42 KDE Plasma Version: 6.3.4 KDE Frameworks Version: 6.13.0 Qt Version: 6.9.0 Kernel Version: 6.14.4-400.asahi.fc42.aarch64+16k (64-bit) Graphics Platform: Wayland Product Name: Apple MacBook Pro (14-inch, M1 Pro, 2021) ADDITIONAL INFORMATION cannot confirm when this bug started, as up until recently DragonPlayer did not work on my system at all (https://bugs.kde.org/show_bug.cgi?id=494054). -- You are receiving this mail because: You are watching all bug changes.
[Elisa] [Bug 480573] Elisa always switches back to outputting to the audio output used when Elisa is initially launched when changing tracks.
https://bugs.kde.org/show_bug.cgi?id=480573 Talya changed: What|Removed |Added Version|24.08.1 |25.04.0 --- Comment #6 from Talya --- first of all, this is also true for the latest version so i'm updating that in the bug parameters. doing some more testing, this doesn't seem to just be an issue of switching output mid-song, but also of Elisa choosing the wrong output to begin with. if headphones are plugged in before booting Elisa, that is the output that will be used. however when starting Elisa without any music in the queue and no sound coming out and then plugging in headphones, the built-in speakers will be selected as output, even when the global settings are headphones. even when during that stage (i.e. before playing the first song after starting) one switches the global setting to speakers and back to headphones, the output for Elisa is still the speakers. after that the bug is as described by Ali. however this earlier behaviour means that anyone who plugs in/turns out their headphones after starting Elisa will likely encounter it, as they'll always have Elisa using the speakers, which is either solved by switching the global settings to speakers and back to headphones (which does not result in Ali's bug), or by switching Elisa specifically to headphones (which does). SOFTWARE/OS VERSIONS Elisa: 25.04.0 Operating System: Fedora Linux Asahi Remix 42 KDE Plasma Version: 6.3.4 KDE Frameworks Version: 6.13.0 Qt Version: 6.9.0 Kernel Version: 6.14.4-400.asahi.fc42.aarch64+16k (64-bit) Graphics Platform: Wayland Product Name: Apple MacBook Pro (14-inch, M1 Pro, 2021) -- You are receiving this mail because: You are watching all bug changes.
[Elisa] [Bug 503849] New: Elisa audio output resets to laptop speakers when switching songs
https://bugs.kde.org/show_bug.cgi?id=503849 Bug ID: 503849 Summary: Elisa audio output resets to laptop speakers when switching songs Classification: Applications Product: Elisa Version: 25.04.0 Platform: Fedora RPMs OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: matthieu_gall...@yahoo.fr Reporter: myjunkmailbox2...@gmail.com Target Milestone: --- Created attachment 180998 --> https://bugs.kde.org/attachment.cgi?id=180998&action=edit screenshot of audio outputs, with "built-in audio headphones" and "Macbook Pro J314 speakers", the latter being selected SUMMARY when switching song, be it manually or by one song ending and the next one in the queue starting automatically, the audio output resets to laptop speakers without user intervention. this is true both for headphone jack and bluetooth headphones. STEPS TO REPRODUCE 1. start a song 2. make sure the output is *not* laptop speakers 3. switch to another song OBSERVED RESULT output switches to laptop speakers EXPECTED RESULT output should not change unless the user changes it SOFTWARE/OS VERSIONS Operating System: Fedora Linux Asahi Remix 42 KDE Plasma Version: 6.3.4 KDE Frameworks Version: 6.13.0 Qt Version: 6.9.0 Kernel Version: 6.14.4-400.asahi.fc42.aarch64+16k (64-bit) Graphics Platform: Wayland Product Name: Apple MacBook Pro (14-inch, M1 Pro, 2021) ADDITIONAL INFORMATION this does not happen in any app other than Elisa (that i noticed). -- You are receiving this mail because: You are watching all bug changes.
[Elisa] [Bug 480573] Elisa always switches back to outputting to the audio output used when Elisa is initially launched when changing tracks.
https://bugs.kde.org/show_bug.cgi?id=480573 Talya changed: What|Removed |Added CC||myjunkmailbox2...@gmail.com --- Comment #5 from Talya --- *** Bug 503849 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[Elisa] [Bug 503849] Elisa audio output resets to laptop speakers when switching songs
https://bugs.kde.org/show_bug.cgi?id=503849 Talya changed: What|Removed |Added Resolution|--- |DUPLICATE Status|REPORTED|RESOLVED --- Comment #1 from Talya --- apologies, this is a duplicate of 480573, my bad. *** This bug has been marked as a duplicate of bug 480573 *** -- You are receiving this mail because: You are watching all bug changes.
[Elisa] [Bug 493777] Clicking radio station still plays the previous one
https://bugs.kde.org/show_bug.cgi?id=493777 --- Comment #3 from Talya --- in fact, it seems to even happen when switching from non-radio to radio. instead of radio stream, the current playlist track before switching will be played. -- You are receiving this mail because: You are watching all bug changes.
[Elisa] [Bug 480573] Elisa always switches back to outputting to the audio output used when Elisa is initially launched when changing tracks.
https://bugs.kde.org/show_bug.cgi?id=480573 --- Comment #7 from Talya --- correction: even changing the global settings to be speakers then back to headphones doesn't fix this bug, it'll still return as soon as the song switches. so any time one connects a new output after starting Elisa this will happen, no exceptions. -- You are receiving this mail because: You are watching all bug changes.
[Elisa] [Bug 480573] Elisa always switches back to outputting to the audio output used when Elisa is initially launched when changing tracks.
https://bugs.kde.org/show_bug.cgi?id=480573 --- Comment #9 from Talya --- turns out this also happens when going the other way - starting elisa with headphones connected, then unplugging, means Elisa keeps outputting to the headphones. however, since now you only have one actual audio source plugged in, you can't even switch the output in the audio applet, and you have to restart Elisa. -- You are receiving this mail because: You are watching all bug changes.
[Elisa] [Bug 503425] After pausing, waiting a while, then unpausing, no sound is output even though the progress slider resumes moving
https://bugs.kde.org/show_bug.cgi?id=503425 --- Comment #4 from Talya --- okay so now that this bug is no longer considered duplicate, what further info is needed? -- You are receiving this mail because: You are watching all bug changes.
[Elisa] [Bug 503408] With QtMultimedia backend, playback will not begin for some song files until the progress/seek bar is dragged
https://bugs.kde.org/show_bug.cgi?id=503408 --- Comment #46 from Talya --- i can still reproduce the issue on Fedora Asahi Remix with qt 6.9.1 and gstreamer 1.26.2. unpaused music still takes a few seconds to start playing proper (2-6 seconds). this is true regardless of the power profile selected. also, it is happening on ogg files, not just mp3 as suggested in the fix. -- You are receiving this mail because: You are watching all bug changes.
[Elisa] [Bug 503408] With QtMultimedia backend, playback will not begin for some song files until the progress/seek bar is dragged
https://bugs.kde.org/show_bug.cgi?id=503408 --- Comment #47 from Talya --- and just as i was finished writing the comment, had that happen again, this time with a substantially bigger delay of 30 seconds. other than the varying times, the bug reproduces itself consistently. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 506360] New: screen locker dies at almost all instances of screen lock [Fedora Asahi Remix]
https://bugs.kde.org/show_bug.cgi?id=506360 Bug ID: 506360 Summary: screen locker dies at almost all instances of screen lock [Fedora Asahi Remix] Classification: Plasma Product: plasmashell Version First 6.4.1 Reported In: Platform: Fedora RPMs OS: Linux Status: REPORTED Severity: crash Priority: NOR Component: Screen locking Assignee: plasma-b...@kde.org Reporter: myjunkmailbox2...@gmail.com Target Milestone: 1.0 SUMMARY in 100% of instances after wakeup from sleep as well as in half of normal locks (e.g. with meta+L) the screen locker dies with the following error: > The screen locker is broken and unlocking is not possible anymore. In order > to unlock it, switch to a virtual terminal (e.g. Ctri+Alt+F2), log in to your > account and execute the command: > loginctl unlock-session 10 > Then log out of the virtual session by pressing Ctrl+D, and switch back to > the running session (Ctrl+Alt+F4). Should you have forgotten the > instructions, you can get back to this screen by pressing Ctrl+Alt+F4 pressing the power button again at this stage (which normally goes to sleep) kills the user session and goes to First Unlock, after which the user session starts as if after boot. STEPS TO REPRODUCE 1. have the laptop go to sleep (due to inactivity, due to action configured as sleep etc.) 2. wake up from sleep OBSERVED RESULT screen locker gets broken EXPECTED RESULT screen locker appears normally. SOFTWARE/OS VERSIONS Operating System: Fedora Linux Asahi Remix 42 KDE Plasma Version: 6.4.1 KDE Frameworks Version: 6.15.0 Qt Version: 6.9.1 Kernel Version: 6.14.8-400.asahi.fc42.aarch64+16k (64-bit) Graphics Platform: Wayland Product Name: Apple MacBook Pro (14-inch, M1 Pro, 2021) ADDITIONAL INFORMATION this seems to be new behaviour from today, following some updates likely installed yesterday. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 506316] Locked screen cannot be unlocked
https://bugs.kde.org/show_bug.cgi?id=506316 --- Comment #23 from Talya --- (In reply to geekiehiway from comment #21) > Created attachment 182983 [details] this is not a solution to the bug, but it seems to me the screen unlocks zoomed in to the max, can you zoom out using super+minus? -- You are receiving this mail because: You are watching all bug changes.
