I think I went over the top with that

The main thing is for it to be possible to do three things (as far as I can think):
1. Display a nice date/time for the last time this song was played without having to resort to too much (or any) title-formatting. This is already possible given the way you have made the plugin.

2. Use a search of some sort to find songs last played on or after a certain day. This would be possible using YYMMDD instead of the current DDMMYY

3. Use a search to find songs last played more than a certain length of time ago (e.g. 24hrs). Just saying "the day before" doesn't work if it is just after midnight . I believe this would be best done with a timestamp in seconds as you can then get the current time and subtract the length you want. Neither of the above would allow this because ***this was incorrect! woops***

Ok what I meant in part 3 was assuming the split play_date and play_time fields, you couldn't say play_date LESS 040416 AND play_time LESS 2000 to get all tracks played before 8pm on 16-04-04. Of course this is irrelevant if you can choose the formatting to be: YYMMDDHHMM

If that was the case, the reason I was talking about



was to allow one field to be play_date_readable (for e.g.) and one to be play_date_calculable.

obviously with better names

You caught it before I could point that out.

The nice thing about formatting is that you could set the format for PLAY_DATE to YYMMDDHHMMSS, and easily use "play_date GREATER 0404142000". With a timestamp, you'd first have to figure out what the seconds past the epoch are (not very straight forward.

Please, make the storage of the time format standard, and then just choose the way it would be displayed. Not using a standard format means that you will have cases that make it impossible to determine the real date.

Example:
User stores the date as 10/08/2000. In Europe this means August 10th, 2000. In the US, it means October 8th, 2000.

Solution:
Always store the time in a well defined format. I would suggest the W3 Date/Time format. It is simple, well defined, a subset of the ISO 8601 standard, and the accuracy can be changed by where you truncate the date. It is also easy to parse for simpler display. (You may want to leave out the "T" in the middle for readability though.)

This is a tricky issue. Say a common format is chosen. Do we store timezone information? We don't now, it's just the local time. If we store timezone info, this complicates displaying a local time in the playlist (or wherever). Or, we could store everything GMT, but displaying local time is still a problem.

My point is this: There is no simple way to handle this when this info is expected to be used by TAGZ. If someone were using this via C++, it's a different question, and I would store a timestamp.

Would it not be acceptable to allow the user to specify the format? That is, you could choose to enter a format that produces ISO 8601.

New version:

1.3 (Apr 16 2004):

1) Added support for specifying the date/time tags and format. The tag name can be specified, or left blank to skip. For either field, a format string can be specified.



The preference page lets you specify up to two tags, and each corresponding format. If you don't change the preference page, it should work exactly as the previous version.

If you want something like teetee desired, you could change the first tag name to "PLAY_STAMP", and use a format that produces YYMMDDhhmmss, then blank out the fields for the second tag.

It's also possible to use the masstagger to combine (and reformat) the existing fields into a single field. For example, use "Format value from other fields", specify PLAY_STAMP as the destination field name, and for the Formatting Pattern, use:



This would combine PLAY_DATE and PLAY_TIME into a PLAY_STAMP of the format mentioned above.

It will make more sense when you look at the pref page and formatting help dialog.

Play Count 1.3 (Binary)

Play Count 1.3 (Source)

Very nice, thanks tboehrer :]

For those who want to use the W3 Date/Time format as Pamel suggested, I've saved you the (little) trouble so you can just paste this into the format:


Edit:
you can also convert the older PLAY_DATE and PLAY_TIME tags to this format, as tboehrer pointed, using the Masstagger's "Format value from other fields"; use the following:

Remember to replace the "+08:00" with whatever timezone $T gives you

Edit 2 (yeah I know; bored and nothing better to do..):

Formatting string writers, you can parse this into a nicer display
(namely, 2004-04-15T21:02:05+08:00 -> 2004.04.15 9:02:05 PM) with the following:

What's nice about this one is that you can easily change the separaters if you don't like '-' (I find '.' the most visually appealing)

Edit 3: small fix in above title formatting (12 PM/AM)

I'm struggling to see the benefit of this new feature... would putting them in this said (^) format allow sorting? (Because at the moment PLAY_DATE is just treated as a numerical value when sorting.) Or is the benefit a better appearing/easier to read timestamp?

Steve

Okay,I'm trying to write a script that'll automatically rate my files according to number of plays. I'm new to Foobar, and I'd put myself in the 'Beginner' catagory of programming skill, but I really can't see anything wrong with this. Maybe one you funky people could help?



The field to be endited, quite obviously is RATING. If anyone needs it explained in English I can do that, but I think its pretty obvious what I'm trying to achieve.

