MinimServer Forum

Full Version: Album Art Display on n-Stream
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2
Good afternoon,

Just a little note regarding the display of album art on the n-Stream App:

When browsing/scrolling through albums the cover art for some albums are shown with a noticeable delay only.

The delayed albums are not necessarily the last albums to appear in the view while scrolling. I am also pretty sure that this does not occur randomly e.g. late albums for one scroll are also late if the scroll is repeated another time.

Does anyone else have a similar experience?

MinimServer is running on a Qnap TS-419P+, the n-Stream App on an iPad mini
(01-05-2014 16:46)Fritz Wrote: [ -> ]Good afternoon,

Just a little note regarding the display of album art on the n-Stream App:

When browsing/scrolling through albums the cover art for some albums are shown with a noticeable delay only.

The delayed albums are not necessarily the last albums to appear in the view while scrolling. I am also pretty sure that this does not occur randomly e.g. late albums for one scroll are also late if the scroll is repeated another time.

Does anyone else have a similar experience?

MinimServer is running on a Qnap TS-419P+, the n-Stream App on an iPad mini

This is probably related to the size of the cover art images. MinimServer sends all images at full original resolution. Larger images take longer to send across the network and longer for the control point to process.
(01-05-2014 17:16)simoncn Wrote: [ -> ]
(01-05-2014 16:46)Fritz Wrote: [ -> ]Good afternoon,

Just a little note regarding the display of album art on the n-Stream App:

When browsing/scrolling through albums the cover art for some albums are shown with a noticeable delay only.

The delayed albums are not necessarily the last albums to appear in the view while scrolling. I am also pretty sure that this does not occur randomly e.g. late albums for one scroll are also late if the scroll is repeated another time.

Does anyone else have a similar experience?

MinimServer is running on a Qnap TS-419P+, the n-Stream App on an iPad mini

This is probably related to the size of the cover art images. MinimServer sends all images at full original resolution. Larger images take longer to send across the network and longer for the control point to process.

Thanks for the fast reply. Just checked. There are some examples where a large image (~ 300kb) is displayed instantly whereas the neighboring image (~60 kb) is slow. ... but may need to check precedence rules e.g. between embed images and accompanying images in folders.
"Double-checked" by applying the precedence rule from the User Guide (embedded image has precedence). There are examples like the one mentioned before of "larger" images being displayed instantaneously whereas "small" images are slow. Could this be related to the cache? Is there a way to influence the caching of cover art images?
(01-05-2014 18:48)Fritz Wrote: [ -> ]"Double-checked" by applying the precedence rule from the User Guide (embedded image has precedence). There are examples like the one mentioned before of "larger" images being displayed instantaneously whereas "small" images are slow. Could this be related to the cache? Is there a way to influence the caching of cover art images?

MinimServer doesn't cache cover art images. When the control point reads an image URL, MinimServer serves the bytes for the image from its original file location. If the image is embedded in an audio file, MinimServer seeks to the correct offset in the file to start reading the image bytes.

It is quite likely that n-Stream is doing some image caching, which might explain what you are seeing. Can you try clearing the n-Stream cache and then repeating the test?
(01-05-2014 16:46)Fritz Wrote: [ -> ]Good afternoon,

Just a little note regarding the display of album art on the n-Stream App:

When browsing/scrolling through albums the cover art for some albums are shown with a noticeable delay only.

The delayed albums are not necessarily the last albums to appear in the view while scrolling. I am also pretty sure that this does not occur randomly e.g. late albums for one scroll are also late if the scroll is repeated another time.

Does anyone else have a similar experience?

MinimServer is running on a Qnap TS-419P+, the n-Stream App on an iPad mini

Yes, it does this on mine too. Like you the image file size doesn't seem to matter as much as it might - some large ones display quickly, some small ones do not. All my files have cover art embedded in them. Sorry I can't be any more help.
This problem is due to nStream.

If the URI path is more than 256 characters it will not cache the image, but request it every time leading to a short delay. This was discussed in a thread I started last summer http://forum1613.minimserver.com/showthread.php?tid=607

Naim have never replied to any of my requests to remove the restrictions. I'm guessing they've done it thinking about windows similar restrictions, but as URI uses more characters for spaces and special characters, they are not the same.

I went through an exercise a while back to change all the folder paths which were too long - painful, but it did solve the problem.

Nick
(17-05-2014 09:08)stampie Wrote: [ -> ]This problem is due to nStream.

If the URI path is more than 256 characters it will not cache the image, but request it every time leading to a short delay. This was discussed in a thread I started last summer http://forum1613.minimserver.com/showthread.php?tid=607

Naim have never replied to any of my requests to remove the restrictions. I'm guessing they've done it thinking about windows similar restrictions, but as URI uses more characters for spaces and special characters, they are not the same.

I went through an exercise a while back to change all the folder paths which were too long - painful, but it did solve the problem.

Nick

Thanks for this information Nick - very useful to know.

Michael
Thanks is this a good lead. I took it from the discussion that the URI is derived from the file path of the first track of an album and checked some examples. The file path names (including the filename) of delayed album icons are around 200 characters, so below the limit you mention.

To further investigate it would be nice to know the relationship between the length of the URI and the length of the file pathname or if simpler to communicate how the URI is build. Simon, can you help?
(18-05-2014 21:50)Fritz Wrote: [ -> ]Thanks is this a good lead. I took it from the discussion that the URI is derived from the file path of the first track of an album and checked some examples. The file path names (including the filename) of delayed album icons are around 200 characters, so below the limit you mention.

To further investigate it would be nice to know the relationship between the length of the URI and the length of the file pathname or if simpler to communicate how the URI is build. Simon, can you help?

If you have Linn Kinsky for Windows, you can right-click on any track and click Details to see the URI for the audio data and the URI for the album art.

Here's an example from my own library of a URI for embedded album art:

http://192.168.0.10:9790/minimserver/*/music/musicfiles/CDGIM040/CDGIM040-08-Hei*20mihi,*20Domine.flac/$!picture-1096-16241.jpg

The file path contains two space characters that are expanded to the sequence *20 in the URI. This expansion of special characters can make the URI significantly longer than the file path in some cases.
Pages: 1 2
Reference URL's