Improving foo_playcount for 0.9, some suggestions Options

[Killmaster]

Now that 0.9 is upon us and the SDK is out there, I thought I'd go ahead and make some suggestions for improving the existing playcount plugin. I have no idea if the source code's out there or what, but here's my ideas:

-Move all existing data out of the main config and into a seperate file that is stored either in %AppData%\foobar2000 or the main directory, depending on whether user profiles are enabled.

-Add an import function in preferences. If possible, this should be able to get the data from the mySQL plugin of 0.8.3, as well as any tags in the files themselves. Something similar to masstagger's "guess values from other fields" function should be used to interpret different %last_played% values that people decided to choose.

-Don't allow customized tag values. This is unneeded and can only result in pain for anyone trying to make a standardized titleformatting string.

-Add the customizable playback time percentage back in.

-Since Masstagger allows built-in scripts now, maybe merge in quicktag capabilities to allow people to add ratings info and other non-tag data? This might necessitate changing the name of the plugin to something else, maybe foo_usertag or something like that.

[takt]

I totally agree with moving the data into a separate file into the main directory.

[AsD]

-Don't allow customized tag values. This is unneeded and can only result in pain for anyone trying to make a standardized titleformatting string.

I dont agree...
And i dont see how could affect you or anyone if i have my files tagged in the way i want.
Anyway, people should be able to decide, thats my opinion.

This post has been edited by AsD: Apr 1 2006, 18:00

[unabatedshagie]

-Don't allow customized tag values. This is unneeded and can only result in pain for anyone trying to make a standardized titleformatting string.

I dont agree...
And i dont see how could affect you or anyone if i have my files tagged in the way i want.
Anyway, people should be able to decide, thats my opinion.

It makes it really hard for other plugin creators or columnsui config makers to have to try and guess what names you have given your tags, if there is a common recognised default variable then it makes everyones life easier.

[AsD]

Plugin creators or columnsui config makers can program to common recognised default variable and the people who want to use non standar tags can still use them...

But maybe i didnt understand correctly...

When Killmaster said: "-Don't allow customized tag values" I thought he was talking about not storing for example "%last_played%" in the file tags but in an external file. The tags will still exist...

The difficulty will be the same for the programers if the custom tag is in the file tag or into a seperate file that is stored either in %AppData%\foobar2000 or the main directory and will be their choise to take them in account.

[Stuart60611]

I think it is essential that a user has the option to store playcount and last played fields as tags, if they so choose.

[Killmaster]

I think it is essential that a user has the option to store playcount and last played fields as tags, if they so choose.

Fair enough.

One thing that I was thinking about, is maybe someone could develop an external database component that would have its own API for other components to use? This would have some major benefits:

-No reinventing the wheel
-One file with EVERYTHING in it, could be easily backed-up by the user
-Common configuration screen for db-only tags (make it really similar to the main tagging window)

For the sake of simplicity, I think this should be a part of foo_playcount, in the same way that foo_ui_columns is a lot more than just columns. I think that there's enough plugins to make it useful, just off the top of my head:

-foo_quicktag
-foo_skip

There's also some other plugins that could take advantage of such a thing, if it was found useful:

-Equalizer - custom equalizer settings for individual tracks
-foo_scheduler - designate tracks to play at a certain time

I'm sure there's countless other things that could be done with a db-only tagging system; basically any plugin that requires designating individual tracks could use this.

[foosion]

Note that there already is an API that can retrieve (text) tag values no matter where they are stored: the titleformat API.

[crazybilly]

Is there a .9 version of playcounter out yet? I'm working on the assumption that it's what feeds foo_uie_trackinfo's %playcounter% tags.....

[MC Escher]

As I said in the other thread: I want my playback statistics in the tags of the files the statistics belong to. That would keep them safe from any type of corruption in a single file or database. An additional benefit is that tags are easy to read for any possible component.
Is there any fundamental reason why tags are not good?

[The Link]

Is there any fundamental reason why tags are not good?

IMHO playback statistics are volatile information which shouldn't be permanently attached to a file (files from a backup CD/DVD would come with old playback statistics which would be quite useless (at least for me)). On the other hand I don't really care because with foobar2000 you can delete tags really quickly if you don't need/want them anymore. But I really like the current method of storing that kind of information.

[boombaard]

Is there a .9 version of playcounter out yet?  I'm working on the assumption that it's what feeds foo_uie_trackinfo's %playcounter% tags.....

