Audio Import time offset

Is the problem with the program title information or with the "added by admin at XYZ" displayed on the node?

Wait, so what time based info is correct? any of it? Three possible parts:
- Program info. Is the correct program selected.
- Node creation time. Is the time and date on the "Submitted by admin on XYZ" string correct?
- Taxonomy terms. Is the correct time being selected?
And if they're wrong which way, + or - hours, and by how much.

okay that makes sense. the archive doesn't assume that the schedule and archive are in the same timezone but it does assume that the file is ripped on the same machine. the easiest thing is for you to modify your ripper.php script to add (or subtract) an offset when it copies the audio between machines.

humm, after hearing from the WHRC guys that they're having a similar problem, i'm thinking it might not just be a problem with your setup. i'm going to try to get some more info from them.

in the mean time, you can just add or subtract (i'm not sure which way it'd have to go) 7200 to the timestamp that's used for the filename in the ripper script.

I've just committed some changes to CVS that I hope will fix some of this. The timestamp from the filename is a GMT timestamp, this is now converted into a local timestamp and used for the formatted date and the taxonomy terms. I've done some basic testing and it looks good but your setup is obviously different so let me know if it's better or worse.

in the hope that everything works great ;)

the ripper script shouldn't make any difference. are the times all still wrong the same way?

humm, looking at the wsum.net site, it looks like the most recent changes to the archive module aren't there... can you verify that the CVS ID is // $Id: station_archive.module,v 1.7.2.12 2006/09/26 16:30:57 drewish Exp $
or greater?

