Topic: BroadCast.UpdateTitle stop sending metadata

[marco]

I'm using BASS to create an Encoder application.

I'm using BroadCast.UpdateTitle to update metadata, encoding on an icecast server.

The problem is that after a while (5 days in average) this function stops to update titles and is necessary to restart the stream to make it work.

Anyone knows how to avoid this problem?

[Ian @ un4seen]

Please try capturing the network traffic when the problem happens (eg. with Wireshark), and check in that if the metadata requests (look for "GET /admin/metadata") are sent to the server and what the server's response is. Also confirm what encoding you're using, and that you have BASS.Net's ICEcast "UseBASS" property set to true.

[marco]

I'm using an encoder via ffmpeg and ICEcast class. Trying to set useBass to true and see what happens!
Thanks

[marco]

after a scan with wireshark the server reply 200 with "Mountpoint will not accept this URL update" as message. Now i'm using also usebass=true

[marco]

this is the request /admin/metadata?mode=updinfo&mount=%2F4media_str5&song=ULTIMA%20ORA%20in%20diretta%20dalla%20redazione%20di%20Roma%20

[Ian @ un4seen]

Do you still have the Wireshark capture? If so, please upload that to have a look at here:

   ftp.un4seen.com/incoming/

[marco]

filename : UpdateTitle capture.pcapng

packet interested for example the 3628

thanks

[Ian @ un4seen]

I couldn't find the "Mountpoint will not accept this URL update" message in the Icecast sources, but I do see it in the icecast-kh sources, so I guess you're using that? One cause of it is that the metadata update is from a different IP address than the stream's source. Might that be true in your case, eg. perhaps there may be multiple routes out of your LAN to the internet?

When the problem happens, is the stream still playable?

[marco]

You can find that message in a OK packet (3628) in eXtensible Markup Language>iceresponse>message.

When the metadata stop updating the audio still work and the stream still on.

Thanks to your hint about different IP as source i know that the environment where the software is installed has a firewall that switch on a second provider in case of fail of the main one. After a check on the logs of the firewall i noticed that there are frequent switche between two providers (customer problem). Maybe this the problem?

Now i'm forcing the firewall to use only the main source and i'll see what happens.

Thanks

[Ian @ un4seen]

You can find that message in a OK packet (3628) in eXtensible Markup Language>iceresponse>message.

Yes. To clarify, I meant that I couldn't find the message in the Icecast source code, which I checked to find out what it means. I did find it in the icecast-kh source code though (so it appears that's what you or your host is using), and that's where I saw the same IP address requirement.

   https://github.com/karlheyes/icecast-kh/blob/92f228321b451c910aceee6166b2f8a5631a4690/src/admin.c#L1089

Thanks to your hint about different IP as source i know that the environment where the software is installed has a firewall that switch on a second provider in case of fail of the main one. After a check on the logs of the firewall i noticed that there are frequent switche between two providers (customer problem). Maybe this the problem?

Yes, I think that's almost certainly the cause of the problem, due to the IP address changing.