Problem with that is, how do you access it. Usernames have varying lengths, therefore it becomes impossible to format it through TAGZ.

That why I included that code...if you always place it at the end of the last_played field, you just access it by taking everything to the right of your fixed-length date/timestamp data.

But I think you're right...I don't like tag field proliferation, but this data is of a different type than date/timestamp, and even if consistency is maintained by each user with himself, it would be nice if .fcs developers could account for this data as well.

I mean hey, if it's just optional, why not throw it on there? I'm sure someone will find a use for it. LAST_PLAYED_BY is a very logical name, too.

The $right() function is horrible on performance. Apart from that, what if I wanted to add other variable length options in between.

Eg. 2005-06-11 08:02:04 Sunday ATHLON3500 kl33per
Here you have regular timestamp, the day, name of the machine on the network, and the username, but you can't format it with TAGZ.

$substr(%last_played%,20,$len(%last_played%))

...will display all appended info after the date- and timestamp.

One coud split that by resource-hungry searching for spaces as seperators and then splicing the substring. But for sure not an optimal solution.

- Lyx

But if there are multiple pieces of information, all with varying lengths after the official timestamp, you can't format it.

Wow, so much has happened this morning. Reason I initially used underscores was because I was just following the established Matroska fields. Could've gone either way, but to be honest, kinda glad things ended the way they did (my brother just finished backing up all his music to DVDs a few days ago). Thanks, kl33per and hope you aren't getting too stressed :3

Stressed is my middle name .

Edit 1: Is there anyone actually interested in having a LAST_PLAYED_BY field. If you missed it above, it stores the user name of the last person who played a particular song. Only useful to those people who have multiple users on one computer, or who have there music collection available on a network.

Edit 2: Tag will only work on Windows 2000 and above. I'm not sure what will happen on Win9x machines.

That'd be cool (my music's on a network). Probably would use it if you implemented it, but no biggie if you didn't.

Well atm, it looks like the next version will support both a LAST_PLAYED_BY field and a PLAY STAMP field, as per topdownjimmy's suggestion above. LAST_PLAYED_BY is turned on by default (easy to turn off) and PLAY STAMP is turned off by default.

Edit 1: PLAY STAMP format is "2005-01-01 00:00:00 User Name"

What if the information contained spaces (eg. "User Name").

An Update

I have now built a new version of foo_playcount which supports a new tag PLAY STAMP, and which supports my proposed amendments to the tags LAST_PLAYED and FIRST_PLAYED. My proposals can be found here.

This build will become available if/when my proposal becomes an encourage standard, so please head over to the thread linked above and have your say.

can we use
"yyyy-mm-dd hh:mm:ss w /User Name"
because with the "/" we can use $filename(%LAST_PLAYED%) to display the user name
(it only would make a problem if "/", "\" or ":" would be in the user name, but ithink that isn't possible)

And do you really want make always a new %play stamp% field for each time?
(i think a new line would be better)

That's kind of a hack. I don't think the $filename function was really designed for that purpose.

As far as using a new %play stamp% field every time, that was the original suggestion. How hard would it be to pass the kind of tag you describe, with a new line for each piece of information.

foo_playcount 1.7.6 (Source & Binary Included)

Version 1.7.6 (May 16 2005)

1) Added new specifier #U which writes the name of the user who started foobar2000.

2) Merged the appended information fields into one field.

3) Adds support for new PLAY_STAMP tag. Requires LAST_PLAYED/FIRST_PLAYED writing to be enabled. PLAY_STAMP is disabled by default. The PLAY_STAMP tag gets copied from the LAST_PLAYED tag on update. In other words, the old LAST_PLAYED tag gets transferred to a PLAY_STAMP tag. The PLAY_STAMP tag can occur multiple times.

Edit 1: To be more clear, if you enable PLAY_STAMP, it will record all the times a song has been played between the time it was first played, and the time it was last played.

Eg.

FIRST_PLAYED = A
PLAY_STAMP = B
LAST_PLAYED= C

on next play:

FIRST_PLAYED = A
PLAY_STAMP = B
PLAY_STAMP = C
LAST_PLAYED= D

Edit 2: If anyone has any requests for the next version (I have no plans... yet), please just post.

Hey kl33per,

I like the changes that you've made. I'm glad to see that %W and #U are optional, as I would not use the #U but might incorporate %W. One question though....how much does each PLAY_STAMP tag add to the filesize?

Again, great job...and sorry to see that there has been such a comotion over the space vs underscore issue.

If I could have all that features in a sqlite version (external database) that will be great Great job dude.

That's why I asked about the size of the PLAY_STAMP tag. I think a tag like that would be better if it wasn't written to the file, but to a database. Hopefully something can get figured out. If not, so be it.

So, so, so, so awesome. I've been waiting for an update to this plugin for so long.

Thank you!!

20 PLAY_STAMP tags (including the appended %W) just cost me about 500 bytes (APEv2).

