ArtWork Issues!!
Beantwortet
I am running BluOS on a Windows Desktop and have a terrible time with images. I have built a jpeg template to provide cover art for many albums without covers. The dummy image loads fine so I know it works. But if I add text to identify the album, BluOS fails 80% of the time. The system reverts to the template, even though the template is no longer in the folder. I have done all the recommended processes: re-indexed, reloaded artwork, rebuild the index via Diagnotics 5 times. Nothing works. Each folder has "cover" and "folder" jpg with the same image. There are no layers in any of the image files. All images are correctly sized. I think BluOS is drawing images from a cache, but rebuilding the index has no effect. The images all work fine in Music Bee. How do I solve this???
-
Offizieller Kommentar
folder.jpg or cover.jpg, not both. (Remove one of them) and rebuild index.
If that don't help, try deleting the content in: C:\Users\your_user_name\AppData\Roaming\BluOS Controller\Cache (make sure BluOS Controller is closed before doing that)
-
Also having the same problem now. But it's with the playlists.
For some reason starting today, none of the playlists show any kind of artwork, although they always have.
I've indexed the music shares a few times, restarted the server the music is on plus restarted the speakers.
0 -
Hi Anthony
In the App, select Settings, Reload Artwork to refresh the artwork cache on your handheld device.
If problems persist, Help[, Send Support Request in the App.
0 -
After a few index changes and refreshes, the artwork started coming through again and it looks normal.
I can't figure out my playlists, though, and it has more to do with the m3u playlists that are in music folders. Usually I just deal with playlists I create in the Bluesound app, but I've started looking at the rest of the playlists recently.
I started out with about 40 m3u playlists, deleted some and renamed some others for consistency. Also created some new ones using VLC player. All of the m3u playlists are in the root directories of the music files/ albums.
Although a majority of the old/ new playlists do show up in the app, a lot of them do not. I thought after going to reindex a few times, they would start showing up, but they do not. Is there a trick to getting m3u playlists to show up? I can't figure it out.
Thanks.
0 -
Make sure your playlist(s) have the "relative path" to the music files.
If there is an "error" in the path your playlist will not be imported.
Example:
S-U\Tales Of Evening\2019 - A New Dawn Awaits - {FLAC}\Track02.flac
D-F\Follow The Cipher\2018 - Follow The Cipher (Digipak) - {FLAC}\Track04.flac
A-C\Cindy Blackman Santana - 2020 - Give The Drummer Some - {FLAC}\Track01.flac
A-C\Alan Walker\Single, EP\2019 - Are You Lonely (Single) - {FLAC}\Track01.flac0 -
The playlist issues seemed to have more to do with VLC than anything else.
VLC saves the path names with %20 in for the spaces, and I can't find a way around it. I used an mp3 tagging app to create the m3u files and it works fine now.
1 -
I am having the same difficulty. I am using MusicBrainz Picard on a Mac mini to edit the metadata. The cover art is embedded in the metadata, but i cant figure out how to delete the existing cover art.
0 -
If that don't help, try deleting the content in: C:\Users\your_user_name\AppData\Roaming\BluOS Controller\Cache (make sure BluOS Controller is closed before doing that)
Yes! That sorted out some very odd issues I was getting. Is there an existing feature request / bug raised regarding this? I'm not sure what "Reload Artwork" even does if you need to go clear a cache folder manually to actually reload it. It'd certainly be handy (if not essential) if it cleared the folder for you when you click this button.
folder.jpg or cover.jpg, not both. (Remove one of them) and rebuild index.
That bit doesn't seem to matter any more - I thought it was my problem as I often have both (high quality cover.jpg from Bandcamp, low quality folder.jpg I've added myself for BluOS), so I was about to raise a ticket asking to change this behaviour, but it turns out to have just been the caching controller-side that was causing problems.
0
Bitte melden Sie sich an, um einen Kommentar zu hinterlassen.
Kommentare
8 Kommentare