Here is a small plugin that will update the DB with a running playcount, along with the date and timestamp a track was last played. It currently only updates the DB (not the file).

The following tags are updated:

PLAY_COUNTER = A counter that is incremented each play

PLAY_DATE = the date last played, format DDMMYY

PLAY_TIME = the time last played, format HHMMSS

Play Counter (binary)
Play Counter (source)

Wow this is great. Simple yet useful. Already added it to my playlist formatting and it updates perfectly. Maybe in the next version you can add an option to update only when you finish a song, instead of just starting to play it. Sometimes i misclick a song, and I don't want it to count as a "played" song. Thanks.

Thanks. Works great with foo_tunes !

I'm sorry, but I don't understand how to use this. I've placed it in my "components" folder, but how do I get it to work / show up in my playlists?

I suspect I'm missing something obvious, but any help would be appreciated.

You have to change your formatting for the playlist. Assuming you use the default interface, go to Preferences->Display->Title Formatting and modify the formatting for the Playlist.

For example, at the bottom of the formatting string that's there add:



This will display the last played date as "mm-dd-yy" after the track length. This will only look right if you have a fixed space font...

I use foo_ui_columns, and it's similar... but different.

Support for this needs to be added into foo_pod as well. With a correct playcount and last time played timestamp, it'll make it one step closer to keeping correct information during a sync and producing more fields for smart playlists and such.

I'm not familiar with foo_pod... If someone wants to explain what is required, I'd be interested in making it compatible if possible.

Terrific! It's exactly what I've been waiting for for a long time.


I'm with this.

I'm with this too. Ummm... wait... that means I have to do it. Nevermind. That's a really dumb idea.

I'll get on it. I noticed the same thing.

Hmm, though it only updates the DB, it will write to the file if any tags are ever updated. Any way around this? (besides the obvious 'Block tag update operations' which would prevent any tag changing to files completely). As a tech field maybe? Thanks as well, as this plug-in's really useful.

Here is the format I used, I added the time stamp to the code that tboehrer provided.

Good point. Originally, I wanted to update the file immediately, but didn't like the fact that WAV files would cause the Console to appear. Updating the DB (and deferring the update) changes the issue slightly. But then again, tech info is written to file too, are they not?

i think that not, though i'm not sure (replaygain is technical info and gets updated, tracking infos like filesize not - hard to say).

anyway, i think that you should move it to technical info.

there should be additional tag saying whether to keep that info only in database / prevent it from writing to the files (or add blocklist). peter, would you add that? i guess time calls for it

I guess I would need a more definitive reason to move it to tech info. It's not really a programming issue because it's just as easy to put it one place vs the other.

It's more of an issue of whether one place is any better than the other, and whether it shouldn't be written to file. From experience with Winamp, which stored it in the DB only, the playcount info was lost when a file was moved, or when the DB was rebuilt. It was inconvenient.

Plus, if I look at the contents of a track (with a binary editor), I at least see the replaygain tags. This would indicate at least that written to file. Yes?



I take it you are saying something like this doesn't exist now and you are asking Peter to add it?

Tech info represents file properties, and thus is not stored to the file, rather it is derived from the file. Metadata on the other hand is stored in some kind of tagging format (depending on the file format and user preferences). Replaygain data is special, as most format store it as metadata (afaik), yet fb2k stores it as tech info internally.

As for play counter and similar data such as rating: I think these are rather related to the user than the files (like artist, title or any other tag). As such, I'd hesitate to store them in the file. fb2k's inability to separate metadata that is to be stored in the files from metadata that is to be stored in the database only, kept me - and probably all the others - from implementing a play counter plugin before.

I've always preferred functionality over some perceived notion of "correctness". There is certainly no harm in storing play count information as tags (that I've heard).

As a matter of fact, I pulled the PLAY_COUNTER from a list of tags for Matroska (PLAYCOUNTER for ID3v2.4.0). Not to mention tags like ENCODINGTIME, TAGGINGTIME, etc... This gives some basis for using tags.

Not to mention that it would be generally desirable to have play information follow the file, because after all, it is related to a specific track.

So... I'll stick with using tags. If, at some later date, fb2k supports true DB-only information, I can add support for that.

I in no way meant to condemn your approach. It is a perfectly valid solution in a single user setting. However, there are complications when multiple users share a music collection and tag writing is enabled: for example, the play count from user A will "carry over" to user B, if it gets written to the file. As already mentionend, this is a limitation of the current API, not of your plugin.

Sorry for nitpicking, I guess I have a bit of a perfectionist in me.

No offense taken. I realized your comments were purely analytical, and meant as counterpoint.



Good point.



Me too (when I can be). On that note, does anyone know how to eliminate the console warning when a WAV file is updated? For that matter, are there other formats that give the same warning? I guess I'm looking for a method called "is_this_going_to_throw_up_an_annoying_warning", or at least a way deduce this information. For example, could the only way be to add a config field indicating which extensions (.wav,etc...) to skip?

Very cool plugin! THX!

New version 1.1 (Apr 14 2004):

Added preferences dialog with:

1) Added option to update counter when playback starts (as opposed to when playback completes). If disabled, the counter does not update until playback completes normally; manually stopping playback (or switching to another track) will not update the counter.

2) Added "DB only mask" to compensate for lack of support for determining files that don't support tags. i.e., WAV files. In version 1.0, a DB update was done for all files, but this only defers updating the file (the next tag update will also write
the play counters). The default value is "*.wav", which will cause it to not attempt
updates to WAV files. If the method used in 1.0 is desired, a mask of *.* can be
used instead. Hopefully I discover a better way...