I'm gonna use it in case someone comes up with a brilliant implementation of this data.

Nice update !

I like the idea of play_stamp, but when a file is played many times, it becomes very hard to read the tags in the special file info box.
Would it be possible to just append the next stamp to the current stamp?

eg : PLAY_STAMP = a

I play the file :
PLAY_STAMP = a;b

I play it again :
PLAY_STAMP = a;b;c

etc.

I also think it might be best to store the last played and first played stamps in PLAY_STAMP fields as well. This way you only have to do a search on one field if you're looking for historical data.

That or someone could ask Nirana to update foo_infobox to display multiple fields as a single entry (like the multiple items properties box with the \ separators) or as a little +/- tree. Don't know if that'd be possible, but would be rather cool.

Edit: added 'multiple'

i really like the work you've done on this plugin. keep up the great work.

A problem I can see with that is that then the user name issue becomes a problem again...if you want to include user names in your play stamps and they're all on one line, the data becomes impossible to parse.

...or maybe just more difficult, I haven't thought that through. Someone more adept at tagz, help me out...

This has got me thinking about the application of this data as well. Say it's Sunday morning and I can't think of anything to listen to...how might I create a playlist with the songs that are played most often on Sunday mornings? Is that even possible?

Not impossible to parse, but definately more difficult. Also becomes much slower to parse. I will investigate the option of starting a new line for each stamp.

About the external database issue. I may investigate adding MySQL/SQLite support due to the lack of other requested features. It might not be for a little while though. If I do, I will atempt to have it all contained in the one plugin with the ability to write tags to file, database, or both.

I considered this, but then there is redundancy in the data. I can make it so PLAY_STAMP is a field all unto it's own, but I liked the idea that it displayed a complete play history between the first and last times played.

It should be possible (at least to get songs played on a Sunday), although it would be a complicated bit of TAGZ code.

Let me think on it.

Edit:
The code below will give seperate the day of the week. I don't have access to foobar right now, so I don't feel confident in writing full TAGZ code. However, it should be a start.

Not really a feature-request, but a development-style proposal:

Since the plugin is right now a bit unstable (not in terms of bugs, but instead in terms of features) maybe it would make sense to call versions which are meant to test-drive new features "test-versions", and then from time to time do "stable" versions which contain only finalized features. That would solve the problem of you implementing a new feature - then people using it - but then you want to change it and have to deal with the users who are using the old-method.

Good idea Lyx. Although I expect development rate to slow significantly now that I have almost everyone's feature requests done, I will probably still do this. If I do, the stable version will always be at the normal address (http://users.tpg.com.au/adsll926/foobar/foo_playcount.rar).

In accordance with Lyx's suggestion, foo_playcount 1.7.6 is a test version designed to test the PLAY_STAMP tag. All other features are finalised. In other words, until PLAY_STAMP is finalised, it's format may change.

Some stuff about hosting and filenames which i wanted to mention anyways:
Currently, your new playcount plugin file is directly linked in the tag-standards-thread - additionally it will probably get linked in the navigator docs.
So, it would be of advantage if the URL doesn't change. In that case, it may also make sense to name test-versions differently than stable versions(so that the people who DL it via the direct-links only get stable versions).

Something which would of course be much more elegant (and give the plugin more publicity) would be the following:
Once you're satisfied with your plugin, you could do a stable version, bump the version number to 2.0.0, and then upload it to the 3rd-party plugins site as "foo_playcount v2". Then, all direct-links could just point to the 3rd-party plugins site, and you could do test-versions in this forum thread. That way, you would also probably never get into traffic-problems(well, at least not the ones on the inet ;)

- Lyx

I already decided this before your above post.

About the plugins site, I already have placed it there, but it is still linked to my webspace. I really don't forsee any problems with it being hosted there.

Edit: In terms of 1.7.6, I'll leave it at the default address until the next test version. The only feature not finalised is PLAY_STAMP which is off by default anyway.

Whops, i completely missed that part about the URL, sorry. I've changed the link in the tag-standards thread to your entry on the 3rd party plugins site. So in case you need to change filenames or URLs for whatever reason, then you just have to update the linking on the 3rd party plugins site.

- Lyx

Coolio.

foo_playcount 1.7.7 Test Version
Alright this new test build writes only one PLAY_STAMP tag. Each timestamp is on a new line. If people find this easy enough to parse with TAGZ, it will become the stable version.

Edit 1: Can anyone successfully create a playlist (using TAGZ obviously) that lists all the songs played in a particular month based on 1.7.7's version of PLAY_STAMP tag. If you can, please post and 1.7.7 can become a stable release.

Edit 2: For reference, the TAGZ function to get a new line is $char(10).

Edit 3: Updated the URL.

Checking for the month of May:

