what is BASS/2.4 in xml

[djcenk]

hello
i see in shoutcast server xml
- <LISTENER>
<HOSTNAME>85.105.112.137</HOSTNAME>
<USERAGENT>BASS/2.4</USERAGENT>

what is this bass/2,4 player ?
which device use this player

thank you

[Nick@ss]

Stream ripper,

Best to ban it if you dont want your slots taken up.

[ridz]

how to ban stream ripper? Are you sure it is safe to ban BASS/2.4

[DrO]

you can ban it via the banning interface in the stream's admin pages. is up to you if you think it's safe or not though you can only ban by IP and not user-agent with the DNAS.

-daz

[jaromanda]

BASS/2.4 is NOT a stream ripper, it's a player created using BASS library - http://www.un4seen.com/

[DrO]

Originally Posted by DrO

is up to you if you think it's safe or not

did say the above as obviously it could be a streamripper based on the BASS library (feasible considering what the library can do). is the same for some people questioning WinampMPEG/5.50 being a legit Winamp client useragent or if it is just a streamripper (bit of both it seems).

at times i wonder if adding in useragent banning would be useful or not though i can see it possibly causing more hurt than good especially as just targeting specific problematic users is the better way to go i think instead of a blanket approach.

-daz

[Trekkan]

Wow, my last visit date was 5 years ago here... anyway... heh

I'm possibly getting back into the Shoutcast realm and am reading to get caught up on current events/software/etc. The idea of banning by useragent isn't a bad idea, but as it can be faked so easily, it's not really effective.

That being said, using regex to help more easily identify known ripper agents, couldn't hurt. would allow people to easily pass around blacklists between each other if they wanted too.

As for BASS, it can be used as a ripper for sure, but I also wrote a legit player for my own station back in the day using it.

Also, glad to see work being done on Shoutcast again, thanks DrO!

[DrO]

Originally Posted by Trekkan

The idea of banning by useragent isn't a bad idea, but as it can be faked so easily, it's not really effective.

aye, that's one of the things that has put me off doing it, at least it involves a bit more work to circumvent an IP ban compared to getting around a useragent based ban (though it's easy enough to get around IP bans as well nowadays it seems).

Originally Posted by Trekkan

That being said, using regex to help more easily identify known ripper agents, couldn't hurt. would allow people to easily pass around blacklists between each other if they wanted too.

that's an interesting idea, or at least logging known ripper agents in a specific place though it then leaves the issue of maintaining / ensuring that what is put there is valid and not just someone doing it to spite someone else, etc. but a fair idea to think about at some point

-daz

[Trekkan]

It's off topic for this thread kinda, but... something I always wanted was logins for the streams. Basically an auth system that once authed would generate a token, possible like TeamSpeak generates a UID for each system it's on.

Then, the host can use that key to grant access to the stream. While this doesn't stop rippers, it does allow you to setup special streams for people/premium membership and all of the cool things that come along with it.

[MADxHAWK]

Originally Posted by DrO

at times i wonder if adding in useragent banning would be useful or not though i can see it possibly causing more hurt than good especially as just targeting specific problematic users is the better way to go i think instead of a blanket approach.

-daz

Well i think adding a solution to ban by useragent would be a great feature cause one of the most common problems by banning only via IP are the dynamic IPs most ISPs use. I ban an IP, the banned user simply reconnect to his ISP and get a new IP and i have to ban the next IP. Also many ISPs disconnect their users every 24 hours, so they also get a new IP.

Banning by useragent would be the better solution imho.

Another solution agains streamrippers would be a delay in sending the songinformations.
For example a delay of 5 to 10 seconds would make every ripped song useless cause the first seconds of the song are missing. Maybe there can be added a option to the config like DelayMetaUpdate=xx seconds

- MAD

[jaromanda]

Originally Posted by MADxHAWK

Banning by useragent would be the better solution imho.

If I were to write a streamripper, I would use a known useragent anyway

Originally Posted by MADxHAWK

Another solution agains streamrippers would be a delay in sending the songinformations.
For example a delay of 5 to 10 seconds would make every ripped song useless cause the first seconds of the song are missing. Maybe there can be added a option to the config like DelayMetaUpdate=xx seconds

- MAD

already in the design of edcast v4 or is that riocast v1

[DrO]

with useragent banning, like jaromanda points out, it's simple enough to just use an existing useragent like WinampMPEG/5.50 for example so you then end up banning legit users for what is probably a small proportion of actual users connected.

with the title delaying, that's an interesting idea and yes i know streamripping is an issue but disadvantaging real users isn't a good idea either. plus i can think of a number of things which would break with such a delay.

the site player is one straight off as a 5-10 second delay is well outside the time the connection is active for when trying to pull the metadata from the stream. yes i know there needs to be a better site player so that isn't an issue but i can then see complaints coming through that titles don't work - as i already get due to a bug in the current v2 DNAS with v1 sources and all of the other issues with the site player, but a lot of people sadly seem to rely on using it.

-daz

[jaromanda]

Originally Posted by DrO

the site player is one straight off as a 5-10 second delay is well outside the time the connection is active for when trying to pull the metadata from the stream.