Steve

[EDIT] Atm, this returns 5 for every track [/EDIT]

You might want to give $ifgreater() a try.

I don't think you can use < directly as mathematical functions in TAGZ.

Hope this helps. In case you have anymore questions, feel free to ask.

You can find a definition of $ifgreater in the titleformatting help.

edit: The usual late discovery of a typo

The benefit of changing the PLAY_DATE field to at least YYMMDD is that you will then be able to sort by date across months (and years). With the default format, if you play something on 30th April (300404) and then something on 1st May (010504), they will be sorted wrong (10,504 < 300,404).

Using the full timestamp in W3 Date/Time format allows you to also sort by time (up to second accuracy). Also, if someone wrote a plugin using these timestamps for part of its functionality, it would be better if there was one format being used with all the possible information it.

I don't think sorting across timezones would work but that would be a lot rarer for an individual .

PS Thanks for the new version tboehrer

I would like an option like "only update in db", else i have to fill in all my file types in DB Only Mask

Cheers - that works fine :-)

and Cheers teetee for that explanation. I'll give formatting a sorting a go later today... its a feature that I'd like to make use of.

Steve

Cheers, this was a fantastic help. I used the standard formatting for play_stamp, and I used your code to convert the old tags.

I edited your script slightly I changed the date around so it was in a nicer, British format: just because the tag is in that silly order doesn't mean I have to view it like that

Thanks alot,
Steve

Nice pointers guys!! I appreciate the AM/PM formatting... I was too lazy to figure it out myself.

Linkin Posted on Apr 17 2004, 02:13 AM:


*.* should work. I think...

Please excuse my lack of title formatting skills, but I don't know where to place the string to show the counter (just the counter, not the last time played) at the far right of the playlist.

Here is my current formatting string:


If someone could tell me where in the string to put it, that would be great.

Thanks for the plugin, I'm looking forward to using it.

Silverbolt I'm undermiming you again

I've edited your formatting script again Here's mine now:


Did this because when the track hasn't been played loadsa horrible random stuff was being displayed in Last Played collumn. There is probably a better way of scripting it, but this was the only way I could think of.

Steve

@Addicted:

That seems to be the global script... go to Collumns, add collumn, call it what you like, and in the display tab, paste the script.

Steve

Sorry, I dont use columns..... just the default playlist with the above formatting string...

(edit spelling)

@addicted

You can add this at the end of you code or where ever you want it!!

Thanks a lot..... I even figured out how to set it's color and add a "pipe" on the left side.

I'd love this plugin if it was able to put the stats on a separate (plain text?) file and that could be then accessed through some sort of interface.
The only problem I can figure would be knowing what songs are really played. Perhaps it should track them by paths, but then, if I rename a file it would b0rk the statistics. Perhaps it would be somehow possible to see changes made by foobar's masstagger/renamer, as that's the only way I rename my files.

It is possible to get notifications of files being moved by masstagger and similar plugins (if there were any), so that's not a problem. If the play counts are stored in an external file, path and subsong index should be used as key.

I wouldn't hold your breath for me changing it to write to an external file... but hey... I posted the source.

Thanks, I already have enough plugins of my own to keep me busy.

I'm not asking you to change the current behaviour, just adding some new functionality and for me the source is no use as I can't program at all.

how could it make that info available to all other parts without altering database? foosion?

The links (from the first post) are not working anymore. Any specific reason, hosted on your own computer? (tboehrer)

Seems to work for me... I'm not really hosting it personally so to speak. It's running on my businesses external web site. It's a server dedicated as a web server. Anyone else having problems?

Neksus may still have it mirrored at:
http://www.neksus.dk/foobar/foo_playcount.dll

Edit:While I can't rule out a server problem, there were network problems with our provider this morning... up and down... up and down. Of course, this can happen to any server...

Yes my mirror is still up!

--
Neksus

Sorry, exactly what info are you referring to?

Besides the fact that this plugin doesn't take into account whether you've actually played through the file, there's another problem... if you play through most of a song, close Foobar while it's playing, then open it again it'll count it as being played twice.

I'm afraid you'll have to be more specific... I can't reproduce this behavior. What do you have your playback completion slider set at?

Edit: I see... If you have "Resume playback after restart" enabled, it does this.

My files doesn't get updated when the database is disabled, is this normal behavior? (using 1.3)

Yes. But when I go in to fix killmasters issue, I'll make that an option.

New Version 1.4 (Apr 25 2004):

1) Switched to using actual played amount to calculate update point. i.e., Previously, the percentage complete was based on position in the track; once the seekbar passed the set percentage amount, the update took place. Now, the update only happens when the correct percentage has actually been played.

