Forget about my previous post people, the answer was give a long time ago.
BUT, unfortunately this string does't seem to work

Thanks again for your help

Can collect the date of today since how much day the title was not played?

Edit: for using in Track Info Panel, not in the playlist (I find %_system_day%... but only for Columns UI)

Think I found it... I should be:

If you use the sql version, replace %play_counter with %__play_counter%

%__last_played%

or whatever your tag it plus the two underscores.

this should work. I've whipped it up myself quickly:

The mentioned bug in Navigator has been fixed. It should now fully support the new playcount-plugin without flaws.

In the next version, I'm thinking of removing the DB Only Mask, as it seems to be to be a usless feature. It doesn't prevent tag updates, it only delays them until something else updates the tags. If anyone can give me a good reason to hold on to this feature, please post.

Right. The only way it could be effective is if you never used foobar to modify your tags. And if that were the case, why aren't you blocking tag updates in foobar altogether?

Not only is it a useless feature, it's deceptive and has led to a lot of confusion from people (including myself many moons ago) who couldn't figure out why the tags got written even with that option checked.

edit: BUT you could make this argument: some people may want the tags written to the file, but not immediately, since on slower computers it may slow down the time it takes to start the next track (especially if they're using id3v2). So, they might like the option of keeping the data only in the database until other tags are written into the file. So maybe instead of getting rid of the option altogether, you could rename it "Delay tag writing" or something.

@kl33per: I know you said you have not much motivation into making a sqlite version of your plugin, but did you reconsider it?

Thanks.

Does someone know if fb2k 0.9 will allow db-only tags?

Yeah, that will be nice to know, so we could only keep one internal DB (and not 1-2 external sqlite). I've been following the 0.9 beta thread but I didn't see anything related.

No ones asked Peter as far as I know, and you can't really tell without the SDK. At least no available plugins make use of DB only tags.

As far as an SQLite version. If I did make one, it would only support SQLite and not mySQL. I've started to lay some basic ground work (realy basic ) for it, but that doesn't mean I'll actually implement. If I do it won't be a seperate plugin, but integrated into one plugin, with the option to switch between SQLite and tags. My interest in this has increased, but it was never really my interest that stopped me. I'm interested in improving this plugin in anyway that I can (even if it doesn't directly benefit me). What's stopped me is a lack of understanding of C++. I'm slowly learning, but balancing University, A part-time job, Guitar Playing, The two bands I'm in, and programming, can at times be a little tiresome. I'm doing this in my free time (which ATM is about 12.30am onwards daily). It's a feature I would like and would use, but it's pretty hard to implement (at least for me).

Current Goals for Next Version:
- Massive UI update (including more detailed info on all the features)
- Post so I can add more!!

Completed Goals:
- Fix bug in "Immediately Update Songs after X Seconds"
- Finalise PLAY_STAMP format. PLAY_STAMP now records a complete play history including the FIRST_PLAYED andLAST_PLAYED stamps.

That's nice to hear that you'll be interested in implementing the sqlite stuff. Thanks for your time in improving the playcount plugin, believe me as an user it's really appretiated

i do have to say that this is a nice plugin and all, but i am also of the opinion that the external DB would be a good thing also. I have my reasons that i have also decided to not publish online. but they are valid.

other than the external DB being missing i would have to say that this is a nice plugin. BTW, any word from kode on an update?

thx for all the work you have put into this also

I hope someone could help me with my problem. I have tried to solve it in several hours...

My code in the Track-Info looks like this:


Now i want to replace the month with Jan, Feb, March, and so one.

Does anybody know how to make this?
Sorry for the stupid question, it was answered hundred times...

Thanks.

It looks so easy.
You're my man. Thank you very much .

I would hope you can keep this feature. Though it is indeed misleading, it does still work out for me (and possibly for other people too).

My personal collection goes into a music/ directory while new downloads and rips go into a work/ directory situated somewhere else. foobar itself is configured to only add files in music/ to its internal database and playcount skips tracks not in the internal database.

Files in the work/ directory are added to a temporary playlist and listened through to decide what to keep and what not to, go through ReplayGain analysis and tagging. So any tag modifications done on these files, I want them to be written to the files directly.

