Confusing Use of Time

dReKurCe has asked for the wisdom of the Perl Monks concerning the following question:

Greetings monks: The following is an xmms hack that logs the track listened to and its time played. Interestingly enough it created time annomolies! Any monks that have the time to spend with the following code would help this intrepid coder on his way through a journey of time. First to impliment the script tracktime, edit the command parameter in the Song_Change1.2.4(libsong_change.so) {this plugin is enabled in the previos dialouge} to include: echo %s >>/opt/www/musicpub/tracks |perl /home/japh/bin/tracktime These are accessed via OPTIONS,PREFERENCES,EFFECTS/GENERAL PLUGINS ii)The code for tracktime:

my $tracks;
my $ritetime;
my $philetracks;

opendir(MUSICPUB, "/opt/www/musicpub/");
while (defined($tracks=readdir(MUSICPUB)){
      if ($tracks=~m/tracks/){
          $philetracks="/opt/www/musicpub/$tracks";
      }
}
closedir(MUSICPUB);
$ritetime=(stat($philetracks))[9];

open(TRACKS, "+<< /opt/www/musicpub/tracks");
print TRACKS "$ritetime\n";
close TRACKS
[download]

This code produced the following output upon initial testing:

311-Evolution:
1093970368
311-Freak Out:
1093970368
311-FullRide:
1093970368
311-Champagne:
1093970739
311-Hive:
1093970368
[download]

Thanks for any insight into this temporal predicament. # I'm posting my progress with the tracktime script in question. It would seem as a miscrient file created by early testing (the file was named tracks0) was somehow being matched by the first regular expression!? So, removing tracks0 from the target directory magically fisked the problem.The tracktime reported is in ascending order so futher manipulations of the difference and conversion functions can be added.Thanks for the help, as far as the regex is concerned possible explanations would be welcome. Now , back to thinking about Gauss and the number 5050....

Comment on Confusing Use of Time Select or Download Code

Replies are listed 'Best First'.
Re: Confusing Use of Time by chromatic (Archbishop) on Aug 31, 2004 at 22:27 UTC
According to perldoc -f stat, the entry at index 9 of the return value is the last modified time of the file in the number of seconds since the epoch, if your filesystem supports that information. What time information did you expect? Did you perhaps want index 8, the last accessed time? Even then, I'm not sure that the filesystem stores any information about how long XMMS played a particular file.	[reply]
Re^2: Confusing Use of Time by dReKurCe (Scribe) on Aug 31, 2004 at 23:26 UTC
Thanks for the reply. The time reported is indeed the number of seconds since the epoch(i'm thinksing now about the IEEE and the cookbook quote;) Perhaps I was accordingly mistaken in thinking that time flows forward: ie;the writen track title echoed to the tracks file toggles the mtime at song changes,so the two time indices are the ending of one song to the begging of the other.	[reply]
Re^3: Confusing Use of Time by iburrell (Chaplain) on Sep 01, 2004 at 17:56 UTC
You are mistaken. The mtime is the time when the file was last modified. For a music track, this is likely when the file was created or copied. xmms should not be modifying the files when it reads them. You should try looking at the access time (index 8 in stat array). It will be changed by xmms reading from the file. You might be able to make the assumption between the atime on the previous file and atime on current file is the play time for the current file. But you will have to verify this. It will depend on when xmms calls the plugin.	[reply]
Re: Confusing Use of Time by Old_Gray_Bear (Bishop) on Aug 31, 2004 at 22:27 UTC
Pardon my confusion, but did you expect the mtime to different or the same? You seem to be reporting the results of several run. And the way the code is currently constituted you are only getting the mtime of the 'last' file in the directory; perhaps the stat and its friends belong a few line further up? Inside the while loop, perhaps? If your question is why are several of the times the same, I should point out the mtime is the last -modified- time; not necessarily the creation time. ---- I Go Back to Sleep, Now. OGB	[reply]
Re^2: Confusing Use of Time by dReKurCe (Scribe) on Aug 31, 2004 at 23:19 UTC
Thanks for the suggestions howevr the same time is reported on two succesive for track changes when using field 8 of stat as well.I'm not sure that I see the logic in including the stat ealier however!?The atime or mtime shound be toggled when the shell writes the track title to the tracks file.	[reply]