Skip to main content
Topic: foo_playcounter acting weird (Read 2120 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

foo_playcounter acting weird

hey, sorry guys if i am confusing but here it goes

play_counter never ever updates first of all, and settings department it doesn't accept the new settings

i.e:

play_date  --- %M|%D|%y

play_time ----  $H:$M

it just won't change the display please help thanks

foo_playcounter acting weird

Reply #1
Those strings are generated when the play count is updated. Changing their formatting configuration will only affect files that you play afterward.

The sort-of-fork which I posted in another topic stores the timestamps in an external database, so you could just reload the info for all timestamped files, and the info strings would be regenerated. I might add functionality for database synchronization, ie. update Foobar2000 metadb for all entries in the external database, prune external database of entries which do not have matching file entries in the metadb, etc. Then again, I might not...

foo_playcounter acting weird

Reply #2
Quote
Those strings are generated when the play count is updated. Changing their formatting configuration will only affect files that you play afterward.

The sort-of-fork which I posted in another topic stores the timestamps in an external database, so you could just reload the info for all timestamped files, and the info strings would be regenerated. I might add functionality for database synchronization, ie. update Foobar2000 metadb for all entries in the external database, prune external database of entries which do not have matching file entries in the metadb, etc. Then again, I might not...
[a href="index.php?act=findpost&pid=230483"][{POST_SNAPBACK}][/a]



kode it was the database :-/ thanks man i feel dumb :-x

foo_playcounter acting weird

Reply #3
Don't feel dumb, it's not as if this was really well documented. Unfortunately there is no API for components to maintain persistent info fields arbitrarily across the entire database, otherwise even the standard foo_playcount could store its fields in the info section, and regenerate the formatted timestamps whenever you reload.

As it is now, it could be designed to scan the entire database for playcount marked files and reformat the optional strings, and/or remove/rename strings if you changed the fields settings, but that would get kind of slow, as the variables change as you type...

The one caveat to the MySQL version's info reloading is that if you reload from the file properties, your play count info will appear to vanish, because the info dialog gets a copy of the info immediately after it's reloaded. This is because I use a sort-of hack, so when you reload, and the info is missing, it pulls it from the external database and delay readds it to the files.

I suppose the only secure way to allow for these custom named fields to work properly would be for there to be an API for exposing custom persistent info fields for each file, and a way to indicate that some of them are dynamically generated, so that they are not stored in the database, and so that every time they are referenced, the info or formatting code calls the respective service on the specified file/subsong to retrieve the current value, possibly passing a const file_info pointer so that the service doesn't need to query for it, which otherwise might lead to recursion. Damn, this idea sounds spoony.

 

foo_playcounter acting weird

Reply #4
Quote
I suppose the only secure way to allow for these custom named fields to work properly would be for there to be an API for exposing custom persistent info fields for each file, and a way to indicate that some of them are dynamically generated...


Something like this would be cool.  I would dig it.
Santa is very jolly because he knows where all the bad girls live.  - Dennis Miller

 
SimplePortal 1.0.0 RC1 © 2008-2020