the site player is flash? so it couldn't get it's metadata "inline" via icy-metadata request / icy-metaint response headers, right? so it doesn't actually get it's metadata "from the stream" as such

just wondering what mechanism it uses, because I can't seeing it use the inline metadata, so it would get it via a separate connection, which it would make at some interval which I wouldn't think was less than 30 seconds ... so the "metadata" would rarely be in sync anyway

or do I totally misunderstand the inner workings of the "site player"

[DrO]

metadata from the stream for the site player is obtained via the 'SHOUTcast Metadata Puller' connection which just grabs the stream and tries to find the metadata from it that way (not happy with that all when i found out though i can see why it was done that way and is why i'm trying to at least leverage for v2 streams taking what is stored in the db's since that is updated pretty much when a title change happens & would then allow for less client connection hits, etc).

so yes the metadata is out of sync (which can be out by a few minutes depending on what method is used - currently all stations get puller connections) but a 5-10/custom delay would most likely mean the puller would never get any details and just show 'no information supplied' which i am pretty sure would lead to people complaining (as they do, heh).

-daz

[jaromanda]

Originally Posted by DrO

metadata from the stream for the site player is obtained via the 'SHOUTcast Metadata Puller' connection which just grabs the stream and tries to find the metadata from it that way

wow, that sounds inefficient - why not read and parse index.html - 7.html rocked in DNAS 1 oh, but DNAS 2 has something similar too doesn't it

anyway - I'm dragging this thread WAY off topic now, I'll shut up

[jaromanda]

Ironically, over at the BASS forums, someone is complaining that the streamripper they just "wrote" only records about 7 seconds of audio

[DrO]

i think the idea behind it was that pulling the metadata via a second connection is going to be less prone to being faked, etc compared to pulling from 7.html. though this is guessing things against a dev team which was disbanded a while ago...

yeah the v2 DNAS has a /stats option to replace the 7.html but that cannot be guaranteed to be even there plus that then involves the YP knowing the streamid or having additional data sent for where to query which isn't ideal as well.

hence why i'm trying to get the puller to see if it's a v2 station and then use the now playing info stored (and then fallback to using the puller) since the v2 updates are a lot more frequent than the +/-10mins that the v1 touches have.

obviously the ideal option is to just to take it from the stream like a proper client but with how things are, then it's always going to be some sort of compromise until a better site player is put in place (if / when that happens i don't know).

Originally Posted by jaromanda

Ironically, over at the BASS forums, someone is complaining that the streamripper they just "wrote" only records about 7 seconds of audio

this one i'm guessing... http://www.un4seen.com/forum/?topic=13248.0

-daz

[MADxHAWK]

Originally Posted by DrO

so yes the metadata is out of sync (which can be out by a few minutes depending on what method is used - currently all stations get puller connections) but a 5-10/custom delay would most likely mean the puller would never get any details and just show 'no information supplied' which i am pretty sure would lead to people complaining (as they do, heh).

-daz

Well a delay between 0 to 10 seconds would be enough. So why dont add an custom option and limit the custom delay for eg. to 10 seconds, while the metadata puller always works with a delay of for eg 12 seconds So the puller will always get vaild informations, just with a default delay of 12 seconds.
This would be good for the Stationowner who want to get rid of the streamrippers AND it would make the shoutcastlisting unattractiv for automated streamrippers using the shoutcastlisting to search vor ripping sources and therefore it also will save some traffic.

- MAD

[Trekkan]

Granted, it's a lot more work, but you could drop in an auth token to get stream data (other than out of the stream itself).

You create an auth token already for YP stuff, use that same token (or one like it) to authorize who can pull data from your server. Then, the only rippers that would work, are ones that use the data directly from the stream. Might cause more problems than it's worth, but it's an idea that might be able to be expanded on. =)

[DJBear]

I decided to use R.I.P and ban BASS Audio Library agents following recent simultenaous attacks, as in 12+ connections from different countries together, some with multiple IP's. For my small stations, I wouldn't get 12 simultaneous together let alone with this player. Yesterday I got 2x more attacks with about 6 connections, so basta. I have had for a few months single users with this agent and thought they were genuine, till this morning, one got banned from RIP and that connection tried to automatically reconnect for about 10-15 minutes so for me that was clear, I won't allow that player on my station now, in the unlikely event that a genuine listener not ripping me was using this player too bad, but I am 100% sure my listeners use "normal" players. I will post another post with a question related to winamp 5.5, when I find the right place

[radioextreme]

I am a long time after this agent. Conclusion which i was one - banning all!
I have disabled two hundred IP address using the BASS Audio, and every day i see new. Plague!

[Marck1]

BASS/2.4 can also be a game called ''MTA: San Andreas'' which sometimes stream music over player locations.

Read this: http://forum.mtasa.com/viewtopic.php?f=91&t=73859

If you see BASS/2.4 on logs, it's likely to be an BASS libary integrated player
The chances of it being MTA is also great; this game has over 14,000 players all time constantly online in 4000 gameservers, many servers use ''radio'' that streams from web radio with raw URL's to stream of. If this is your stream radio, players driving past others or having occupants in their cars, will trigger the stream for everyone in the area that hears the radio