owntone / owntone-server

Linux/FreeBSD DAAP (iTunes) and MPD audio server with support for AirPlay 1 and 2 speakers (multiroom), Apple Remote (and compatibles), Chromecast, Spotify and internet radio.
https://owntone.github.io/owntone-server
GNU General Public License v2.0
2.1k stars 237 forks source link

No artwork in "Song View" in iOS Remote app #427

Closed tobx closed 7 years ago

tobx commented 7 years ago

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

img_3145-1

ejurgensen commented 7 years ago

This should work, so to find the problem I hope you are willing to help with some debug info:

  1. Set the log level to debug in /etc/forked-daapd.conf
  2. Restart forked-daapd and also Remote
  3. Start playback of some track where artwork doesn't show up

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.

ejurgensen commented 7 years ago

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.

tobx commented 7 years ago

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).

ejurgensen commented 7 years ago

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?

tobx commented 7 years ago

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?

ejurgensen commented 7 years ago

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).

ejurgensen commented 7 years ago

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.

tobx commented 7 years ago

Perfect, it works for me, thank you very much. I love this software, but one thing is missing: the donate button ;)

ejurgensen commented 7 years ago

Thanks! Your appreciation is donation enough for me!