| View previous topic :: View next topic |
| Author |
Message |
relen
Joined: 11 Sep 2008 Posts: 6 Location: UK
|
Posted: Thu Sep 11, 2008 9:23 am Post subject: Confused metadata display during server contention |
|
|
My apologies if this is dealt with elsewhere - I tried loads of search terms but either got nothing or everything.
We produce programming 24/7 with a different presenter handling each day (as a rule). Our presenters are in different timezones all over the world, so the handover between one and the next is often done by kicking the existing source at a suitable point (while the originating system is unattended); the superseded presenter then turns off their source client after they wake up (for example).
This means there is often a period of overlap where one source client is driving the stream while another (the previous presenter's system) is trying to get in and failing. During this period, the metadata from BOTH source clients is displayed to listeners, the currently-displayed metadata depending on which source client last sent an update. This is not optimum.
Is there a way of configuring the server so that only the metadata of the currently-streamed source client is displayed and the metadata from the contending source client is ignored (just as its audio is ignored)? Or is this a bug?
You would think that the default would be that the metadata from the source currently driving the audio stream would be the ONLY one displayed, but in fact the metadata from a contending source client will also be displayed, even if that contending source client is not successfully accessing the server audio-wise.
Any ideas or observations welcome. We cannot assign different priorities to different mount points as we don't know who will supersede who, and I am not sure this would solve the issue anyway.
Thanks in advance for any helpful advice.
--Richard E |
|
| Back to top |
|
 |
iunderwood

Joined: 23 Aug 2008 Posts: 114 Location: Leicester, MA
|
Posted: Thu Sep 11, 2008 1:47 pm Post subject: |
|
|
What are you using for a source client?
It sounds like the source uses admin requests to change the Metadata on the stream, which doesn't require a client to be logged in. _________________ ++I; |
|
| Back to top |
|
 |
relen
Joined: 11 Sep 2008 Posts: 6 Location: UK
|
Posted: Thu Sep 11, 2008 2:06 pm Post subject: |
|
|
| iunderwood wrote: |
What are you using for a source client?
It sounds like the source uses admin requests to change the Metadata on the stream, which doesn't require a client to be logged in. |
That's a fascinating observation. Unfortunately it happens with both the source clients we use regularly, which are primarily SAM Broadcaster (Win) and NiceCast (Mac). It may also occur using WinAmp but we haven't used this for a while so I can't be sure.
We are streaming MP3, by the way, for maximum compatibility with listeners.
By the sound of it, this is not the recommended method of changing the metadata: should I be contacting the suppliers and encouraging them to change it? Or is there a way round this issue?
What is the correct or recommended way of updating the metadata, ie what would I tell the suppliers they ought to be doing?
Thanks,
--Richard E _________________ Radio Riel - Real radio: your reality
http://www.radioriel.org |
|
| Back to top |
|
 |
karlH Code Warrior

Joined: 13 Jun 2005 Posts: 5476 Location: UK
|
Posted: Thu Sep 11, 2008 10:24 pm Post subject: |
|
|
someone reported something like this a week or so ago, what I've committed to trunk (post 2.3.2) is to block metadata update requests made by source clients unless the IP is the same as the one matching the stream. It's not perfect but should handle most if not all cases. You can get a snapshot from trunk to use that, or let me know if it needs to be a win32 build.
karl. |
|
| Back to top |
|
 |
relen
Joined: 11 Sep 2008 Posts: 6 Location: UK
|
Posted: Fri Sep 12, 2008 2:48 pm Post subject: |
|
|
Brilliant! Thanks! I think that would probably cover us.
I'll ask our server provider to look at this thread and let me/us know whether or not there is any need for any additional work.
Best,
--Richard E _________________ Radio Riel - Real radio: your reality
http://www.radioriel.org |
|
| Back to top |
|
 |
|