New Music Additions

[gr8sho92]

Whatever you finally decide to do, keep website performance in mind. The now playing section and shout continue to suffer connectivity loss.

About the query, one other bell or whistle might be to search on release year. Not all new adds are actually new releases.

[VAXman(Admin)]

Originally Posted by gr8sho92

Whatever you finally decide to do, keep website performance in mind. The now playing section and shout continue to suffer connectivity loss.

There are a couple of changes that can be made in this regard. If only the streaming server could be NTP synched with a stratum time server. Then that section of the page could be obtained by and maintain on the web server and the <iframe> refresh could be tightly coupled with the current song's playing time in conjunction with the user's site arrival time.

To explain this...

Assume it is about noon. The current song started at noon and it is exactly 6 minutes in length. That section of the page will be static until 12:06:00. The information that is displayed could be obtained at noon and cached on the web server. At 6 mins past the noon hour, the page <iframe> needs to be refreshed in any browsers connected. This would be done by setting the refresh on the <iframe> when the new song loads. But you ask, what happens if a user arrives at exactly 3 mins past noon? Well, the refresh interval would be computed from the following: <track finish time> - <user arrival time> In this example: <12:06:00> - <12:03:00> is 3 minutes. This would be set as this user's refresh timeout on the <iframe>. This is all pie-in-the-sky unless we can get NTP up and functioning on the streaming server.

The performance hit now is that EVERY user causes a database query to the streaming server to pull over the information and CPU time to format this information.

Originally Posted by gr8sho92

About the query, one other bell or whistle might be to search on release year. Not all new adds are actually new releases.

The search would be on the date added to the library regardless of the fact that the album's release was yesteryear. Jim's current list is compiled on date added to the library. My intention is to have the code mimic that trend. FWIW, there a many albums in the AM library with incorrect information regarding release date. When they've been brought to my attention, I have corrected them. Therefore, release date isn't really one of the better search criteria for this feature.

Performance-wise... Unlike the ON-THE-AIR/Dedication/RECENTLY-PLAYED (I often shorthand this as OTA/Ded/RP) section which automatically refreshes (and all too often), this feature would be a form. The USER would need to click on a link to pull up the form. Much like Jim's present list of additions news item, it is not (or will not be) a part of the main page load.

[gr8sho92]

Originally Posted by VAXman

Therefore, release date isn't really one of the better search criteria for this feature.

That suggestion was in addition to (another option), not in lieu of date added. The release dates are for the most part good enough.

Performance-wise... Unlike the ON-THE-AIR/Dedication/RECENTLY-PLAYED (I often shorthand this as OTA/Ded/RP) section which automatically refreshes (and all too often), this feature would be a form. The USER would need to click on a link to pull up the form. Much like Jim's present list of additions news item, it is not (or will not be) a part of the main page load.

Understood. My concern here is more about transactions hitting the remote SQL database having an overall impact on the website.