Closed tobx closed 7 years ago
This should work, so to find the problem I hope you are willing to help with some debug info:
Now copy /var/log/forked-daapd.log and find the artwork request from Remote. It will be a line with "DACP request" and the request should contain "nowplayingartwork". After that there should be a bunch lines with "artwork:" and maybe also some with "cache:". Please post all those lines.
BTW, please check that you actually have embedded artwork in the now playing file. You can do that with "avprobe [file]" or "ffprobe [file]".
If you see artwork in the album/artist views, but not for the now playing file, it could be because another file in the album has the embedded artwork.
Thank you for the fast help. First off the output of the ffprobe command for the Rehab mp3 file includes the following relevant part:
Stream #0:1: Video: png, rgb24(pc), 500x500, 90k tbr, 90k tbn, 90k tbc
Now I followed the log output with tail
and in Open Artist.log you see the artwork request (that was successfully showing the album art for album in Remote).
Then I tapped on the Rehab song and after some lines found the following:
[2017-10-26 09:02:50] [DEBUG] player: Start playback of '/mnt/NAS/Amy Winehouse/Back To Black/01 Rehab.mp3' (id=8791, item-id=1)
After some more ffmpeg/audio logs you can find the first artwork request and the following lines in
the Play Song.log (that was not showing the album art for the song in Remote).
Strange, the log says that artwork was found in the cache. Could you try to stop forked-daapd and Remote, delete the cache (the /var/cache/forked-daapd/cache.db file), and then restart everything?
I emptied the cache, but that seems not to be the problem.
After some more testing, I found that some covers do load in the song view (all covers are working in artist or album view, but only some are working in the song view). So I analyzed the difference between working and non working files (ffprobe) and the only thing I found was the cover size.
Then I generated two equal audio files (just 10 seconds of silence) and created two jpg covers, one with size 500x500 and one with size 1000x1000 (mp3_files.zip). I added both to my library and guess what, the 1000x1000 cover was loading and the 500x500 was not.
Here are the log files from both files loading: Big Cover.log Small Cover.log
The only differences that I can spot is that it reduces the size of the big cover to 750x750, but does not try to enlarge the small one, what do you think?
Wow, excellent work, I think you are definitely on to something. Seems that the covers that are being scaled down by forked-daapd work, while those that are just passed directly to Remote do not work. I will test this myself later. Might be a general problem with the pass-through functionality, or it could be because the source image is in a format that Remote doesn't like (doesn't seem very likely, but let's see).
I believe the issue is now fixed. The problem was from a change I made a while ago (but after release 25.0). It meant that when no rescaling was required, the mp3 file was sent as artwork (as opposed to sending the embedded image in the mp3 file).
Thanks for reporting, and let me know if you run into other problems.
Perfect, it works for me, thank you very much. I love this software, but one thing is missing: the donate button ;)
Thanks! Your appreciation is donation enough for me!
Hi,
I see no artwork in the "Song View" in the iOS Remote app (see screenshot). I do see the cover art in the artist and album views. My cover art is embedded in the songs only (every song in an album has the same album cover embedded).
I tried to put a jpg file in the album folder instead and this worked without issues.
I am using iOS 11.03