[Android Apps and Games] xyzzy42:
Not getting largest album art size

BubbleUPnP isn't requesting the largest size album art that it could from the library. It seems like this would be better to request the largest one, up to the display resolution available for where it's used.

I'm using a patched MiniDLNA that supports multiple album art image sizes. Which could of course be the problem, but I've traced the exchange and it looks like the server is fine and BubbleUPnP is the one that's requesting the smaller size. The server is supplying three sizes, JPEG_TN, JPEG_SM, and JPEG_MED. The last is the largest, but BubbleUPnP requests the JPEG_SM sized image. JPEG_SM is only up to 640x480, while my device is 1920x1080 and so could display a larger image.

Here's the metadata exchange, with multiple album art images. I had to replace "http" with "xxxx" to be allowed to post it.

POST /ctl/ContentDir HTTP/1.1
Content-type: text/xml;charset=utf-8
Soapaction: "urn:schemas-upnp-org:service:ContentDirectory:1#Browse"
Content-Length: 471
Host: 192.168.0.9:8200
Connection: Keep-Alive
User-Agent: Android/4.4.4 UPnP/1.0 BubbleUPnP/2.8.6

<?xml version="1.0" encoding="utf-8" standalone="yes"?><s:Envelope s:encodingStyle="xxxx://schemas.xmlsoap.org/soap/encoding/" xmlns:s="xxxx://schemas.xmlsoap.org/soap/envelope/"><s:Body><u:Browse xmlns:u="urn:schemas-upnp-org:service:ContentDirectory:1"><ObjectID>1$7</ObjectID><BrowseFlag>BrowseDirectChildren</BrowseFlag><Filter>*</Filter><StartingIndex>0</StartingIndex><RequestedCount>16</RequestedCount><SortCriteria></SortCriteria></u:Browse></s:Body></s:Envelope>HTTP/1.1 200 OK
Content-Type: text/xml; charset="utf-8"
Connection: close
Content-Length: 1528
Server: 4.2.0-35-generic DLNADOC/1.50 UPnP/1.0 MiniDLNA/1.1.5
Date: Mon, 23 Jan 2017 06:53:02 GMT
EXT:

<?xml version="1.0" encoding="utf-8"?>
<s:Envelope xmlns:s="xxxx://schemas.xmlsoap.org/soap/envelope/" s:encodingStyle="xxxx://schemas.xmlsoap.org/soap/encoding/"><s:Body><u:BrowseResponse xmlns:u="urn:schemas-upnp-org:service:ContentDirectory:1"><Result><DIDL-Lite xmlns:dc="xxxx://purl.org/dc/elements/1.1/" xmlns:upnp="urn:schemas-upnp-org:metadata-1-0/upnp/" xmlns="urn:schemas-upnp-org:metadata-1-0/DIDL-Lite/" xmlns:dlna="urn:schemas-dlna-org:metadata-1-0/">
<container id="1$7$0" parentID="1$7" restricted="1" searchable="1" childCount="1"><dc:title>Fleet Foxes</dc:title><upnp:class>object.container.album.musicAlbum</upnp:class><upnp:storageUsed>-1</upnp:storageUsed><dc:creator>Fleet Foxes</dc:creator><upnp:genre>Folk</upnp:genre><upnp:artist>Fleet Foxes</upnp:artist><upnp:albumArtURI dlna:profileID="JPEG_TN" xmlns:dlna="urn:schemas-dlna-org:metadata-1-0/">xxxx://192.168.0.9:8200/AlbumArt/2-0.jpg</upnp:albumArtURI><upnp:albumArtURI dlna:profileID="JPEG_SM" xmlns:dlna="urn:schemas-dlna-org:metadata-1-0/">xxxx://192.168.0.9:8200/AlbumArt/2-1.jpg</upnp:albumArtURI><upnp:albumArtURI dlna:profileID="JPEG_MED" xmlns:dlna="urn:schemas-dlna-org:metadata-1-0/">xxxx://192.168.0.9:8200/AlbumArt/2-2.jpg</upnp:albumArtURI></container></DIDL-Lite></Result>
<NumberReturned>1</NumberReturned>
<TotalMatches>1</TotalMatches>
<UpdateID>1</UpdateID></u:BrowseResponse></s:Body></s:Envelope>

And just the albumArtURI section:

<upnp:albumArtURI dlna:profileID="JPEG_TN" xmlns:dlna="urn:schemas-dlna-org:metadata-1-0/">xxxx://192.168.0.9:8200/AlbumArt/2-0.jpg</upnp:albumArtURI><upnp:albumArtURI dlna:profileID="JPEG_SM" xmlns:dlna="urn:schemas-dlna-org:metadata-1-0/">xxxx://192.168.0.9:8200/AlbumArt/2-1.jpg</upnp:albumArtURI><upnp:albumArtURI dlna:profileID="JPEG_MED" xmlns:dlna="urn:schemas-dlna-org:metadata-1-0/">xxxx://192.168.0.9:8200/AlbumArt/2-2.jpg</upnp:albumArtURI>

Initially, from the library view only the JPEG_TN sized 2-0.jpg is requested. Upon selecting "show cover" from the metadata view, BubbleUPnP requests "xxxx://192.168.0.9:8200/AlbumArt/2-1.jpg". I'd have expected it to request the "JPEG_MED" size file "2-2.jpg" instead.

It actually requests the JPEG file twice (bug?). The first time it gets 107153 bytes and then closes the socket (TCP RST from bubbleuPNP side), requests the same image 25 ms later, and this time receives all 157075 bytes. This abort and retry seems pretty consistent.