Post Reply 
 
Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
No artwork
27-11-2012, 16:47
Post: #21
RE: No artwork
(27-11-2012 16:10)Crom Wrote:  I've mailed 'em...let's see if we get a response ;-)

Well, the cynic in me didn't expect a response, let alone one within 30 minutes!! My faith is restored! Does this mean that we should get the bug fixed before the end of the week though? ;-)

Naim's response went as follows:

"Thankyou for your feedback – we have had this issue reported when used with MinimServer and it has been logged for resolution."
Find all posts by this user
Quote this message in a reply
29-11-2012, 12:40
Post: #22
RE: No artwork
I tried to make the point that this is our only option for Transcoding on the Mac so hopefully it will help. I think it makes a big difference as the Naim streamers are optimised for WAV as this is what their hardware servers (HDX, UnitiServe) use
Find all posts by this user
Quote this message in a reply
29-11-2012, 13:52
Post: #23
RE: No artwork
This seems fairly promising so far.

How frequently do Naim release software updates?
Find all posts by this user
Quote this message in a reply
21-02-2013, 17:08
Post: #24
RE: No artwork
I've got a test build that should fix the problems caused by the Naim software handling some special characters incorrectly. If anyone would like to try this, please send me a PM saying whch platform you are using to run MinimServer.
Find all posts by this user
Quote this message in a reply
21-02-2013, 17:19
Post: #25
RE: No artwork
@bubbleguum

(22-11-2012 00:40)bubbleguuum Wrote:  Gzip+base64 is a good idea as it is decodable to the original string.

I tried this. The zlib compression actually increases URL length, with base64 expanding it even more.

Instead, I've decided to use an alternative encoding for special characters. For example, instead of encoding a space as '%20', I'm encoding it as '*20'. The '*' character is unreserved in URLs, and I'm hoping that the buggy control points and renderers will treat it as a normal character and pass it through unchanged.

This approach preserves URL readability, doesn't expand URL length, and doesn't require external persistent storage.
Find all posts by this user
Quote this message in a reply
22-02-2013, 11:14 (This post was last modified: 22-02-2013 11:15 by bubbleguuum.)
Post: #26
RE: No artwork
(21-02-2013 17:19)simoncn Wrote:  @bubbleguum

(22-11-2012 00:40)bubbleguuum Wrote:  Gzip+base64 is a good idea as it is decodable to the original string.

I tried this. The zlib compression actually increases URL length, with base64 expanding it even more.

Instead, I've decided to use an alternative encoding for special characters. For example, instead of encoding a space as '%20', I'm encoding it as '*20'. The '*' character is unreserved in URLs, and I'm hoping that the buggy control points and renderers will treat it as a normal character and pass it through unchanged.

This approach preserves URL readability, doesn't expand URL length, and doesn't require external persistent storage.

That's fine if you can find an alternate scheme.

In my experience, URL length and readability doesn't matter much.
You have not seen Google Music streaming URLs, which are super long and unreadable =).
Find all posts by this user
Quote this message in a reply
Post Reply 


Forum Jump:


User(s) browsing this thread: 2 Guest(s)