Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Playback Statistics component: version 3.0.1 (Read 200312 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Playback Statistics component: version 3.0.1

Reply #25
I used converter to convert one of my library's lossless releases to lossy in a temp folder (c:\temp) that is not in my library path

It looks like intended behaviour to me, see the doc in the opening post.
In theory, there is no difference between theory and practice. In practice there is.

Playback Statistics component: version 3.0.1

Reply #26
It is delicate thing, but I would like to consider it as link to file path instead virtual tag linking as these files are not added in library

Playback Statistics component: version 3.0.1

Reply #27
I rewrote a couple of tags with mp3tags so they'd work properly with my iPod. Seems that wiped them from the Playback Statistics, as they lost statistics and got new %added% tags. After looking, ~350 files had their tags rewritten, ~150 of those lost their statistics.

The component should consider file paths as well, in case it doesn't.

By the way, some lossless formats have audio checksums, would it be possible to use those as well? FLAC does this quite well, though the fingerprints probably differ between different versions of a CD etc.

Playback Statistics component: version 3.0.1

Reply #28
By the way, some lossless files have audio checksums, wouldi t be possible to use those as well?


That seems quite clever. Has this ever been considered before?

 

Playback Statistics component: version 3.0.1

Reply #29
Background: I do not use file tags. [...] It sounds like the new version of this component will not work with my collection at all though.

The wiki doesn't mention it but there are fallbacks in place for tagless files. It should work just as well as old version.

Playback Statistics component: version 3.0.1

Reply #30
I rewrote a couple of tags with mp3tags so they'd work properly with my iPod. Seems that wiped them from the Playback Statistics, as they lost statistics and got new %added% tags. After looking, ~350 files had their tags rewritten, ~150 of those lost their statistics.

The component should consider file paths as well, in case it doesn't.


Your complaint is the only shortfall that I can see that's made me stick with the old one for the time being. There should be a way to select how the new component tracks stats.. be it by tags, by file path (only), by pattern, etc, and maybe a way to select the fallback method too.

Playback Statistics component: version 3.0.1

Reply #31
  - <your-foobar2000-profile>\index-data\6370B286-BE93-4A7C-AA3B-281FEC61B182



Just a quick question. I usually have the ''automaticly put info into file tags'' option on. But it seems the database itself is also a good way of storing it. But now my question; how many times does this file get saved? After every change or what?

Playback Statistics component: version 3.0.1

Reply #32
What about adding the HOTNESS  algorithm in the new component,  based on playcount, rating, last & first played timestamp?
Would be cool.

Playback Statistics component: version 3.0.1

Reply #33
It would be nice if there would be additional field returning number of tracks/files that share same statistics (also, maybe an option to quickly find all of them - like options from QuickSearch that adds additional items into context menu for artist/album).

Playback Statistics component: version 3.0.1

Reply #34
Feature proposal.

Are there any chance of adding %album rating%?

I understand that:

1. There will be duplication for each track of the album.
2. Probably it's not too easy to implement because current scheme uses track as a particle.
3. Album rating could be calculated (at least visually) as aggregate rating of all tracks.

But the main idea is that track rating is used for tracks being played out of album context.
And there's no way to find albums that are great as a whole. E. g. Beatles' "Abbey Road" is a great album.
But there are several tracks that should be played consequently. And it's not a good idea to have them in
auto playlist called "my favourite tracks".

Yes, I know I can use tags for storing such info, but I guess storing it along with %rating% is a better idea.

Thanks

Playback Statistics component: version 3.0.1

Reply #35
This is awesome and leads to a feature request I've wanted for a LONG time, namely the ability to merge playback statistics. I listen to music at home and at work. I copy albums from my home computer, bring them to work and listen to them here. I would love the ability to export the playback statistics from work, take them home and then merge them with my existing play counts. I assume a tool could be easily written to do this via, comparing XML documents, but it'd be great if it were built in to the component itself.

Playback Statistics component: version 3.0.1

Reply #36
The functionality of this component looks interesting, but I need to make sure that my file tags are respected: PLAY_COUNTER, FIRST_PLAYED, LAST_PLAYED. Is that the case?

Playback Statistics component: version 3.0.1

Reply #37
hey peter, thanks really enjoying the new beta of playcount.  simply fantastic!
your hard work is much appreciated!

Playback Statistics component: version 3.0.1

Reply #38
but I need to make sure that my file tags are respected: PLAY_COUNTER, FIRST_PLAYED, LAST_PLAYED. Is that the case?


No. Your tags are not the official ones.

Playback Statistics component: version 3.0.1

Reply #39
http://wiki.hydrogenaudio.org/index.php?ti...rmatting_fields

Quote
%first_played% - date/time at which the song was played for the first time.
%last_played% - date/time at which the song was played last time.
%play_count% - how many times the song has been played.
%played_per_day% - estimate how many times per day the song has been played, based on time first played, time last played and times played.
%added% - date/time at which the song was added to the Media Library.
%rating% - song's rating, on a 1..5 scale.
%rating_stars% - song's rating, formatted as up to five stars, e.g. ★★★
%rating_stars_fixed% - song's rating, formatted as five stars, e.g. ★★★☆☆

Playback Statistics component: version 3.0.1

Reply #40
Great addition, keep up the good work!
Nice to see soft linking concepts in other plugins.
I also use the track duration for the matching in my plugin, maybe it can also be used in this plugin.

Playback Statistics component: version 3.0.1

Reply #41
Hey, does anyone know the exact algorithm that is used to generate the ID field in the exported XML? I'm trying to write a program to import my statistics from another player

Example:
Code: [Select]
<Entry ID="00f74f2216a06220" Count="0" Added="129256773087720756" />


is generated for Indiana Jones by John Williams, track 00, no album name

Thanks

Playback Statistics component: version 3.0.1

Reply #42
but I need to make sure that my file tags are respected: PLAY_COUNTER, FIRST_PLAYED, LAST_PLAYED. Is that the case?


No. Your tags are not the official ones.


I have no problem using "PLAY_COUNT" instead of "PLAY_COUNTER", easy enough with Masstagger. BUT the information in the Wiki concerning the playstamp tags seems to be erroneous.
As another user quoted before, the expected tags should be

Code: [Select]
%first_played% - date/time at which the song was played for the first time.
%last_played% - date/time at which the song was played last time.


However, I made some tests, installed foo_playcount and checked "synchronize file tags with media library".  About a quarter into the song, the dreaded "FIRST_PLAYED_TIMESTAMP" and "LAST_PLAYED_TIMESTAMP" are written instead of the ones advertised in the Wiki. The only way to get rid of them is to install "foo_playback_custom" and let it convert them automatically immediately afterwards to the correct format "first_played" and "last_played". Having to install 2 extensions to get correct tags can't be right, though.

Playback Statistics component: version 3.0.1

Reply #43
%first_played% and %last_played% will return dates/times when used in Foobar, but the component writes them to tags as UTC (?).

Playback Statistics component: version 3.0.1

Reply #44
%first_played% and %last_played% will return dates/times when used in Foobar, but the component writes them to tags as UTC (?).


No fields which are called "%first_played%" or "%last_played%" are written as tags at all.

Playback Statistics component: version 3.0.1

Reply #45
Oh, didn't see the part about Masstagger. You could use the properties dialog to write them.
Properties, right-click, "Automatically fill values".
http://img525.imageshack.us/img525/241/afv.jpg

EDIT: Uh, *facepalm*. There should a command for "Format from tags" or similar in Masstagger.

Playback Statistics component: version 3.0.1

Reply #46
After playing around a bit with this component, here's my verdict:

GOOD
    1) Tags stored in database can apply to various albums with the same name

    2) Playstamp tags appear in Properties dialogue, rather than the metadata dialogue. This takes care of situations where one doesn't want a file hash to change every time its statistics are updated.

    3) Star display for ratings[/li]