and probably also because it'd be very slow that way to aggregate info about for instance what genre you play most, or what artist..

[Audionut]

I prefer tags myself, as it's one less thing I have to remember to back up if i'm reinstalling or transfering.

However, the option to choose where to store the central file, would be as good. Then I could store that file with the audio files.

[vilse]

Is there any fundamental reason why tags are not good?

Apart from the read-only media someone already mentioned, there's also multi-user systems where tags can be impractical.

[legzalito]

Just so I know, will this plugin be updated , is it in progress, etc. I'm not sure how to count played times in 0.9 other than putting
$add(%play_counter%,%play_count%) in my playslit column.. And i'm not very happy with it because information is shared between the ID3 tags and the foo 0.9 statistic file..

Any idea? How do you deal with it?

[randal1013]

this is the last plugin i need to make the switch to .9.

is anybody working on it?

[Bl@ck_warrior]

this is the last plugin i need to make the switch to .9.

is anybody working on it?

it already exist --> http://pelit.koillismaa.fi/plugins/redir.php?id=535

edit : oops my mistake i have the good component ( playback statistic) but the link was the old one :/ sorry

This post has been edited by Bl@ck_warrior: Apr 12 2006, 12:54

[randal1013]

this is the last plugin i need to make the switch to .9.

is anybody working on it?

it already exist --> http://pelit.koillismaa.fi/plugins/redir.php?id=535

um.....that's an old version for .8.x, not .9.

[legzalito]

it already exist --> http://pelit.koillismaa.fi/plugins/redir.php?id=535

I'm afraid it is not the good version. This one seems to be 0.8 compliant only

[Stuart60611]

it already exist --> http://pelit.koillismaa.fi/plugins/redir.php?id=535

I'm afraid it is not the good version. This one seems to be 0.8 compliant only

I have been wating for this too. Earlier in this thread someone uploaded the source. Someone just has to port it to .9. I would if I could so hopefully someone else will step up.

[vlada]

Have you tried the official Playback Statistics component?

[randal1013]

yes, and it's.......well, not good.

[Stuart60611]

Have you tried the official Playback Statistics component?

The main problem with the official statistics plugin is that it does not allow one to save the data in file tags and instead saves the data in the foobar.cfg file. This poses many problems. First, the .cfg file has the potential to become corrupt and therefore loose all of the statistics data. Moreover, one will loose all their statistics with each new version of foobar. Moreover, one cannot use these statistics with other media players, such as winamp and others. The last stable version of the .83 playcount plugin can be download here with its source code included. http://users.tpg.com.au/adsll926/foobar/foo_playcount.rar All we need now is for someone to compile it with the .9 SDK. I would if I could. Hopefully, someone will step up and compile the old plugin which many (if not most) prefer.

This post has been edited by Stuart60611: Apr 10 2006, 21:15

[Killmaster]

Have you tried the official Playback Statistics component?

The main problem with the official statistics plugin is that it does not allow one to save the data in file tags and instead saves the data in the foobar.cfg file. This poses many problems. First, the .cfg file has the potential to become corrupt and therefore loose all of the statistics data. Moreover, one will loose all their statistics with each new version of foobar. Moreover, one cannot use these statistics with other media players, such as winamp and others. The last stable version of the .83 playcount plugin can be download here with its source code included. http://users.tpg.com.au/adsll926/foobar/foo_playcount.rar All we need now is for someone to compile it with the .9 SDK. I would if I could. Hopefully, someone will step up and compile the old plugin which many (if not most) prefer.

As I already suggested in the very first post of this thread, the data needs to be moved to a seperate file for the sake of security, portability, multiple users, etc. I really, truly don't see the need for storing the data in tags when almost every concern brought up in this thread could be alleviated by simply storing it in a seperate file, but I suppose an option could be added for those who insist.

[Stuart60611]

As I already suggested in the very first post of this thread, the data needs to be moved to a seperate file for the sake of security, portability, multiple users, etc. I really, truly don't see the need for storing the data in tags when almost every concern brought up in this thread could be alleviated by simply storing it in a seperate file, but I suppose an option could be added for those who insist.

The reason why it is essential that the user be given the option of storing this information in the tag is that other software players may not be able to access the external file where this data is stored. As such, by allowing the data to be stored in tags, the data could be made available to other software.