Hi Damien,
If a user does not follow the convention, his/her files will not be played.
Usually all shows are planned some weeks or days before. We use a google
calendar for planning this.
The calendar synchronisation creates all directories from this and additionally
creates the website entries with all show descriptions.
So mostly user dont need to create any directories, since this is automatically
done if the show is scheduled at the calendar.
So user just needs to drop its mp3 file into the right directory. If there is a
urgent need (e.g. someone has forgotten to schedule the show)
he sees all existing directories and can use them as template for the path
convention. User does not even has to take care of the file name or any metatags
(except correct audio duration metadata).
The scheduler writes frequently current and next show to log. So you can check
for errors, before the scheduler (or a cron job) would try to start a
non-existing file.
Additionally I do not want to need the user to care about correct file paths in
the jobs.
All of this should help to prevent misconfiguration or user errors.
There are multiple reasons why I do not to use a cron job for this:
- Most users I know, do not know even what a cron job is or what faults you can
do when writing one.
Additionally I would not like a separate cron job for each show (imagine 24
shows a day, 365 days a year, ok, today we have only around 10 preproduced
shows a week).
- If there are any changes needed, the user just needs to update the file
system.
So there is no database or any other redundant definition (like cron) of
what is to be played when.
- Furthermore the scheduler checks frequently if the current show player is
running.
If not, the start of the show will be cutted and played from the current
position.
This is useful for reboots due to power outages and other outages like
process failures. The scheduler would be respawned by upstart on failure.
Another case like this: the user puts the file at the right directory
still one minute after the show should have been started (many users I deal
with deliver their productions at the last minute .-)
As you can see the scheduler does a lot more than still starting a file at a
certain time (e.g. logging, process audits, house keeping, etc.) to keep
everything running
BR, Peter
Am 27.09.2011 20:33, schrieb Audiodef Online:
> That looks useful. What if a user doesn't follow the correct dir/file
> structure format? What advantage does this have over using a cronjob?
> Just wondering. :-)
>
> Damien
>
> On 09/27/11 18:03, Peter Retep wrote:
>> Hi,
>>
>> I am trying to use the pulseaudio mix channel as input for liquidsoap.
>>
>> Do you know how I can find out the names of available pulseaudio devices?
>> I played around with the names I see at audacity but unfortunately I did not
>> succeed.
>>
>> e.g. the following line will not work, since 'mix' is not the right device
>> name.
>>
>> liquidsoap 'output.file(%mp3, "/tmp/test.mp3"
>> ,input.pulseaudio(device="mix") )'
>>
>> Background:
>>
>> As you might remember we always wanted to have some dynamic scheduler to
>> start a show (a single audio file) at a certain date& time.
>> I have written now a small scheduler which frequently scans all
>> subdirectories below a storage /mnt/storage/ where start date and time is
>> mapped to the path by convention.
>> e.g. if file /mnt/storage/2011/09/27/20-00/show.mp3 exists, show.mp3 will be
>> started at 2011-09-27T20:00:00.
>> Starting a file means starting a cvlc for playout. (At our studio we put the
>> playout audio directly on the sound mixer).
>>
>> Directories are automatically created from our program schedule, so user
>> just has to drop a file in the right folder.
>> To delete or move a show, user can still delete or move the file.
>> The scheduler takes care of file changes, even for shows that are in the
>> past (like a show is inserted to be started a half hour before now).
>> This works good for now and has a very small cpu and memory footprint.
>>
>> Now I would like to build a continous stream with help of liquidsoap to make
>> the scheduler useful for other people, too.
>>
>> Best regards, Peter
>>
>>
>>
>> ------------------------------------------------------------------------------
>> All the data continuously generated in your IT infrastructure contains a
>> definitive record of customers, application performance, security
>> threats, fraudulent activity and more. Splunk takes this data and makes
>> sense of it. Business sense. IT sense. Common sense.
>> http://p.sf.net/sfu/splunk-d2dcopy1
>> _______________________________________________
>> Savonet-users mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/savonet-users
>>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1
> _______________________________________________
> Savonet-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/savonet-users
>
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
_______________________________________________
Savonet-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/savonet-users