After that process, they're moved into the music/ directory. I consider the tags on all those files to be perfect, I don't want them be modified, appended or removed. I do not ever use masstagger on these files, the only tag updates done to these files are the playcount data.

So with the current 'DB mask only' feature checked, tag updates to files in the work/ directory are written to the files directly and without playcount data (the desired effect). And tag updates to files in the music/ directory are stored into the internal database only (again, the desired effect).

So I guess, by luck, I've developed a process where the 'misleading' behaviour of the DB mask only option doesn't affect me and allows the option to work as it should. Of course, if a future version of playcount uses SQLite, then this renders my rebuttal moot but in the meantime, may I request this feature to be kept?

I'm planning to do an overhaul of the UI, so much more explaining of this 'feature' (read: hack) will have to be done in the preferences dialog, if it is kept. I can only see it as a useless feature that confuses new users. If your music files are so 'perfect' why not just block all tag updates? It will have exactly the same effect.

Because with the block all tag updates option checked, I can't use the masstagger to perform tag operations on the files in my work/ directory. The point is that, I have two main directories where foobar plays files from. In one directory, I only want the files to be read and meta-deta like playcount to be stored into an internal DB. In the other directory, I want to be able to modify the files directly. So using a broad "block all tag updates" approach isn't workable for me.

You could turn off "block all tag updates" when using your work directory. Seriously, how often are you adding music to your collection, unless your downloading vast amounts of music illegally.

All I'll say for now is we will see. I can't say I like it, and if I was building this plugin from the ground up, this 'feature' would definately not be included. I'm certainly not convinced that it should be kept, but we will see.

Other then (very) minorly fragmenting your drive, and a moral objection to storing statistical data in tags, there is very little reason not to write tags to the file.

You could imagine me as a hoarder of music with gigabytes of mp3s in my donwload queue and a fanatic attempt to perfectly tag everything I hoarde... but fair enough on your point about enabling and disabling the block all tag updates option as I need to. I guess it's just a matter of an extra step that I don't have to deal with currently.

The main reason why I object to storing playcount data into the files directly is because I feel they do not belong. Arist, title, disc number, etc. all describe attributes that are inherent to the song. Play-count on the other hand, is arbitrary and an external property of the file. But I wouldn't call it a moral objection, just preference. There's also the minor quip that storing play-count data directly to the file means in a house where the files are shared amongst multiple users, the play-count then becomes how many times the song has been played globally. But I digress.

To kl33per

Now I change rating tag with QuickTag scrip manualy.

It is possible add next feature (optionally): set 5 {r1, r2, r3, r4, r5} number for rating. If play_counter greater then r[i] and less or equall r[i+1] then rating set to i.

Any people may set its own array of rating.

In this way manually changing rating tag would be lost.

Took me a while to understand what your saying, but I think I have it now. You don't need another tag to do this. It could be done with TAGZ code.

I don't want change tag manualy, but I want automaticaly change %rating% when change play_counter in this nice plugin.

I know what you want. I saying that based on your suggestion, you don't need to have a rating tag at all. You could 'calculate' your rating with TAGZ code. For an example on how a similar sort of feature is implemented see the "hotness" thread.

well.. what hotness gives is more of a measure of recentness of play with a decay rate that is slower with a higher playcount and rating i believe it is. but it is probably what the guy is talking about... and topdownjimmy (the man who has done all the gruntwork on hotness) would be able to explain it better than i.

That is why I said similar. As far as the legwork with tagz is concerned, it'll be pretty similar to what hotness does (although not as sophisticated).

Instead of using %rating%, just use this string:


This is the only "manual" thing you'll have to do to get what you want. Put this in the globals section of the Columns UI preferences and you can use %_autorating% to get this automatic rating.

INFO (foo_uie_albumlist) : Could not find or message foo_uie_albumart.
WARNING (foo_playcount) : SQL logic error or missing database
WARNING (foo_playcount) : database is full
WARNING (foo_playcount) : database is full

What now :S

Beats me.

More information?

are you using the SQL version that kode has made?

Is there a working non-tag updating version of this? My mp3s have id3 album art in them for use with an iPod picture. Whenever a song plays it consequently removes this art.

