SHOUTcast Transcoder 2 Beta (Build 54) 10/07/2011

[nwgator]

There always needs to be a source connected. I don't think there's a way to get around that. But correct me if I'm wrong DrO

[DrO]

you're correct, as soon as a DJ source disconnects, it will attempt to use the next available event until reverting back to the main playlist. so there should typically not be a gap in playback when the DJ disconnects.

so at the moment, it's working as it's meant to, since the whole point of sc_trans is to keep the stream going no matter what and i'm really not sure about changing the behaviour.

maybe it could be altered to allow for a few seconds from one DJ to another but that likely complicates things. i've made a note but i doubt it'll happen.

-daz

[Morpheus267]

Fore the next Version you can maybe a new DJ Port create and make a easy if case.

Something like this:

code:
if(dj_port1 == "connected" && dj_port2 == "connected"){

playmode = "dj";

} else {

playmode = "playlist";

}

I hope you know what i mean.

[DrO]

sorry, i'm not following what you're trying to say / ask as any active DJ connection will mean it's running in 'DJ' mode otherwise it'll use the 'playlist' mode.

-daz

[Morpheus267]

yes, this is what i mean.
And the second port is a waiting port for Shoutcast to let it know that a other dj want to continue the active dj connection.

I hope I could explain better now.
Sry for my bad English .

[DrO]

as i said in my other reply, i've made a note about delaying things but i'm not going to do that suggestion as it complicates things more than is needed especially when the last time i worked on sc_trans was about simplifying the whole port handling (which is the main issue with the DJ support at the moment).

so implementing that would be confusing as you then have to give out 2 or more ports for the DJ's to attempt to connect on (as they'll not know who is on what before attempting to connect) and then you have to prioritise them / add options to allow a connection but hold it or cache what is being sent and then use it when it's allowed - which is just confusing, complicated and counter-intuitive.

sorry but it's not going to happen as you want and as i said in my other reply, i've made a note about the delay but i don't think i'm going to implement it as it goes against what is trying to be achieved with sc_trans.

i know why you've said it but sc_trans works in the way it does since that is how we keep the stream alive without causing issues for clients (which is the whole point of things).

-daz

[juanmanuelrojasc]

hello there my friends..

i am using a 3d party server in a hosting stream company..

so from my pc only i am transmitting in 24k in mp3


do i need to install the transcoder locally or in the shoutcast server?

regards

[DrO]

it can be installed locally or on the server (if the host will allow you to install it). the main thing wherever it gets installed to is that the configuration will ensure sc_trans will point to the correct server address.

-daz

[flatbmx]

My shoutcast server has been crashing here and there due to a metadata bug that the transcoder sends it and i read that the transcoder would be updated to fix this. The error i am getting is:

std::runtime_error'
what(): XML parser error: not well-formed (invalid token) at line 4

I am running transcoder build 54, I was wondering if there is a fix for this or a newer transcoder version that fixs this issue. Sadly my current playlist contains some songs that cause this issue and the radio only stays up for about 30 minutes before crashing due to this error and the transcoder sits there trying to transmit to the server that has crashed.

[DrO]

as there hasn't been a new public build released and i've absolutely no idea when there will be an update (i'm not actively working on the tools anymore), you're going to be better off fixing the metadata than waiting for an update.

-daz

[flatbmx]

Ok, i think its being caused by german characters in the album name, ill double check and see if changing the characters will fix it, ty tho, you really seem reachable here =P

[DrO]

is usually due to characters between character code 128 and 160 and anything between 0 and 31 (excluding 9, 10 and 13).

-daz

[nwgator]

Originally Posted by DrO

as there hasn't been a new public build released and i've absolutely no idea when there will be an update (i'm not actively working on the tools anymore), you're going to be better off fixing the metadata than waiting for an update.

-daz

That's disappointing. Will you guys ever consider making the code open source?

[DrO]

i wouldn't expect that to happen (licensing agreements and all that) and fixing the tags is the safest option irrespective of the development status of the tools. and i've only not been working on the tools (which i couldn't say why at the time) due to working on some aspects of the new Winamp product... http://www.winamp.com/labs/cloud

[nwgator]

Oh ok, made it sound like it was indefinite. My tags have been fixed for quite a while, I was talking about what you mentioned about working on it.

This new winamp seems interesting. I shall sign up!

[neXor]

is there any chance of a fix release only for the characters?

this seems to be the only (serious) Problem right now (is it?).

As a radio station that plays medieval and pagan Sounds, there are often titles ith characters like "í î" and stuff wich crashed the server up to 4 times a week...

~neX