The Shoutcast DNAS isn't displaying this information, but the stream itself is functioning fine otherwise. 

What should I be looking at as a possible cause?

Current song information being stuck can be fixed if I shut down the Auto DJ, then shut down and restart the stream (which restarts the Auto DJ).  But I can't keep on this way, this is not supposed to be a continuous, round the clock problem.

Centova admins?  Anybody?

Anybody? 

Never had this problem once. Does it happen on a specific songs, or specific songs, repeatedly? Or do you have any useful log data from when it gets stuck?

Mostly it happens on our episodes of our radio serials (but not consistently).  But we weren't having this problem before the most recent version upgrade.  It all started about then.  No other changes.

Either the information being sent to the Shoutcast DNAS Admin panel is being curtailed, blocked or modified, or something about the Shoutcast DNAS itself is being periodically broken.  Since the Centova software is what changed, my money's on the Centova software.

A complete shutdown and restart of the stream and AutoDj usually (but not always) clears the condition. For about an hour after the restart there is no recent tracks data available at all - then it begins to behave normally again.  It almost seems like it has to fill the recently played list buffer before it will start displaying anything.

Okay, this is new.

Now the "Now Playing" information only updates when we play something from a shorter playlist we use for station identification - and nothing else.

Anybody got some clues on what might be actually going wrong here?

I've found that sometimes mine shows 'unknown' even though the same track under v2 knew who it was. I think the tags are read under the process after you bring it in via FTP or webdav, and it skips it some. I KNOW my tracks have the proper ID3 tags. Maybe we just need a 're-index' button like we had in V2. I've reimported files (the same ones mind you) and they fixed it. So, I'm going to speculate that something went haywire during the import the first time.

Hope this helps.

Michael Roark

I did the whole reindex thing several times.  I finally did fix it - I did it by making a new playlist, selecting all the contents of the old playlist and dragging and dropping them into the new playlist. 

The old playlist claimed to contain 51 hours of music.  The new one contains only 47 hours. 

I then deleted the old playlist and we're now just using the new one, and the problems have ceased.  The information to be drawn from this (and I hope the developers are paying attention here) is that it is possible for a playlist to become corrupt and interfere with the function of the Now Playing and Recent Tracks data. 

The workaround for the problem is to create a new playlist using the contents from the old one.  This writes a new playlist to the database, minus the corruption. 

Thanks Krypton! That's good to know. I'm going to try that on all of my weighted general rotation playlists today. I hope the developers are paying attention too. We all know bugs and leaks happen, but even scripting out what you did as a fix could help automate resolving issues for those who may not understand. (as long as that playlist is not being played from).

Michael Roark