Play Counter, Play count plugin Options

[tboehrer]

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)

This post has been edited by tboehrer: Apr 13 2004, 21:00

[brainzelda]

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.

This post has been edited by brainzelda: Apr 13 2004, 21:09

[Sebert]

Thanks. Works great with foo_tunes !

[tourmalet]

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.

[tboehrer]

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:

CODE

$if(%play_date%,'   '$substr(%play_date%,3,4)-$left(%play_date%,2)-$right(%play_date%,2),'           ')

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.

This post has been edited by tboehrer: Apr 14 2004, 00:41

[Otto42]

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.

[tboehrer]

Support for this needs to be added into foo_pod as well.

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.

[Raymond]

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

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.

I'm with this.

This post has been edited by Raymond: Apr 14 2004, 01:16

[tboehrer]

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.

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.

[Silverbolt]

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.

[Giljorak]

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

CODE

$if(%play_date%,' '$substr(%play_date%,3,4)
|$left(%play_date%,2)|$right(%play_date%,2)' @ '
$left(%play_time%,2):$substr(%play_time%,3,4),
'                 ')

CODE

The output looks like this at the end of my playlist:
04|13|04 @ 19:33

[tboehrer]

Hmm, though it only updates the DB, it will write to the file if any tags are ever updated.

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?

[mazy]

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

[tboehrer]

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

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?

there should be additional tag saying whether to keep that info only in database / prevent it from writing to the files (or add blocklist).

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

[foosion]

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.

[tboehrer]

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.

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.

[foosion]

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).

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.

[tboehrer]

I in no way meant to condemn your approach.

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

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:

Good point.

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

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?

[Radion]

Very cool plugin! THX!

[tboehrer]

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)

This post has been edited by tboehrer: Apr 14 2004, 18:21

[Paranoia]

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

[tboehrer]

Is there no easy way to get it to update 50% of the way through?

I knew someone would ask for that... hehehe

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

[Paranoia]

Thank You

[Killmaster]

Is there no easy way to get it to update 50% of the way through?

I knew someone would ask for that... hehehe

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

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

[tboehrer]

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...