VinylMusicPlayer
Folder cover image not loaded
Folder cover image (not the embedded album art) is not loaded anymore since version 1.5.3 (Android 13 upgrade)
Originally reported in #788
Hello @mikelpr, I cannot reproduce this with the latest version (1.5.5, submitted to PlayStore). Tested with a cover.jpg in the album folder. Do you mind re-checking and report back your observation?
I can confirm this issue, no cover art is loaded.
cover art file: folder.jpg System: Android 13
Version 1.5.2 is the last one working, I have tried 1.5.3 to 1.5.5
I can also reproduce this issue on version 1.5.5. Let me know if you need any more information on this issue
Can you guys help me to clarify one thing? Are you all using Folder view, not the Library view?
I'm using library view. I just installed the app, so I didn't change any settings.
I'm using library view. I just installed the app, so I didn't change any settings.
Thanks for confirming. The PR mentioned above fixes the cover art loading for Library view.
The PR says it fixes folder view, not library view
Oops, you are right, I didn't read your reply correctly
I'm using library view. I just installed the app, so I didn't change any settings.
@fwsmit Can you please share me a screenshot of your settings, as well as a sample folder (track + cover file) that you expect to function properly?
@soncaokim For me it is also library view, folder view does not work at all, just tried. Folder view only shows "Empty" and when trying to scan in ROOT/STORAGE/EMULATED/0/MUSIC it says "nothing to scan"
Btw, maybe it is related, rescanning the library takes ages with about 3 Songs per Second instead of the almost instant scan running through all the files. This also holds true when installing Vinyl after uninstall or after first install. This also began with 1.5.3. No issues with 1.5.2
Would you like me to open a new issue?
Rescanning throws this error:
java.lang.NullPointerException: Can't toast on a thread that has not called Looper.prepare()
at com.android.internal.util.Preconditions.checkNotNull(Preconditions.java:167)
at android.widget.Toast.getLooper(Toast.java:185)
at android.widget.Toast.
@soncaokim For me it is also library view, folder view does not work at all, just tried. Folder view only shows "Empty" and when trying to scan in ROOT/STORAGE/EMULATED/0/MUSIC it says "nothing to scan"
This is a separated problem, already reported (and I cannot reproduce, need to find a way to gather more info).
Btw, maybe it is related, rescanning the library takes ages with about 3 Songs per Second instead of the almost instant scan running through all the files. This also holds true when installing Vinyl after uninstall or after first install. This also began with 1.5.3. No issues with 1.5.2
Yes, I needed to change the way the embedded cover image are extracted from track data - to support Android 13. For now I want to concentrate on bugs first, will need to revisit that for performance after.
Rescanning throws this error: java.lang.NullPointerException: Can't toast on a thread that has not called Looper.prepare() at com.android.internal.util.Preconditions.checkNotNull(Preconditions.java:167) at android.widget.Toast.getLooper(Toast.java:185) at android.widget.Toast.(Toast.java:170) at android.widget.Toast.makeText(Toast.java:498) at android.widget.Toast.makeText(Toast.java:486) at com.poupa.vinylmusicplayer.discog.tagging.TagExtractor.extractTags(Unknown Source:25) at com.poupa.vinylmusicplayer.discog.Discography.addSong(Unknown Source:23) at
Will have a look on this "toast" error. Do you mind open a new issue for this?
@soncaokim about reproducing the errors, may I ask, what phone and Android Brand (Samsung, Sony, Vanilla, LineageOs,...) and Version are you using? I am on LineageOS 20 (Android 13) as well as on Oneplus OxygenOS 13.1 (Android 13)
Files I am using are .flac, if it is of relevance Folder Structure: /Music/FLAC/Artist/Album/*.flac (with id3 tags) + folder.jpg
About the "toast" error, sure, will open a new issue late this day or weekend.
Here is an example of an album where the album art didn't load (and it did load in phonograph). I removed every song except one to get under the size limit, but that shouldn't affect testing. I also didn't change any settings, except for dark mode.
I'm using android 10 on the Honor 10 by the way
And here is the screenshot (sorry, it's very long):
Also affected, in a somehow strange manner. I use Vinyl for quite a long time, and some albums that used to display their cover doesn't anymore.
But on top of that, I think there was some caching from Vinyl for the songs already known. Here it looks like this cache doesn't exist anymore and that it reloads covers everytime I move over the album in the interface (if I go further away and then come back, the cover isn't here anymore and have to reload again). The covers and the color change it triggers to the interface also seems to be much slower than it used to be, probably because of this reloading behavior. While I've some doubts and I'm not 100% sure of that last part and can remember it wrong, the covers that used to load and doesn't load anymore are 100% sure.
This is the kind of errors appearing in logs, and reported above:
10-27 14:29:19.384 5519 5519 W Glide : Load failed for com.poupa.vinylmusicplayer.glide.audiocover.AudioFileCover@d93b4dbd with size [522x522]
10-27 14:29:19.384 5519 5519 W Glide : class com.bumptech.glide.load.engine.GlideException: Failed to load resource
10-27 14:29:19.384 5519 5519 W Glide : There was 1 cause:
10-27 14:29:19.384 5519 5519 W Glide : java.util.MissingResourceException(No artwork)
10-27 14:29:19.384 5519 5519 W Glide : call GlideException#logRootCauses(String) for more detail
10-27 14:29:19.384 5519 5519 W Glide : Cause (1 of 1): class com.bumptech.glide.load.engine.GlideException: Fetching data failed, class java.io.InputStream, LOCAL
10-27 14:29:19.384 5519 5519 W Glide : There was 1 cause:
10-27 14:29:19.384 5519 5519 W Glide : java.util.MissingResourceException(No artwork)
10-27 14:29:19.384 5519 5519 W Glide : call GlideException#logRootCauses(String) for more detail
10-27 14:29:19.384 5519 5519 W Glide : Cause (1 of 1): class java.util.MissingResourceException: No artwork
10-27 14:29:21.948 5519 5568 I flac : /data/user/0/com.poupa.vinylmusicplayer/cache/17233552959024661220379.flac StartByte:4 BlockType:STREAMINFO DataLength:34 isLastBlock:false
10-27 14:29:21.948 5519 5568 I flac : /data/user/0/com.poupa.vinylmusicplayer/cache/17233552959024661220379.flac StartByte:42 BlockType:PICTURE DataLength:819927 isLastBlock:false
10-27 14:29:21.948 5519 5568 I flac : /data/user/0/com.poupa.vinylmusicplayer/cache/17233552959024661220379.flac StartByte:819973 BlockType:VORBIS_COMMENT DataLength:745 isLastBlock:false
10-27 14:29:21.948 5519 5568 I flac : /data/user/0/com.poupa.vinylmusicplayer/cache/17233552959024661220379.flac StartByte:820722 BlockType:PADDING DataLength:8778 isLastBlock:true
Phone is running Android Oreo (8.0) stock running Vinyl from F-droid, and it started with version 1.5.3 I think (maybe previous one).
EDIT: And the fact covers have to reload everytime in the play view before adapting UI colors resulted in a lack of responsiveness and snappiness in the interface redrawing on song change.
Here is an example of an album where the album art didn't load (and it did load in phonograph). I removed every song except one to get under the size limit, but that shouldn't affect testing. I also didn't change any settings, except for dark mode.
I've reproduced the error with this sample, on my real device but not on the emulator (!!!)
With some more instrumentation: the app failed to load the .jpg file with FileNotFoundException: .../Mac.Miller/Mac Miller/Circles/folder.jpg: EACCESS (Permission denied)
Did you put the Mac Miller directory in the Mac.miller directory? I use a directory like Music/Mac Miller/Album/
From the above error seems like vinyl is trying to open the right file, but doesn't get permission. That's weird, since at least on my device it has storage permissions
@fwsmit and all: Thanks for your help here.
The background: To support Android 13, we had to drop some storage permission. A13 restricted the raw storage access, and unfortunately we rely a lot on this - to load the metadata, to load the cover art, to fallback on the folder.jpg, to browse the folder/files.
To circumvent, we've add new workflows to gain the user explicit permission on the folder containing the music. We've probably overlooked and missed some cases. The PR #832 brings some corrections.
The hypothesis I'm considering: For some reason, the app dont get the user permission on the folder.jpg. Either because you havent granted it, and we've missed the cases where we should have asked you that. Or the granted permission doesnt cover new folders/files, or doesnt cover non-audio files.
The help I need: If possible, can you please reset the app (remove storage/cache) Then go through the welcome screen, grant all audio/media permission. Important: Then try to simulate a song delete - i.e. not actually delete it, but just trigger the permission workflow via which you grant the app access to your music folders (the one containing Mac.Miller in the previous example). --> Is the folder.jpg gets loaded (in the Library view and in Folders view) for the song that doesnt have embedded cover?
Thank you for looking into this issue!
The help I need: If possible, can you please reset the app (remove storage/cache) Then go through the welcome screen, grant all audio/media permission. Important: Then try to simulate a song delete - i.e. not actually delete it, but just trigger the permission workflow via which you grant the app access to your music folders (the one containing Mac.Miller in the previous example). --> Is the folder.jpg gets loaded (in the Library view and in Folders view) for the song that doesnt have embedded cover?
I have some questions regarding the testing. Should we test the latest master? If so, where can I download it? The other question is, how do I trigger the permission workflow for deletion? Do I just need to click delete from device and then cancel? For me it would not be an issue to just delete a song, since I can easily sync it back.
The background: To support Android 13, we had to drop some storage permission. A13 restricted the raw storage access, and unfortunately we rely a lot on this - to load the metadata, to load the cover art, to fallback on the folder.jpg, to browse the folder/files.
Does the new way of storage permissions work on older versions of android?
Should we test the latest master? If so, where can I download it?
In the front page of this repo, you have the "pre-release" link that points to the latest master. Otherwise, here you go: https://github.com/VinylMusicPlayer/VinylMusicPlayer/releases/tag/pre-release
The other question is, how do I trigger the permission workflow for deletion? Do I just need to click delete from device and then cancel? For me it would not be an issue to just delete a song, since I can easily sync it back.
Yes, please select the menu next to a song -> Delete from device. Once you granted the folder permission (please select the parent folder of all your music), you should have a prompt to confirm the deletion of the song.
Does the new way of storage permissions work on older versions of android?
Well, it should. Unless us stupid developers failed to cover all cases.
A13 just enforces something they introduced way back but we opted not to follow (since a lot of code change and horrible workflow). Now we are forced to go their way, otherwise no clearance to publish to PlayStore. That explains, partly, the hiatus on PlayStore in the past year(s).
I just installed the pre-release 39b9b10 and tried the test you described @soncaokim.
OnePlus 7 Pro Lineage OS 20 (Android 13)
After giving Vinyl access to my library directory, it still could not load any of my folder.jpg's.
Here is the bug report after I gave Vinyl access:
java.io.FileNotFoundException: /[storage/emulated/0/Music/Library/_namirin/_namirin/folder.jpg](http://storage/emulated/0/Music/Library/_namirin/_namirin/folder.jpg): open failed: EACCES (Permission denied) at libcore.io.IoBridge.open(IoBridge.java:574) at java.io.FileInputStream.<init>(FileInputStream.java:160) at com.poupa.vinylmusicplayer.glide.audiocover.AbsCoverFetcher.fallback(Unknown Source:25) at com.poupa.vinylmusicplayer.glide.audiocover.AbsCoverFetcher.fallback(Unknown Source:5) at com.poupa.vinylmusicplayer.glide.audiocover.SongCoverFetcher.loadData(Unknown Source:47) at com.bumptech.glide.load.engine.SourceGenerator.startNextLoad(Unknown Source:15) at com.bumptech.glide.load.engine.SourceGenerator.startNext(Unknown Source:97) at com.bumptech.glide.load.engine.DecodeJob.runGenerators(Unknown Source:23) at com.bumptech.glide.load.engine.DecodeJob.runWrapped(Unknown Source:59) at com.bumptech.glide.load.engine.DecodeJob.run(Unknown Source:29) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1137) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:637) at java.lang.Thread.run(Thread.java:1012) at com.bumptech.glide.load.engine.executor.GlideExecutor$DefaultThreadFactory$1.run(Unknown Source:31) Caused by: android.system.ErrnoException: open failed: EACCES (Permission denied) at libcore.io.Linux.open(Native Method) at libcore.io.ForwardingOs.open(ForwardingOs.java:563) at libcore.io.BlockGuardOs.open(BlockGuardOs.java:274) at libcore.io.ForwardingOs.open(ForwardingOs.java:563) at android.app.ActivityThread$AndroidOs.open(ActivityThread.java:7810) at libcore.io.IoBridge.open(IoBridge.java:560) ... 13 more
After giving Vinyl access to my library directory, it still could not load any of my folder.jpg's.
But you do have the ability to browse through the songs, correct? Both in Library view and Folders view?
Thanks
After giving Vinyl access to my library directory, it still could not load any of my folder.jpg's.
But you do have the ability to browse through the songs, correct? Both in Library view and Folders view?
Thanks
I could already browse through songs in both Library and Folders views before I granted access to attempt to delete a song.
Tried 1.5.6, there are still some albums for which while cover loaded before, it doesn't load anymore.
If the logic to build covers cache have changed to add new ways, I'm wondering if it can somehow be a similar issue as experimented in https://github.com/chr56/Phonograph_Plus/issues/65.
If that's the case, that might also explain some performance issues as was experimented there. Since the issue began, since a couple of days I couldn't really use Vinyl anymore: it was trying to reindex songs and was not having any progress anymore, with mostly freezes. After some uninstall/reinstall of older/current releases, it looks like this is gone, but when reindexing every song and until it's done, interface stutter/freezes a lot and it creates many performances issues. Once finished (after several minutes, if not 15/20 minutes for 844 songs located on SD card), things get better (but maybe slightly worse than before, as noted in my previous comment for cover loading). Those performances issues could or not be related to this cover issue so hard to tell for now and open another issue.
Now, is there any way for us to provide more input and help solving this?
EDIT: Also, Artists view seems to not show any pictures anymore. That one might also be related to what we're talking about here so I might wait to open a new issue, unless you prefer those opened right away, even if these could be related issues.
Thanks Clément,
There is a known trouble where album cover art inside the album folder is not loaded (the EACCESS error mentioned in this thread). I'm looking into it when time allows.
To help, can you please isolate an album/a song that worked before but not in the 1.5.6 version and share it, so that I can have a look if I've overlooked anything?
For the artist cover, please open another issue.
It would be annoying to share for several reasons, but what they all seems to have in common is that the songs themselves doesn't have the cover in their metadata and have a cover as picture file in the folder (harder to notice though due to the limitations of scouring through MTP protocole, which is very limitative).
However some other albums also are having picture file in the folder and no issue with it. Most of those with the issue are flac files but not all of them, some others are mp3 so I don't think that's relevant information.
In the end, I guess that's the same issue you're already still looking into (that started with 1.5.3); also, all the songs are located on the SD card. Opening the issue for artists.
Hello, so I have a very large library of 6.5k songs, and this is all on the internal storage of my S22. every album folder has a "Folder.jpg" (or the occasional png). None of these load. There are a handful of songs with the album art embedded in the song, and those load just fine. I just upgraded to 1.5.6, and then noticed it was still not loading the album art. So I followed some advice I read earlier, and uninstalled/reinstalled.
After finishing the library scan, I attempted to delete a song and it triggered the storage request. I selected my root music folder. Still was not showing the album art, so I rescanned again. Still nothing.
java.io.FileNotFoundException: /storage/emulated/0/Music/Tool/ænima/folder.jpg: open failed: EACCES (Permission denied)
at libcore.io.IoBridge.open(IoBridge.java:574)
at java.io.FileInputStream.
I had this issue with version 1.5.5. I did "force stop", "clear cache", "clear storage", uninstall, reinstall, and the problem disappeared. I think previously i tried just "force stop", "clear cache", "clear storage" and that didn't help.
Also, at the time this cover image problem was happening, i was able to see all music in Library view, but nothing was visible in Folders view at all.
Hi, I was wondering what the status is on this issue. As far as I understand, the issue has been reproduced. What still needs to be done to fix it?