(though, if it is not, you'll want to update the whole set of modules)

i've fixed it so that the created time is now a GMT timestamp rather than a local one.

looks like this wasn't totally fixed: http://drupal.org/node/93576

tuquee, if you want to follow up here with more details that'd be helpful.

Hey guys- I upgraded my station.module (and archive/schedule as well) to cvs because I was having this problem as well. Unfortunately: still no luck. All my audio is offset by one hour, even though both servers are in the same timezone. For instance, the show "Hip-Hop Tastebuds" is scheduled for 10pm on Wednesday, but in the most recent archive entry for it, it appears as 11pm.

tuquee, that's wierd that the taxonomy time is off. can you gather up some information for me? it'd be helpful if you could install the devel module on both machines. it make it easy to findout the underlying values of a node.

first well gather some some timezone info from both archive and schedule computers. the idea is to determine if one of the machines has different timezone settings from the other, and also, one has different timzone settings running on the command line and serving webpages (the ripper.php runs on the command line and Drupal import runs under the webserver):

• value printed by running echo time(); through a webpage at roughly the same time
• value printed by running echo date('r'); through a webpage at roughly the same time
• value printed by running: php -r "echo time();" on the command line at roughly the same time
• value printed by running php -r "echo date('r');" on the command line at roughly the same time
• drupal's timezone offset (in admin/settings)

next we want to look at the importing process by following one mp3 as it's recorded and then imported. please provide the following:

• before importing, the original mp3 file name. this should be the timestamp when the recording started.
• after importing, open the audio node's object structure tab (provided by the devel module) and copy and paste out the whole node

via webpages:
schedule: 1163107597 / Thu, 09 Nov 2006 13:26:15 -0800
archive: 1163107572 / Thu, 09 Nov 2006 13:26:12 -0800

The server running schedule doesn't accept -r as a php flag, so I couldn't do command line testing.

Audio files:
1163102400.mp3 was imported as Unscheduled_programming_(12pm_on_Nov_9th,_2006).mp3, which matches the taxonomy label. 1163106000.mp3 is the file currently in the import directory, presumably being written to at the moment.

oops, forgot the node structure:

nid

65
vid

65
type

audio
status

1
created

1163102400
changed

1163106315
comment

0
promote

0
moderate

0
sticky

0
revision_timestamp

1163106315
title

Unscheduled programming
body

teaser

log

format

0
uid

1
name

archive
picture

data

a:3:{s:6:"submit";s:18:"Create new account";s:7:"form_id";s:13:"user_register";s:10:"form_token";s:32:"32f56d87110c25b128452c13f466c534";}
audio_fileinfo

Array
(
    [vid] => 65
    [nid] => 65
    [play_count] => 0
    [download_count] => 0
    [downloadable] => 1
    [fileformat] => mp3
    [sample_rate] => 22050
    [channel_mode] => mono
    [bitrate] => 32000
    [bitrate_mode] => cbr
    [playtime] => 62:56
    [filesize] => 15110223
)
title_format

%title
audio_file

stdClass Object
(
    [origname] => Unscheduled_programming_(12pm_on_Nov_9th,_2006).mp3
    [filename] => Unscheduled_programming_(12pm_on_Nov_9th,_2006).mp3
    [filepath] => files/audio/Unscheduled_programming_(12pm_on_Nov_9th,_2006).mp3
    [filemime] => audio/mpeg
    [filesize] => 15110223
)
url_play

http://archives.rosslandradio.com/audio/play/65
url_download

http://archives.rosslandradio.com/audio/download/65/Unscheduled_programming_%2812pm_on_Nov_9th%2C_2006%29.mp3
audio_tags

Array
(
    [title] => Unscheduled programming
    [year] => 2006
)
audio_images

Array
(
)
station_archive

Array
(
    [program_nid] => 0
    [program_title] => Unscheduled programming
    [imported] => 1163106315
    [permanent] => 0
)
taxonomy

Array
(
    [30] => stdClass Object
        (
            [tid] => 30
            [vid] => 1
            [name] => Thursday
            [description] => 
            [weight] => -3
        )

    [36] => stdClass Object
        (
            [tid] => 36
            [vid] => 1
            [name] => 12pm
            [description] => 
            [weight] => 12
        )

)

Oh, and both machines' Drupal timezones are set to -0800.

tuquee, looking at the node you provided it looks like everything is working as it should be. could you point out specifically what times are wrong? everything (taxonomy, node create date, and filename) looks like it's thrusday 12pm on nov 9th...

It's not the times per se that are wrong: that is the correct audio file for that period in time, and it does have the correct taxonomy label. The problem has to do with correlating to the schedule.

If you take a look at the archives site right now and compare it with Sunday's schedule, you'll notice that each program title is one hour ahead of when it airs. (For instance, the audio for "Hip-Hop Tastebuds" is the audio recorded on Monday at 12am, but that's not when the show actually aired.) That's the major issue here, and sorry if there was any confusion.

tuquee, i see what you're saying. could you enable the current program block on the archive server?

also you should enable the contact form on your profile: http://drupal.org/user/52198/contact it'd make it easier to contact you off thread.

tuquee, i need you to get that time info from the command line php. if your php doesn't support -r you can put those commands into a simple file and run it on each machine:

echo time() ."\n";
echo date('r') ."\n";

because if everything looks right when it's imported then the problem is probably with the timstamps used to generate the files.

Here's the command line timestamps:
schedule:
1163458438
Mon, 13 Nov 2006 14:53:36 -0800
archive:
1163458414
Mon, 13 Nov 2006 14:53:34 -0800

And the current program block is now enabled on both machines. (I've also enabled my personal contact form.)

I'm in the studio right now doing "tuquee! the show"- however, only the schedule server wants to acknowledge it, as the archive server still thinks that we're on autopilot according to the Current Program block.

tuquee, good to know. i hadn't had a chance to check your site but i was hoping there'd be a clear descrepency between the two sites. i'll see if i can't figure out why that'd be the case.

tuquee, one thing that occured to me for you to check is that both machines' clocks are accurate. if they're 5 or 10 minutes off that would probably screw up the timing.

If you run the servers, I'd recommend using NTP to sync to "real" time.

archives are set via NTP, and i'm assuming the scheduler is reasonably accurate; however, it's not within my control.

mattrock- i just turned user time zones back on to see what user/1's was set to, and it was -0700 instead of -0800. i've reset it- hopefully this will solve my problems!

ah, that'd would do it. drupal doesn't switch timezone automagically. the taxonomy terms are "local" but the timestamps are translated based on your user profile's offset.

bah! no luck- i made sure that the timezones were the same at both the system & user level, but no dice! the archive system is still one hour behind in terms of the schedule.

Another observation: the archive server's Current Program block syncs up with the schedule server about 1/2 an hour into the program. Weird.

I noticed that 1/2 bit when I was working on this yesterday. I've got no idea what's happening with it. I changed around the way that the now playing information is retreived/cahed. If you wouldn't mind, update to HEAD and then see if it start syncing up at the 1/4 hour instead.

does clearing the cache on the archive server get the now playing info updated correctly?

updated to HEAD, cleared cache- it's now 15 minutes behind on the current program block, but the hour offset still remains a problem.

humm, this is freaking annoying. i've got this feeling that your clocks are just off enough that the way the times are rounded is screwing it up. we might just have to add a "magic" number offset to the time functions.

oh, you probably want to start running 4.7 now. HEAD will be 5.0 specific from now on... well until 6.0 comes out anyway ;)

an update: the archive server crashed a few days ago due to an HD failure, and so I took the opportunity to reinstall the software on it according to the howto on your website. unfortunately, still no breakthrough; the schedule delay is still there.

okay, then we'll create a setting for the archive to add in an magic number that gets added to the time so you can hack this to get it working.

I've just committed an offset setting that should correct this. Feel free to re-open the issue if it didn't fix it for you.