BAD
    a) The "Ratings"-field is a universal tag used by Windows  and other media players and must appear as a tag under Metadata, not as a file property as it does with this component. A rating is not a physical property of a file.

    b) Names of statistical fields are different for tags and database. ADDED vs. ADDED_TIMESTAMP, LAST_PLAYED vs. LAST_PLAYED_TIMESTAMP, FIRST_PLAYED vs. FIRST_PLAYED_TIMESTAMP. There's no reason this plugin should be an exception to every other tag in foobar with its query syntax not having the same name as the tag. It's also bad programming: a database should store a date value as integer but display it as a human-readable date according to the users country/language setting of the OS. (These values are also not physical properties of a file, btw.)

    c) Reading of database values takes precedence over tags-reading. It must be the other way round (at least as soon as "Automatically synchronize file tags with statistics" is enabled, but possibly always). Otherwise the plugin breaks compatibility with the field "rating" since that is being completely ignored if it is written as a tag, but not added to the database (it also block the "Quick Tagger" plugin).[/li]



Playback Statistics component: version 3.0.1

Reply #47
c) Reading of database values takes precedence over tags-reading. It must be the other way round (at least as soon as "Automatically synchronize file tags with statistics" is enabled, but possibly always). Otherwise the plugin breaks compatibility with the field "rating" since that is being completely ignored if it is written as a tag, but not added to the database (it also block the "Quick Tagger" plugin).


I also would really like this to be optional as I have been using playback statistics custom for a while now and foobar can't read my first/last played from that time anymore

Why not somekind of options-page to customize what tags are enabled etc.?

Playback Statistics component: version 3.0.1

Reply #48
to display stuff in file tags, use $meta. eg

$meta(rating)
$meta(first_played)

Playback Statistics component: version 3.0.1

Reply #49
to display stuff in file tags, use $meta. eg

$meta(rating)
$meta(first_played)


I don't think that works with query syntax. I have an autoplaylist with last_played during 4 weeks, but foo_playcount overrides tags so I only have the songs I've played since installing this component.

Is there any way to save existing filetags to foo_playcount's database?