Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Play Counter (Read 340726 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Play Counter

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)
Santa is very jolly because he knows where all the bad girls live.  - Dennis Miller

Play Counter

Reply #1 –
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.

Play Counter

Reply #2 –
Thanks. Works great with foo_tunes !

Play Counter

Reply #3 –
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. 

Play Counter

Reply #4 –
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: [Select]
$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. 
Santa is very jolly because he knows where all the bad girls live.  - Dennis Miller

Play Counter

Reply #5 –
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.

Play Counter

Reply #6 –
Quote
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.
Santa is very jolly because he knows where all the bad girls live.  - Dennis Miller

Play Counter

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

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

Play Counter

Reply #8 –
Quote
Quote
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.
Santa is very jolly because he knows where all the bad girls live.  - Dennis Miller

Play Counter

Reply #9 –
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.
f to c to f to c

Play Counter

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



Code: [Select]
$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: [Select]
The output looks like this at the end of my playlist:
04|13|04 @ 19:33
There are 10 kinds of people in the world, those that understand binary and those that don't.

Play Counter

Reply #11 –
Quote
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?
Santa is very jolly because he knows where all the bad girls live.  - Dennis Miller

Play Counter

Reply #12 –
Quote
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

Play Counter

Reply #13 –
Quote
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?

Quote
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?
Santa is very jolly because he knows where all the bad girls live.  - Dennis Miller

Play Counter

Reply #14 –
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.

Play Counter

Reply #15 –
Quote
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.
Santa is very jolly because he knows where all the bad girls live.  - Dennis Miller

Play Counter

Reply #16 –
Quote
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.
 

Play Counter

Reply #17 –
Quote
I in no way meant to condemn your approach.


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

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

Quote
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?
Santa is very jolly because he knows where all the bad girls live.  - Dennis Miller

Play Counter

Reply #19 –
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)
Santa is very jolly because he knows where all the bad girls live.  - Dennis Miller

Play Counter

Reply #20 –
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

Play Counter

Reply #21 –
Quote
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.
Santa is very jolly because he knows where all the bad girls live.  - Dennis Miller

Play Counter

Reply #22 –
Thank You 

Play Counter

Reply #23 –
Quote
Quote
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

Play Counter

Reply #24 –
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...
Santa is very jolly because he knows where all the bad girls live.  - Dennis Miller