Play Counter 1.1 (Binary)

Play Counter 1.1 (Source)

I'll av a play with it now

Is there no easy way to get it to update 50% of the way through? thas my only major quibble atm - its not a major one, it'd just be better at 50% I feel.

Good work :-)

Steve

I knew someone would ask for that... hehehe

I'll do it the next time I'm in the code.

Thank You

Actually, a slider to choose what percentage you'd like would probably be best... cool plugin BTW, been wanting something like this for a while

OK... last change for awhile... I hope...

1.2 (Apr 14 2004):

1) Replaced option to update at play start vs completion with a slider bar so that
a playback percentage can be specified instead.


Play Count (Binary)

Play Count (Source)

Enjoy...

Is there any easy way to have it NEVER update the actual files themselves with this information? I don't want my MP3 tag, for example, to get an update everytime I play a file. I do want other updates to the tags to occur, but I don't want playcounts/timestamps/that sort of thing to get in there. Not even deferred. I do want this info stored in the foobar DB, just not in the files.

This may be outside the scope of this plugin, but I figured I'd ask anyway.

Well... that was the gist of the discussion earlier in this thread. I don't see a way, and foosion doesn't either, to prohibit updates to the files (for just these tags).

This is one of those "use it if you don't mind the side effect" type plugins. As for myself, I could care less if these tags are in the file. That is, after all, the purpose of meta data. But each to their own I suppose...

Maybe someday the fb2k god's will add DB only meta info...

yeah, we definitely need that! some easy function which would set special flag for given tag, which would keep it db only ...

this would need only small change to sdk and db.

Perfect for me now.
Thanks!

Very very nice plugin!!!
I am adding a Play Counter Column to my Azrael formatting string!!

--
Neksus

This looks like a very useful plugin, unfortunately I can't get it at the moment.. The server seems inaccessible. Could you (someone) upload the latest version to the Uploads Forum please? Thanks!

Here is my mirror!
foo_playcount.dll

--
Neksus

Yeah... sorry... the server it's on just bit the dust for the momemt. It will be back up in a little while.

Thanks tboehrer, I have been waiting for a plugin like this. I personally like the fact that tags are added to the files and not just kept in database.

I noticed that the percentage, only reflects the position of the progress bar, and not the actual percentage of the file that has been played. Not a big problem for me as I rearely touch the progress bar anyway, but I guess some might find it inconvenient that skimming through a file is counted.

Huh? If I have a 163 second long track, set the percentage to 20%, it does the update at approx 32 seconds into the file. 60% would be approx 98 seconds into the track. Both seem to work here. What are you seeing?

EDIT: I think I understand... correct me if I'm wrong. You are thinking that, assuming 20% complete (for 163 second track), that after 32 seconds of played audio, irrespective of the seek bar position the update would happen. Not just simply once the seek bar passed the 32 second mark. If so, interesting. Never considered that.

Thanks for the quick updates. Perfect for me now.

Are tags really added to files? I move some files to another folder and play them again, all pre_added tags are lost.

Works here...

Open your console, and play a track. You should see messages that the file is getting updated.

Yeah I can see a message in console like this:

INFO (foo_playcount) : file://E:\Music\== Listening ==\Rock Pink Floyd - Animals\03 Pigs (Three Different Ones).mpc

And the tags are do added. But if move this file to another place and play it , its tags are lost. Then move it back, the tags are back too! Really strange.
Then I doubt if tags are stored in DB file, I delete database.foo file, the tags are still there. Confused...

Edit: deleted

Ok, check your emailbox pls.

If I set the bar to 98%, the tags are updated if I'm seeking directly to the end of the file. Even if the file is 30 minutes long, and if I play it during 5 seconds, the tags are updated if I'm playing the last 10 seconds (tested with v.1.2).

Cool, this works for me.

Edit: Discovered your other new plugin - the Extended Playlist Generator.

The only problem for me is I can't easily generate the playlists I want because of the date and time being in different fields. Also the date being in that form is difficult. It would be a lot easier if it was stored as seconds since Epoch..

e.g. I can't do "play_date LESS 150304" to get songs I haven't played since 150304. Either moving this to 040315 format or changing the fields to a single "second since epoch" would solve this.

Changing to this would make it difficult to format for the display, yes? What about an optional 3rd timestamp?

Actually, what about being able to specify the format for the date and time fields? That way, you could pick the format that best suits you. Maybe even an option to disable a tag?

mm I know.. I think the ideal situation would be for Peter to add a couple of TAGZ functions to translate between timestamps and pretty dates, and a $time_now() function.

I don't imagine these would be particularly high on his priority list. So, for now, please do implement a 3rd timestamp field .

Thankyou!

That would be even better. Allowing people to have x tags added to a file when has been played y% through. Each of the tags being a combination of the information coming out of a time() function (timestamp, yearday, monthday, hour, etc..)

Makes for possible redundancy but that is up to the user..

This sounds like an idea!

--
Neksus

The more I think about it, I'm not sure how someone would easily use "seconds since epoch". It's not as if humans are used to using a timestamp like that. For example, if you wanted to know what was played since last Friday, what is the value? Not very practical I would think?

I'm not sure what you are saying. I was thinking something along the line of being able to enter: YYMMDD. Or if they wanted to preformat it MM-DD-YYYY, or DD/MM/YY. You probably wouldn't want to use non-numbers in the format if you wanted to do what you had suggested (play_date LESS 040415). But it would save having to have the various title formatting do it. Up to the user though.