I’ve just starting using Symfonium and find that a lot of albums lack cover images in the app. I can chose to find local files (though frustrating the app doesn’t default to the local directory and I have to navigate through the whole music library to get to the relevant directory to do so), so I know that a lot of these albums do indeed have cover art images in their directories.
With other music apps, there was a setting to try to use local image files as cover art, but I can’t find such a setting in Symfonium. Am I not looking in the right place?
I think one problem is that it’s indexing separately anything with a .CUE file and not finding covers for those? In the album view, more than half of things don’t have covers and almost everything is duplicated.
I need your help here, if you do not answer the question and give no details I have no way to guess the content of your folder and what you see on the screen to be able to help.
So please provide actual usable details so that we can figure out the details.
I apologise for the frustrations here, Tolriq. I am aware of the difficulties of providing assistance without sufficient information, and I greatly appreciate how responsive and helpful you’ve been.
Let me try to give as much information as possible, also with hopes that it could help other people in future.
(Summary for the issues brought up in this thread at this point: (a) I don’t think there’s anything addressable by you at this point, other than perhaps a couple of tentative feature requests; (b) some things may have been (silent?) permissions issues, maybe related to GrapheneOS.)
Duplication issue
The duplication problem seems to have resolved itself since last night, which is a bit confusing to me. Last night, more than 50% of albums were duplicated, usually with the one having cover artwork and the other not. This morning, I do not find this duplication anymore. I wonder if there could have been old entries that somehow got cleaned up? That feels unlikely, but I’m not sure what other explanation makes sense.
Original missing artwork issue (permissions?)
For the initial issue I reported, it’s possibly (though I’m not certain), that some of this could have been App Permissions related. I’m on GrapheneOS, and by default Symfonium only had permissions for “Network” and “Sensors”. It was still able to see my Music location and files in it and play music, but (I think) was only displaying cover art for music where the art was embedded in the individual files. I subsequently gave Symfonium permissions for “Music and audio” and “Photos and videos”. Maybe this is a red herring, but I wondered if the previous lack of permissions for one or other of these could have been related to the apparent issue with finding non-file-embedded cover art?
remaining missing artwork:
Symfonium seems less opportunistic in grabbing .jpg, .png artwork in folders than some other music players. perhaps it is looking just for folder.jpg|.png or cover.jpg|.png? Because some of the albums remaining without artwork do indeed have image files in their directories, but they’re named things like “name of album.jpg” or “front.png” rather than “folder.jpg”.
tentative feature requests related to previous issue
a. if it’s the case, maybe have an option to make Symfonium more opportunistic in grabbing other image files in local directories when the standard folder.jpg, cover.jpg, &c. images are not present.
b. when choosing Change Local Thumbnail and then From File Picker, instead of the search location being either the root of the added local device or the last used location, could it automatically route me to the relevant directory for the album? (I also tried as a sort of workaround, to go into the “Details” for a song and copy the file path from the File Path info, but, though I can highlight text, I can’t get it to copy.)
c. Some music players (e.g. Poweramp) will have an option to try to search online for relevant cover art; this would be a nice convenience
I know I should put the feature requests in a different part; I include them here just because they’re thematically linked. I will do it properly as well.
No way to know, usual suspect would be that you changed some settings like the album split and now the albums are no more wrongly splits. Only logs would have tell.
If you use SAF mode those permissions are not needed and does not impact the scan at all. Only logs would have tell.
I’ve found an issue with png being ignored so that’s one thing that will be fixed, I support a few more file names including the front, but the name of album.jpg is not. There’s very little chance that I add support thanks to Google changes about raw file access, that would slow down insanely the scan process for a quite rare case. If you have some well know filenames not taken in account I can probably support them.
a) as for 3
b) I can’t really force the path specially since the path can not exist for all the other providers, for the copy paste issue this is a Compose bug that I hope they will fix one day but they do not seem to care
c) No, it’s the same as lyrics, it can return explicit content and requires a new age rating on Play Store and many risks if any one complain, Google is stupid and does not offer proper support in case the app is banned for a wrong user report.
I’m sorry that I didn’t initially provide logs. Then, later, I forgot to turn on Debug mode until after, so perhaps the logs I did get were only so useful. Sorry again for this. I’ll leave Debug mode on now and try to provide useful logs for any future issues. (I haven’t changed any album split settings. What does Symfonium do with .CUE files, if anything? I know I have a number of .CUE files in directories.)
Ah, that’s useful to know, and so unconnected with GrapheneOS.
I didn’t realise about the performance issues. It does then sound like the best thing is what you’re doing, i.e., using a list of common cover names. (adding “front” would indeed be good here, I think.) The other issue I can think of here is when there are subdirectories, sometimes the cover is actually in the containing directory. E.g. there’s a path album-name/cover.jpg but then the music files are actually in album-name/disc_1/song_1.flac etc.
a) right
b) that makes sense. I suppose the same issue would apply to having an option to copy the local path to the clipboard?
c) this makes sense too. So, I guess what Poweramp does opens them up to this potential issue then. What about what Musicolet does? (It doesn’t require Network permission at all, and doesn’t fetch images directly into the app itself, but rather has an option to open a browser to an image site (Google Images or Bing Images, I forget which) with the album+artist name pre-populated and then one can download images in the browser, but since they’re recently downloaded, it is relatively easy to use the image selector for recent downloads to add the cover).
CUE files are parsed and songs and albums are created from the value that is present in them.
As said front is supported, the issue is the png extension in your case probably, and yes covers in parent folder are not supported, it would be slow and it would also trigger possibly tons of wrong link.
The option to copy the path should be there it’s just that it’s broken in the toolkit I use for now. One day it will work
Poweramp is very old and rules have changed a lot, I hope they never get an issue by the Google bots.
You can also press 3 dots on a song then web search.
When adding covers to albums in Symfonium, the tracks don’t seem to inherit the cover art. So, for instance, if I add album art to an album lacking a cover, and then add all of the tracks from the album to a playlist, the tracks in the playlist don’t have any album art.
