Play Counter

Topic: Play Counter (Read 342387 times) previous topic - next topic

0 Members and 1 Guest are viewing this topic.

Reply #100 – 2004-04-30 05:01:19

I think I found a minor bug.

Preset name including ']' character isn't saved properly after restart.

Anyway, thanks for the nice component which is really useful.

EDIT:Oops, this is the commet for the extended playlist generator plugin. Sorry, just ignore this.

Play Counter

Reply #101 – 2004-04-30 05:07:08

Quote

I mean the current local variables in the callback class. Since the callback is a static class, you can safely move the _played and _length variables out, rename to g_played/g_length, implement the cfg variable storage directly from on_quit.

I gotcha... Mainly I don't do that because global data breaks encapsulation rules of OO... one of the purposes of a class. My preference would be to have no cfg vars be global since they are "owned" by playcounter. Though, breaking encapsulation for a relatively simple piece of code like this was acceptable it seems.

Quote

Forcing reload of play count / timestamp for all files referenced in the external database (if you change the formatted tag options, they will be regenerated)

Is there a metadb callback in order for you to know when meta data changes for a track? If so, I would think it would be easy to reload the info fields from the external store automatically.

Quote

Forcing scan of external database for entries no longer referenced in the player metadb
- Hilighting entries in the current playlist based on a query to the external database ... could be simplified to facilitate a simpler internal count database, or allow full MySQL query.

Why all this work? Is there some reason you don't want to store this info in the DB? If I had a wish, it would be to have true "DB only" info, maybe with the option for it to be "sticky".... i.e., reloading from file doesn't blow away the sticky info. But I don't have control over that.

Play Counter

Reply #102 – 2004-04-30 05:43:59

Quote

Quote
I mean the current local variables in the callback class. Since the callback is a static class, you can safely move the _played and _length variables out, rename to g_played/g_length, implement the cfg variable storage directly from on_quit.

I gotcha... Mainly I don't do that because global data breaks encapsulation rules of OO... one of the purposes of a class. My preference would be to have no cfg vars be global since they are "owned" by playcounter. Though, breaking encapsulation for a relatively simple piece of code like this was acceptable it seems.

Now if only more people thought this way when writing audio player code, and perhaps emulators that could be modified to play only audio. There's a new N64 format, but it's a huge mess of single instance crap that I'll have to get bored and wrap into classes some day.

Quote

Quote
Forcing reload of play count / timestamp for all files referenced in the external database (if you change the formatted tag options, they will be regenerated)

Is there a metadb callback in order for you to know when meta data changes for a track? If so, I would think it would be easy to reload the info fields from the external store automatically.

Well, you see, I do get a callback notice after the info is reloaded into the database, but I can't modify the metadata within the callback. I have to queue a db-only update for that information to occur after the callback, using a message window. This delay tactic prevents the new info from appearing in places such as the file info dialog. Once again, it's another hack for doing something the API was not designed for. (Yet.)

Quote

Quote
Forcing scan of external database for entries no longer referenced in the player metadb
- Hilighting entries in the current playlist based on a query to the external database ... could be simplified to facilitate a simpler internal count database, or allow full MySQL query.

Why all this work? Is there some reason you don't want to store this info in the DB? If I had a wish, it would be to have true "DB only" info, maybe with the option for it to be "sticky".... i.e., reloading from file doesn't blow away the sticky info. But I don't have control over that.

Can you feed SQL queries to the internal database? :B

Like I said, simple queries would be possible with normal info, but until it's possible to register permanent info variables to a particular service, it will be necessary to either write the values to the files' tags, or maintain them in an external storage system. A simple array would do nicely. You can even use the metadb_handles as indexes, for the duration of the process session. The handles would be translated to path/subsong when saving, then to playable_location to metadb_handle on load. (Of course, you'd be wise to do this translation in on_init, once all the components have been loaded and their services registered, etc.)

Whee, fun.

Play Counter

Reply #103 – 2004-05-15 15:28:25

So, adding *.* to "DB Only Mask" will make it only track in the database, and it WON'T write tags to files?

I like this plugin but I don't like components to write tags to my music, I would prefer it in the database always unless I specificy otherwise.

I think this plugin should log this information should be logged by all file types to the DB by default. It's kinda nasty to have it write to the files themselves unless it is a standard tagging format that most other players would recognize (which this isn't, or am i wrong)

Play Counter

Reply #104 – 2004-05-15 21:51:18

Quote

So, adding *.* to "DB Only Mask" will make it only track in the database, and it WON'T write tags to files?

I like this plugin but I don't like components to write tags to my music, I would prefer it in the database always unless I specificy otherwise.

All that will do is defer the write to the file until you specifically tell it to update the file with DB info, or when you do some other tag update operation. There is currently no way to never write the tags to the file and have the info in the DB.

Play Counter

Reply #105 – 2004-05-16 01:09:28

Now I'm still using Playcount v1.2.
I disable DB and block tag update operations in the same time. So the tags are neither stored in files nor DB. But it really does the counting. I have no idea where the tags are but I like this way.
The later versions lost this "feature".

Play Counter

Reply #106 – 2004-05-16 01:31:45

Quote

I disable DB and block tag update operations in the same time. So the tags are neither stored in files nor DB. But it really does the counting. I have no idea where the tags are...

Neither do I....

