For a very long time--years in fact--I have had a problem with one of the replays on the server I manage. For this one replay only, which is a program of two hours duration, the bottom of the statistics table for the stream says the current song is xxx/the-show-name, and the 'xxx' in question bears no relation to the current song. In fact, there *is* no currents song--the file that's playing has no other metadata in it except the name of the program in the MP3 title field, and the name of the presenter in the MP3 artist field. What could be causing this? Where does this "current song" data come from?
Philipp Schafft
2020-May-12 10:28 UTC
[Icecast] Mystery Song Artist Shows in Listener Stats
Good morning, On Mon, 2020-05-11 at 14:44 -0400, Steve Matzura wrote:> For a very long time--years in fact--I have had a problem with one of > the replays on the server I manage. For this one replay only, which is a > program of two hours duration, the bottom of the statistics table for > the stream says the current song is xxx/the-show-name, and the 'xxx' in > question bears no relation to the current song. In fact, there *is* no > currents song--the file that's playing has no other metadata in it > except the name of the program in the MP3 title field, and the name of > the presenter in the MP3 artist field. What could be causing this?> Where > does this "current song" data come from?Metadata are in the responsibility of the source client. So please check that your source client doesn't have the additional text configured in some way. Also make sure there are only one source running per mount. Sometime broken source clients keep trying to update metadata even when not successfully connected to the mount point. With best regards, -- Philipp Schafft (CEO/Geschäftsführer) Telephon: +49.3535 490 17 92 Löwenfelsen UG (haftungsbeschränkt) Registration number: Bickinger Straße 21 HRB 12308 CB 04916 Herzberg (Elster) VATIN/USt-ID: Germany DE305133015 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part URL: <http://lists.xiph.org/pipermail/icecast/attachments/20200512/930985d8/attachment.sig>
It took some real deep digging, but I figured out what's going on. It's an EZStream problem. Or maybe not. Here's what's going on. The song name that's wrong comes from a three-second file that streams immediately before the main program. This file contains someone saying "The following program is broadcast in German." It seems that when the next file streams, only some of the metadata updates Listener Stats shows the correct program name, but the last line--Current song--gets held over from that short file that streams first. On 5/12/2020 6:28 AM, Philipp Schafft wrote:> Good morning, > > On Mon, 2020-05-11 at 14:44 -0400, Steve Matzura wrote: >> For a very long time--years in fact--I have had a problem with one of >> the replays on the server I manage. For this one replay only, which is a >> program of two hours duration, the bottom of the statistics table for >> the stream says the current song is xxx/the-show-name, and the 'xxx' in >> question bears no relation to the current song. In fact, there *is* no >> currents song--the file that's playing has no other metadata in it >> except the name of the program in the MP3 title field, and the name of >> the presenter in the MP3 artist field. What could be causing this? >> Where >> does this "current song" data come from? > Metadata are in the responsibility of the source client. So please check > that your source client doesn't have the additional text configured in > some way. > > Also make sure there are only one source running per mount. Sometime > broken source clients keep trying to update metadata even when not > successfully connected to the mount point. > > With best regards, > > > _______________________________________________ > Icecast mailing list > Icecast at xiph.org > http://lists.xiph.org/mailman/listinfo/icecast-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.xiph.org/pipermail/icecast/attachments/20200512/9f86aab4/attachment.html>
I don';t know if this is the proper place to ask this, but here goes. I've been running icecast with ices for quite some time, and my log files are growing quite large. (/var/log/icecast/access.log and /var/log/icecast/error.log as well as (/usr/local/icecast/var/ices.log). I am having some trouble properly setting up the three logs under logrotate. I seem to remember having this all set up back when I started with icecast/ices under Redhat 7.3 or so, and now, I'm streaming under Fedora 32. It must have fallen out of configuration during one of the many software or hardware upgrades and migrations I have done. Can anybody give me a push in the right direction? Many thanks, Michael J. Brenegan USAR, Retired Clinical Engineering Yale/New Haven Hospital -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.xiph.org/pipermail/icecast/attachments/20200513/c2838d72/attachment.html>