Creating a REAL smart block
  • 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?


    Post edited by Ade Hill at 2014-09-14 12:08:23
  • 26 Comments sorted by
  • Its quite hard doing this because of the way AT have organised their database.

    Firstly a Smartblock is a concept - not a thing. Its just a recipe to make a playlist.

    You have to tie together the schedule, show, show instance and files tables and keep them all in step, calculate timings precisely yada yada. :(

    However - some time ago, I thought of a CHEAT which would be quite simple to implement - but does not go all the way to fixing it

    It should be possible to do a SHUFFLE of a smart block - without nasty maths. Would that help?
    No longer using Airtime or Libretime.
  • Hey John,

    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.
  • John, have you tired using a cron job approach?

    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.

    Post edited by Ade Hill at 2014-09-14 16:54:28
  • 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
    No longer using Airtime or Libretime.
  • Yes I understand the concept of what smart blocks are, sorry I should have mentioned that before ;)

    I was talking about reusing that same code / rules that airtime runs to create the blocks as you mentioned above.

    Do you know where that is located or what it looks like?

    I'm up for having a pop at this :)
  • 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.




    Post edited by Ade Hill at 2014-09-15 08:50:13
  • 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.



    No longer using Airtime or Libretime.
  • 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}' &

    then you add a webstream into airtime to http://localhost:8080/show.mp3.

    I use a similar method to transcode a satellite radio stream to airtime.
    Post edited by Quentin Divay at 2014-09-15 15:39:21
  • 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.

    I'll let you know how I get on. ;)
    Post edited by Ade Hill at 2014-09-17 10:47:26
  • 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.


    No longer using Airtime or Libretime.
  • 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.
  • Trimming the show file would not work for me - I want to here the end of the story each time and 'who dunnit'.

    Firstly I would empty the browser cache. Does that fix it?

    If not: Look under folders under the stor folder and you will find files with like 1.mp3 3.mp3
    Its self cleaning.
    Post edited by John Chewter at 2014-09-18 20:17:03
    No longer using Airtime or Libretime.
  • Hi John,

    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?
  • FFS... Just tried deleting the cached files and nothing plays :(

    Just what you want on a live station...
  • When the next show starts it should rebuild it
    No longer using Airtime or Libretime.
  • Yes it did exactly as you said, but only does it after it has played dead air for a show.

    So....

    1) I delete the cache 10 mins before a show is due to start.

    2) 10 mins later the shows starts - no audio file

    3) The cache gets re-populated and then the following show plays as normal.
  • Weird. Mine works fine.
    No longer using Airtime or Libretime.
  • What version are you using John?
  • 2.51a
    Post edited by John Chewter at 2014-09-22 10:34:23
    No longer using Airtime or Libretime.
  • 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...

    I've found this is a really good git flow tutorial that is very straight forward:
    http://rogerdudler.github.io/git-guide/

    There are other good beginner and up guides to follow that up.

    Airtime's github repository is (of course) here:
    https://github.com/sourcefabric/Airtime

    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).

    With Git installed, you simply:
    git clone https://github.com/sourcefabric/Airtime.git

    And go from there.

    Welcome to Open Source...  ;)

    Will be interested to see how this smart block feature works out.

    Cheers,

    Kevin

    NB:  Oh yeah, don't forget to review the Airtime Developer docs:

    https://wiki.sourcefabric.org/display/CC/Developer+Docs

    https://wiki.sourcefabric.org/display/DC/Developer+Tools
    Post edited by krattai at 2014-09-22 13:00:04
  • Thanks Krattai,

    I will have a good read of those links you posted, appreciate it.
  • Not a problem.  :)

    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.

    Maybe a little confusing, but it does ultimately make sense.  For more info, refer to this github doc:
    https://help.github.com/articles/using-pull-requests
  • Hi there, any news about a strong workaround ? I'm facing the same problematic.

    Let's keep Airtime alive it's a great project. Thanks + Best !