Sonos UPnP Error 714 received: Illegal MIME-Type

Configuration
1

I am trying to play an audiobook file via the media_player.play_media service to one of my sonos speakers. The source is from my audiobookshelf server, and I have extracted the correct URL and token required to pull just the audio file from the audiobookshelf server. When attempting to run the service call, I get the dreaded Illegal MIME-Type error.

I am unsure what to do, as I have tested the URL in a new incognito browser window (to verify the authorisation token is accepted) and it pops up with the audio file playing no problems. Playing the audio file locally via the x-file-cifs:// command works for the exact same file, so I know the sonos speakers can play it. How do I structure my media player call to allow sonos to stream from my audiobookshelf server?

Thanks!

service call:

service: media_player.play_media
target:
  entity_id: media_player.living_room
data:
  media_content_type: music
  media_content_id: >-
    https://audiobook.EXAMPLE.COM/api/items/91f4e8e8-1add-42c6-bf7a-e3481fbf1a77/file/8320?token=APITOKEN
2

MIME-types is a tag that says something about the format of the file, so maybe it is not music as content type.

3

Thanks for the thoughts @WallyR

Given that the exact same file plays ok when referenced via the x-file-cifs:// method (with music as the type), I’m less inclined to think that the MIME type itself is the issue, and that there is something else going on? :thinking:

4

Hello MrSir,

I agree that it doesn’t like the file.
Some things are true whether you believe them or not.
Try other types (words).
Maybe “audio/mp3”

5

That doesn’t work either, unfortunately…

2024-08-24 20:38:15.093 ERROR (SyncWorker_53) [homeassistant.components.sonos.media_player] Sonos does not support a media type of "audio/mp3"
2024-08-24 20:38:30.380 ERROR (SyncWorker_30) [homeassistant.components.sonos.media_player] Sonos does not support a media type of "audio"

All other automations/service calls I have with my sonos speakers use ‘music’ as the content type

6

Maybe this can help.

7

Thanks WallyR - after a couple of hours of playing around still no luck on that one. Troubleshooting this is proving a real challenge :sweat_smile:

8

ok so interestingly, it doesn’t seem to check the MIME-Type of the actual file/link, as a packet capture shows that it never even attempts to contact the link in the media_content_id to determine the MIME-Type. So something in the service call itself must be tripping the MIME-Type error??

10.32.0.33 = HomeAssistant
10.50.0.62 = Sonos Arc
10.32.0.41 = Audiobookshelf (which isn’t contacted per the packet log below - even when using the direct IP address instead of domain. I’ve confirmed that the firewall is wide open here, so it is not blocking anything).
image

That is from a service call as below (with or without leading http:// has been tested):

service: media_player.play_media
data:
  media_content_type: music
  media_content_id: '10.32.0.41/api/items/91f4e8e8-1add-42c6-bf7a-e3481fbf1a77/file/8320?token=TOKEN'
target:
  entity_id: media_player.living_room

@jjlawren sorry to tag you in this, but I think you’ll know the most about how it all works! Any ideas? :slight_smile:

9

Whilst the above still seems to be problematic, I found a way to work around the problem with the following:

media_content_id: 'x-rincon-mp3radio://http://10.32.0.41/hls/d74b3bb6-526d-45a8-ad52-1adb13754aae/output.m3u8?token=TOKEN'

Audiobookshelf has the option to return an m3u8 playlist as a hls stream (as I just discovered when poking around the API), which allows sonos to connect to it as if it were a radio stream.

Whilst this solves my immediate problem, I still don’t understand why the invalid MIME-Type error is reported against a url without sonos even checking what the MIME-Type is… :thinking:

1 Like
10

Did you ever find a solution to this??? I am having a similar problem but with HA Cloud and TTS (not using the tts.speak option)

11

No, sorry. Sonos eventually updated their dumpster fire of an app and allowed me to add direct connections to my NAS again - so that’s my final-state solution (despite it not really being relevant to the topic above as that was more of a workaround than anything else)