Minidlna hangs due to picture/photo resize, DNS-323, Alt-F RC4

[Michael Roth]

First of all Alt-F is great stuff. Only due to Alt-F I still keep my "good old" DNS-323.

However, I have an issue with minidlna (currently 1.1.3 together with Alt-F RC4). Movies and Music are all fine. But if I want to see photos on a tablet or smartphone (e.g. with BubbleUPnP) minidlna starts additional processes which consume all the DNS-323 CPU (see attached JPG file with top-snapshot). 

The DNS-323 never returns from this state. It almost does not respond to anything. Even commands via telnet to kill the new minidlna processes take ages. 

Watching photos via a DLNA capable TV works (most of the time).

After some investigation I found via the minidlna debug options that minidlna tries to resize the pictures because BubbleUPnP (or any other Android UPnP player) requests it.

Here the line from the minidlna log after which the whole DNS-323 hangs: 

upnphttp.c:1654: info: Serving resized image for ObjectId: 19 [/mnt/md0/xxx/IMG_1111.JPG]

It is not the number of photos. For test purposes I gave minidlna only a few photos to scan. 

My questions:

1. Why does minidlna never finish resizing a photo?
   
2. If resizing can not be done on a DNS-323 (because of CPU power or so) how can I prevent resizing. I did not find appropriate options in minidlna.conf or as command line parameters.

Thanks in advance,

Michael

[João Cardoso]

On Saturday, September 27, 2014 10:25:32 PM UTC+1, Michael Roth wrote:

First of all Alt-F is great stuff. Only due to Alt-F I still keep my "good old" DNS-323.

However, I have an issue with minidlna (currently 1.1.3 together with Alt-F RC4). Movies and Music are all fine. But if I want to see photos on a tablet or smartphone (e.g. with BubbleUPnP) minidlna starts additional processes which consume all the DNS-323 CPU (see attached JPG file with top-snapshot). 

The DNS-323 never returns from this state. It almost does not respond to anything. Even commands via telnet to kill the new minidlna processes take ages. 

I glimpse  through minidlna code and found that it forks when an image resize is requested, thus the several minidlna child processes, and that every pixel of the image is (obviously) processed using expensive floating point operations (the box has no FPU), making these child processes consume so many CPU and memory.

The same kind of issue might happen if the client asks for the server to transcode movies or songs. I think that I have disabled transcoding in mediatomb and fuppes.

There is not much I can do.

Watching photos via a DLNA capable TV works (most of the time).

After some investigation I found via the minidlna debug options that minidlna tries to resize the pictures because BubbleUPnP (or any other Android UPnP player) requests it.

Here the line from the minidlna log after which the whole DNS-323 hangs: 

upnphttp.c:1654: info: Serving resized image for ObjectId: 19 [/mnt/md0/xxx/IMG_1111.JPG] 

It is not the number of photos. For test purposes I gave minidlna only a few photos to scan. 

Thanks for the research and info, it helped, I went directly to the "offending" function.

 

My questions:

1. Why does minidlna never finish resizing a photo?
   

above

 

2. If resizing can not be done on a DNS-323 (because of CPU power or so) how can I prevent resizing. I did not find appropriate options in minidlna.conf or as command line parameters.

better ask on a minidlna  forum... in any case I could apply a patch so that the server refuses to do the operation, but that would require some time, which I don't presently have.

Your best option is to disable that at the client side, or use another client.

PS- just looked at minidlna site and found a new version, filling a package request https://sourceforge.net/p/alt-f/packagerequest/35/

Thanks in advance,

Michael

[Michael Roth]

Thanks for the prompt reply João.

Your investigation shows that a patch preventing minidlna to do any re-sizing would be the best option. A different UPnP player is not an option. I tried all sorts of UPnP players on Android and Windows (incl. VNC and Windows Media Player). All of them request re-sizing from the server :-(  

I appreciate your efforts for a minidlna patch and also to adopt the new version of minidlna in an updated package.

Thanks,

Michael

On Sunday, September 28, 2014 6:16:35 PM UTC+2, João Cardoso wrote:

On Saturday, September 27, 2014 10:25:32 PM UTC+1, Michael Roth wrote:

First of all Alt-F is great stuff. Only due to Alt-F I still keep my "good old" DNS-323.

However, I have an issue with minidlna (currently 1.1.3 together with Alt-F RC4). Movies and Music are all fine. But if I want to see photos on a tablet or smartphone (e.g. with BubbleUPnP) minidlna starts additional processes which consume all the DNS-323 CPU (see attached JPG file with top-snapshot). 

The DNS-323 never returns from this state. It almost does not respond to anything. Even commands via telnet to kill the new minidlna processes take ages. 

I glimpse  through minidlna code and found that it forks when an image resize is requested, thus the several minidlna child processes, and that every pixel of the image is (obviously) processed using expensive floating point operations (the box has no FPU), making these child processes consume so many CPU and memory.

The same kind of issue might happen if the client asks for the server to transcode movies or songs. I think that I have disabled transcoding in mediatomb and fuppes.

There is not much I can do.

Watching photos via a DLNA capable TV works (most of the time).

After some investigation I found via the minidlna debug options that minidlna tries to resize the pictures because BubbleUPnP (or any other Android UPnP player) requests it.

Here the line from the minidlna log after which the whole DNS-323 hangs: 

upnphttp.c:1654: info: Serving resized image for ObjectId: 19 [/mnt/md0/xxx/IMG_1111.JPG] 

It is not the number of photos. For test purposes I gave minidlna only a few photos to scan. 

Thanks for the research and info, it helped, I went directly to the "offending" function.

 

My questions:

1. Why does minidlna never finish resizing a photo?
   

above

 

2. If resizing can not be done on a DNS-323 (because of CPU power or so) how can I prevent resizing. I did not find appropriate options in minidlna.conf or as command line parameters.

better ask on a minidlna  forum... in any case I could apply a patch so that the server refuses to do the operation, but that would require some time, which I don't presently have.