[Elisa] [Bug 480573] New: 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 Bug ID: 480573 Summary: Elisa always switches back to outputting to the audio output used when Elisa is initially launched when changing tracks. Classification: Applications Product: Elisa Version: 24.01.90 Platform: Fedora RPMs OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: matthieu_gall...@yahoo.fr Reporter: radb...@gmail.com Target Milestone: --- Created attachment 165382 --> https://bugs.kde.org/attachment.cgi?id=165382=edit Audio Volume Plasmoid when this bug occurs (excuse the Dualshock 4, I'm using it to pass audio through USB) SUMMARY When there is more than one audio output, switching to a different one via the Audio Volume Plasmoid mid playback will output current playback to the selected audio output as expected, but when the next track plays/current track changes, Elisa only outputs to the audio output that was in use when Elisa was opened/before the audio output was switched. STEPS TO REPRODUCE 1. Connect two audio outputs and select one via the Audio Volume Plasmoid 2. Open Elisa and play a track 3. Switch audio output mid playback 4. Change the currently playing track OBSERVED RESULT After the currently playing track changes, Elisa only outputs to the audio output that was in use when Elisa was launched. EXPECTED RESULT Elisa keeps playing audio to the currently selected audio output. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Fedora Linux 40 KDE Plasma (Rawhide) (available in About System) KDE Plasma Version: 5.92.0 (Plasma 6.0 RC1) KDE Frameworks Version: 5.248.0 Qt Version: 6.6.1 ADDITIONAL INFORMATION This can also be visually seen in the Audio Volume Plasmoid, where you can see sound being output to an audio device that isn't selected. -- You are receiving this mail because: You are watching all bug changes.
[Elisa] [Bug 480572] New: Elisa causes high CPU usage and higher-than-usual RAM usage while (choppily) scrolling through huge libraries.
https://bugs.kde.org/show_bug.cgi?id=480572 Bug ID: 480572 Summary: Elisa causes high CPU usage and higher-than-usual RAM usage while (choppily) scrolling through huge libraries. Classification: Applications Product: Elisa Version: 24.01.90 Platform: Fedora RPMs OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: matthieu_gall...@yahoo.fr Reporter: radb...@gmail.com Target Milestone: --- Created attachment 165378 --> https://bugs.kde.org/attachment.cgi?id=165378=edit Generated backtrace of Elisa after it crashes while attempting to close it while it uses system resources. SUMMARY Elisa causes high CPU usage while quickly scrolling through big libraries through any view, this goes away after scrolling stops in a few seconds. Elisa also uses more RAM than usual when you quickly scroll through a big library, but this amount doesn't decrease even after you stop scrolling until you exit and reopen Elisa. STEPS TO REPRODUCE 1. Import a big music library (in my case, it's 7800+ unique files) 2. Scroll quickly via either a scroll bar or scroll REALLY fast using a mouse wheel in any category that displays your local files (Albums/Artists/Tracks/Genres). 3. Use any resource monitoring tool to check how much resources Elisa is using. OBSERVED RESULT Elisa choppily scrolls through the big library, incurring temporarily high CPU usage (up to 85%! possibly higher?) and higher than usual ram usage (I've got it from 400MBs-1GB!~ of RAM now, but it may get higher with a bigger library/the more you quickly scroll.) EXPECTED RESULT Elisa handles scrolling through said library smoothly with minimal impact on system resources. (staying around 100MBs~, which is what I usually see before doing this) SOFTWARE/OS VERSIONS Linux/KDE Plasma: Fedora Linux 40 KDE Plasma (Rawhide) (available in About System) KDE Plasma Version: 5.92.0 (Plasma 6.0 RC1) KDE Frameworks Version: 5.248.0 Qt Version: 6.6.1 ADDITIONAL INFORMATION The music library is stored on a USB 3.1 Gen 1 flash drive with up to 150MB/s in read speeds plugged into a USB 3.1 Gen 2 USB C port, I'm not sure if this would be the prime cause of the issue but I unfortunately can not test this as I do not have the storage required to have all these files on my SSD. Below are my hardware specs for reference: Processors: 4 × Intel® Core™ i5-6267U CPU @ 2.90GHz Memory: 7.6 GiB of RAM Graphics Processor: Mesa Intel® Iris® Graphics 550 P.S My current daily Linux Desktop is a Debian 12 Stable KDE install where I often use Elisa, and I have been able to reproduce this bug on the natively packaged version of Elisa (22.12.3) with worse results involving straight crashes when using the scroll bar to scroll quickly. -- You are receiving this mail because: You are watching all bug changes.
[Elisa] [Bug 399249] Add support for scrobbling to last.fm
https://bugs.kde.org/show_bug.cgi?id=399249 Rad "Radicalite" Radbirb changed: What|Removed |Added CC||radb...@gmail.com --- Comment #8 from Rad "Radicalite" Radbirb --- same as others, Elisa not having official scrobbling support with no clear workarounds is pretty much the only thing that prevents me from switching to it, would be much appreciated if we saw this feature confirmed! <3 -- You are receiving this mail because: You are watching all bug changes.
[neon] [Bug 451034] New: Plymouth themes don't apply correctly (and neon's default plymouth theme isn't selectable in the settings menu)
https://bugs.kde.org/show_bug.cgi?id=451034
Bug ID: 451034
Summary: Plymouth themes don't apply correctly (and neon's
default plymouth theme isn't selectable in the
settings menu)
Product: neon
Version: unspecified
Platform: Neon Packages
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: general
Assignee: neon-b...@kde.org
Reporter: radb...@gmail.com
CC: j...@jriddell.org, neon-b...@kde.org, sit...@kde.org
Target Milestone: ---
SUMMARY
Plymouth themes don't apply on startup, but do apply on shut down
KDE neon's default plymouth theme is also unavailable in system settings,
although always is used on startup, even when a specific plymouth theme is
selected
STEPS TO REPRODUCE
1. Open System Settings > Appearance > Boot Splash Screen
2. Select A Theme
3. Reboot
OBSERVED RESULT
Selected Plymouth theme shows up on shutdown, but not startup
EXPECTED RESULT
Selected Plymouth theme should show up on startup (instead of the unselectable
neon plymouth theme) and shutdown
SOFTWARE/OS VERSIONS
macOS: 12.2.1 (HOST)
VMware Fusion: Player 12.2.1
Linux/KDE Plasma: KDE neon 5.24 User Edition (VM)
KDE Plasma Version: 5.24.2
KDE Frameworks Version: 5.91.0
Qt Version: 5.15.3
ADDITIONAL INFORMATION
1.While this is on a VM that I use regularly, I doubt it is VM only
2. I've had plymouth themes actually show on startup and work correct on a
fresh install (I used Breeze (Text Mode) for a while.), but after a couple
weeks worth of update and switching back to default Breeze, Plymouth on startup
only shows the default Neon plymouth theme.
3. Neon's default plymouth theme (aka the one that shows up instead of the
custom plymouth theme on startup) is not a select-able option in Boot Splash
Screen.
4. Applying a plymouth theme also takes an unusual amount of time, usually
around a minute
Pumping System Settings through terminal and posting the output of selecting a
plymouth theme.
rad@DripKonq:~$ systemsettings
QQmlEngine::setContextForObject(): Object already has a QQmlContext
file:///usr/share/kpackage/kcms/kcm_landingpage/contents/ui/main.qml:130:9: QML
FormLayout (parent or ancestor of QQuickLayoutAttached): Binding loop detected
for property "preferredHeight"
file:///usr/share/kpackage/kcms/kcm_landingpage/contents/ui/main.qml:20:9: QML
FormLayout (parent or ancestor of QQuickLayoutAttached): Binding loop detected
for property "preferredHeight"
QQmlEngine::setContextForObject(): Object already has a QQmlContext
file:///usr/lib/x86_64-linux-gnu/qt5/qml/QtQuick/Controls.2/org.kde.desktop/ScrollView.qml:85:25:
QML ScrollBar: Binding loop detected for property "visible"
file:///usr/lib/x86_64-linux-gnu/qt5/qml/QtQuick/Controls.2/org.kde.desktop/ScrollView.qml:85:25:
QML ScrollBar: Binding loop detected for property "visible"
qml: The item SubCategoryPage_QMLTYPE_114(0x560a2bc0ca70) is already in the
PageRow
QQmlEngine::setContextForObject(): Object already has a QQmlContext
file:///usr/share/kpackage/kcms/kcm_plymouth/contents/ui/main.qml:79:5: QML
Connections: Implicitly defined onFoo properties in Connections are deprecated.
Use this syntax instead: function onFoo() { ... }
"Could not convert argument 0 at"
"onChangedEntriesChanged@file:///usr/share/kpackage/kcms/kcm_plymouth/contents/ui/main.qml:75"
"Passing incompatible arguments to C++ functions from JavaScript is dangerous
and deprecated."
"This will throw a JavaScript TypeError in future releases of Qt!"
file:///usr/lib/x86_64-linux-gnu/qt5/qml/QtQuick/Controls.2/org.kde.desktop/ScrollView.qml:85:25:
QML ScrollBar: Binding loop detected for property "visible"
file:///usr/lib/x86_64-linux-gnu/qt5/qml/QtQuick/Controls.2/org.kde.desktop/ScrollView.qml:85:25:
QML ScrollBar: Binding loop detected for property "visible"
qml: The item SubCategoryPage_QMLTYPE_114(0x560a2bc0ca70) is already in the
PageRow
"Could not convert argument 0 at"
"onChangedEntriesChanged@file:///usr/share/kpackage/kcms/kcm_plymouth/contents/ui/main.qml:75"
"Passing incompatible arguments to C++ functions from JavaScript is dangerous
and deprecated."
"This will throw a JavaScript TypeError in future releases of Qt!"
"Could not convert argument 0 at"
"onChangedEntriesChanged@file:///usr/share/kpackage/kcms/kcm_plymouth/contents/ui/main.qml:75"
"Passing incompatible arguments to C++ functions from JavaScript is dangerous
and deprecated."
"This will throw a JavaScript TypeError in future releases of Qt!"
Debug message from helper: Running update-alternatives --list default.plymouth
now
Debug message from helper: Running update-alternatives --set now
Debug message from helper: Running update-initramfs -u now
kf.auth: "Did not receive a reply. Possible causes include: the remote
application did not send a reply, the message bus security policy blocked the
reply, the reply
