Not extracting images from m4a files when scanning about mopidy-local

[kingosticks]

Mopidy-local relies on metadata extraction provided by Mopidy Core (using Gstreamer) so it's more likely to be an issue there. Before we move it, can you provide output for the commands at https://docs.mopidy.com/en/develop/troubleshooting/#track-metadata

❯ python3 -m mopidy.audio.scan ~/Music/Summrs/Evolved/03\ -\ RIP\ Sketchy.m4a
2021-02-21 13:04:02,598 TRACE element decodebin0: have-audio;
2021-02-21 13:04:02,599 TRACE element fakesink0: GstMessageTag, taglist=(taglist)"taglist\,\ audio-codec\=\(string\)\"MPEG-4\\...
2021-02-21 13:04:02,603 TRACE element fakesink0: GstMessageTag, taglist=(taglist)"taglist\,\ title\=\(string\)\"RIP\\\ Sketchy...
2021-02-21 13:04:02,603 TRACE element fakesink0: GstMessageTag, taglist=(taglist)"taglist\,\ audio-codec\=\(string\)\"MPEG-4\\...
2021-02-21 13:04:02,603 TRACE element pipeline0: GstMessageAsyncDone, running-time=(guint64)18446744073709551615;
uri                    file:///home/lol/Music/Summrs/Evolved/03%20-%20RIP%20Sketchy.m4a
mime                   None
duration               105513
playable               True
seekable               True
tags
audio-codec            ['MPEG-4 AAC']
maximum-bitrate        [320066]
bitrate                [320066]
title                  ['RIP Sketchy']
artist                 ['Summrs']
album-artist           ['Summrs']
album                  ['Evolvеd']
datetime               ['2019']
date                   ['2019-01-01']
encoder                ['Lavf58.20.100']
track-number           [3]
genre                  ['Hip-Hop/Rap']
image                  [b'\xff\xd8\xff\xe0\x00\x10JFIF\x00\x01\x01\x00\x00\x0...
private-qt-tag         [b'\x00\x00\x00\x19rtng\x00\x00\x00\x11data\x00\x00\x0...
container-format       ['ISO MP4/M4A']

❯ gst-discoverer-1.0 ~/Music/Summrs/Evolved/03\ -\ RIP\ Sketchy.m4a 
Analyzing file:///home/lol/Music/Summrs/Evolved/03%20-%20RIP%20Sketchy.m4a
Done discovering file:///home/lol/Music/Summrs/Evolved/03%20-%20RIP%20Sketchy.m4a

Properties:
  Duration: 0:01:45.513000000
  Seekable: yes
  Live: no
  container: MPEG-4 AAC
    audio: MPEG-4 AAC
      Stream ID: cd59305061788fd2c1a34623ed7a76b58bb8e6f56cccc9907398ea84fd022c5b/001
      Language: <unknown>
      Channels: 2 (front-left, front-right)
      Sample rate: 44100
      Depth: 32
      Bitrate: 320066
      Max bitrate: 320066

[kingosticks]

The one you have posted looks absolutely fine and I cannot understand why imghdr would have any problem identifying that's a jpeg. But that isn't the same file as the one in your original post. Can you share the output from that one?

My bad. Here you go.

~ 
❯ gst-discoverer-1.0 ~/Music/MDMA/Genie\ \(Deluxe\)/01\ Xccelerate.m4a 
Analyzing file:///home/lol/Music/MDMA/Genie%20(Deluxe)/01%20Xccelerate.m4a
Done discovering file:///home/lol/Music/MDMA/Genie%20(Deluxe)/01%20Xccelerate.m4a

Properties:
  Duration: 0:02:49.906000000
  Seekable: yes
  Live: no
  container: MPEG-4 AAC
    audio: Apple Lossless Audio (ALAC)
      Stream ID: bcbed18d3e6429e9737954742553b084a745a026bfa11eb97cd703679280d360/001
      Language: <unknown>
      Channels: 2 (front-left, front-right)
      Sample rate: 44100
      Depth: 16
      Bitrate: 909001
      Max bitrate: 0


~ 
❯ python3 -m mopidy.audio.scan ~/Music/MDMA/Genie\ \(Deluxe\)/01\ Xccelerate.m4a 
2021-02-23 14:33:19,801 TRACE element decodebin0: have-audio;
2021-02-23 14:33:19,802 TRACE element fakesink0: GstMessageTag, taglist=(taglist)"taglist\,\ audio-codec\=\(string\)\"Apple\\\...
2021-02-23 14:33:20,190 TRACE element fakesink0: GstMessageTag, taglist=(taglist)"taglist\,\ title\=\(string\)Xccelerate\,\ ar...
2021-02-23 14:33:20,192 TRACE element pipeline0: GstMessageAsyncDone, running-time=(guint64)18446744073
709551615;
uri                    file:///home/lol/Music/MDMA/Genie%20%28Deluxe%29/01%20Xccelerate.m4a
mime                   None
duration               169906
playable               True
seekable               True
tags
audio-codec            ['Apple lossless audio']
bitrate                [909001]
title                  ['Xccelerate']
artist                 ['MDMA']
album-artist           ['MDMA']
album                  ['Genie (Deluxe)']
datetime               ['2020']
date                   ['2020-01-01']
encoder                ['Lavf57.71.100']
track-number           [1]
genre                  ['Hip-Hop/Rap']
image                  [b'\xff\xd8\xff\xe1\tPhttp://ns.adobe.com/xap/1.0/\x00...
private-qt-tag         [b'\x00\x00\x00\x19rtng\x00\x00\x00\x11data\x00\x00\x0...
container-format       ['ISO MP4/M4A']

[kingosticks]

No worries. So we can see the jpeg header (0xff 0xe1) but imghdr is really basic/strict, and doesn't support Adobe's XMP format that's used here. We can't read this artwork format, even if it is in a valid format.

well thats unfortunate. i guess i just have to replace the images for any files using that artwork format?

[adamcik]

In theory one could feed the image data into gstreamer and let it figure out identifying it, but that would require some one to go through the required code changes and wiring it all up with an appsrc to feed in the image data. Or one could find something else with better support than imghdr.

[kingosticks]

It looks like we can also fixup imghdr to be more accommodating quite easily, like they did at wagtail/Willow@1592781

[kingosticks]

@Nameless1337 can you try the branch at https://github.com/kingosticks/mopidy-local/tree/fix/jpeg-detection ?

I don't get any "Unknown image type" errors anymore but I'm still missing some albums in my ncmpcpp media library that play fine in the filesystem browser, like this track for example ~/Music/Summrs/Evolved/03\ -\ RIP\ Sketchy.m4a
Considering that track has a proper jpeg header, I'm guessing this issue is unrelated.

[kingosticks]

Could you open a new issue with the portion of the debug log showing that file being scanned and then added to the database?