2) Fixed issue when "Restart playback after restart" is on, and Foobar is shutdown while a track is playing, after restart, the counter could have been updated twice. This was actually fixed by change #1 (above).

3) Added option in preferences to disable skipping of tracks not in the DB.

Known issues:

1) The "percentage complete" is reset when playback is manually stopped. ex., If you play 50% of the file, and press stop, then restart playback, the percentage complete starts again at 0.

2) If you have "Restart Playback after restart" active, and shutdown Foobar while playback is active, the percentage complete is NOT preserved. i.e., At restart, the percentage complete starts again at 0.

I am undecided when/if I will address these. If enough people want it, I suppose it can be added at some point.


Play Count (Binary)

Play Count (Source)

Seems to be working well

Cheers,
Steve

Just installed the latest version works great.
However this was not fixed:

The double update still happens it just happens a little later. Here is an example:
I have update counter set to 10%.
I play a song until it has played 50% (counter was updated at 10%) and close foobar when I restart foobar the song starts and when the playback reaches 60% the counter is updated again.


I guess this is covered by this:



Thanks for the great plugin.

Perhaps that could be fixed by having the plugin make a note of what song is currently playing when Foobar closes? I'm no programmer, but it probably wouldn't be that hard to set a "file's been played enough" flag at close.

One would think. That's what I thought. But it's not as straight forward as I would prefer. But then again... that's the challenge.

The problem is, given the way it's written, a "stop" clears the info. But on system shutdown, I get the stop prior to the shutdown. i.e., The info is gone already.

It's not a big problem... just have to rethink it a bit.

While I'm not effected by this bug, I can't just let you guys live with it... I see what I can come up with. Shouldn't take too long.

things like this play counter etc. my understanding is that plugings etc. can provide additional 'variables' to formatting functions using that 'extra items' list, or what is its name.

however, it's not possible to do that on general level, is it? like appending common list of these name-value pairs to every call to formatting functions (it would be nice to have callback which would get called prior to any formatting function with metadb handle and would return secondary 'extra items' list).

so, right now, one has to store anything he wants to be available to all parts of foobar in database / tags, am i correct?

possible ways in new versions of foobar:

1) provide above-mentioned callback (there could be problems like duplicate names - from database, callbacks and the caller)

2) give us a way to make some info in database permanently db-only (flag or something)

Yes, that's correct.

New Version 1.4.1 (Apr 28 2004):

1) Really did fix issue #2 from 1.4

If you don't require this fix, there really isn't a big reason to update.

Play Counter 1.4.1


I'm going to be out-of-pocket for a couple days... if the new version has a problem, you can get the 1.4 version at

Play Counter (Previous Version)

I tinkered with your source code a bit this morning, producing the following changes:

1) All tags are written to the info block instead of metadata.
2) Fixed timestamp field is stored as milliseconds elapsed since 1/1/0001, UTC.
3) Configured fields can be whatever you want, formatted by the same rules as strftime, in local time. Since they are always formatted from the UTC timestamp, they will be regenerated whenever you reload info from a file that is already stored in the external play count database.
4) Since info can be munged by reloading, play count and UTC timestamp are stored in an external database, referenced by file path and subsong index. For now, this database is an external MySQL database, interfaced by pmysql class. I may work on a custom internal database system later.

There is no configuration for the database, and I have not even modified the configuration to remove the now obsolete database-only options or add configuration for the external database.

The change to strftime formatting was due to the fact that I decided to use the PTypes datetime type and related functions for the play start time, since I was already using the PTypes-based MySQL wrapper.

The database reloading action queues a message window to retrieve the values from the external database after the callback, since modifying the database from within callbacks is a big no-no. It's still a dirty hack, since the info is refreshed from the external source after the actual reload, so the info will not be visible immediately. Example, you will not see the delay reloaded info if you click reload from the file info dialog. This is basically a dirty workaround for trying to do something that is otherwise impossible with the current API.

This is not in any workable condition for release, at least not yet. I will integrate your 1.4.1 changes, if you included them in the source archive ... later.

What is the advantage of any of these changes, is it your expectation these changes be incorporated into my version, and if the info is stored in an external DB, can it still be accessed from other tools like DB Search or the Playlist Generator?

I know this is a terribly dumb question in all likelihood, but is there a way to get the play count to display in the regular track list? I have %PLAY_COUNTER% listed as part of my display string but it shows up as just %PLAY_COUNTER%.

Can someone help? Oh, and my string is as follows:



As always, thanks in advance for the help.

