postlund
commented
3 years ago Most definitely! I only took the basic parts to the going, but it would be great to send more stuff. tinytag actually looks pretty good, I might consider switching to it. I like that it's very minimalistic. When looking at this I realize that I'm doing I/O in the event loop as I'm loading metadata (and the audio file as well) without sending it of to an executor. That is typically very bad and another bug I need write...
Not all devices do, the AirPort Express for instance only supports progress and gets mad if you send metadata to it. I've tried 😉 I check that the device supports metadata before sending it nowadays, so it should be ok:
audio-metadata actually supports images as well and it seems to be able to extract mime-type for most file formats as well. So I think it is good enough to use for pyatv. Most file formats just use a magic at the beginning of the file, so it would probably not be that hard to support the most common formats if doing it manually. But as mentioned, I think audio-metadata should work fine and it's probably quite easy to implement. Almost like it's time to collect a few demo files that can be used for testing. I don't have that many audio files laying around, especially not with artwork.
What feature would you like? Currently only the title, artist and album are send. It would be nice to also send the artwork, genre, year, track number and total number of tracks. I think at least the Apple TV displays some of the informations.
Describe the solution you'd like All devices should support receiving the artwork even if they don't have a way to display it. Nevertheless one could check the "md" txt record of the corresponding service to see if sending the artwork is supported. If this is the case a SET_PARAMETER request should be enough to send the artwork. I'm not sure if
audio-metadatacan extract the artwork of a file. If notTinyTagis well maintained, supports various file formats and allows extracting all of the information listed above. Furthermore the image MIME type needs to be set as the content-type in the RTSP request. I'm not sure if the content-type is really used by the receiver to display the image. If this is not the case one could hardcode it to be something likeimage/png. If it is requiredpython-magiccould be used to extract it from the raw image data. A hybrid approach such as: use python-magic to guess the MIME type if available, otherwise fallback toimage/pngcould be used as well. I don't know how hard it is to guess the MIME type of an image. Maybe a couple lines of python are enough to implemented it. This would be the best case scenario.