I think this is the fixed playcount : http://www.foobar2000.org/beta/components.html (http://www.foobar2000.org/beta/components.html) ?
ok thats great to see a fixed playcount component but all my files user play_counter instead of play_count and my hotness rating scheme works off play_counter... is it possible to setup the component so i can choose the name of the play_count to be play_counter...
surely I am not the only person with this dilema and I have 40,000 mp3's this will take a long time to convert all the names..
also the lats played timestamp seems a huge number.. is there any way to get some more sense out of how it works...
If I have to get used to it, then thats fine but can we also have first played in the statistics db as well...
thanks for the awesome work on foobar.. always appreciated and loved...
I think this is the fixed playcount : http://www.foobar2000.org/beta/components.html (http://www.foobar2000.org/beta/components.html) ?
I don't know what with you, but i think the new beta play_count official dosen't seem to work al all...
No <PLAY_COUNT> nor <LAST_PLAYED> tags has added.
Furtermore, as 4nt1 just sayed above me, i also have used play_count unofficial and all my files taged different from play_count official standart,
Is it possiable to make an advace option in play_count official to choose tag standard?
Thanx.
Official playcount doesn't add any tags to files. It keeps information in foobar's cfg file, as I heard.
Official playcount doesn't add any tags to files. It keeps information in foobar's cfg file, as I heard.
- I think you may right in the past, but the new plugin "Collects statistics about tracks from your Media Library being played. Statistics can be displayed using %last_played% and %play_count%, or using a context menu command. Now includes option to
write statistics to file tags." Foobar play count beta (http://www.foobar2000.org/beta/components.html)
- And again, i don't even find the component properties, even He is in the "components" section.
Oops, my bad.
Haven't tried the latest beta yet.
I like what I see but the playcount thing is a big deal for me. I like stats and a lot of my playlists are built from them.
As people have already said, the new playcount.dll on the beta page does work now but it writes %play_count% rather than %play_counter% so it's not compatible with the stats I've already built up. I'm not wiping them to start again and changing all my %play_counter% tags to %play_count% by hand would take forever. Also, I can't see anywhere to change the % of song complete before it counts as played and I think it has to be the whole thing...
So I'm still staying away from the beta for now I guess.
I'm not wiping them to start again and changing all my %play_counter% tags to %play_count% by hand would take forever.
Why by hand? Couldn't you use Masstagger to copy the values from %play_counter% to %play_count%?
Robert
yeah you could do that but all the last played dates and first played dates do not match up...
so its not as simple as play_counter to play_count
i wish it was but it isnt.
Official playcount doesn't add any tags to files. It keeps information in foobar's cfg file, as I heard.
- I think you may right in the past, but the new plugin "Collects statistics about tracks from your Media Library being played. Statistics can be displayed using %last_played% and %play_count%, or using a context menu command. Now includes option to write statistics to file tags." Foobar play count beta (http://www.foobar2000.org/beta/components.html)
- And again, i don't even find the component properties, even He is in the "components" section.
I reply to myself, i mistake, play_count official did work, but not in the meaner that the quote from the site sayed. He store the information in the data base (or the cfg file), but not in the file tags nor i can't find any propeties window to force write to file or something like this.
I reply to myself, i mistake, play_count official did work, but not in the meaner that the quote from the site sayed. He store the information in the data base (or the cfg file), but not in the file tags nor i can't find any propeties window to force write to file or something like this.
Did you have a look at the advanced options section in the preferences?
I reply to myself, i mistake, play_count official did work, but not in the meaner that the quote from the site sayed. He store the information in the data base (or the cfg file), but not in the file tags nor i can't find any propeties window to force write to file or something like this.
Did you have a look at the advanced options section in the preferences?
I don't look before, but now:
(http://img150.imageshack.us/img150/1203/15001500148815131501ab4.th.jpg) (http://img150.imageshack.us/my.php?image=15001500148815131501ab4.jpg)
Sorry, what a shame.. Thanx.
Official playcount doesn't add any tags to files. It keeps information in foobar's cfg file, as I heard.
- I think you may right in the past, but the new plugin "Collects statistics about tracks from your Media Library being played. Statistics can be displayed using %last_played% and %play_count%, or using a context menu command. Now includes option to write statistics to file tags." Foobar play count beta (http://www.foobar2000.org/beta/components.html)
- And again, i don't even find the component properties, even He is in the "components" section.
The download link takes me back to foobar's main page,does anyone have that 1.1 version of playcount?
I haven't expected that the official play_count plugin would be developed further. As i know it was created for purpose of testing. Now let me ask if the developer/s are considering to add some features to make the unofficial play_counter plugin (and all its annoyments) completely needless.
I am thinking about the already mentioned opportunity to define the percentage of a track when the playcount has to be added and the info "first_played". In that context i hope that Peter and Holger will think about how useful %added% and %play_stamp% could be.
The download link takes me back to foobar's main page,does anyone have that 1.1 version of playcount?
I don't know, but the link take me to foobar's optional beta component. And yes, i have it, but i don't know how to upload or transfer it..
What is format new tag - LAST_PLAYED_TIMESTAMP.
I want create script with two actions:
1. change all LAST_PLAYED to LAST_PLAYED_TIMESTAMP
2. rename play_counter to play_count
and apply it to all my library, but without format of LAST_PLAYED_TIMESTAMP I don't create this script.
What is format new tag - LAST_PLAYED_TIMESTAMP.
I want create script with two actions:
1. change all LAST_PLAYED to LAST_PLAYED_TIMESTAMP
2. rename play_counter to play_count
and apply it to all my library, but without format of LAST_PLAYED_TIMESTAMP I don't create this script.
Why u would do this? does unofficial play_count still under development?
What is the profit to move to official play_count?
What is the profit to move to official play_count?
No crashes.
so, do i undestand right, that the option on advanced preferences enables official playcount to write the file tags?
But it uses other tags than the unofficial did?
So, if I'm right, then i just have to rename the tags used by unofficial to the ones the official does, enable this advanced option and 'use' it as i 'used' the unofficial one?
The download link takes me back to foobar's main page,does anyone have that 1.1 version of playcount?
Use right clic and Save Target As...
The download link takes me back to foobar's main page,does anyone have that 1.1 version of playcount?
I think it's got to do with a server overload or somesuch.
I got that result many many many times trying to download something from foobar2000's site. Admin's solution? Keep trying, you're bound to succeed sometime in the future...
Hmm yeah helpful...
The download link takes me back to foobar's main page,does anyone have that 1.1 version of playcount?
I think it's got to do with a server overload or somesuch.
I got that result many many many times trying to download something from foobar2000's site. Admin's solution? Keep trying, you're bound to succeed sometime in the future...
Hmm yeah helpful...
This is off topic but the server uses anti hotlinking features that prevent downloading when referer doesn't match server. Some so called privacy tools disable referers, you may want to examine options in the software that you use.
can I invoke the playcount fields written to the DB in masstagger in this version? previous one prevented me from doing that....
thanks.
This is off topic but the server uses anti hotlinking features that prevent downloading when referer doesn't match server. Some so called privacy tools disable referers, you may want to examine options in the software that you use.
I tried it with three different browsers. Opera 9, Firefox 1.5, IE7. It didn't work anywhere. Also right click and "Save as..." gives me only the index.html. I don't use any proxys or such stuff. Is there perhaps another way to get that component?
This is off topic but the server uses anti hotlinking features that prevent downloading when referer doesn't match server. Some so called privacy tools disable referers, you may want to examine options in the software that you use.
I tried it with three different browsers. Opera 9, Firefox 1.5, IE7. It didn't work anywhere. Also right click and "Save as..." gives me only the index.html. I don't use any proxys or such stuff. Is there perhaps another way to get that component?
Same here.Can anyone who has obtained it please upload it to wherever is possible?
What is the profit to move to official play_count?
No crashes.
Not only that! The shortly appearing box while writing tag to file which steals the focus is one of the most annoying bugs!
Not to forget: The user have the freedom to decide if the info about playback statistics should be written in file or not.
So if I understand this correctly, all one has to do is rename and transfer (with masstagger) the metadata from the old field names from the unofficial playcount to the new field names of the beta statistics and enable writing of data to file tags from the advanced options, and I will have all the functionality of the unofficial playcount with the new beta statistics. Does the new beta statistics plugin write the actual data for the play_count and last_played fields in a different format than the unofficial playcount?
Not only that! The shortly appearing box while writing tag to file which steals the focus is one of the most annoying bugs!
It seems that increasing file buffering up to something like 1024 kb (in Configuration/Advanced) gets rid of the annoying progress bar.
Can we have %play_count% working in masstagger even if we are writing the stats only to the config file, please?
Thanks.
The download should work now; see here: http://www.hydrogenaudio.org/forums/index....c=46586&hl= (http://www.hydrogenaudio.org/forums/index.php?showtopic=46586&hl=)
Not only that! The shortly appearing box while writing tag to file which steals the focus is one of the most annoying bugs!
It seems that increasing file buffering up to something like 1024 kb (in Configuration/Advanced) gets rid of the annoying progress bar.
Thanks for that suggestion. I was having a long pause after one minute but it seems to have stopped since changing the buffer length
Can anyone explain what format LAST_PLAYED_TIMESTAMP is? For example 127977078848593750?
walla: The amount of seconds since January 1st 1970 00:00.
EDIT: typo
walla: The amount of seconds since January 1st 1970 00:00.
EDIT: typo
Wrong. It is not a UNIX time, which is quite easy to see, if you try to interpret the number as such (year 4,058,128,518). Try Win32 FILETIME (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sysinfo/base/filetime_str.asp) instead.
It's possible add to ofifcial plugin next thing - create tag first_played if play_count and play_counter equal zero or not presents and last_played tag not presents?
Without tag "first_played" statistics monitoring is useless!
No one mentioned this here..
the official component updated to v1.2.
http://www.foobar2000.org/beta/components.html (http://www.foobar2000.org/beta/components.html)
Just with the new beta
Is it possible to save in a dedicated statistics file?
Like statistics.txt in foobar directory (or User/home directory).
And will it be possible to add a field fore every time playing a song fore better statistick. That would open fore viewing "hot" songs and diagrams over a specified month.
Thanks fore all the wonderfull work with foobar.
Sorry fore the bad english.
No one mentioned this here..
the official component updated to v1.2.
http://www.foobar2000.org/beta/components.html (http://www.foobar2000.org/beta/components.html)
Just with the new beta
... maybe change logs are forbidden by some forum rules...
Hello everybody,
I have found a bug. You can see the result in the screenshot.
Screenshot (http://www.holzhaeuer.info/foobar/bug_double_names.gif)
First I blamed foo_sic for the doubled tags as it happens right after computing the fingerprint but after removing one plugin after the other I found out it is only playcounts' fault.
Using foobar 0.9.3 beta 2 and official playcount 1.2
Does anyone else experience this behaviour?
Hello everybody,
I have found a bug. You can see the result in the screenshot.
Screenshot (http://www.holzhaeuer.info/foobar/bug_double_names.gif)
First I blamed foo_sic for the doubled tags as it happens right after computing the fingerprint but after removing one plugin after the other I found out it is only playcounts' fault.
Using foobar 0.9.3 beta 2 and official playcount 1.2
Does anyone else experience this behaviour?
Yes. I have this issue. It also occurs if you use masstagger scripts from the context menu too often. Try it by changing the rating of a song several times.
Well, I tried updating the new play_counnt manually via context menu. The old play_counter tag is REPLACED with a play_count tag. And the field is updates - that is, it does not start from zero.
Am I right??
Also, why is it disrecommended to auto-sync files tags with statistics?? Playcount unofficial used to write tags during playback with no fatal problems, and quite flawless in foobar 0.8.3.
No one mentioned this here..
the official component updated to v1.2.
http://www.foobar2000.org/beta/components.html (http://www.foobar2000.org/beta/components.html)
Just with the new beta
... maybe change logs are forbidden by some forum rules...
The official page doesn't say much, but
* View your playback stats in Properties, on the General Properties tab, for one or multiple tracks
* No weirdy LAST_PLAYED_TIMESTAMP visible now
I have found a bug. You can see the result in the screenshot.
Screenshot
I also have this bug but it only appears with ogg vorbis files (at least, not with mp3 and mpc) when the component synchronise file tags with tags .
As beto said the bugs also appears when retagging playing ogg vorbis files.
"The double name" bug desappears when the song stops.
So it's seems to be
a bug with ogg vorbis tags .
Not that i don't like to official playcount, but could you add an option to select what info you want have to be stored in db/mp3 tag? Some users dont need the first played, some do, so why not let them chose?
And could you let the user chose again if he wants the timestamp or the other format of the last/first played time? I'd rather like to have all tags in the mp3's instead of the db (for the case the db gets lost/damaged/whatver) so that the statistics can be restored. But what shall i do with this wired timestamp, having the 'real life time' format is much easier to handle IMHO.
As you see, and already might know, to let users chose what and where the plugin writes might be a bit better. Perhaps you could add some of these options in further versions. thanks anyways.
(What about a changelog for 1.2 -> 1.3.1? ^^)
Oficial playcount plugin had been updated to version 1.3.1.It now features the %first_played% field
and IMO now it is better than the unoficial one
Get it here: http://www.foobar2000.org/components/index.html (http://www.foobar2000.org/components/index.html)
i had a little bit of trouble with it at first, but i got it straightened out. it works great now. i really like how it doesn't have a pop-up window when it updates. my only complaint/request is that i'd like to be able set when the plug-in updates the song.
i had a little bit of trouble with it at first, but i got it straightened out. it works great now. i really like how it doesn't have a pop-up window when it updates. my only complaint/request is that i'd like to be able set when the plug-in updates the song.
that would be nice. as well as updating files that are not in the database. and perhaps some way to syncronize the existing statistics that have been collected over the past 2 years.
also, how is "128002441598125000" usefull to me when i want to know the date and time the last time a track played?
Is there any way to transfer the play_count data between files without writing the data to the file?
For instance if I have a song in mp3 and I re-rip to flac could I transfer the data between them?
Is it possible to retrieve the playback statistics information from another plugin without having the statistics synced with the file tags (without resorting to a titleformatting call)?
Thanks.
Is there any way to transfer the play_count data between files without writing the data to the file?
For instance if I have a song in mp3 and I re-rip to flac could I transfer the data between them?
Anyone???
unabatedshagie: No.
question after the latest version of play back statistics I have decided to convert all my current tags ie play_counter to play_count, this is working fine, how ever it does not put the play count information in the database and simply comes up as another tag...
if there a way I can convert my play count tag data to the playback statistics?
any help apreciated...
The no pop-up dialog would be a big selling point for me switching to the official version (I hate that dialog ), except that I have no idea how to read the date tags. Could someone please post a bit of code to translate the number into a useable date and time (including weekday, if possible)?
Also, I made a request a couple of years back to the unofficial version which got implemented, so, here I go again...
When using foo_dsp_continuator, short tracks don't get tagged by foo_playcount. Could an option be added to tag short tracks (<30secs) as soon as they begin, instead of waiting for a certain amount to be played?
C'mon folks! Any reply to my previous post. ^^^
The unofficial plugin has been behaving oddly of late. When writing the tag, it sometimes makes the music pause or stutter, then I find my track has been played three times within a matter of seconds.
How do you import data from the previous playcount plugin? play_counter appears to be automatically imported but first_played and last_played appear to be ignored. first_played_timestamp and last_played_timestamp aren't ignored, but I think it's impossible to convert first_played to a win32 FILETIME with masstagger, and I don't see how to update the playcount plugin's database from the file tags in batch (without playing each file once), so I can't import 2/3 of my old plugin's playcount data.
Since I couldn't find any information about the timestamps for the official playback statistics component, I worked through them myself.
General information:
180000000000 is 1601-01-01 00:00:00 any lower number gives invalid timestamp errors [Edit: as noted below this number is probably related to timezone, all numbers should then be adjusted by the number of hours from GMT, in this case GMT - 5 hours]
The last seven digits are probably some fraction of a second
180010000000 is 1601-01-01 00:00:01
180600000000 is 1601-01-01 00:01:00
216000000000 is 1601-01-01 01:00:00
126230400000000000 is 400 years, approximately (400*365.25*24*60*60)
126227988000000000 is 2001-01-01 00:00:00
126543348000000000 is 2002-01-01 00:00:00
126858708000000000 is 2003-01-01 00:00:00
127174068000000000 is 2004-01-01 00:00:00
127490292000000000 is 2005-01-01 00:00:00
127805652000000000 is 2006-01-01 00:00:00
10000000 is one second
600000000 is one minute
36000000000 is one hour
864000000000 is one day
315576000000000 is one year on average
315360000000000 is one year, non-leap year
316224000000000 is one year, leap year
Here are some scripts for converting old format data to the new format (assuming you are using tags and not the database). They all will only work for dates/times after 2001-01-01 00:00:00 as I didn't need to overcomplicate them to work for me (this way I only had to account for one leap year).
To convert FIRST_PLAYED to FIRST_PLAYED_TIMESTAMP (format: 200Y-MM-DD HH:MM:SS):
$add($select($substr(%first_played%,4,4),
126227988000000000,126543348000000000,126858708000000000,127174068000000000,127490292000000000,
127805652000000000),$mul($select($substr(%first_played%,6,7),0,31,$ifequal($substr(%first_played%,4,4),4,60,59),
$ifequal($substr(%first_played%,4,4),4,91,90),$ifequal($substr(%first_played%,4,4),4,121,120),
$ifequal($substr(%first_played%,4,4),4,152,151),$ifequal($substr(%first_played%,4,4),4,182,181),
$ifequal($substr(%first_played%,4,4),4,213,212),$ifequal($substr(%first_played%,4,4),4,244,243),
$ifequal($substr(%first_played%,4,4),4,274,273),$ifequal($substr(%first_played%,4,4),4,305,304),
$ifequal($substr(%first_played%,4,4),4,335,334)),864000000000),$mul($sub($substr(%first_played%,9,10),1), 864000000000),$mul($substr(%first_played%,12,13),36000000000),$mul($substr(%first_played%,15,16),
600000000),$mul($substr(%first_played%,18,19),10000000))
To convert LAST_PLAYED to LAST_PLAYED_TIMESTAMP (format: 200Y-MM-DD HH:MM:SS):
$add($select($substr(%last_played%,4,4),
126227988000000000,126543348000000000,126858708000000000,127174068000000000,127490292000000000,
127805652000000000),$mul($select($substr(%last_played%,6,7),0,31,$ifequal($substr(%last_played%,4,4),4,60,59),
$ifequal($substr(%last_played%,4,4),4,91,90),$ifequal($substr(%last_played%,4,4),4,121,120),
$ifequal($substr(%last_played%,4,4),4,152,151),$ifequal($substr(%last_played%,4,4),4,182,181),
$ifequal($substr(%last_played%,4,4),4,213,212),$ifequal($substr(%last_played%,4,4),4,244,243),
$ifequal($substr(%last_played%,4,4),4,274,273),$ifequal($substr(%last_played%,4,4),4,305,304),
$ifequal($substr(%last_played%,4,4),4,335,334)),864000000000),$mul($sub($substr(%last_played%,9,10),1),
864000000000),$mul($substr(%last_played%,12,13),36000000000),$mul($substr(%last_played%,15,16),600000000),
$mul($substr(%last_played%,18,19),10000000))
To convert PLAY_DATE and PLAY_TIME to a timestamp (date format: DDMMYY; time format: HHMMSS)
$add($select($substr(%play_date%,6,6), 126227988000000000,126543348000000000,126858708000000000,127174068000000000,127490292000000000,
127805652000000000),$mul($select($substr(%play_date%,3,4),0,31,$ifequal($substr(%play_date%,6,6),4,60,59),
$ifequal($substr(%play_date%,6,6),4,91,90),$ifequal($substr(%play_date%,6,6),4,121,120),
$ifequal($substr(%play_date%,6,6),4,152,151),$ifequal($substr(%play_date%,6,6),4,182,181),
$ifequal($substr(%play_date%,6,6),4,213,212),$ifequal($substr(%play_date%,6,6),4,244,243),
$ifequal($substr(%play_date%,6,6),4,274,273),$ifequal($substr(%play_date%,6,6),4,305,304),
$ifequal($substr(%play_date%,6,6),4,335,334)),864000000000),$mul($sub($left(%play_date%,2),1), 864000000000),$mul($left(%play_time%,2),36000000000),$mul($substr(%play_time%,3,4),600000000),
$mul($substr(%play_time%,5,6),10000000))
These scripts will all blindly overwrite any existing data in the target tags. I have not thoroughly tested them, especially for any date before 2005-01-01 as none of my existing tags had data for any earlier dates. I had some errors in my accounting of days in early versions of these scripts, but I think that I've found and fixed them all. If you notice that any particular months convert incorrectly (probably one or two days off from expected), let me know.
Edit: Yeah, the 180000000000 is related to time zone, I didn't really bother to think about that (I did determine it was 5 hours, but I didn't really care because my script works for me). Plus if anyone wants to use these scripts, they'll have to remove all of the line breaks I added. All of the statistics that I cared about were stored with the files as I have a tendency to lose my configs (like having the unofficial statistics plugin bringing down my computer and corrupting my foobar config).
General information:
180000000000 is 1601-01-01 00:00:00 any lower number gives invalid timestamp errors
180000000000 is also equal to 5 hours, which means you're probably in the eastern time zone, and this script also only returns correct dates for people in the eastern time zone, though that's not a big deal for me since most of the data I want is relative anyways.
Now that it's possible (but ugly) to convert first/last played times to the required format, how can I import the data without playing each file for one minute (which also wipes the correct last_played data and increments the play_count by one)?
In addition, when you use %last_played% the value in LAST_PLAYED takes precedence over the value in LAST_PLAYED_TIMESTAMP, so while the timestamp is updated with this plugin, the LAST_PLAYED value is the one displayed. You have to delete the LAST_PLAYED tag to get %last_played% to display the LAST_PLAYED_TIMESTAMP. Of course, you could use %last_played_timestamp%, but there won't be any formatting done so you just get the number.
There is a new version versinon nr. 1.3.2) on the server (http://foobar2000.org/components/index.html).
Does anybody know what is new?
Thanx
Reworked the code to make it easier to modify for different time zones and also ran them through more thorough testing.
In the part of the code that is "$mul(10000000,$add($mul(
5,3600)" change the 5 to an appropriate offset value for your data. All of these only work for dates on or after 2001-01-01 00:00:00.
To convert PLAY_DATE and PLAY_TIME to timestamps (date format: DDMMYY; time format: HHMMSS):
$mul(10000000,$add($mul(5,3600),$select($put(x_year,$substr(%play_date%,6,6)),12622780800,
12654316800,12685852800,12717388800,12749011200,12780547200),$mul($select($substr(%play_date%,3,4),
0,31,$ifequal($get(x_year),4,60,59),$ifequal($get(x_year),4,91,90),$ifequal($get(x_year),4,121,120),
$ifequal($get(x_year),4,152,151),$ifequal($get(x_year),4,182,181),$ifequal($get(x_year),4,213,212),
$ifequal($get(x_year),4,244,243),$ifequal($get(x_year),4,274,273),$ifequal($get(x_year),4,305,304),
$ifequal($get(x_year),4,335,334)),86400),$mul($sub($left(%play_date%,2),1),86400),
$mul($left(%play_time%,2),3600),$mul($substr(%play_time%,3,4),60),$substr(%play_time%,5,6)))
To convert FIRST_PLAYED to timestamp (format: 200Y-MM-DD HH:MM:SS):
$mul(10000000,$add($mul(5,3600),$select($put(x_year,$substr(%first_played%,4,4)),12622780800,
12654316800,12685852800,12717388800,12749011200,12780547200),$mul($select($substr(%first_played%,6,7),
0,31,$ifequal($get(x_year),4,60,59),$ifequal($get(x_year),4,91,90),$ifequal($get(x_year),4,121,120),
$ifequal($get(x_year),4,152,151),$ifequal($get(x_year),4,182,181),$ifequal($get(x_year),4,213,212),
$ifequal($get(x_year),4,244,243),$ifequal($get(x_year),4,274,273),$ifequal($get(x_year),4,305,304),
$ifequal($get(x_year),4,335,334)),86400),$mul($sub($substr(%first_played%,9,10),1),86400),
$mul($substr(%first_played%,12,13),3600),$mul($substr(%first_played%,15,16),60),$substr(%first_played%,18,19)))
To convert LAST_PLAYED to timestamp (format: 200Y-MM-DD HH:MM:SS):
$mul(10000000,$add($mul(5,3600),$select($put(x_year,$substr(%last_played%,4,4)),12622780800,
12654316800,12685852800,12717388800,12749011200,12780547200),$mul($select($substr(%last_played%,6,7),
0,31,$ifequal($get(x_year),4,60,59),$ifequal($get(x_year),4,91,90),$ifequal($get(x_year),4,121,120),
$ifequal($get(x_year),4,152,151),$ifequal($get(x_year),4,182,181),$ifequal($get(x_year),4,213,212),
$ifequal($get(x_year),4,244,243),$ifequal($get(x_year),4,274,273),$ifequal($get(x_year),4,305,304),
$ifequal($get(x_year),4,335,334)),86400),$mul($sub($substr(%last_played%,9,10),1),86400),
$mul($substr(%last_played%,12,13),3600),$mul($substr(%last_played%,15,16),60),$substr(%last_played%,18,19)))
hi, im using normal %last_played% tags in the playlist tree. where the tags already have the date. if i switch to this plugin, will all this code make the tree unusable when it has to process this code for every song?
I don't know if it would make the tree unuseable, but if you are using the official playback statistics, you'd want to convert the tags into the new format so that they are being updated by the plugin correctly.
I wrote the above code for the mass tagging utility in foobar. Right click on a song > Tagging... > Manage Scripts > click on Add > select "Format value from other fields..." > type in or select the tag that you want to modify (such as LAST_PLAYED_TIMESTAMP) > paste my code into "Formatting pattern:" field (after removing all of the line breaks, because the code should all be on one line) > press OK > put a name for the script in the "Scripts" field > click on save.
You can then click on Run or use the right click menu to run the script on a song or a group of songs. Once you have confirmed that the conversion worked correctly (by comparing old tags' dates to new tags' dates), you then should delete/rename the old tags so that the new tags display properly in foobar (using %last_played%).
Edit: This will overwrite anything currently in LAST_PLAYED_TIMESTAMP, so if there is any data in the tag you should probably copy it to another tag until you are sure you don't want it.
It seems that if Foobar is used to rename or move files with db-only tags, the stored playback statistics are lost! Even renaming the file back to it's original name doesn't help. Is this intended behaviour? And if so, is the only way around this to store the playback statistics in the file tags? If that is the case, what would be the easiest way to convert the tags stored in the db into file tags in masstagger?
Reworked the code to make it easier to modify for different time zones and also ran them through more thorough testing.
In the part of the code that is "$mul(10000000,$add($mul(5,3600)" change the 5 to an appropriate offset value for your data. All of these only work for dates on or after 2001-01-01 00:00:00.
i am here:
Standard time zone: UTC/GMT +1 hour
Daylight saving time: +1 hour
Current time zone offset: UTC/GMT +2 hours
Time zone abbreviation: CEST - Central European Summer Time
Shall i use current real time offse without daylight savings, and, since it is plus and not minus how shall i adapt that piece of code?
thanks in advance
Please allow me to choose to apply this plugin to music that is not in my database! (I am using it on newly downloaded music that hasn't been imported yet. I very frequently do that, so to update by database each and every time is a little unnecessary. Not to mention, I just don't like to use the database and you could allow me to do that if the old option was re-created.) In general, all of the settings on the unofficial version would be very handy! ... >_<
Please allow me to choose to apply this plugin to music that is not in my database! (I am using it on newly downloaded music that hasn't been imported yet. I very frequently do that, so to update by database each and every time is a little unnecessary. Not to mention, I just don't like to use the database and you could allow me to do that if the old option was re-created.) In general, all of the settings on the unofficial version would be very handy! ... >_<
i like the fact that it tries to keep the statistics off the files, but it's just not sophisticated enough to track files that have been moved. maybe the move and rename options in foobar will allow you to keep the stats.
also, i think this might be considered a bug. lets say i run a script to convert old tags to the new tag scheme. if i do this and then synchronize the statistics with the file tags, the stats are wiped. this is fine, but when i reload the files in the database and then synchronize the statistics the tags are still wiped. it seems that the statistic tags are only updated properly in the database after a file has been played. shouldn't the this also happen when the database is rescanned?
i tried to screw with the play counts by restarting foobar and messing with the slider. it only updated tags once after the file was loaded and 60 seconds of the track played, or less of the track length is under 60 seconds. it does this regardless if foobar restarted and playback is resumed. i don't think this behavior could be any better.
as for stats not updating on files not in the database, i hope someone can make an option for this, as well as reloading info and stats from file(s).
here is the masstagger script i put together that will convert YYYY-MM-DD hh:mm:ss tags to whatever format this plugin uses. the code is by iridium183.
stats format updater.mts (http://home.cogeco.ca/~rmalcolm/stats%20format%20updater.mts)
I've been reading this thread to better understand the behavior of this component, and I'd like to record what I've learned in the wiki. Before I do, is the following accurate?:
* Playback statistics are stored in the foobar database (database.fpl), and are retrievable by using %LAST_PLAYED%, %FIRST_PLAYED%, and %PLAY_COUNT%. Stats can be written to tags through either a context menu or by enabling tag writing in foobar's advanced preferences section.
* When stats are written to the file's tags, they are given the names %LAST_PLAYED_TIMESTAMP% and %FIRST_PLAYED_TIMESTAMP%
* If you had previously written playback stats to your files using the unofficial foo_playcount, that component's %PLAY_COUNTER% value will be incorporated into the official foo_playcount's %PLAY_COUNT% value to retain playcount history.
* The official foo_playcount will not, however, incorporate the unofficial component's %FIRST_PLAYED% field. The old value will remain in the tag and the new value will be written to the database.
* If %FIRST_PLAYED% or %LAST_PLAYED% is called, and values exist both in the file's tag and in the database, the file's tag will take precedence.
* %PLAY_COUNT% is increased by 1 when 60 seconds of a file have elapsed, whether consecutively or not. This threshold is shorter for songs shorter than 60 seconds.
* %LAST_PLAYED% and %FIRST_PLAYED% are stored in the format YYYY-MM-DD HH:MM:SS
Is there anything else I should mention?
* Playback statistics are stored in the foobar database (database.fpl), and are retrievable by using %LAST_PLAYED%, %FIRST_PLAYED%, and %PLAY_COUNT%. Stats can be written to tags through either a context menu or by enabling tag writing in foobar's advanced preferences section.
The statistics are not stored in database.fpl, but in foobar2000.cfg. The rest is correct.
* If you had previously written playback stats to your files using the unofficial foo_playcount, that component's %PLAY_COUNTER% value will be incorporated into the official foo_playcount's %PLAY_COUNT% value to retain playcount history.
Yes, the component should import an existing play count value from file tags.
* The official foo_playcount will not, however, incorporate the unofficial component's %FIRST_PLAYED% field. The old value will remain in the tag and the new value will be written to the database.
Yes, playback timestamps will not be imported.
* If %FIRST_PLAYED% or %LAST_PLAYED% is called, and values exist both in the file's tag and in the database, the file's tag will take precedence.
Yes, actual tags always take precedence over "virtual" fields provided by a component such as foo_playcount (see below).
* %PLAY_COUNT% is increased by 1 when 60 seconds of a file have elapsed, whether consecutively or not. This threshold is shorter for songs shorter than 60 seconds.
Correct.
* %LAST_PLAYED% and %FIRST_PLAYED% are stored in the format YYYY-MM-DD HH:MM:SS
Not quite. foo_playcount actually stores those timestamps as Win32 FILETIME values (i.e. 100ns intervals since January 1, 1601). If you synchronize playback statistics to files, they will be stored in text form as %first_played_timestamp% and %last_played_timestamp% (and only in that case will you be able to access the raw timestamps in titleformatting scripts with these names). foo_playcount provides the fields %first_played% and %last_played% dynamically to titleformatting scripts using the date format you mentioned.
Thanks foosion -- though it appears the wiki is locked.
I know this has been discussed before, so excuse me if this is something you've considered and decided against. But I would really like the option for a multi-value %PLAY_STAMP% field that contains timestamps for every time a track is played. With the new file properties dialog, these won't take up tons of room (which was an earlier concern), and the data could prove useful (for instance, in my hotness code).
I know it's arguably frivolous, but giving us the option would be nice.
edit: Also, can the wiki page for this component be unlocked so that I can add that info from a few posts ago? Or can someone else add it? Those are important facts about the way the component behaves, it's a shame that you have to mine the forum to learn them.
I had been using the old playcount component until a few months ago when I finally made the switch to 0.9.x, but I didn't realize that the datestamp formats had changed. I'm trying to figure out exactly how to convert the legacy data into the new format and having a bit of trouble.
The biggest part of the problem stems from the fact that I've been using the new official component for a few months, and I can't just blindly convert all the old datestamps over without clobbering the more recent data. (I think? Or can I?) The official component wasn't configured to automatically write to tags, so the most recent datestamps exist only in the database. The old data from the 0.8.x playcount component are in FIRST_PLAYED/LAST_PLAYED tags, in YYYY-MM-DD HH:MM:SS format.
From what I've been able to figure out so far, I just need to convert all the old FIRST_PLAYED tags to FIRST_PLAYED_TIMESTAMP with the snippet a few posts above this one, then remove the FIRST_PLAYED tag so that %first_played% will use the internally-calculated value instead of the physical tag. However, I tested this out on a few files, and foobar is ignoring the new FIRST_PLAYED_TIMESTAMP tag which I just wrote to the file, and reporting the value for %first_played% that it had in the database before, even after reloading the info from disk. Am I doing something wrong? Is there any way I can wipe all the timestamps from the database and get foobar to just use whatever it sees in the file tags after I convert them to the new format? Keeping the metadata with the files themselves rather of tucking them away in a seperate database/config file is my preferred method, so I certainly won't mind syncing the stats with the file tags first if I have to.
walla: The amount of seconds since January 1st 1970 00:00.
EDIT: typo
Wrong. It is not a UNIX time, which is quite easy to see, if you try to interpret the number as such (year 4,058,128,518). Try Win32 FILETIME (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sysinfo/base/filetime_str.asp) instead.
Sorry I didn't understand whats on the linked page. How kann I show the date and time last played in tags?
You can see this correct in properties - properties tab
Iridium: Do I understand your description correct you added a script which add the right time tag?
@Gob the .mts doesn't work for me
How can I get rid of the useless timestamp tags? and have instead last_played/First played?
@Gob the .mts doesn't work for me
How can I get rid of the useless timestamp tags? and have instead last_played/First played?
i'm not too sure what you're asking here. are you sure you're using my mts for the right purpose? and what are the useless tags you are trying to get rid of?
Sorry I was a bit angry Now I feel ashamed.
So for example I have a a track:
Artist Name : Ensiferum
Track Title : Goblins' Dance
Album Title : Ensiferum
Date : 2001
Genre : Metal
Track Number : 12
<FIRST_PLAYED_TIMESTAMP> : 128097358089062500
<LAST_PLAYED_TIMESTAMP> : 128106551782812500
<PLAY_COUNT> : 4
On properties tab:
Played : 4 times
First Played : 2006-12-04 20:56:48
Last Played : 2006-12-15 12:19:38
I loaded your script and ran it. As you can see there are the timestamp tags.But there is no date.
So I thought it didn't work. Maybe I have done something wrong?
Please give me some adwise.
Sorry for beeing so stupid.
is it possible to convert the last_played-timestamp back to last_played?
cause i wanna go back to the unofficial play_count cause i dont like the db-only-tags - also i wanna see the tags in other components like foo_infobox.
i like the fact that it tries to keep the statistics off the files, but it's just not sophisticated enough to track files that have been moved. maybe the move and rename options in foobar will allow you to keep the stats.
This isn't the case - using the moving and renaming things in foobar still removes the statistics. It would be nice if this could be fixed since it makes moving files and preserving the statistics quite complicated.
foo_playcount actually stores those timestamps as Win32 FILETIME values (i.e. 100ns intervals since January 1, 1601). If you synchronize playback statistics to files, they will be stored in text form as %first_played_timestamp% and %last_played_timestamp% (and only in that case will you be able to access the raw timestamps in titleformatting scripts with these names). foo_playcount provides the fields %first_played% and %last_played% dynamically to titleformatting scripts using the date format you mentioned.
Just out of curiosity: is there any advantage/benefit of recording the values in this format rather than the more readable format that the unofficial plugin uses?
I just noticed that when you perform a file move operation in foobar, playback statistics are lost. Can this be prevented in future versions?
I just noticed that when you perform a file move operation in foobar, playback statistics are lost. Can this be prevented in future versions?
Hopefully!
I recognized that the opportunity to define in Preferences -> Advanced the time
when the playcounter should be increased is very important although the behaviour to update aafter one minute of playback is very good for normal tracks. But what about tracks under one minute? Also audiobooks, speeches and more that last two hours and more. These are files that are often heard in many sessions and when i complete hearing it the first time i am told that it was heard five times or more.
Great would be to define the time in dependence of tracks length - i am thinking about using Tagz for that
iridium183, I really appreciate the work you've put into you're date/time conversion scripts. The only problem I see, however, is they cannot handle input values that were written in 2007, and write the year as 1601 (the rest of the date/time are accurate).
And does anyone have an idea of how long this "standard" is expected to last? A month? Two?
As I have fixed the conversion from unofficial plugin -> official:
The play counting is easy since -as already mentioned- Foobar 0.9 automatically changes %PLAY_COUNTER% to %PLAY_COUNT%. Just masstag every ...counter to ...count or use something like $if3(%play_counter%,%play_count%,).
The LAST_PLAYED_TIMESTAMP can be read with %LAST_PLAYED% without the _TIMESTAMP bit. You get the correct date / time automatically!
Only problem is that if you used the unofficial plugin you already have the LAST_PLAYED tag in your files. Foobar will not read LAST_PLAYED_TIMESTAMP as long as LAST_PLAYED is there. So masstag all LAST_PLAYED to something else (I used LAST_PLAY). With $if3(%last_played%,%last_play%) Foobar will read the LAST_PLAYED_TIMESTAMP first and if that one is not (yet) available read the old unofficial plugin's LAST_PLAY tag.
As I have fixed the conversion from unofficial plugin -> official:
The play counting is easy since -as already mentioned- Foobar 0.9 automatically changes %PLAY_COUNTER% to %PLAY_COUNT%. Just masstag every ...counter to ...count or use something like $if3(%play_counter%,%play_count%,).
The LAST_PLAYED_TIMESTAMP can be read with %LAST_PLAYED% without the _TIMESTAMP bit. You get the correct date / time automatically!
Only problem is that if you used the unofficial plugin you already have the LAST_PLAYED tag in your files. Foobar will not read LAST_PLAYED_TIMESTAMP as long as LAST_PLAYED is there. So masstag all LAST_PLAYED to something else (I used LAST_PLAY). With $if3(%last_played%,%last_play%) Foobar will read the LAST_PLAYED_TIMESTAMP first and if that one is not (yet) available read the old unofficial plugin's LAST_PLAY tag.
You can also do this (http://www.hydrogenaudio.org/forums/index.php?showtopic=46582&st=50#).
I have the Playback Statistics 1.3.2 installed. How is this plugin working?
Does it only update the DB after i have played a whole title or also if i play about 50% of a title?
you could try reading or searching the thread (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=46582&view=findpost&p=453926) before asking a question.
Thanks
But it's realy hard to read all interesting threads if you are new. ColumsUI, PanelUI, Trackinfo then i will need about more than a week to read them all
Update occurs after 60s of playing.
I have had various versions of Foobar v0.9.4.x hang my PC entirely a few times and I suspect Playback Statistics is the cause as I have it set to synchronizing file tags with database automatically.
I suppose I should disable auto synchronization - but I feel more comfortable with the statistics stored in my file tags. What is the general practise for most of you?
Another problem, I'm using foo_uie_trackinfo and will it will update the %last_played% tag live i.e. when the track has played more than 60 seconds, the play count remains unchanged until I sync the database info back to the file tag. Any suggestions how to deal with this?
I just noticed that when you perform a file move operation in foobar, playback statistics are lost. Can this be prevented in future versions?
Just curious, are developers aware of this problem? Is it not a problem at all, but rather intended behavior? It's becoming very frustrating to lose all that data when I move files.
edit: Also, can the wiki page for this component be unlocked so that I can add that info from a few posts ago? Or can someone else add it? Those are important facts about the way the component behaves, it's a shame that you have to mine the forum to learn them.
And is there any chance of getting access to the wiki to include information about the component's behavior?
Finally, it would be nice to have an option to undo file tag synchronization, something that would take the data out of the tags and put them exclusively into the config file. Currently, removing the hard tags removes the "virtual" data as well.
I would also like to have the possibility to customize the timestamp setting behavior in some kind of an properties dialog.
1. minimum play time: The time a song has to be played before %play_count% is increased. I would prefer a setting in percent.
2. saving time: The time the tag is saved to db or file. This can be at minimum play time or the end of the song.
I just noticed that when you perform a file move operation in foobar, playback statistics are lost. Can this be prevented in future versions?
Just curious, are developers aware of this problem? Is it not a problem at all, but rather intended behavior? It's becoming very frustrating to lose all that data when I move files.
This is a limitation of the implementation and was known from the start. As far as I know it cannot be fixed without breaking compatibility with the stored data (the one in foobar2000.cfg, file tags are safe).
edit: Also, can the wiki page for this component be unlocked so that I can add that info from a few posts ago? Or can someone else add it? Those are important facts about the way the component behaves, it's a shame that you have to mine the forum to learn them.
And is there any chance of getting access to the wiki to include information about the component's behavior?
As far as I can see, there is no special protection for that wiki page. There used to be a hint on the edit error page that you (a) need to have a wiki account to edit any page at all, and (b) need to contact Jan S. on the forum (include your wiki username in the message).
Thanks foosion.
I just noticed that when you perform a file move operation in foobar, playback statistics are lost. Can this be prevented in future versions?
Just curious, are developers aware of this problem? Is it not a problem at all, but rather intended behavior? It's becoming very frustrating to lose all that data when I move files.
This is a limitation of the implementation and was known from the start. As far as I know it cannot be fixed without breaking compatibility with the stored data (the one in foobar2000.cfg, file tags are safe).
In that case, would it be possible to implement my other suggestion, that there be a command to remove file-embedded playstamp tags, leaving the data only in foobar2000.cfg? I imagine this would be convenient anyway, for people who've been writing to their files and would like to stop doing that -- plus it would allow you to temporarily write the playstamps to the file tags, move the files (with playstamps preserved), then take them back out of the files.
In that case, would it be possible to implement my other suggestion, that there be a command to remove file-embedded playstamp tags, leaving the data only in foobar2000.cfg?
You can already do this. Just remove file-embedded playstamp tags using anyway you like (Masstagger is recommended). playcount info in CFG file will still be intact.
What i would like is.. an ability to manually stamp playcount info to files tag instantly when i want. Right now if i want playcount info to stamp to tag and not using automatic synchronize. I have to enable it. and play each file for 1 minute before files get stamp. and that's very annoying
or ability to choose what kind of filetype to use automatic synchronize or just use database. right now i see that WAV file can use database tag only to store playcount info even if i use automatic synchronize. it would be great if i can choose another filetypes too.
In that case, would it be possible to implement my other suggestion, that there be a command to remove file-embedded playstamp tags, leaving the data only in foobar2000.cfg?
You can already do this. Just remove file-embedded playstamp tags using anyway you like (Masstagger is recommended). playcount info in CFG file will still be intact.
Strange -- I swore I had tried that unsuccessfully earlier this week. Thanks.
edit: Actually, when I do this, the .cfg playstats don't survive the move of files. They appear to at first, showing up in the file properties tab, but when the embedded playstats are removed with masstagger, everything is lost.
So I guess what I'm looking for is a command to re-write the playstats to the .cfg file.
What i would like is.. an ability to manually stamp playcount info to files tag instantly when i want. Right now if i want playcount info to stamp to tag and not using automatic synchronize. I have to enable it. and play each file for 1 minute before files get stamp. and that's very annoying
Can't this be done with the "Synchronize Statistics with File Tags" command?, or are you describing something different?
What i would like is.. an ability to manually stamp playcount info to files tag instantly when i want. Right now if i want playcount info to stamp to tag and not using automatic synchronize. I have to enable it. and play each file for 1 minute before files get stamp. and that's very annoying
Can't this be done with the "Synchronize Statistics with File Tags" command?, or are you describing something different?
argh... You are right.. i remember that i used it once and it's screw my tag.(maybe because i do it the wrong way i guess)
and.. i thing we both want the same thing..
So I guess what I'm looking for is a command to re-write the playstats to the .cfg file.