Play Counter

Reply #107 – 2004-05-16 03:17:13

Quote

I have no idea where the tags are...

Maybe they're being stored in the playlists. Check the .fpl files in "C:\Program Files\foobar2000\playlists\"

Play Counter

Reply #108 – 2004-05-16 03:34:07

Quote

Maybe they're being stored in the playlists. Check the .fpl files in "C:\Program Files\foobar2000\playlists\"

You're right! Tags are being stored there.
So, tboehrer, is it possible to add an option to store tags ONLY in .fpl files?

Play Counter

Reply #109 – 2004-05-16 03:37:49

Quote

is it possible to add an option to store tags ONLY in .fpl files?

No clue. It's not something I control. That I know of at least.

Play Counter

Reply #110 – 2004-05-16 03:52:18

You can also check with kode54... he posted some messages saying he was working on a version that writes the tags to an external DB. I don't know the status of it though.

Play Counter

Reply #111 – 2004-05-16 03:52:50

Quote

No clue. It's not something I control. That I know of at least.

I know nothing about foobar plugin programming. But actually v1.2 was already in this way...

Play Counter

Reply #112 – 2004-05-16 04:17:33

Quote

I know nothing about foobar plugin programming. But actually v1.2 was already in this way...

The last version added an option to disable the "skip if not in DB" feature. It's more likely that when you disabled the DB, the plugin simply ignores the track. I truly don't have much control over what gets written where... I simply make a call to some SDK code and it does the rest.

Play Counter

Reply #113 – 2004-05-16 10:11:24

Thanks for the reply tboehrer. I will wait for kode54's new version (if it becomes available). Very nice plugin ... once it can write to a DB and not to the files themselves I will be pleased This is functionaliy from Winamp 5 which I miss in foobar2000

Play Counter

Reply #114 – 2004-05-17 21:52:40

Minor release:

Version 1.5 (May 17 2004)

1) Added julian date format
2) Fixed bug with "Skip tracks not in the DB" not being checked first.

The Julian date is used by specifying either %j or %J in the format. Use %j to use a julian date without the time fraction, or %J to get the full Julian date.

Play Counter

Reply #115 – 2004-06-20 01:41:54

I searched in the forum, but don't found nothing, then here goes my question:
How can I change:
DDMMYY to YYYY.MM.DD (or YY.MM.DD)
and HHMMSS to HH:MM
?

I want to show this way in playlist: YYYY.MM.DD - HH:MM

Play Counter

Reply #116 – 2004-06-20 09:30:51

this should do what you want - tell me if it doesn't work as I haven't tested it:

Code: [Select]

$ifgreater($substr(%play_date%,5,6),20,19$substr(%play_date%,5,6),20$substr(%play_date,5,6)).
$substr(%play_date%,3,4).$substr(%play_date%,1,2) - 
$substr(%play_time%,1,2):$substr(%play_time%,3,4)

Steve

Play Counter

Reply #117 – 2004-06-20 17:31:19

Or if you want a much simplier way, try to put

"%Y.%M.%D" in the play_date tag (in configuration of play_count)

and "$H:$M" in the play_time tags

and then %play_date% - %play_time% in your playlist

Play Counter

Reply #118 – 2004-06-20 17:35:16

^ But that would require reformatting old tags wouldn't it

Steve

Play Counter

Reply #119 – 2004-06-20 17:48:40

Paranoia Posted on Jun 20 2004, 11:35 AM

Quote

^ But that would require reformatting old tags wouldn't it

Steve

Yes. The masstagger works well for reformatting. I would reformat prior to changing the Play Counter format though.

Play Counter

Reply #120 – 2004-06-20 17:56:54

Quote

^ But that would require reformatting old tags wouldn't it

Steve

true, I hadn't thought to that

My solution is better on the long run, yours is better on the short term

As tboehrer says, the best is probably to masstag and then change the play_date & time tags configuration

Play Counter

Reply #121 – 2004-06-21 00:10:49

Thanks everybody.

I will change that format of the variables, then use the Paranoia's strings to format it in the playlist.
Andu use masstagger to change the old ones.

Paranoia, your string is buggy, it shows 20TA.06.20 20:12 per example, but that ok, i'll use %Y to get YYYY.

Play Counter

Reply #122 – 2004-06-21 01:44:40

@tboehrer:
I had a look at your website but didn't see the 1.5 version. Is that the foo_playcount.dll file?
Also, this looks like a great plug-in, could you have it added to the plug-ins page?
Thanks for the great work.

Play Counter

Reply #123 – 2004-06-21 14:10:07

By the way, could you implement an option to update counter when playback percentage is n% OR nminutes? It would be really great for some songs that have hidden tracks (ie looong part of silence in the middle, which one usually just skips).

Play Counter

Reply #124 – 2004-06-24 00:27:51

Quote

Quote
So, adding *.* to "DB Only Mask" will make it only track in the database, and it WON'T write tags to files?

I like this plugin but I don't like components to write tags to my music, I would prefer it in the database always unless I specificy otherwise.

All that will do is defer the write to the file until you specifically tell it to update the file with DB info, or when you do some other tag update operation. There is currently no way to never write the tags to the file and have the info in the DB.

Just get all the normal tags the way you like it, then write protect all of your files.

Thats what I am doing.

DB will be updated, but files will not.

Notice