this issue was spawned out of this thread

i've got some ideas for big change to the ripper script. it all kind of ties into reworking of the schedule to remove the one hour block structure. make it more of a start at this minute ends at this minute kind of thing. for the admin end i'm thinking everything will be rounded into 15 minute increments.

the idea is the archive downloads the week's schedule and writes it to a schedule.ini file. the file consists of a list of start times for shows and their durration (and maybe a program id in there). you schedule the ripper to run every 15 minutes so when it starts it checks if there's a program starting at the current time, and if so how long should it record for.

my aim is to minimize the requirements for the ripper script. the ini file is simple enough it can be edited by hand or generated by another program.

Comments

mfb’s picture

mfb
they or he
commented

My thought was the rip script could be web-based. e.g. cron script is "curl http://example.com/station/archive/cron" -- the cron script runs thru the drupal bootstrap like cron.php does so has access to settings, schedule, etc. stored in the database. The streamripper binary can be executed and all output piped to /dev/null so it can be backgrounded and the php script can end.

drewish’s picture

drewish commented

i see a couple of downsides. since you're exiting the parent script you wouldn't be able to call the drupal functions to import the audio file. so you'd end up doing the import in the drupal cron hook. and you'd want to be sure you didn't try importing a half finished file. using the .cue files as a "lock" which is deleted when the rip is finished works well. but that would need some sort of a script to add a delete command it after the rip is complete. for that to be cross platform you'd want to do the script in PHP... and now you're kind of back where we're at now.

it seems like it'd be a cool feature if you wanted to occasionally, manually, record parts of a stream (and knew how long you'd record for) but it doesn't seem like a compelling improvement over the current structure.

mfb’s picture

mfb
they or he
commented

the shell command you exec could string other commands on the end, using &, to e.g. delete a cue file. But I hadn't considered the cross-platform issue (I don't do windows ;)

I know some folks have managed to bootstrap drupal on the php commandline. This would give the cron script access to all drupal data and functions.

drewish’s picture

drewish commented

yeah, all my stream ripper code started on windows and as i was able to slay the servers it moved to freebsd. but, since i do my development on windows i like to keep it cross platform. looking at your sample script, it really sounds like it would be more like a general purpose module. you'd probably be able to talk me into adding it to audio/contrib.

mfb’s picture

mfb
they or he
commented

One thing i am trying to do is use one station_archive instance to archive multiple stations.

I haven't explored it fully enough yet to see how best to do this. I'd like it to work with a drupal multi-site setup (multiple sites sharing the same codebase, possibly with some db tables shared).

yay freebsd =)

drewish’s picture

drewish commented

I think it should all work fine... It'd use different taxonomies, you'd probably want to use different files directories... let me know how it goes.

mfb’s picture

mfb
they or he
commented

One thing I've noticed is that the schedule and archive sites need to have the same timezone setting.

at least, I hope that will get it working -- so far having a site in SF and a site in amsterdam has not worked.

I'm also wondering about drupal core's timezone deficiencies. In order to keep the time correct, you actually have to reset your site timezone twice a year, when the clocks change. This will probably cause all the shows archived in the other six months of the year to have the wrong time. Anyone using timezone dependent modules (station, event, etc.) really need to push for proper timezone handling in drupal core.

drewish’s picture

drewish commented

humm, yeah i guess you're right. i've got servers in different timezones but they're set to the same timezone. that bit about manually changing the timezone is a bitch. the good news is that if you change it right on time everything is fine, the times of old and new programs are correct. if you forget for a day you'll have a bunch of wanky titles.

drewish’s picture

drewish commented

over in this thread i've got some ideas that might make the timezone stuff easier to handle. the problem is that all the archive links are by recording time right? not the program, the idea there is to track program node id's and build the archive links that way. feel free to add any comment to that thread.

drewish’s picture

drewish commented
Version: 4.7.x-1.x-dev » 5.x-2.x-dev
Component: Code - Archive » Archive
damienmckenna’s picture

damienmckenna
Location TN, USA
commented
Status: Active » Closed (won't fix)

The Drupal 5 versions are no longer supported, if someone would like to step up to co-maintain it then please do so, otherwise future work will only happen for D6 and D7. Thank you.