sc_trans2 relaying from sc_serv v1 title issue

[qgazq]

Hi,

I've tried searching for this and haven't found anyone posted about this issue. Which is odd because I would have expected someone else to notice it so I might be doing something daft.
Anyway the scenario I have is:

SAMBC -> sc_serv -> sc_trans2 -> sc_serv -> listener

The sc_serv's are currently version 1, and although they might get upgraded at some point it's not imminent.

It all seems to work, except the title seem to have some URL encoding which isn't quite right. As I understand SCv1 title data is URL encoded? So when sc_trans2 get it from the source it should decode it, the re-encode it when sending it out again.
It seems to be missing this first stage as it all the title it receives are still encoded, then its encoding them a second time (I think) and so ending up looking quite odd at the player end.
As I say I believe this is what is happening, if I stop the relay and it falls back to the local play list then the titles come through fine, and connecting to the first sc_serv they are fine as well. When relaying the source then all the titles come through with escaped characters. It seems like winamp deals with the %20's but everything else is still encoded, and other players (including the shoutcast info page) leave everything encoded.

The sc_trans2 logs show:
2012-02-12 14:28:37 I msg:[SOURCERELAY] Relaying metadata (Marillion%20%2D%20Forgotten%20Sons)
2012-02-12 14:28:46 I msg:[SHOUTCASTMETADATA] Metadata string [Marillion%20%2D%20Forgotten%20Sons]
2012-02-12 14:28:46 I msg:[SHOUTCASTMETADATA] Sending metadata

So is this a known issue?
Is there something I need to do to tell sc_trans2 that the source is v1 and so it needs to decode the title?
Have I made a load of incorrect assumptions about how titles are handled?

Regards
QGazQ

[DrO]

v1 titles were never normally url encoded and is more down to some newer builds of sc_trans url encoding when it shouldn't be on v1 streams. am sure it's mentioned in the current sc_trans release thread and is something which needs to be changed to only work on v2 based streams which need to be url encoded.

i've got it noted already but cannot say if it'll be fixed in the next sc_trans release or the one which after comes after it (though there's no eta on a new release at the moment).

-daz

[qgazq]

Ok, looks like I got confused as to which version of sc was and wasn't url encoded.
As I say I saw something about it not getting the encoding right on the output, but this seemed to be an input problem.

As long as its a known issue and on the todo list then I'll will wait.

Thanks
QGazQ

[qgazq]

Not sure if its any use but I tried a few experiments to narrow down where the problem is.
Now it might be you already know this, but just in case its useful:
sc_trans2 is just setup to relay the stream (in the actual real world it will be changing the bit rate, and I'm also using calendar events etc, but for the purpose of the test it was pretty much a straight relay).

shoutcast 1 source:
sc_trans2 log file: titles url encoded
shoutcast 1 dest: titles url encoded
shoutcast 2 dest: titles ok

shoutcast 2 source:
sc_trans2 log file: titles ok
shoutcast 1 dest: titles ok
shoutcast 2 dest: titles ok

So the only combination which fails (assuming these are the only parameters which effect it) is the case where both source and destination are v1 shoutcasts. Which is the current setup I have. But it does appear if I can upgrade either end the problem will go away for now so I will look into the feasibility of doing that.

Regards
QGazQ