Post Reply 
 
Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
No artwork
22-11-2012, 00:40 (This post was last modified: 22-11-2012 00:42 by bubbleguuum.)
Post: #11
RE: No artwork
@simon

Various UPnP software and hardware epic failing at URL encoding/decoding is a classic (that, and failing at XML encoding/decoding in very creative ways).

That's why I always generate URLs that require no percent encoding and no queries in path if the URL can be used by a recipient I have no control over.
Gzip+base64 is a good idea as it is decodable to the original string.

Naim is super slow at fixing its software, if they ever fix it.

I guess proxying Minimserver with BubbleUPnP Server could serve as a temporary workaround, as it will generate simple URLs that even the dumbest UPnP client should have no problem with.
Find all posts by this user
Quote this message in a reply
22-11-2012, 08:56
Post: #12
RE: No artwork
(22-11-2012 00:40)bubbleguuum Wrote:  @simon

Various UPnP software and hardware epic failing at URL encoding/decoding is a classic (that, and failing at XML encoding/decoding in very creative ways).

That's why I always generate URLs that require no percent encoding and no queries in path if the URL can be used by a recipient I have no control over.
Gzip+base64 is a good idea as it is decodable to the original string.

Naim is super slow at fixing its software, if they ever fix it.

I guess proxying Minimserver with BubbleUPnP Server could serve as a temporary workaround, as it will generate simple URLs that even the dumbest UPnP client should have no problem with.

Thanks for the suggestion to use gzip+base64. I'll look into doing this, either as an option or as the default approach. Having the client URL easily reversible to the original server-side path when reading trace logs is important to me for debugging purposes.

This would presumably explain why so many web page URLs contain extremely long unreadable strings!
Find all posts by this user
Quote this message in a reply
22-11-2012, 09:53 (This post was last modified: 22-11-2012 09:53 by bubbleguuum.)
Post: #13
RE: No artwork
(22-11-2012 08:56)simoncn Wrote:  
(22-11-2012 00:40)bubbleguuum Wrote:  @simon

Various UPnP software and hardware epic failing at URL encoding/decoding is a classic (that, and failing at XML encoding/decoding in very creative ways).

That's why I always generate URLs that require no percent encoding and no queries in path if the URL can be used by a recipient I have no control over.
Gzip+base64 is a good idea as it is decodable to the original string.

Naim is super slow at fixing its software, if they ever fix it.

I guess proxying Minimserver with BubbleUPnP Server could serve as a temporary workaround, as it will generate simple URLs that even the dumbest UPnP client should have no problem with.

Thanks for the suggestion to use gzip+base64. I'll look into doing this, either as an option or as the default approach. Having the client URL easily reversible to the original server-side path when reading trace logs is important to me for debugging purposes.

This would presumably explain why so many web page URLs contain extremely long unreadable strings!


An alternative to gzip+base64 is to use a md5sum of the file path.
That limits URL length at the (small) expense to have to store the md5sum => file path association in a file. Which is very easily done by using Java serialization on a HashMap for example. That's what I'm doing in BubbleUPnP Server. But in other scenarios I just use gzip+base64.
Find all posts by this user
Quote this message in a reply
22-11-2012, 10:46
Post: #14
RE: No artwork
(22-11-2012 09:53)bubbleguuum Wrote:  An alternative to gzip+base64 is to use a md5sum of the file path.
That limits URL length at the (small) expense to have to store the md5sum => file path association in a file. Which is very easily done by using Java serialization on a HashMap for example. That's what I'm doing in BubbleUPnP Server. But in other scenarios I just use gzip+base64.

The disadvantage of this would be that I couldn't decode paths in trace logs created by users for problem solving and debugging. This isn't a problem if I use a self-contained reversible encoding.
Find all posts by this user
Quote this message in a reply
22-11-2012, 10:53
Post: #15
RE: No artwork
(22-11-2012 10:46)simoncn Wrote:  
(22-11-2012 09:53)bubbleguuum Wrote:  An alternative to gzip+base64 is to use a md5sum of the file path.
That limits URL length at the (small) expense to have to store the md5sum => file path association in a file. Which is very easily done by using Java serialization on a HashMap for example. That's what I'm doing in BubbleUPnP Server. But in other scenarios I just use gzip+base64.

The disadvantage of this would be that I couldn't decode paths in trace logs created by users for problem solving and debugging. This isn't a problem if I use a self-contained reversible encoding.

It always has to be reversible, otherwise you would not be able to get the path to stream the file (independently of logging).

In the case of md5sum, the association (md5sum, filepath) must be stored and persisted in a hash table to be able to decode the md5sum.
Find all posts by this user
Quote this message in a reply
22-11-2012, 12:09
Post: #16
RE: No artwork
(22-11-2012 10:53)bubbleguuum Wrote:  It always has to be reversible, otherwise you would not be able to get the path to stream the file (independently of logging).

In the case of md5sum, the association (md5sum, filepath) must be stored and persisted in a hash table to be able to decode the md5sum.

I understand that the MinimServer runtime can reverse the md5sum mapping. However, I can't reverse this mapping when a user sends me a trace log.
Find all posts by this user
Quote this message in a reply
26-11-2012, 17:41
Post: #17
RE: No artwork
Hmmm, I've also run into this problem with Naim ndx. I don't s'pose, there's the possibility of adding a configuration switch for 'dumb upnp clients' that removes the encoding?

BTW, been playing with your software for an hour or so. Loving the configurability of the software and the speed compared to Plex and the synology default media server is amazing. I'm about to try the sound quality test on the wav 24bit transcoding.

Many thanks,Crom
Find all posts by this user
Quote this message in a reply
26-11-2012, 18:39 (This post was last modified: 26-11-2012 18:40 by bbrip.)
Post: #18
RE: No artwork
(26-11-2012 17:41)Crom Wrote:  Hmmm, I've also run into this problem with Naim ndx. I don't s'pose, there's the possibility of adding a configuration switch for 'dumb upnp clients' that removes the encoding?

BTW, been playing with your software for an hour or so. Loving the configurability of the software and the speed compared to Plex and the synology default media server is amazing. I'm about to try the sound quality test on the wav 24bit transcoding.

Many thanks,Crom

Put pressure on the Naim folks, they should fix this swiftly if they want to stay competitive Wink
Find all posts by this user
Quote this message in a reply
26-11-2012, 18:54
Post: #19
RE: No artwork
(26-11-2012 18:39)bbrip Wrote:  Put pressure on the Naim folks, they should fix this swiftly if they want to stay competitive Wink

I think that's a good idea, as it's their bug. If multiple Naim customers complain, that might persuade Naim to take this bug more seriously.

As a possible workaround if Naim don't respond positively, I've been looking at the base64/gzip approach suggested by bubbleguuum. The next step is for me to write a bit of test code and try it on some typical URLs to see what it produces.
Find all posts by this user
Quote this message in a reply
27-11-2012, 16:10
Post: #20
RE: No artwork
I've mailed 'em...let's see if we get a response ;-)
Find all posts by this user
Quote this message in a reply
Post Reply 


Forum Jump:


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