core
core copied to clipboard
Unable to Play entire album from Media for dlna_dms
The problem
I have Jellyfin acting as a DLNA Server. I can see all my music from Media, but cannot play an entire album with a single click of Play button.
Instead the Album Art is displayed in a popup
What version of Home Assistant Core has the issue?
core-2024.2.5
What was the last working version of Home Assistant Core?
No response
What type of installation are you running?
Home Assistant OS
Integration causing the issue
dlna_dms
Link to integration documentation on our website
https://www.home-assistant.io/integrations/dlna_dms
Diagnostics information
2024-03-04 11:04:49.799 DEBUG (MainThread) [homeassistant.components.dlna_dms] Browsing for odroidhc4 / :7e64e319657a9516ec78490da03edccb 2024-03-04 11:04:49.799 DEBUG (MainThread) [homeassistant.components.dlna_dms] async_browse_media(:7e64e319657a9516ec78490da03edccb) 2024-03-04 11:04:51.815 DEBUG (MainThread) [homeassistant.components.dlna_dms] Browsing for odroidhc4 / :15bdd8077373199361fdda1cb2eade8a 2024-03-04 11:04:51.815 DEBUG (MainThread) [homeassistant.components.dlna_dms] async_browse_media(:15bdd8077373199361fdda1cb2eade8a) 2024-03-04 11:04:53.908 DEBUG (MainThread) [homeassistant.components.dlna_dms] async_resolve_media(:15bdd8077373199361fdda1cb2eade8a) 2024-03-04 11:04:53.972 DEBUG (MainThread) [homeassistant.components.dlna_dms] Resolved to url http://192.168.1.13:8096/Items/15bdd8077373199361fdda1cb2eade8a/Images/Primary/0/e349c225dd7c92c60939d49378045349/jpg/4096/4096/0/0 MIME image/jpeg
Example YAML snippet
No response
Anything in the logs that might be useful for us?
No response
Additional information
I'm calling this out as an issue with DLNA_DMS, but it could be an issue with the Media web interface.
Hey there @chishm, mind taking a look at this issue as it has been labeled with an integration (dlna_dms
) you are listed as a code owner for? Thanks!
Code owner commands
Code owners of dlna_dms
can trigger bot actions by commenting:
-
@home-assistant close
Closes the issue. -
@home-assistant rename Awesome new title
Renames the issue. -
@home-assistant reopen
Reopen the issue. -
@home-assistant unassign dlna_dms
Removes the current integration label and assignees on the issue, add the integration domain after the command. -
@home-assistant add-label needs-more-information
Add a label (needs-more-information, problem in dependency, problem in custom component) to the issue. -
@home-assistant remove-label needs-more-information
Remove a label (needs-more-information, problem in dependency, problem in custom component) on the issue.
(message by CodeOwnersMention)
dlna_dms documentation dlna_dms source (message by IssueLinks)
I would like to be able to play an entire album too. It seems a reasonable thing to do...
B.
I am also hitting this issue when trying to play an album to my Sonos speakers from a Jellyfin DLNA server. Playing individual files is fine, but playing an album gives a mime error in the sonos integration and this log. Ive seem some suggestion that whem playing an album, the integration sends the album art, so that may explain the mime error.
Logger: homeassistant.components.websocket_api.http.connection Source: components/websocket_api/commands.py:239 integration: Home Assistant WebSocket API (documentation, issues) First occurred: 19 April 2024 at 14:11:04 (7 occurrences) Last logged: 13:48:42
[140023695003712] Error calling SonosMediaPlayerEntity._play_media on media_player.living_room: UPnP Error 714 received: Illegal MIME-Type from 192.168.1.46 [140023671642560] Error calling SonosMediaPlayerEntity._play_media on media_player.living_room: UPnP Error 714 received: Illegal MIME-Type from 192.168.1.98 [140023684158656] Error calling SonosMediaPlayerEntity._play_media on media_player.living_room: UPnP Error 714 received: Illegal MIME-Type from 192.168.1.98 [140023674447040] Error calling SonosMediaPlayerEntity._play_media on media_player.living_room: UPnP Error 714 received: Illegal MIME-Type from 192.168.1.98 [140023718221248] Error calling SonosMediaPlayerEntity._play_media on media_player.living_room: UPnP Error 714 received: Illegal MIME-Type from 192.168.1.98 Traceback (most recent call last): File "/usr/src/homeassistant/homeassistant/components/sonos/helpers.py", line 63, in wrapper result = funct(self, *args, **kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/src/homeassistant/homeassistant/components/sonos/media_player.py", line 626, in _play_media soco.play_uri(media_id, force_radio=is_radio) File "/usr/local/lib/python3.12/site-packages/soco/core.py", line 148, in inner_function return function(self, *args, **kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.12/site-packages/soco/core.py", line 833, in play_uri self.avTransport.SetAVTransportURI( File "/usr/local/lib/python3.12/site-packages/soco/services.py", line 207, in _dispatcher return self.send_command(action, *args, **kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.12/site-packages/soco/services.py", line 515, in send_command self.handle_upnp_error(response.text) File "/usr/local/lib/python3.12/site-packages/soco/services.py", line 571, in handle_upnp_error raise SoCoUPnPException( soco.exceptions.SoCoUPnPException: UPnP Error 714 received: Illegal MIME-Type from 192.168.1.46
The above exception was the direct cause of the following exception:
Traceback (most recent call last): File "/usr/src/homeassistant/homeassistant/components/websocket_api/commands.py", line 239, in handle_call_service response = await hass.services.async_call( ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/src/homeassistant/homeassistant/core.py", line 2543, in async_call response_data = await coro ^^^^^^^^^^ File "/usr/src/homeassistant/homeassistant/core.py", line 2580, in _execute_service return await target(service_call) ^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 971, in entity_service_call single_response = await _handle_entity_call( ^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 1043, in _handle_entity_call result = await task ^^^^^^^^^^ File "/usr/src/homeassistant/homeassistant/components/sonos/media_player.py", line 543, in async_play_media await self.hass.async_add_executor_job( File "/usr/local/lib/python3.12/concurrent/futures/thread.py", line 58, in run result = self.fn(*self.args, **self.kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/src/homeassistant/homeassistant/components/sonos/helpers.py", line 77, in wrapper raise SonosUpdateError(message) from err homeassistant.components.sonos.exception.SonosUpdateError: Error calling SonosMediaPlayerEntity._play_media on media_player.living_room: UPnP Error 714 received: Illegal MIME-Type from 192.168.1.46
It seems to me that the whole idea of integrating dlna servers and renderers is pointless without an adequate dlna control point. I don't quite understand what the objective was for supporting dlna media in HA.
Well, its certainly a useful and appreciated feature to be able to control my speakers and play music without having to use yet another app.
If you can accept the limitations of playing one track at a time. For Dlna, the ideal control point IMO is Bubbleupnp
This is indeed a current limitation of Home Assistant, in combination with how DLNA works.
In DLNA terms, the musicAlbum
is a container for audioTrack
items. Each DLNA object (e.g. musicAlbum
or audioTrack
) is a piece of metadata that can have resources, res
, which point to the actual media/files. The musicAlbum
's resource is pointing to the cover art image, and that is what you are "playing": for @rwrozelle in the HA front end, and for @piggz on a Sonos speaker.
The way to play an album would be to iterate each of the musicAlbum
's children (audioTrack
s), adding their resources to the media player's queue. But HA doesn't currently have the concept of a media queue, and its metadata handling (e.g. track title) isn't ready for it either.
I started on the long journey of getting this going a while ago. But I got bogged down by countless bug reports of DLNA renderers where the manufacturer hadn't implemented the spec correctly, and I spent my time debugging and adding quirks to HA or the async-upnp support library.
@chishm thanks for the useful info and its good to know youre kinda looking at it. i wondered if it was possible to generate a playlist of tracks and send that to the speaker to play, which would save having to keep track of a media queue?
@chishm Thank you for responding. I can understand how difficult this is after doing some research. My goal here is to create a media player using ESPHome. The work that is here https://github.com/gnumpi/esphome_audio/tree/main is interesting in creating a Media Player in esp-idf using the esp-adf. I've been trying to customize that work to use a playlist file referencing a Webserver (no security) I have with my audio files (flac). So far it will play the first file in the playlist, but something goes wrong when it attempts to play the second file, so I'm still researching.
There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.
I'm not happy with it being marked stale. We still haven't had a response from the developers as to what is going to be done (if anything) to fix the problem. I can't see the point in providing any kind of DLNA support unless the equivalent of a control point is integrated into HA.
@chishm I've been thinking more about this issue. I think a workaround would be to create an m3u file on the fly with any audio file children (I think 1 level would be minimum viable; full tree search would be amazing). Place the file in a designated media server folder and send back that URL (with sigauth). Yes, the dlna_dms becomes dependent upon media folder existing, so crossing swim lanes, but it should work. If m3u exists, just use it. use same identity id as dlna identity id for the given folder when naming m3u. Populating the m3u accurately might require tinytag to be added.