Ok I'm not capable of doing this on my own but I'm willing to give this a shot if some of you can help me?
A massive thing missing from Airtime, I think you'll all agree, is proper dynamic playlisting.
Right now we have smart blocks, but they are only partly useful in their current state.
If you want to set up a 2hr playlist that plays a random selection of music from the genre "rock" for example, this can be done with a Smart block easily, but as soon as you schedule that playlist it is no longer "smart" or "dynamic", meaning that if you want to use this playlist once a day you have to create that smart block again and schedule it for every instance where you want it to play or it will just play the same randomly selected songs that it picked at the time of the playlist creation instead of picking a new random selection from the genre "rock" everyday..
This is a massive waste of manpower for something so simple, and something so obviously useful.
So i'm offering to either modify the current smart block or write an entirely new one based on the existing one, but with true dynamic playlist generation from within a scheduled show, and not at the library / media builder stage.
Trouble is, I have no idea where to start :(
Anybody fancy helping me to try and get this working?
Like your thinking, but that wouldn't really work as it could only shuffle songs that were originally added to the playlist. It wouldn't include anything added to the library after the smart block was created.
I've been toying with another way of doing it using pls files. Still testing it at the moment, and it's very buggy, but i'll keep you updated if I can get it working properly.
Essentially the show slot would be empty, and then 10mins before the show is due to air, a cron job populates a smart block and dumps it into the slot.
In theory I can't see why this wouldn't work. It's just knowing what to put in the script to make it perform all of the above.
** EDIT **
Just for clarification...
I'm taking about running a cron job on the server, not an Airtime script. The reason for taking this approach versus hacking the Airtime code, is because Airtime would naturally perform all of it's database linkage etc as soon as the playlist was created. I can't see why it wouldn't be possible but we'd need one of the Airtime developers to help us out with the code.
There is no real smart block to program as such - its a set of rules to generate and insert the same list of timed tracks into the schedule table, for each show instance refered to by the show - and all timed top milisecond level and allowing for cross fades. There can be a hundred or more show-instances created for a single-repeating-linked show.
Gulp.
Probably the easiest way would be to reuse AT functions to delete the show content and tell it to add a new smart block using the right parameters.
Not impossible but not a week-end project either.
Post edited by John Chewter at 2014-09-14 19:14:53
Yes Quentin that's exactly what I'm talking about!
This is my set up, the problems I'm having and why I need to find a solution : Overview
My station exclusively airs 1 or 2hr radio shows from DJ's around the world. The station runs 24/7 and the DJ's submit a brand new show every week.
The Set Up
I have this spread across 5 different web servers, for handling each aspect of the station. The DJ's upload their shows to an offsite server via a dedicated upload script in their account (nothing to do with Airtime). The files are then processed (renamed, ID3 tags are re-written etc) and then just sit there waiting to be downloaded.
The Airtime server (using repeating scheduled cron jobs) downloads and imports each file 2 hours before the relevant show is due to begin.
I'm using repeating linked shows in the calendar. Each show has a file in it which has the same name and ID3 properties of each of the relevant radio show mp3 files. So Airtime thinks it's playing the same file, but in fact it's playing a new file every week. It works, but it's not without problems.
The Problems
The biggest problem is that Airtime doesn't update all of the Meta across the system. So when a file that is 1hr 3mins one week, and 1hr 2mins the next week is played, Airtime doesn't see the new length in the linked instance of the show. This causes glitches, restarts and drop outs due to the headers not being correctly read. The meta is fully updated when the new file is imported into Airtime, but that isn't reflected anywhere that the file is already being scheduled.
Things I have tried to make this work - but don't
1) Using a dummy MP3 file that is longer than the actual show file will ever be. Dropping this into a playlist and then dropping that playlist into the linked show - (Causes glitches & restarts).
2) Dropping the actual MP3 file into the linked show instead of using a playlist. (Same as above).
3) Created PLS files for each show that point to the relevant MP3 file, and then set up a Webstream playlist for each show pointing to each PLS file and dropping that in the linked shows. (This was a disaster, files played at the wrong speeds, chopped up, restarted etc). Don't try this one!
Possible Solutions
The easiest one would be to make Airtime automatically update all scheduled instances of it's shows maybe once an hour? So it scans the db, checks to see if anything has changed and if so, it updates each show with the correct file information (obviously ignoring the currently active show as that could cause problems).
Another solution would be what you & I have suggested. That cron fires a script XXmins before the start of each show which creates and populates a smart bock with content based on pre-selected meta properties and then drops in into the relevant show slot.
Or the one that we all want to see... Smart blocks that actually generate their playlists dynamically after being scheduled.
Hmm.. It needs to see if any of the schedule table items, referenced by the show_instance table item have been changed AND that no other item in the schedule table co-incides. AT doesn't check this very well, hence people moaning about double track playing.
If your server machine is not some feeble weekling..... I guess you could cheat and use something like XBMC to do the clever smartlist stuff (which it does very well) and the add-in scheduler (not the one that ships with it - the one in the forum) and use that as a livestream source.
For the moment I have no solution. To update smart blocks I delete/recreate shows and fill them, and for weekly shows i do that manually.
For you, a dirty workaround would be to cron vlc 1min before and broadcast to airtime, for example : sleep 55 && vlc --no-video --noaudio -I dummy "/media/folder/show.mp3" --sout '#http{dst=:8080/show.mp3}' &
That's a nice idea Quentin, will try that if the solution I've thought of below doesn't work out. Yeah John, this is starting to sound really messy lol.
Ok, so I have found something that SHOULD work.
It's pretty clean too although does involve some CPU juice, (not an issue for me as all this is being done on an offsite server)..
After I've renamed and copied the uploaded files i'm going to try using FFMPEG on them (without re encoding) to edit them down to the exact show running times, cutting anything that runs longer (as you'll never hear it anyway). Then when Airtime imports them there shouldn't be any problems with varying file lengths as the replacement file will always be the same length.
BTW, I have a cron'd script that is nearly done that will correctly update the times for the new incomming mp3. BUT you must NEVER put a track AFTER it in a show - you must use fallback.
Ahh John that's great but i've got it working now.
Finally, after months of messing around I've cracked it.
It uses a mixture of eyeD3 and SOX to name and trim the files so that they are always exactly the same. It works too!
But there is one issue I've found.
Caching...
How is airtime caching the upcoming shows?
The reason I ask is that when I replace the show file it will play the new audio from within airtime via the preview, but when the show is scheduled it still plays the old audio that used to be in the file? WTF? Where is it getting that information from? There is only one copy of the actual show file on the entire system.
Yes I can see those files, but how can I stop airtime from caching them in the first place?
I don't want to have to set up a cron job to delete the contents of that folder every 10 minutes, is there a way I can just turn off caching all together?
Also, If I delete these files will airtime still function properly? Does it need these cached files for play out?
Hey @Ade, just to follow up on your other post regarding support and this specific topic, I think you've got a great contribution to Airtime, if you are willing, but I understand that you are having trouble wrapping your head around git...
You wouldn't FORK Airtime, but rather clone and then branch to create proposed changes (and development / testing) which would then be pushed to Airtime for possible merging into Airtime (once clean and working and of value to Airtime).
If not installed, install git on your system (generally a command line tools, although some developer tools such as Eclipse, will include addons for git).
And yes, a great product like Airtime, even with it's glitches, really can use committed people that generally become the "volunteer" support, creating a knowledge base of sorts, as well, that will help all those who come after.
I have a suspicion that you might be one of those people that contribute real value back to the community... ;)
I thought I would add (rather than edit my prior post) some more information to clarify (correct?) some things that I may have been misstated above.
I primarily work on master branches of git, since pretty much everything I do is on my own repositories. So as I stated above, creating a branch on the origin and doing a pull request would be the way I would expect merges to occur.
But from the git page I just read, apparently forks are treated as branches, so one CAN in fact fork a project, make changes on the fork, and then do a pull request on the master branch. In other words, a fork of Airtime acts as a traditional fork (away from the original code path), while it still behaves as a traditional branch which can be potentially merged back to the Airtime repository with a pull request.