player is not suitable for use

[Dirli]

I don't fully understand why you don't want to send this player to history.
chronic errors:

• it is not stable,starting very often leads to a crash
• if it starts (try running it from the console), you will immediately see a large list of warnings, including critical ones
• it doesn't know how to work with collections. even 2000 thousand songs blocks its normal operation. It doesn't make any sense to use it on large collections. for example, 10,000 tracks are scanned for more than 20 hours (although an adequate time is 10 minutes)
• it's very fond of memory. for example, when scanning 10,000 songs, the consumption exceeds 5 Gb. when working with these compositions later, the consumption is over 800 Mb
• and most importantly, it is very expensive to fix all these errors. the player is terrible architecturally. a lot of unnecessary singleton; the global scope is cluttered for no reason; you operate with objects that you drag everywhere, although you only need URIs; when playing in the background, the player takes up 800 MB, because doesn't play the player, but the entire app

I tried to figure out what was wrong with it, but for a month I couldn't figure out how to fix the errors, I just got more confused, judging by the fact that many errors (including critical ones) are not fixed for years, I'm not the only one. Obviously, the easiest way is to rewrite it

After a bit of research on this topic, here's what would make sense:

• the player should not know anything other than the list of URis that it plays, and some additional functionality related to playback (for example, the equalizer). it should be a console player, light and fast. it will also make it possible to have one console player for which developers can make their own GUI
• to communicate with the player, there are mpris and settings that can be used to correctly control the player.
• forget about the async model when scanning and accessing the database, it will still be painful for large collection. it is more logical to use threads.
• use events instead of multiple links
• anyone who suggests putting an entity in the global scope "for access from anywhere", does he think that perhaps he is not the only one who will work with this code.

unfortunately, it seems to me that it can no longer be fixed, and if it's possible to eventually fix the problem, it will take no less time than rewriting it. Moreover, users actually presented you with a roadmap (pointing out bugs)

PS But the idea and its appearance would very much like to keep, because they are really good)

[Dirli]

it is also a bad idea to directly manage files in the file system. it seems to me that there are more specialized elements for this.

[jeremypw]

I have been trying to work with the code recently and tbh I tend to agree with you. However, we would first have to find a suitable replacement (which may well require restyling).

[Dirli]

I have certain sketches (https://github.com/Dirli/music2). but I'm too lazy to test it for non-standard situations (it often takes a lot of time). So to speak: "everything works for me". The 80 GB scan time is approximately 10 minutes. in the running form, the result is shown in the screenshot.
Occasionally there is a bug when starting the GUI. But it's so rare that I can't catch it in any way. And maybe I brought it from here.

[Dirli]

I do not know how to do this, but it would be logical to freeze the current version of the player and stop its development, and slowly start making a new one that would take into account the errors of its parent. otherwise we just go around in circles

[cassidyjames]

Honestly my inclination is to create a simple Audio player app that can handle playing a file on demand (i.e. so if someone downloads a song or recording or something, we can preview it), but to not try to handle all of the library stuff. A lot of folks are moving away from local music collections, and those who like local collections may have an existing music player of choice that they can grab from AppCenter or Flathub.

At the same time, I don't want to unnecessarily kill off something that people use, especially if there are people willing to maintain it. The problem is that nobody has been willing and able to maintain Music long-term.

[Dirli]

I don't agree that the demand for such functionality is reduced. Even if you look at this player. A lot of people write about problems with it. So they're using it.
Yes, I agree that it can be made more flexible, and if the user didn't specify the home folder, don't use unnecessary functionality. But the complete rejection of this functionality, I think, is a bad idea. if you exclude all inconvenient functionality from stock apps, then what is the point of it? Just a dummy?
It seems to me that the maintainers would be found if the project was at least easy to read.

[jeremypw]

It would be better to have a rock-solid, well-written and documented audio player for a native app even if it did not have all the bells and whistles at first. Not sure what a minimum viable specification would be or whether it is worth starting from scratch - there are at least a couple of music players written in Vala that might serve as a basis if the basic structure of the code is good.

[jeremypw]

@Dirli So, looks like Music2 is based on the elementary Music app?

[davidmhewitt]

Another alternative to consider if we do want to keep the library functionality is to use GNOME Tracker to index and keep a database of the music library.

This is what GNOME Music and Photos (for photos) do but I don’t know how well they handle large collections.

[Dirli]

@jeremypw No, it is not correct to say that it is based. This is a rewritten player. I kept the appearance, and the General idea. But I tried to get rid of what I thought was spoiling it.
The ideas I outlined above just came out of this. Especially since I have a large collection of music and have something to test on.

[jeremypw]

@Dirli OK, that's good.

[Dirli]

@davidmhewitt correct me if I'm wrong. The Tracker indexes all files on hard drives and the player then selects music files from there? If this is the case, then the solution is on an amateur. Maybe there's some music I don't want to see yet. But what about the tags? Re-scan them every time on the fly? But it is quite expensive. And playlists?
The current idea looks quite viable, but its implementation is not very good. And I don't think it's a good idea to try to reinvent the wheel.

[danirabbit]

I think the drawback of Tracker is I'm not sure if it can really distinguish between audio files and music, so you probably could end up with a lot of junk especially if your work involves audio files

My inclination is that a rewrite would probably only be worth it if it was built around streaming services. I'm not sure how many people really curate local audio collections anymore. It seems like this functionality would be secondary and more niche. But I guess this depends on the availability of some API.

I think this is why some of us have considered a much more minimal audio previewer and maybe no music app by default

[Marukesu]

Maybe I beginning dumb, but, we can transform the core in a d-bus interface, so we can easily write streaming backends. Also we can add a option to open a minimal view when the request is for a single music/audio file.

[Marukesu]

afaik, Dezzer, Spotify and Apple Music offers a JavaScript SDK, I don't know about YT Music

[Dirli]

Thank you, I heard the opinion of the main project participants

[jeremypw]

It is problematic to infer how other people use elementary from the one's own usage or that of one's own generation or region.

[Dirli]

I agree, which is why I raised this topic. Judging by the number of issue, I'm not the only one who would like to see the Music working. but I don't want to argue with the people who determine the main vector of project development.

[r0thko]

My inclination is that a rewrite would probably only be worth it if it was built around streaming services. I'm not sure how many people really curate local audio collections anymore. It seems like this functionality would be secondary and more niche. But I guess this depends on the availability of some API.

I just would like to indicate that even in streaming era not everyone uses these services, there is at least one reason: not everything is present there and for many the preferable way is to listen full albums from their hard disk.

Anyway a player with simple UI (like foobar, for instance) is a need.

[CubeGame]

What about a rewrite with the app as an mpd client?