thumbnails not working with minidlna on debian/unstable

[xenogenesi]

Thanks for this app, I'm using it a lot with a synology nas and a debian/sid desktop and it works great.

About the small issue I'm having with minidlna and thumbnails:

with the synology dlna server I just put a jpg image with the same name of a video and the thumbnail is shown correctly in the directory listing (test.mp4 -> test.jpg)

on the debian server instead I'm using the minidlna package, lightweight and easy to setup, for my understanding it should support thumbnails (not sure but maybe the inotify option need to be enabled), it looks for basename + .cover.jpg (test.mp4 -> test.mp4.cover.jpg), if the .cover.jpg file exists it is indexed into a sqlite3 db (/var/cache/minidlna/files.db) table ALBUM_ART

select * from ALBUM_ART ;
1|/var/cache/minidlna/art_cache/var/lib/minidlna/test.mp4.cover.jpg

I captured a directory listing (below) and the thumbnail is listed and published correctly, I think the issue is something similar to one already fixed (https://github.com/KernelCrap/android-dlna/pull/8/commits/838069b32c21be06fe88b18a8c20b028e7ddd5c8) but I'm not upnp expert, don't know how to fix this one yet, any suggestion where to look?

Thanks in advance

<?xml version="1.0" encoding="utf-8"?>
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"><s:Body><u:BrowseResponse xmlns:u="urn:schemas-upnp-org:service:ContentDirectory:1"><Result>&lt;DIDL-Lite xmlns:dc="http://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/"&gt;
&lt;item id="2$8$0" parentID="2$8" restricted="1" refID="64$1"&gt;&lt;dc:title&gt;test&lt;/dc:title&gt;&lt;upnp:class&gt;object.item.videoItem&lt;/upnp:class&gt;&lt;dc:date&gt;2014-11-04T04:37:50&lt;/dc:date&gt;&lt;res size="19096399" duration="0:00:46.022" bitrate="414940" sampleFrequency="44100" nrAudioChannels="2" resolution="1920x1080" protocolInfo="http-get:*:video/mp4:DLNA.ORG_PN=AVC_MP4_HP_HD_AAC;DLNA.ORG_OP=01;DLNA.ORG_CI=0;DLNA.ORG_FLAGS=01700000000000000000000000000000"&gt;http://192.168.2.210:8200/MediaItems/23.mp4&lt;/res&gt;&lt;res protocolInfo="http-get:*:image/jpeg:DLNA.ORG_PN=JPEG_TN"&gt;http://192.168.2.210:8200/AlbumArt/1-23.jpg&lt;/res&gt;&lt;/item&gt;&lt;/DIDL-Lite&gt;</Result>
<NumberReturned>1</NumberReturned>
<TotalMatches>1</TotalMatches>
<UpdateID>0</UpdateID></u:BrowseResponse></s:Body></s:Envelope>

edit

apparently minidlna pass the thumbnail as a resource (the second, the first is the video) not as a property, I got it working by adding one more fallback within createItemModel(), but I really don't know much about upnp and I don't think that's an optimal solution:

if (usableIcon == null) {
    for (Res res: item.getResources()) {
        String resValue = res.getValue();
        if (resValue.endsWith(".jpg")) {
            itemModel.setIconUrl(resValue);
            break;
        }
    }
}

[KernelCrap]

Sorry for the late answer - Unfortunately I don't have a lot of time to work on this project anymore.

Great detective work on finding the cause of the issue, but I don't like the solution of setting the first jpeg image found in the resources as the icon url.

Currently the app assumes that each UPnP item only contains a single resource (the media), so depending on the sorting of the resources, the media might not play as expected (the app plays the first resource).

Since an image is not presented by the server using the "ALBUM_ART_URI" or "ICON" property (as other UPnP servers do) I don't consider this an issue with the app.

Based on your findings, I don't see a proper solution for this issue (maybe MiniDLNA can be tweaked to use one of the supported properties for the image - I don't know).

I will leave this issue open for a while incase you or someone else have further comments.

[xenogenesi]

Thanks for replying and for leaving the issue open, I'm using the patch and it is working but I don't like it either.