I hope this is appropriate. I'm not a contributor, but I am a long-time KDE (Fedora) user who has an extensive music collection on my lap-top.
Since I saw the discussion about dropping Amarok (because of the use of qt4???) I installed and tried to configure juk. My experience is - it's not quite ready for prime time.
Once juk is given a directory it creates a "collection" (it's a surprisingly confusing term!). That collection cannot be changed (or at least, the way to change it is lost in the mists of antiquity). Apparently, "collection" is not "directory" or "folder".
A folder, once created, cannot be removed without crashing juk. At least, I found a way to create a folder that crashes juk when any attempt to remove from juk is made.
Playlists are displayed in no known order. It is certainly not alphabetical.
Column order cannot be changed.
Changes to the settings (like, removing the comment column) are not retained from session to session.
I'm starting to hope that Amarok is kept in the live image.
On Saturday, 14 July 2018 19.39.47 WEST Joe Buckley wrote:
Since I saw the discussion about dropping Amarok (because of the use of qt4???) I installed and tried to configure juk. My experience is - it's not quite ready for prime time.
Your last sentence implies that you know this but it is better to be explicit. :-) The proposal to drop amarok is from the live image not from the distribution.
The reason as far as I understand is precisely related with the qt4 dependency and the valuable space that amarok and its dependencies take on the live image. After a given threshold the ROI (return of investment) does not pay off. :-)
In terms of usage I agree with you, I prefer (and use) amarok instead of juk or elisa.
Regards,
On samedi 14 juillet 2018 20:39:47 CEST Joe Buckley wrote:
I hope this is appropriate. I'm not a contributor, but I am a long-time KDE (Fedora) user who has an extensive music collection on my lap-top.
Since I saw the discussion about dropping Amarok (because of the use of qt4???) I installed and tried to configure juk. My experience is - it's not quite ready for prime time.
Once juk is given a directory it creates a "collection" (it's a surprisingly confusing term!). That collection cannot be changed (or at least, the way to change it is lost in the mists of antiquity). Apparently, "collection" is not "directory" or "folder".
A folder, once created, cannot be removed without crashing juk. At least, I found a way to create a folder that crashes juk when any attempt to remove from juk is made.
Playlists are displayed in no known order. It is certainly not alphabetical.
Column order cannot be changed.
Changes to the settings (like, removing the comment column) are not retained from session to session.
I'm starting to hope that Amarok is kept in the live image.
What about Clementine?
Bumping this old thread to mention Strawberry, a fork of Clementine in Qt5: https://github.com/jonaski/strawberry I've packaged it for F28-Rawhide.
I also plan to maintain the Qt5 branch of Clementine in Rawhide (I've taken ownership of it after it was orphaned).
Best regards,
Robert-André
I've just tested strawberry, on F28. It looks promising, but crashes one second after it starts playing. It will eventually get fixed I guess.
By the way, a copr would be welcome.
On Wed, 31 Oct 2018, 13:01 Sinan H <dsob@laposte.net wrote:
I've just tested strawberry, on F28. It looks promising, but crashes one second after it starts playing. It will eventually get fixed I guess.
By the way, a copr would be welcome. _______________________________________________ kde mailing list -- kde@lists.fedoraproject.org To unsubscribe send an email to kde-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kde@lists.fedoraproject.org
Didn't you use the package I made for Fedora? It should be in updates testing, it has a patch to fix the crash issue.
I've grabbed the build from the project site. On F28, installing from testing didn't work out:
$ dnf install --enablerepo=updates-testing strawberry Problème: conflicting requests - nothing provides qtiocompressor >= 2.3.1-17 needed by strawberry-0.3.3-1.fc28.x86_64
indeed: qtiocompressor-2.3.1-15.fc28.x86_64 is the highest version in F28
On vendredi 2 novembre 2018 10:59:15 CET Sinan H wrote:
I've grabbed the build from the project site. On F28, installing from testing didn't work out:
$ dnf install --enablerepo=updates-testing strawberry
Problème: conflicting requests
- nothing provides qtiocompressor >= 2.3.1-17 needed by
strawberry-0.3.3-1.fc28.x86_64
indeed: qtiocompressor-2.3.1-15.fc28.x86_64 is the highest version in F28
My bad, it's an error on my part. I pushed 0.4.7-2.fc28 it should be available in updates-testing in a couple of days.
Yeah, I'll echo your concerns about juk...
I just installed it to test and immediately noticed that it doesn't pick up cover images from within the directory structure (files named folder.jpg) which is a default standard across many applications. The other thing is if you have a large music directory, the initial scan is extremely slow... and at least for me, when I close the application, it hangs then crashes. JuK tries too much to be amaroK lite.
I realize it's it a kde multimedia application, but I don't believe it gives a good user experience - abends notwithstanding.
A much better choice, IMHO for people to use is qmmp - it's light weight, runs with qt5 and does what it sets out to do, which is be a flexible, lightweight music player that runs on qt5, supports skins, has many good plugins for extra features, supports tagged and folder based album covers, etc. A bonus, I've have yet to have it crash on me. If you haven't tried it, you should check it out.
Regarding elisa, as another person had mentioned - it's not yet ready for prime time - and even when it is, I haven't seen a compelling reason to switch from qmmp - but I'm keeping an open mind as they add features, etc.
On Sat, Jul 14, 2018 at 11:39 AM, Joe Buckley jos.buckley@verizon.net wrote:
I hope this is appropriate. I'm not a contributor, but I am a long-time KDE (Fedora) user who has an extensive music collection on my lap-top.
Since I saw the discussion about dropping Amarok (because of the use of qt4???) I installed and tried to configure juk. My experience is - it's not quite ready for prime time.
Once juk is given a directory it creates a "collection" (it's a surprisingly confusing term!). That collection cannot be changed (or at least, the way to change it is lost in the mists of antiquity). Apparently, "collection" is not "directory" or "folder".
A folder, once created, cannot be removed without crashing juk. At least, I found a way to create a folder that crashes juk when any attempt to remove from juk is made.
Playlists are displayed in no known order. It is certainly not alphabetical.
Column order cannot be changed.
Changes to the settings (like, removing the comment column) are not retained from session to session.
I'm starting to hope that Amarok is kept in the live image.
*~ Joe Buckley*
kde mailing list -- kde@lists.fedoraproject.org To unsubscribe send an email to kde-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kde@lists. fedoraproject.org/message/QXUYPFRV25BDGU3ZZ44P4IOSRQV66QIZ/
On Sun, Jul 15, 2018 at 8:11 AM Gerald B. Cox gbcox@bzb.us wrote:
Yeah, I'll echo your concerns about juk...
I just installed it to test and immediately noticed that it doesn't pick up cover images from within the directory structure (files named folder.jpg) which is a default standard across many applications. The other thing is if you have a large music directory, the initial scan is extremely slow... and at least for me, when I close the application, it hangs then crashes. JuK tries too much to be amaroK lite.
I realize it's it a kde multimedia application, but I don't believe it gives a good user experience - abends notwithstanding.
A much better choice, IMHO for people to use is qmmp - it's light weight, runs with qt5 and does what it sets out to do, which is be a flexible, lightweight music player that runs on qt5, supports skins, has many good plugins for extra features, supports tagged and folder based album covers, etc. A bonus, I've have yet to have it crash on me. If you haven't tried it, you should check it out.
Regarding elisa, as another person had mentioned - it's not yet ready for prime time - and even when it is, I haven't seen a compelling reason to switch from qmmp - but I'm keeping an open mind as they add features, etc.
On Sat, Jul 14, 2018 at 11:39 AM, Joe Buckley jos.buckley@verizon.net wrote:
I hope this is appropriate. I'm not a contributor, but I am a long-time KDE (Fedora) user who has an extensive music collection on my lap-top.
Since I saw the discussion about dropping Amarok (because of the use of qt4???) I installed and tried to configure juk. My experience is - it's not quite ready for prime time.
Once juk is given a directory it creates a "collection" (it's a surprisingly confusing term!). That collection cannot be changed (or at least, the way to change it is lost in the mists of antiquity). Apparently, "collection" is not "directory" or "folder".
A folder, once created, cannot be removed without crashing juk. At least, I found a way to create a folder that crashes juk when any attempt to remove from juk is made.
Playlists are displayed in no known order. It is certainly not alphabetical.
Column order cannot be changed.
Changes to the settings (like, removing the comment column) are not retained from session to session.
I'm starting to hope that Amarok is kept in the live image.
*~ Joe Buckley*
kde mailing list -- kde@lists.fedoraproject.org To unsubscribe send an email to kde-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kde@lists.fedoraproject.org/me...
kde mailing list -- kde@lists.fedoraproject.org To unsubscribe send an email to kde-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kde@lists.fedoraproject.org/me...
Regarding elisa, as another person had mentioned - it's not yet ready for
prime time - and even when it is, I haven't seen a compelling reason to switch from qmmp - but I'm keeping an open mind as they add features, etc.
JuK is one of the several music player projects that was created but wasn't maintained and I am not sure if it is the focus of the community.
Music player is that section of the software development where everybody wants to create their own thing but don't want to maintain and develop it for 5 or 10 years.
Whatever is selected let's not go from one shiny thing to another to another. I don't see JuK or Elisa as a strong competitor. Juk doesn't seem to be the focus of the community and Elisa is another new and shiny project.
Sudhir Khanger wrote:
JuK is one of the several music player projects that was created but wasn't maintained and I am not sure if it is the focus of the community.
Juk has seen renewed attention starting with kde-apps-18.04 (and since)
Whatever is selected let's not go from one shiny thing to another to another. I don't see JuK or Elisa as a strong competitor. Juk doesn't seem to be the focus of the community and Elisa is another new and shiny project.
<nod>, it does have weaknesses, but is still the only remotely viable candidate so far (imo)
The only other option I see at this point is to ship with *no* music player at all.
-- Rex
Gerald B. Cox wrote:
A much better choice, IMHO for people to use is qmmp - it's light weight,
I tried using it admittedly only for ~5 minutes and would not be comfortable advocating this as a default media player... offhand:
* interface is small (I guess that means I'm old, the UI text is unreadably small) * not obvious how to configure it (at about 5 minute mark after clicking about everywhere, finally tried right click -> settings) * not preconfigured (as far as I can tell, it didn't automatically find my music in ~/Music . I eventually found how to add it manually (after finding "settings")
On Sun, Jul 15, 2018 at 7:19 AM, Rex Dieter rdieter@math.unl.edu wrote:
Gerald B. Cox wrote:
A much better choice, IMHO for people to use is qmmp - it's light weight,
I tried using it admittedly only for ~5 minutes and would not be comfortable advocating this as a default media player... offhand:
- interface is small (I guess that means I'm old, the UI text is
unreadably small)
- not obvious how to configure it (at about 5 minute mark after clicking
about everywhere, finally tried right click -> settings)
- not preconfigured (as far as I can tell, it didn't automatically find my
music in ~/Music . I eventually found how to add it manually (after finding "settings")
The default interface is to use the winamp skins. You don't remember winamp - or never used XMMS? ;-)
In any event, your concerns can be addressed by simply choosing the "simple user interface". If you wanted that as the default, I'm sure we could speak to the maintainer or upstream and they could accommodate.
The best thing about qmmp is that it as far back as I remember, it has always (and still is) a very active, continuously maintained project. As Sudhir mentioned there are many projects that are created and haven't been maintained. QMMP is the opposite. It has always been very active and maintained.
Weaknesses you've identified with QMMP can be addressed by using the "simple user interface".
Those who are fans of Winamp can use the skinned interface.
It's under:
Plugins User Interfaces (which is the last selection under plugins)
On Sun, Jul 15, 2018 at 9:39 AM, Rex Dieter rdieter@math.unl.edu wrote:
Gerald B. Cox wrote:
In any event, your concerns can be addressed by simply choosing the "simple user interface"
how exactly? I'm having trouble finding that in settings
-- Rex _______________________________________________ kde mailing list -- kde@lists.fedoraproject.org To unsubscribe send an email to kde-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kde@lists. fedoraproject.org/message/NSPGIKKDHP2LQBCUARIHJAGTUFEKKDMB/
Gerald B. Cox wrote:
It's under:
Plugins User Interfaces (which is the last selection under plugins)
OK, that's a good start.
If that were implemented as the default interface, I could consider it. (But I'm not championing it, so the task would have to be taken up by someone else)
-- Rex
On Sun, Jul 15, 2018 at 7:45 PM, Rex Dieter rdieter@math.unl.edu wrote:
Gerald B. Cox wrote:
It's under:
Plugins User Interfaces (which is the last selection under plugins)
OK, that's a good start.
If that were implemented as the default interface, I could consider it. (But I'm not championing it, so the task would have to be taken up by someone else)
-- Rex _______________________________________________
Actually, besides being changeable in the settings, it's also one of many available command line start options:
qmmp --ui qsui
So it can be done in the app launcher.
Other choices can be viewed with qmmp --help
On Sun, Jul 15, 2018 at 8:12 PM, Gerald B. Cox gbcox@bzb.us wrote:
On Sun, Jul 15, 2018 at 7:45 PM, Rex Dieter rdieter@math.unl.edu wrote:
Gerald B. Cox wrote:
It's under:
Plugins User Interfaces (which is the last selection under plugins)
OK, that's a good start.
If that were implemented as the default interface, I could consider it. (But I'm not championing it, so the task would have to be taken up by someone else)
-- Rex _______________________________________________
Actually, besides being changeable in the settings, it's also one of many available command line start options:
qmmp --ui qsui
So it can be done in the app launcher.
Other choices can be viewed with qmmp --help
Or, another option is to create $home/.qmmp/qmmprc with the following contents, before first run:
[Ui] current_plugin=qsui
A much better choice, IMHO for people to use is qmmp - it's light weight, runs with qt5 and does what it sets out to do, which is be a flexible, lightweight music player that runs on qt5, supports skins, has many good plugins for extra features, supports tagged and folder based album covers, etc. A bonus, I've have yet to have it crash on me. If you haven't tried it, you should check it out.
"dnf install qmmp" pulls 140M for me, I don't know if this is a lighter option than amarok.
============================================================================================================================================================= Paquet Architecture Version Dépôt Taille ============================================================================================================================================================= Installation de : qmmp x86_64 1.1.12-3.fc28 fedora 2.3 M Installation des dépendances: fluid-soundfont-common noarch 3.1-18.fc28 fedora 87 k fluid-soundfont-lite-patches noarch 3.1-18.fc28 fedora 137 M libbs2b x86_64 3.1.0-20.fc28 fedora 29 k libsidplayfp x86_64 1.8.7-5.fc28 fedora 165 k libxmp x86_64 4.4.1-4.fc27 fedora 285 k wildmidi-libs x86_64 0.4.2-2.fc28 fedora 61 k Installation des dépendances faibles: qmmp-plugin-pack x86_64 1.1.5-2.fc28 fedora 169 k qmmp-plugins-freeworld x86_64 1.1.12-4.fc28 rpmfusion-free 130 k
Résumé de la transaction ============================================================================================================================================================= Installer 9 Paquets
Taille totale : 140 M Taille totale des téléchargements : 137 M Taille des paquets installés : 207 M
I was referring to system resources needed to play music - not how many Mb you needed to download the software and associated dependencies (which will vary on many factors).
As far as program size required for the named package:
amarok is 5.3Mb amarok-libs is 2.6Mb amarok-utils is 61k
On Sun, Jul 15, 2018 at 5:11 PM, Sinan H sinan@haliyo.net wrote:
A much better choice, IMHO for people to use is qmmp - it's light weight, runs with qt5 and does what it sets out to do, which is be a flexible, lightweight music player that runs on qt5, supports skins, has many good plugins for extra features, supports tagged and folder
based
album covers, etc. A bonus, I've have yet to have it crash on me. If
you
haven't tried it, you should check it out.
"dnf install qmmp" pulls 140M for me, I don't know if this is a lighter option than amarok.
============================================================
===================================== Paquet Architecture Version Dépôt Taille ============================================================ ============================================================ ===================================== Installation de : qmmp x86_64 1.1.12-3.fc28 fedora 2.3 M Installation des dépendances: fluid-soundfont-common noarch 3.1-18.fc28 fedora 87 k fluid-soundfont-lite-patches noarch 3.1-18.fc28 fedora 137 M libbs2b x86_64 3.1.0-20.fc28 fedora 29 k libsidplayfp x86_64 1.8.7-5.fc28 fedora 165 k libxmp x86_64 4.4.1-4.fc27 fedora 285 k wildmidi-libs x86_64 0.4.2-2.fc28 fedora 61 k Installation des dépendances faibles: qmmp-plugin-pack x86_64 1.1.5-2.fc28 fedora 169 k qmmp-plugins-freeworld x86_64 1.1.12-4.fc28 rpmfusion-free 130 k
Résumé de la transaction
============================================================
Installer 9 Paquets
Taille totale : 140 M Taille totale des téléchargements : 137 M Taille des paquets installés : 207 M _______________________________________________ kde mailing list -- kde@lists.fedoraproject.org To unsubscribe send an email to kde-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kde@lists. fedoraproject.org/message/WTYVOL7VWVTTF7AVEL46S3NI3DO7IRXT/
I was referring to system resources needed to play music - not how many Mb you needed to download the software and associated dependencies (which will vary on many factors).
As far as program size required for the named package:
amarok is 5.3Mb amarok-libs is 2.6Mb amarok-utils is 61k
well, in any case, qmmp (which I like by the way) pulls wildmidi-libs, which pulls fluid-soundfont-lite-patches amounting to 140MB. These would have to be included in the liveimage, unless the maintainer can be persuaded to build without midi support.
As a side note, current amarok master is on Qt5. There is no release yet but people report stable behavior. How about erring on the side of bleeding edge ?
On Mon, Jul 16, 2018 at 2:12 AM, Sinan H sinan@haliyo.net wrote:
I was referring to system resources needed to play music - not how many
Mb
you needed to download the software and associated dependencies (which will vary on many factors).
As far as program size required for the named package:
amarok is 5.3Mb amarok-libs is 2.6Mb amarok-utils is 61k
well, in any case, qmmp (which I like by the way) pulls wildmidi-libs, which pulls fluid-soundfont-lite-patches amounting to 140MB. These would have to be included in the liveimage, unless the maintainer can be persuaded to build without midi support.
As a side note, current amarok master is on Qt5. There is no release yet but people report stable behavior. How about erring on the side of bleeding edge ? _______________________________________________
An extra 140MB in the grand scheme of things is nothing IMHO. I believe the more important thing here is to choose an application which is rock solid, does the job and most importantly has a solid history of support. juk and amarok do not meet the last criteria. Yes, after years of neglect both are now getting some renewed attention, but qmmp has a very solid record on this.
On Saturday, 14 July 2018 20:39:47 CET Joe Buckley wrote:
Since I saw the discussion about dropping Amarok (because of the use of qt4???)
FYI amarok from master does not depend on qt4, they "released" version 2.9.70 not too long ago: https://github.com/KDE/amarok/commit/217b33c7eadf63643426f08ae805d61c99a6ee6...
I just built myself a package and the difference in speed/smoothness is substantial :-)
ldd /usr/bin/amarok | grep Qt5Core libQt5Core.so.5 => /lib64/libQt5Core.so.5 (0x00007fc350ccc000)
I must admit though that there are a couple of rough edges here and there.
I might create a COPR if I get to clean up my horrible mess of modified spec file.
-
Bob Mauchin -
Gerald B. Cox -
Joe Buckley -
José Abílio Matos -
Marc Deop i Argemí -
Rex Dieter -
Robert-André Mauchin
-
Sinan H -
Sinan H -
Sudhir Khanger