It can only be accessed by other tools as long as it lives somewhere within the metadb. It will, even after info reload, but the reload hack is a tad dodgy.

Requiring an external MySQL database is a bit much, as well. I only made it for my own use, but I may share it widely if anyone really wants it, along with a PHP page for producing a nice Last (15) songs played page.

I did not incorporate most of the latest changes, mainly because of the initquit hack. Hmm, maybe the variables that config variable needs to store from could be made static global, since the callback class is a static single instance anyway. That instantiate/cast method is a bit dodgy, never mind the restart guesswork. Oh, and what happens if a user closes the player before a second has elapsed? Hehehe.

I'll post some source code a bit later. It currently requires both PTypes and the pmysql class, as well as MySQL source code for the mysqlclient library. (Since there is no binary that links against the dynamic runtime.)

Maybe I should just up the external requirements to HTTP server and PHP so I can reduce all the component-side overhead. The current binary is exactly 200KB.

WARNING.... geek talk about to happen....



Since the initial time callback never arrived, it will be as if the file was never started. Upon restart, everything will work out. The end result? It will work properly to within 1 second. I believe that to be acceptable. Yes?



The cfg vars actually should have been static. But the fact they aren't doesn't really change anything. They are already global. i.e., playcounter sets global variables already, yes? Or are you referring to something else?

Actually, I never considered the initquit technique a hack. The initquit technique, is much cleaner than other alternatives. The key there was getting the "on_quit" shutdown callback. What other technique can you think of? The initquit could call a global callback function, which in turn calls a global "playcounter" variable. Not very clean or OO. What I really would have liked to do was implement the initquit interface on the playcounter class so that it could receive the callback directly...



The restart logic is semi-dodgy because fb2k doesn't provide enough info (that I can see). Can you think of a better way? If the "on_playback_stop" would provide a reason that indicated a stop is being called because fb2k is shutting down, AND there was an event telling us a restart was happening, it would be much much cleaner. But in the end, while confusing, appears to be safe.




So instead of writing to a DB you write to an HTTP service... thereby eliminating MySQL? Makes sense since that would have been my first worry. But my ultimate concern is that being in an external store precludes searches using play count info, which is really what the use of play count info is was for. Though... I've seen requests to have it external, so your changes will be useful to some. I believe I read in the foo iPod thread that they wanted it external?

Oedipax Posted on Apr 29 2004, 04:27 PM


Yes. It works lik any other tag. I can't test it where I am at... no fb2k (*gasp*) on the computer I am using...

It looks like your single quotes are wacky...



If this doesn't help, and someone else doesn't help first, I will be in a position to help tomorrow night (or if it's not night where you are at... 22 hours from now).

WARNING: User is running on fumes. Gee, I don't know why I didn't think of that. Umm, no crap? :B


I mean the current local variables in the callback class. Since the callback is a static class, you can safely move the _played and _length variables out, rename to g_played/g_length, implement the cfg variable storage directly from on_quit.


No, I meant using HTTP with a PHP script as a bridge to MySQL. That way, the component is only about 20-30KB, using PTypes or even simply wininet to perform the http request. Then you only have to worry about URL encoding the query strings.


Which is why it is still stored in the database. Searches can reference info fields, I think...

The external database is only backup for when the user reloads the info from the file. The only problem is the uggly delayed insertion *cough*bloodyhack*cough* used to feed the info back into the database.

There might be some info insertion filters or services for such crap as this in the future, and then again, there might not.


Right now, the info is duplicated in readily accessible info fields, and currently, only the ReplayGain info fields are ever written to the file's tags. So, this info will never modify the files.

In the future, I can add more options for actually manipulating the data...

- Forcing reload of play count / timestamp for all files referenced in the external database (if you change the formatted tag options, they will be regenerated)
- Forcing scan of external database for entries no longer referenced in the player metadb
- Hilighting entries in the current playlist based on a query to the external database ... could be simplified to facilitate a simpler internal count database, or allow full MySQL query.
- Build a playlist based on the above

Hmm, gee, I could some day start working on a MySQL-based replacement for the core DB, if the API allowed for database replacement. I'm not too sure how I'd go about storing multiple values under the same name... (Why yes, fundamental differences in the Foobar2000 and MySQL database systems would make it hard to use MySQL as a replacement for the core DB, and they don't stop at just this.)

Hmm, now that I think about it, it wouldn't be too hard to store metadata in one table and info in another. Multi text strings in one column would be a bit of a challenge. Not to mention it would be nearly impossible to preserve original field order without a special field to indicate the original order. It would also prove fun creating new fields in the table whenever a new field name pops up....