gnome-music issueshttps://gitlab.gnome.org/GNOME/gnome-music/-/issues2024-03-14T09:16:48Zhttps://gitlab.gnome.org/GNOME/gnome-music/-/issues/604Thousands of albums makes the program nearly unusable2024-03-14T09:16:48ZCaden MitchellThousands of albums makes the program nearly unusable## Description
The app is not optimized to be able to load thousands of albums efficiently. It constantly freezes and uses lots of CPU.
## Steps To Reproduce
- Add a few thousand audio files
- Give each file a unique album metadata an...## Description
The app is not optimized to be able to load thousands of albums efficiently. It constantly freezes and uses lots of CPU.
## Steps To Reproduce
- Add a few thousand audio files
- Give each file a unique album metadata and album art
- Place in Music folder and open Music
- Scroll down
## Expected Behaviour
App should run well.
## Actual Behaviour
App lags and freezes constantly. If the album list is still, it seems fairly responsive, but try to scroll, and it will majorly lag and freeze trying to load in the new album art, or possibly from trying to scroll thousands of GtkButtons? I don't know what the bottleneck is, but somehow other music apps can handle loads of albums efficiently.
## Specifications
Gnome Music Version: 45
Desktop Environment: GNOME
Wayland or Xorg: Wayland
Flatpak or Native: Flatpak
Tracker Version: ? (not in about dialog)
Grilo Version: ? (not in about dialogue)
## Additional Informationhttps://gitlab.gnome.org/GNOME/gnome-music/-/issues/603Feature request: Metadata loading status screen2024-03-14T08:45:50ZCaden MitchellFeature request: Metadata loading status screen## Description
When you suddenly introduce Music to thousands of songs while its running, it just kinda seizes up. I think it would be better if there were an AdwStatusPage with an animated spinner and a music icon or something, explain...## Description
When you suddenly introduce Music to thousands of songs while its running, it just kinda seizes up. I think it would be better if there were an AdwStatusPage with an animated spinner and a music icon or something, explaining that it is fetching resources like album art and metadata. There should also be a progress bar showing eg. 22/2,451 songs loaded, so the user gets some feedback on the software. Otherwise, the user may assume the app is frozen or broken, and they may not realize it is just operating normally.
Alternatively, something like Nautilus has, where there is a circle in the upper left corner showing progress, and some text saying "loading metadata". It's a button, and clicking it shows more specifics, like the exact progress, and maybe the current file it's working.
## Steps To Reproduce
- Link or paste thousands of songs with metadata into the Music folder while it is running
## Expected Behaviour
Status report of the metadata scanning operation
## Actual Behaviour
Appears to be frozen
## Specifications
Gnome Music Version: 45
Desktop Environment: GNOME
Wayland or Xorg: Wayland
Flatpak or Native: Flatpak
## Screenshot
![Screenshot from 2024-03-14 01-42-18.png](/uploads/4cee61c783eb847154b721228cb9cb06/Screenshot_from_2024-03-14_01-42-18.png)https://gitlab.gnome.org/GNOME/gnome-music/-/issues/595Search fails to find items in artists/albums2024-02-12T09:25:52ZMarinus Schraalmschraal@gnome.orgSearch fails to find items in artists/albums## Description
Given a song: 'Bohemian Rhapsody', it will find the song itself. But it will not find the related album or artist.
## Steps To Reproduce
* Find a song by name
## Expected Behaviour
I would expect search to find the ar...## Description
Given a song: 'Bohemian Rhapsody', it will find the song itself. But it will not find the related album or artist.
## Steps To Reproduce
* Find a song by name
## Expected Behaviour
I would expect search to find the artist `Queen` and the album 'A night at the opera', besides the specific song.
## Actual Behaviour
* Only the songs list pops up with the specific song.
## Specifications
Gnome Music Version: 45/46
Flatpak or Native: Both
Tracker Version: 3.6.0
## Additional info
Tracker changed some of it's behaviour in the port to Tracker 3, it could be the search queries still rely on unsupported sparql.https://gitlab.gnome.org/GNOME/gnome-music/-/issues/576Widgets never get released and destroyed2024-02-04T12:39:37ZMarinus Schraalmschraal@gnome.orgWidgets never get released and destroyed## Description
I've been noticing slowdowns over time with heavy use of certain widgets. A closer inspection seems to indicate that a sizable portion of widgets never get released and destroyed. Which in turn also carries a ton of signa...## Description
I've been noticing slowdowns over time with heavy use of certain widgets. A closer inspection seems to indicate that a sizable portion of widgets never get released and destroyed. Which in turn also carries a ton of signals and bindings being active at all times, while no longer being relevant or useful.
Also memory increases over time with widgets never getting destroyed.
Specifically the chain of `ArtistAlbumsWidget` -> `AlbumWidget` -> `DiscBox` -> `SongWidget` is kept alive indefinitely it seems.
## Steps To Reproduce
- Add a print statement in `CoreSong`'s selected property (with the song name) to see how often it gets triggered over time.
- Go to the `ArtistsView`, switch between 2 artists for a while.
- Notice the increase in how often a single songs 'selected' property gets checked over time. This indicates the widgets bindings stay alive and active.
- You can also attach a `weak_ref` to a `SongWidget` on creation, the callback never gets called on these widgets.
## Expected Behaviour
The widgets to be destroyed and all the bindings in the process, not resulting in ballooning and slowdown because of way too much property triggers.
## Actual Behaviour
* Slow burn.
* Memory ballooning.
## Specifications
Gnome Music Version: Tested on 44
Desktop Environment: GNOME
Wayland or Xorg: Wayland
Flatpak or Native: Native (I expect Flatpak to be the same)
Tracker Version: 3.5.3
Grilo Version: 0.3.16
## Additional Information
I tested this in the live environment, but it is too difficult to track down the issue. This needs a small reproducer to get a real idea of where to look and I suspect it might be in `PyGObject` or maybe some circular logic between all the signals and bindings Music has.
The way this works is that we use `GtkListBox` with `bind_model` often to work with our `ListModel`'s, when setting a new model the old model's widgets should get destroyed. The `ListBoxRow`'s do get destroyed, but the child widgets do not.
## Related issues
- #530
- #179GNOME 46https://gitlab.gnome.org/GNOME/gnome-music/-/issues/539Share music to Bluetooth or WiFi speaker2024-02-03T20:08:46ZDolly AgentShare music to Bluetooth or WiFi speakerHi everyone,
First, I would like to thanks, all Gnome's team for the work and specially for Music app, I love it. Coming from Apple, the app is perfect, almost perfect because I would like to know if it's possible to develop a Share but...Hi everyone,
First, I would like to thanks, all Gnome's team for the work and specially for Music app, I love it. Coming from Apple, the app is perfect, almost perfect because I would like to know if it's possible to develop a Share button to share music with Bluetooth (or Wifi) on speaker ?
Thanks for your replyhttps://gitlab.gnome.org/GNOME/gnome-music/-/issues/531Pausing during the last second of a song prevents you from playing any more s...2022-06-22T13:55:09ZDaan VanoverloopPausing during the last second of a song prevents you from playing any more songs.When you pause during the last second of a song, GNOME Music enters a state in which you can no longer play anything at all.
Steps to reproduce:
1. Click on the "Artists" tab
2. Play a song
3. Skip to somewhere near the end, or wait fo...When you pause during the last second of a song, GNOME Music enters a state in which you can no longer play anything at all.
Steps to reproduce:
1. Click on the "Artists" tab
2. Play a song
3. Skip to somewhere near the end, or wait for it to reach the end
4. While in the last second of playback, pause the song
5. Attempt to play any other song
Expected behaviour: it plays the song I clicked on in step 5.
Actual behaviour: it still shows the name of the previous song, with the time reset to 0:00, and it does not play anything.
In order to play any other song, GNOME Music must be restarted.https://gitlab.gnome.org/GNOME/gnome-music/-/issues/517`_on_button_released` handler of `SmoothScale` is not called2022-04-05T21:57:28ZOle Bertram`_on_button_released` handler of `SmoothScale` is not calledThe [`_on_button_released` method of `SmoothScale`](https://gitlab.gnome.org/GNOME/gnome-music/-/blob/36041f9f65cfdebc356a16c827cbf0472a8281ca/gnomemusic/widgets/smoothscale.py#L139) does not seem to be called when the user releases the ...The [`_on_button_released` method of `SmoothScale`](https://gitlab.gnome.org/GNOME/gnome-music/-/blob/36041f9f65cfdebc356a16c827cbf0472a8281ca/gnomemusic/widgets/smoothscale.py#L139) does not seem to be called when the user releases the button. I verified this by inserting a simple print statement into the `_on_button_pressed` and `_on_button_released` handlers, and only the `_pressed` one actually prints.
I noticed this because I am writing a music player myself, and I had some trouble with my progress bar myself, so I wanted to see how other implementations deal with this. When I asked about my problem in a chat, I was linked to [this line](https://gitlab.gnome.org/GNOME/gtk/-/blob/21cba193adf150f522c1bd89faa136ba8d9531cd/gtk/gtkrange.c#L1998) as a source of this behavior.
I am not sure if or what impact this actually has on the functionality of the application, but I would be interested if it's possible to fix.https://gitlab.gnome.org/GNOME/gnome-music/-/issues/505Search keypress crasher2023-08-22T11:41:11ZMarinus Schraalmschraal@gnome.orgSearch keypress crasherI reverted !931 before the merge because of a very reproducible crash for me.
1. go to a grid/listview (albumsview or songsview)
2. select 2 regions (ctrl+rubberband) 1 visible on screen, one offscreen
3. cancel selection mode
4. crash
...I reverted !931 before the merge because of a very reproducible crash for me.
1. go to a grid/listview (albumsview or songsview)
2. select 2 regions (ctrl+rubberband) 1 visible on screen, one offscreen
3. cancel selection mode
4. crash
```
**
Gtk:ERROR:../gtk-4.6.1/gtk/gtkwidget.c:2473:gtk_widget_root: assertion failed: (!priv->realized)
Bail out! Gtk:ERROR:../gtk-4.6.1/gtk/gtkwidget.c:2473:gtk_widget_root: assertion failed: (!priv->realized)
```https://gitlab.gnome.org/GNOME/gnome-music/-/issues/454Order of songs in playlist is not saved between sessions2024-03-22T16:45:40ZXavier JohnsonOrder of songs in playlist is not saved between sessionsIf songs in a playlist were reordered manually, that ordering will be lost the next time Music is opened.
It seems that the default ordering is to sort alphabetically by artist name.If songs in a playlist were reordered manually, that ordering will be lost the next time Music is opened.
It seems that the default ordering is to sort alphabetically by artist name.https://gitlab.gnome.org/GNOME/gnome-music/-/issues/439Weird spacing in search view2021-04-09T14:10:45ZYann DelabyWeird spacing in search viewTested with
- 3.38.0-95f7bf58
The artists, albums and songs try to use all the vertical space available in the search view, creating the 2 following issues :
1. A lot of space between types (artists <-> albums <-> song) when there is f...Tested with
- 3.38.0-95f7bf58
The artists, albums and songs try to use all the vertical space available in the search view, creating the 2 following issues :
1. A lot of space between types (artists <-> albums <-> song) when there is few results, see 1.png and 2.png.
2. Widgets changing places as you type, making it difficult to see if what you are searching for has been found, until you stop typing and everything stop moving. See evolution between 2.png and 3.png
One easy way to reproduce it is to add a space after an artist name to filter songs with featuring (like "Mounika. X Ocie Elliot").
![1](/uploads/fcb182a9f8eba36afe28fb56cb223421/1.png)
![2](/uploads/27b565583366f586a1d2112cf468fb22/2.png)
![3](/uploads/cd422ddc21dc65aeda11afb081fb81d4/3.png)https://gitlab.gnome.org/GNOME/gnome-music/-/issues/394Playback time frozen2021-10-05T16:53:51ZAlexandre FrankePlayback time frozen![Capture_d_écran_de_2020-05-27_14-52-51](/uploads/c42899a1b230402502b4e1bfd71fdb47/Capture_d_écran_de_2020-05-27_14-52-51.png)
Playback is still going but the current time is frozen at 8:00 which was the time for the first song of that...![Capture_d_écran_de_2020-05-27_14-52-51](/uploads/c42899a1b230402502b4e1bfd71fdb47/Capture_d_écran_de_2020-05-27_14-52-51.png)
Playback is still going but the current time is frozen at 8:00 which was the time for the first song of that album. I don’t have a way to reliably reproduce it but it happened several time with the time stuck at the duration of a previous song in the list (not necessarily the first one).
This is on Fedora 32, with `tracker-miners-2.3.3-1` and `gnome-music-3.36.2`.https://gitlab.gnome.org/GNOME/gnome-music/-/issues/179Music has a large memory footprint2024-02-04T10:29:21ZPostroutineMusic has a large memory footprintRunning Gnome-Music 3.28.1 on Fedora 28, it use a lot of RAM.
Right after launch it use ~240 Mio and now it is at ~270 Mio of RAM.
#### Update February 2024
The general issue here is that Music can quickly use a lot of memory. This is ...Running Gnome-Music 3.28.1 on Fedora 28, it use a lot of RAM.
Right after launch it use ~240 Mio and now it is at ~270 Mio of RAM.
#### Update February 2024
The general issue here is that Music can quickly use a lot of memory. This is somewhat expected as it uses a lot of cover art which on a lot of integrated systems is main memory used (not GPU ram).
In the past (GTK3) the widgets would also not cycle, so if you had a lot of music it would load all widgets and all coverart with it and that could be a lot of memory. Now with GTK4 and the (re)cycling list widgets this can still be a chunk of memory, but it should stay in the same range over time.
The course of action here would be to profile Music's use of memory, see how much of it is texture related and if that is in line with expectations. If there is nothing out of the ordinary this could be closed.
I don't have the time and knowledge to investigate this at this point in time, so any help is welcome.
Note that there is another issue with widgets not being destroyed that grows Music's memory footprint over time (#576), which muddles the waters a bit. Lets try to keep the issues separated.