In order to prevent this you have to block all tag update operations universally in foobar. This of course prevents you from editing the tags with foobar, but it sounds like you don't do this anyway because you have album art stored.

and so on... odd thing is that the play count does get incremented... this happens with songs with 0 songs played or more...

beats me... has been happening since a week now. havent changed anything in foobar for 4 weeks now.

any ideals?

Something has changed. Does manual tag updating work?

For those of us who would like to keep a check on the size of tags, would it be possible to set a maximum size to the PLAY_STAMP field? For example I could set PLAY_STAMP to have only 3 entries with information on the last three plays.

I have read all post and still dont know how to make play counter work :/ maybe anyone can make a small tutorial how to make it work.

Thx for help

Is anyone working on this plugin? Will it be updated to be 0.9 compatible when the SDK comes out? Hope it will, it's great. So simple, but really great.

@ BAstar
This only works in v.8.3 (i think)
Its pretty simple to use, download the file from the first post (binary) place it in your components folder, then restart foobar. After that you'l see a 'play count' option listed under components in the preferences window. You can set when u want it to update ur file (the slider) and other stuff. The playcount tag it adds is:
%play_counter% (number of times played)
%play_date% (last date it was played)
%play_time% (last time it was played)

"This post has been edited by tboehrer: Apr 14 2004, 06:00 AM"
Judging by this i doubt anyone is developing this plugin, unless tboehrer starts usin .9.... i guess the source is there if anyone wants to try.

<anti-bullshit-mode>
kl33per is probably still "developing" the plugin. There is just no plugin for 0.9 because there is no public SDK <blahblah> SDK will be released when fb2k 0.9 goes final <blahblah> which will be when its done.

Besides, the plugin in the first post together with its tag-scheme is now considered obsolete and was inofficially replaced by kl33pers new version. Thus, whoever downloads the plugin in the first post and tags his/her files with it will find them incompatible with the new plugin when 0.9 comes out and kl33per updates his plugin.
</anti-bullshit-mode>

lol sorry i haven't been keepin up to date, didnt realise kl33per was developing it.
my previous post should probably say:
"Judging by this i doubt [tboehrer] is developing this plugin"
Thanks for the heads up lyx
(I'm still usin .8 atm, so personally im glad there isnt an sdk out yet hehe )
is this: foo_playcount 1.7.8 *TEST VERSION* (May 18 2005) the latest version so far?
edit: cant seem to access the file..

kl33pers playcount is also available at the 3rd-party plugin-site (check "must know sites for fb2k" in the general-subforum if you dont have the link to it).

i think that's a great idea

Alright to address everyone's comments...

Somebody (BaStar actually) asked about a tutorial. That's what I've been working on and why there hasn't been a release in a while. Unfortunately I've also become busy with other projects and real life. However I'm committed to keeping this plugin going. When the 0.9 SDK is out, I'll port it to 0.9.

As to the limiting the number of play_stamp's thing. I need more convincing. The play_stamp field is designed as a complete playback history. Limiting it to the last 'x' plays changes it's purpose pretty drastically.

BTW, when I've done a 0.9 version, I'll start a new thread and the first post will always be kept up to date with the latest version.

The third party plugins site is http://pelit.koillismaa.fi/plugins/. The latest version is always available there. The site seems to be down at the moment though.

The limit to the size of the play_stamp tag would be an option, so that if you really wanted a complete history you could have it. I just really hate tag bloat and was looking for a way to limit metadata to a sane amount in the absense of an external database.

Great to hear foo_playcount will be appearing in 0.9!

topdownjimmy, how will this affect the new version of hotness?

If it doesn't adversly affect the algorithm, I'll implement the feature and release a new version (finally).

all it will mean is that people who set that history limiting option will have to use the old version of hotness, which doesn't rely on play_stamps.

So having a limited number of play_stamp's will break the new hotness? Can the new algorithm be modified to take into account a set number of play_stamps and use the average time between each stamp to calculate the hotness? Or is the new hotness algorithm much more advanced than that?

Is there any way you can have it say the percentage of plays?

IE: If a song has 10 plays and foobar has played 200 songs ever, what would the could be?
Is there a tag/component i can add to count all songs as a general tag to the dB?