Horribly, horribly slow. Doesn't include error checking (i.e. checking for %W on a line that doesn't have it), but should give you an idea. The code above only checks the first 3 lines of the play_stamp field. To check more, keep pasting that 2-line segment over and over and add another parenthesis to the end for each one (obvious disadvantage).

This would be my most wanted feature. It's nice to not have to actually modify music files themselves.

Otherwise, great work on this plugin!

for the extended playlist generator:


Seems to work for me...this seems too easy to be true...is it correct or am I making a fool of myself here? Or both!

Year could similarly be found by searching for '2005-', day by '-15 ', hour=' 12:', minute=':45:', second=':00 ', day of week=' 6 ', if you put a space after the %W in your preferences.

Thank god for those delimiters! I was fighting against them in the standards debate earlier this year. How prescient of the rest of you!

New challenge: a playlist for a specific length of time (one week)? A playlist of the songs most often played on Sunday (not just played at least once on a Sunday)?

Some tagz functions that don't exist that might be useful:

* for-loops
* number of occurences of a given string/character in a tag field
* metadata index number that contains the sought value

So everyone is happy with PLAY_STAMP adding one timestamp per line and not having multiple PLAY_STAMP tags?

Edit: In other words, are there any advantages to using multiple PLAY_STAMP tags (as apposed to one that writes each timestamp on a new line) in terms of playlist generation.

topdownjimmy: good stuff ($meta(play_stamp) HAS "-05-" seems to work too)


Probably length of time as topdownjimmy mentioned and multiple constraints (Sundays + mornings).

Couldn't you do one week (crudely) with something like:



How would you do Sunday's + Mornings with multiple PLAY_STAMP fields? I guess what I'm asking is, do people want the plugin to write multiple fields, or only one field.

Sunday 4-6 am:

I was thinking of a better way, but looks like you can't use simple search on titleformatted strings.

Don't really care whether it's one or multiple fields, but since it sounds mostly like an aesthetic issue in foo_infobox, I'm hoping Nirana replies.

One feature request: Option to add a tag with the date the file was rated (i.e. 2005-05-17 14:05:56), something like LAST_RATED.

Sounds to me, like this would be the job of a seperate rating-plugin. I mean, what does a rating-timestamp have to do with "play_counter"?

We're lacking a good rating-plugin anyways, so that would be possible feature for such a plugin. Since it then wouldn't be tied anymore to the play_count plugin, we could as well forget the underscores, and just make it RATING TIMESTAMP - since it wouldn't be part of the play_count-family of tags anymore.

- Lyx

You're completely right, I just mess my mind with another plugin the foo_quicktag_sql plugin, and this has already been implemented. Sorry

::slaps forehead::

I'm really troubled by the possibility that we'll be limiting future functionality by settling on the wrong format (line breaks vs. multiple fields). I know that a single, delimited field can be split into multiple fields, so it seems we'd be safe as long as the separator we use is functional as a splitting character...if you see what I mean. In masstagger, can you split a single field by its line breaks?

If not, maybe we should consider commas instead of line breaks. It'll be as unobtrusive in the file info box as line breaks would...looking at the actual data in the field would be a bit confusing, but how often do you need to view the data like that? Plus, if then in the future someone realizes that the historical data could be parsed for complex operations more easily if it's split into multiple fields, we could always just split our single field with masstagger.

edit: the reason i have the feeling that this might rely on multiple fields is that metadata stored in multiple fields is indexed, so i can see the date of the fourth time the track was played more easily...and in fact, if we instead use line breaks and include usernames, there's no way at all to find the time of the fourth play. i don't know, somehow i just foresee indexing coming in really handy when the manipulation of this data gets really involved.

a bit offtopic, but as i was thinking about all this code required for querying specific dates and such, i had a vision of a playlist generator with a calendar-like interface, automating all that complex code (something like what i've seen in google's picasa software). why isn't there a more intuitive playlist generator, with simple drop-down menus, check boxes, etc?

i didn't want to start an entirely new thread for some pipe dream...someone either tell me i'm deluded or start theorizing about the way this could look and function in a new thread.

The play-stamp idea shows quite well the limitations of TAGZ..... in any other high-level language, i would just convert the fields into an array, and from there on retrieving or modifying keys would be as easy as doing a $substr(). Lets hope that one of the new features in the next fb2k-version will be a new powerful structured scripting-language (or the existing c-like language with good docs and additional features).

- Lyx

The next version of foobar has been in the back of my mind thinking about this as well, in terms of which format for play_stamp would be better suited for the most probable new features (whatever we speculate those might be).

Tagz is designed to be a titleformatting language; it will not be turned into a full-fledged scripting language.

A note about the test version above.

Why haven't any of you downloaded it? I just realised that I got the URL wrong, but thus far no one has whined about it. If you don't download these things and give me feed back, I might as well give up.

@ topdownjimmy above, yeah, your definately deluded. I'm just kidding, but it would be quite the behemoth of programming challenges.

Edit: It seems it's not possible to split a field up via line breaks.