[BUG] My 3 differents streams plays at the same bitrate

[www.maxa.es]

Hi, I use shoutcast v2, only with dnas (no transcoder).

I configured 3 outputs :

- 1 in AAC 392 kbps
- 1 in MP3 192 kbps
- 1 in AAC+ 60 kbps

When I check the quantity of data send, it looks ok, because the 3 streams were started at the same time and the "bigger" stream has send more data than the others.

When I write IP:Port on a web browser, I see 3 streams up at the right bitrate.

But when I open the stream, they all play in 392 vbr (acc probably).

I tried all ways to open the urls :
- only IP:Port
- with mountpoint
- SHoutcast "listen link" (like "listen.pls?sid=1")



So, maybe this feature need to use the transcoder ? because informations about the bitrate in config fils goes to the transcoder case.

But i'm pretty sure it's a bug, because the data sent and the shoutcast webpage display 3 differents streams.




Maybe it's a bug in Winamp (I havn't yet tried others solutions).

(...)

no, same problem in windows media player.


I'm so disappointed because I don't wan't to use additional software or solution

I will check some documentation about transcoder and shoutcast server v2, but english is not my native language and technical vocabulary is really not easy to understood...

thanks in advance for your answsers.

michael

[DrO]

without an active DNAS link to check against, no one is going to be able to confirm or deny what you appear to be hearing.

-daz

[www.maxa.es]

thank for the answer daz, I didn't know if I'm allowed to inserts links here.




(<removed>) :
"Stream is up at 392 kbps with 1 of 150 listeners (1 unique)"
(<removed>) :
"Stream is up at 192 kbps with 0 of 100 listeners (0 unique)"
(<removed>) :
"Stream is up at 60 kbps with 0 of 50 listeners (0 unique)"






stream 1 : <removed>
stream 2 : <removed>
stream 3 : <removed>

no matter the stream I choice, it's the "sid=1" who display "1 listener connected".
no matter the stream I choice, I always had "392 kbps" (probably in aac)







I think shoutcast always redirect on the first stream and can't relay on the appropriate "ID"

I thought it was an autoaush problem but no, because same Ip = same autohash.
maybe it's because I use the same2 passwords "stream and admin password" on the 3 streams but I had no error message.








ps : the streams are open even if they don't always plays something (I use it for tests right now)

have a nice day
michael

[DrO]

using /stream/#/ where # is the stream number is giving the correct stream output. however like you are seeing, /listen.pls?sid=# is behaving in the manner you are describing and is not something i've seen happen before.

can you post your config file please (with authhash and passwords blanked out) and i'll see if i can replicate the issue with the public and internal builds of the v2 DNAS.

-daz

[jaromanda]

every one of those streams brings winamp to it's knees here

sure, it plays, but the UI is frozen solid

tested with other streams, winamp is fine

wont be going there again

392kbps AAC!!?? That's like hunting rabbits with with a tomahawk missile ... overkill

[www.maxa.es]

;DNAS configuration file
;Made with the SHOUTcast 2 Configuration Builder

password=**********
adminpassword=***************
portbase=80
requirestreamconfigs=1
logfile=sc_serv.log
w3clog=sc_w3c.log
publicserver=always
banfile=sc_serv.ban
ripfile=sc_serv.rip
maxuser=300

streamid_1=1
streampath_1=hq.aac
streammaxuser_1=150
streamauthhash_1=********************
streampassword_1=**********
streamadminpassword_1=***************

streamid_2=2
streampath_2=sq.mp3
streammaxuser_2=100
streamauthhash_2=********************
streampassword_2=**********
streamadminpassword_2=***************

streamid_3=3
streampath_3=lq.aac
streammaxuser_3=50
streamauthhash_3=********************
streampassword_3=**********
streamadminpassword_3=***************



_____________________________

Notes :
- I use the same password for "password" ; "streampassword_1" ; "streampassword_2" ; "streampassword_3"
- I use the same password for "adminpassword" ; "streamadminpassword_1" ; "streamadminpassword_2" ; "streamadminpassword_3"
- I use exactly the same radiostation name on the 3 outputs
- Sometime I add the "debug mode" on the config file but I don't know if it make any difference


don't hesitate if you ned something else.

have a nice day,
michael

[DrO]

jaromanda: it looks like it's something to do with modern skin support (again). will have to track that down as time allows.

michael: thanks, will have a play around. though as a note, if the streampassword_* are the same as password, then you only need to be setting password and it will be used for all of the streams. the same applies for the adminpassword and streamadminpassword values.

-daz

[www.maxa.es]

It also make lags on winamp for me when I configure multiple mountpoints on a same ip.

winamp don't lag when i've only one mountpoint

windows media player don't lag on multple mountpoints, it's probably this bug who makes winamp "unconfortable", but the lag disappear after 30 or 35 seconds.

[jaromanda]

Originally Posted by DrO

jaromanda: it looks like it's something to do with modern skin support (again). will have to track that down as time allows.

it's always a pleasure giving you more work to do

Originally Posted by www.maxa.es

but the lag disappear after 30 or 35 seconds.

ahh, yes, I remember that same thing happening way back in the early days of v2

[DrO]

the streampath issue is due to the lack of a / on the front in the config file - it shouldn't be messing up without that so i'll sort that out and send over a newer test build later today.


as for the UI lockup, it seems to be because of the lack of a title the streams as i've just hooked up sc_trans to quickly provide the streams and set it to not send the titles and i'm seeing the ui lockup issue. how i hate modern skins at times *grumble*

-daz

[DrO]

michael: check your pm.

-daz

[DrO]

update: things all appear to be sorted now with the test DNAS which is now running.

am looking into the cause of the modern skin issue so will send out test builds of in_mp3.dll i'd expect (seeing as that was the point of issue the last time around).

[edit]
will have to keep trying to resolve the Winamp issue as time allows as it's stopped happening for me despite no code changes - this feels very much like last time all over again.

-daz