It'll probably be done eventually... right? :)

I can help with testing and/or documentation if need be!! I just can't write code. :(

I think this is a really cool module for Drupal!

CommentFileSizeAuthor
#11 station-250533.patch8.16 KBdarrick
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

drewish’s picture

Once views and audio are ported I'll start on it until then it's a moving target.

Fayna’s picture

Yay I can add it to the list now! ^_^

ehowland’s picture

As you start thinking about Drupal 6, how are you thinking about the connection between Audio, Station, PEGevent, and maybe the Manhattan Neighborhood Network. From the Drupalcon notes/audio it seems like having discovered each other these projects might try some division of labor/coordination.

I am interested in using Station to schedule stuff for radio broadcasts. I guess PEGevent is more focused toward scheduling, but I like the way that Station defines a program (differently than PEGevent defines a program) and then allows DJs permissions to change the grid for that program (and not others). So perhaps I am already making the division of labor harder (PEGevent does scheduling, Station does web reporting of what happened/is happening). Still if we can resolve the namespace issue, a single instance could run both PEGevent and Station.

I also think that the Audio module does a good job of uploading music and extracting id3 tags. I don't particularly like how every program wants to have it's own location and directory structure for the actual music files. For a radio station that is a big chunk of disk space so you don't want to either copy all the files or enter all the id3 data by hand. I realize that Audio, for example, can have it's disk storage anyplace Drupal can read, but it wants to copy the files into that location as it imports them, rather than accepting that they are already there. And it wants the flles to be all in one big directory, unlike other programs that want to have a directory tree, if my experiments with importing directory trees is any indication.

I am not so much thinking that entering playlists on Station, but would rather like DJs to be able to upload playlists (from iPods or some other format -- in my case Zara Radio playlists) or whole shows (100 meg oggs for 2 hour blocks???) to do reverse podcasting.

I am thinking that after these playlists/podcasts are in the schedule, some other program, or drupal cron job would read the playlists and output this material to hard drive locations that can be picked up by the radio automation software. To some extent this is a question about whether an output module could share data with the Station schedules. I know everyone loves their data structures (and I am kinda fond of yours as well) but is it possible to agree on something like that.

I have read the post (http://drupal.org/node/191686) where tonedoggydogg asked how to do this and drewish's response was that Station is not about scheduling for broadcast, it is about reporting out schedules and archiving during/while broadcast.

I am thinking that after Boston Drupalcon that the scope or at least coordination of the projects is changing. I also note the scheme to get a boatload of money from the Knight Foundation to do this type of coordination/integration, which I support. But I wonder what the plan is before that happens or if the boat turns into a dingy or sinks before reaching port.

Actually, now that I think about it this is not about Drupal 6 at all.

NaheemSays’s picture

Just wondering if the 5.x-2.x-dev branch is stable enough to start porting?

I have ran the files through deadwood and am planning to fix up the rest of the things that coder module has picked up, but it will be a waste for me if the station_schedule and station_program modules are unusable.

drewish’s picture

The code is good I'd been holding off on it hoping to get the archive working with multiple schedules. So feel free to post patches for any remaining 5.x bugs and then get onto 6.x. I should just release a 5.x-2.x release and be done with it. Help with the port would be appreciated.

drewish’s picture

okay just created a 5.x-2.x-alpha1 release. please help test that out so we can get any bugs fixed and a DRUPAL-5--2 branch created so we can start getting going on D6.

also now that #289138: Locked field support. was committed i'd really love to migrate the catalog and program fields to locked CCK fields so we get the free views support and allow admins to re-order them.

drewish’s picture

i've been really busy the last few months but i'm trying to get the audio module updated for d6 right now. that'll be a requirement for getting the archive module updated.

drewish’s picture

Version: 5.x-2.x-dev » 6.x-2.x-dev

Just a status updated. Created a DRUPAL-5--2 branch so I could start doing the upgrade.

Had some time on vacation to start the port and he core station.module, station_catalog.module and station_program.module are pretty much updated. I'm trying to migrate data into CCK fields so that can in turn be used to get Views support for free.

It's going pretty well, archive and schedule are going to be a pain so I'm trying to figure things out on the simpler modules.

Testing would be very much appreciated but it's not ready for actually use yet.

drewish’s picture

I've gotten the playlist module updated and started the schedule. It's actually going really well and this is going to be a huge improvement in terms of functionality and customizibility.

Now requires the CCK, link, date modules.

drewish’s picture

Got the schedule's day view working.

darrick’s picture

FileSize
8.16 KB

Rough patch for porting archive module from 5 to 6.

drewish’s picture

Status: Active » Fixed

spent some time working on darrick's patch. added the schema support and split the module out into .inc files. also renamed the views files but didn't do any work on that.

i'm going to commit this and mark it as fixed. we should address any other bugs in new issues so we don't keep reusing this issue number on commit messages.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.