Hey Ron,

I can't really see how your solution would work in any useful way.

If you are having to log in to the control panel to add the newly downloaded file to the directory why not just upload the new file at the same time via the media uploader?

This is one extremely frustrating area of Airtime that is so outdated when compared to virtually all other software solutions out there.

I have been using the following method to download and playout repeating (weekly) shows with updated content, it works but it's not entirely stable as every time airtime "imports" the new file it doesn't update the meta data (another massive oversight).

1. Upload an audio file called show1.mp3 into your media library or watched folder

2. Schedule it wherever you want to repeat whenever you want

3. I have another server where the djs upload their new shows to. On this server I take the newly uploaded mp3 file, rename it to show1.mp3 and set the relevant ID3 tags using (eyeD3). This new file is moved into a web accesible folder, overwriting the previous version of show1.mp3

4. I have a cron job set up on the airtime server that checks the show folder on the upload server every 5 minutes for new content, if it finds a newer version of show1.mp3 it downloads it to the local watched folder which airtime then imports, overwriting the old file.

The result is that airtime *thinks* it's always playing the same show1.mp3 every week when in fact it is playing brand new content every week contained in the show1.mp3 file.

But like I said, this isn't without problems. If show1.mp3 one week is 63 minutes when you first add it to the media library in step 1, and then the new version of show1.mp3 is only 59 minutes, the meta data isn't updated as far as the database is concerned so it can cause playout errors, skips, restarts etc

The obvious solution to this is to ensure that every show1.mp3 file is exactly the same length, which is easily achieved using something like (SOX), but if you do this airtime won't update the playout cache and uses the previous version of the show1.mp3 file. This results in shows repeating for 2 weeks before the cache clears. It's incredibly annoying. Changing cache settings makes no difference at all.

The way I've managed to make it work is by telling all of my djs to keep each show roughly to the same length OVER their alloted time slot. So if their show is 1hr, then their file should be AT LEAST 1 hour long or above. This way you bypass the restart problem but if they upload something that is vastly different, say 1hr 20 mins, it will cause a whole host of other issues.

There are a whole bunch of things about airtime that make it one of the best radio scheduling solutions on the market, I really love it, but there are a couple of major things that make it virtually impossible to use in any kind of dynamic situation.

I wish you luck mate, one thing I can promise you, in 6 months time you will have spent way more time trying to get stuff working than you ever expected you would ;)

What you are dealing with is a progressive  download mp3.
Vlc ,Foobar,Amarok and some other media players can start playing these at any stage.
Airtime has to have a static mp3 or a stream mp3 mount.

Stream mp3 can come from any Streaming Server Software including muse (webstream)
static mp3 have to be fulled downloaded

 

So I'm working on a potential fork of Airtime. One of things that my station has wanted is the ability to have automatic shows (without manual scheduling). Airtime.pro added a feature called Rotations which I thought would fix this until I realized that it was designed as an auto-fill vs. auto-schedule, meaning it continues to fill up the scheduled show until it overflows the time. It also didn't have the ability to include multiple smart blocks. So for instance I couldn't 1 block that pulled a random station ID and then the next that pulled the most recent episode of a Podcast.

I'm figuring you are using Airtime 2.5.1 like most other people. I'm considering building the fork off of what was on git as saas-dev code, mostly airtime.pro as of December 2015. It needs a bit more massaging and in the process of pulling lost all the git commit messages etc.

But anyways, I think solving problems like this are one of the biggest incentives we have towards forking the codebase.

The first modification I did, which only people who have used Airtime.pro will get is I modified the Podcast Episode script to insert the Podcast title as the Album ID3 metadata. This is important because otherwise there was no way to tie a track back to a specific Podcast for say smartblocks unless the producers were really consistent about their tagging.