Playback Statistics component: v3.x foo_playcount

Topic: Playback Statistics component: v3.x foo_playcount (Read 227407 times) previous topic - next topic

0 Members and 6 Guests are viewing this topic.

Re: Playback Statistics component: v3.x foo_playcount

Reply #125 – 2010-09-22 19:52:58

Quote from: carpman on 2010-09-20 01:39:20

Allow the user to set which fields they want to use to define the UID.

I requested that too. But i think the big problem to implement this is that if you change the pattern for identification then the playback statistics must be erased. Just imagine a simple example: Let's say you have %artist% as pattern and you change it to %artist% %title% - how should the component know how much a title was played since it didn't track that?

Re: Playback Statistics component: v3.x foo_playcount

Reply #126 – 2010-09-26 04:50:49

Is there any way to increase the play count of whole albums? Thing is when I moved to Foobar I already listened to most of my music library, so I´m trying to set my listened music to >0 in the database to use it along with my custom playcount based playlists and random pools.
If I use the copy statistics button it will only set the playcount for the same amount of selected files and it will change as well the other stats. Also it would take forever to leave Foobar playing them all over again...
This was the reason of my earlier post, thanks in advanced.

Re: Playback Statistics component: v3.x foo_playcount

Reply #127 – 2010-09-26 05:47:02

Quote from: q-stankovic on 2010-09-22 19:52:58

I requested that too. But i think the big problem to implement this is that if you change the pattern for identification then the playback statistics must be erased. Just imagine a simple example: Let's say you have %artist% as pattern and you change it to %artist% %title% - how should the component know how much a title was played since it didn't track that?

What I don't get is if you have shared UIDs such as %artist% %title% and you have one added last year and a new one that matches that pattern what happens to the date based data? Is %added% anchored to the oldest date? Is last played anchored to the latest date?

I would have thought that the way to impliment such a method is to have both a real and a pseudo UID.
So stats are gathered at the Real UID level and then shared at the Pseudo UID level. When you change the Pseudo UID the stats are redistributed accordingly. So:

REAL UID: some kind of hash/fingerprint based on file data (that must always be unique).

c:\music\beatles 01 help.mp3
ADDED: 01.01.10
FIRST PLAYED: 01.01.10
LAST PLAYED: 06.06.10
Played: 5

c:\music\lossless\beatles 01 help_remaster.flac

ADDED: 02.02.10
FIRST PLAYED: 05.02.10
LAST PLAYED: 16.10.10
Played: 2

PSEUDO UID PATTERN: %artist% - %title% (NOT unique).

Stats Component collates data from REAL UIDs taking earliest %added%, earliest %first played%, latest %last played% and sums the playcount.

So we have:

Beatles - Help:
ADDED: 01.01.10
FIRST PLAYED: 01.01.10
LAST PLAYED: 16.10.10
Played: 7

When you change the Pseudo UID the data from the root Real UID is simply collated to fit the new Pseudo UID pattern.

Couldn't that have worked?

C.

Re: Playback Statistics component: v3.x foo_playcount

Reply #128 – 2010-09-26 10:43:23

Quote from: carpman on 2010-09-26 05:47:02

When you change the Pseudo UID the data from the root Real UID is simply collated to fit the new Pseudo UID pattern.

Couldn't that have worked?

Sure! Not that i know it or understand how playback statistics work but i assume that it works only on basis of "Pseudo UID" (edit: then it is the real ID naturally). However: How does it work if you enable file tag writing?

Re: Playback Statistics component: v3.x foo_playcount

Reply #129 – 2010-09-26 20:40:08

Is there an option to restrict updates (synchronize file tags) to files only to those referenced by Media Library? Or at least exclude http streams? Turning option to synchronize statistic with filed on causes interruption in playback

Re: Playback Statistics component: v3.x foo_playcount

Reply #130 – 2010-09-26 23:33:52

Quote from: q-stankovic on 2010-09-26 10:43:23

However: How does it work if you enable file tag writing?

Don't know. In fact the more I've thought about it the more I've realised that it's a bit of a nightmare and is very difficult to do well. For example, there's 3 things you can anchor the stats to:
1) Tags
2) Filename / Path
3) File contents (i.e. the audio data itself as some kind of signature)

If I changed any of these I wouldn't want the stats to alter. People often want to rename files, re-tag a wrongly tagged file, and (less) often change the audio (e.g. remove a click or pop from a lossless file). So what you anchor the stats to is not so obvious. Certainly not as obvious as I'd orginally thought. The first question to ask is what (if any) attributes of an audio file never change?

C.

Re: Playback Statistics component: v3.x foo_playcount

Reply #131 – 2010-09-27 21:33:59

Let's say you have two tracks: A and B wich have different tags.
There are now several situations that can happen.

1. A has no statistics but only %added% if at all - B has full statistics. If you change A to have same tags like B then A will get the statistics from B. That seems intuitive to me.

2. A has same full statistics like B. If you change tags of one of them then they will keep their statistics but from that point they are independent. That seems ok as i can't imagine why that should happen at all - it must be a great random accident that two files have exactly the same tags in identification sheme but aren't the same song.

3. A has full statistics and B has full statistics. If you change A to have same tags like B then A will get the statistics from B. About this point i am not sure. Maybe you just corrected the wrong spelling of an artist or did something similar? I have no idea why else after tagging the identification sheme of two file would become the same. Maybe i am missing something. But if not wouldn't it then be better to aggregate the statistics of the two files: summing up the playcount, the oldest first played timestamp, the newest last played timestamp? I think so!

Edit
@carpman
A comment to your "real id": that means the way of old playback statistics and that would lead to the old problem of loosing playback statistics after certain circumstances. That's what Peter tried to avoid.

Edit2
I tested the writing of statistic to file. It writes the database info to tag. The consequence is that you have wrong info if you regard statistics from tag as filespecific and/or different tags for tracks with same statistics in database. That seems to be an absolute senseless feature with great potential for confusion!

Edit3

Quote

Maybe i am missing something. But if not wouldn't it then be better to aggregate the statistics of the two files

Yes, i was missing something. Let's say you have A and B with same statistics because they have same tags, then you correct spelling of artist in A, because of that A and B become independent, then you correct spelling of artist in B. The senseless result would be doubling of playcount if my suggestion of aggregation would be implemented. I think the problem of my point 3 seems not to be solveable without abstruse sideeffects in certain scenarios.

Re: Playback Statistics component: v3.x foo_playcount

Reply #132 – 2010-09-28 00:41:55

Quote from: q-stankovic on 2010-09-27 21:33:59

@carpman
A comment to your "real id": that means the way of old playback statistics and that would lead to the old problem of loosing playback statistics after certain circumstances. That's what Peter tried to avoid.

No my point is this:

Quote

The first question to ask is what (if any) attributes of an audio file never change?

i.e. What about an audio file can you change, yet the song remains the same.
If you change its tags, filename, or repair a glitch it's still the same song. If you remove 30 secs of audio, it's not. But you can't use %length% as its UID. So what never changes, that you can use.

Anyway after reading up on the foo_playcount 3 it's not too big a deal, because:

Quote

When editing tags, affected playback statistics records are transferred accordingly.

[...]

Playback statistics data is no longer dropped when the tracks are removed from the media library. A record gets removed when no matching track has been seen by foobar2000 (in Media Library or in any playlist or in an imported XML backup of playback statistics) for four weeks.

So it's only an issue presumably if you don't use fb2k as your tagging software. Is that correct?

C.

Re: Playback Statistics component: v3.x foo_playcount

Reply #133 – 2010-09-28 05:04:43

I can't think of a better app than f2k to edit your tags...

Re: Playback Statistics component: v3.x foo_playcount

Reply #134 – 2010-09-28 12:14:12

Quote from: gob on 2010-09-28 05:04:43

I can't think of a better app than f2k to edit your tags...

MP3Tag?

Re: Playback Statistics component: v3.x foo_playcount

Reply #135 – 2010-10-02 17:16:33

Peter, would it be possible to include a context menu option (probably tucked away in a sub menu, for safety purposes) to decrease the playcount by 1.

The reason I ask is that if you go to sleep with music playing, you may hear the first few songs, but miss a whole stack. It would be nice to be able to go to the History playlist and simply riight click and reduce the playcount by 1.

Furthermore, it seems that the Import stats from Tags doesn't allow for importing data which has a lower value than what currently exists. So the "via tags method" doesn't work in this regard.

IMO the %last_played% date wouldn't have to change, since it was actually last played on that date, it's just that you didn't hear it.

Thanks for considering the above.

C.

EDIT: ps. If I want to completely wipe my playback stats and reload my library, what now is the best way to do that, do I simply delete the database.dat file?

Re: Playback Statistics component: v3.x foo_playcount

Reply #136 – 2010-10-02 21:07:49

Quote from: carpman on 2010-10-02 17:16:33

Peter, would it be possible to include a context menu option (probably tucked away in a sub menu, for safety purposes) to decrease the playcount by 1.

~~Might as well make it all fully editable in fields, just like manual ReplayGain editing, instead of inventing another debatable and ultimately limiting interface for this.~~ I should check before I speak. These exact context menu options already exist.

I'm still on the wall about whether I'd like the identification tags to be editable or not.

I've put off upgrading to the new component all this time because this thread is 6 pages in and discussion hasn't died down yet. Truth is, there exists no property of a music file that identifies it intrinsically, so at some point you're going to have to pick something an agree to let that be the identification. Is this thread a futile one?

Re: Playback Statistics component: v3.x foo_playcount

Reply #137 – 2010-10-02 21:42:20

Quote from: dhromed on 2010-10-02 21:07:49

These exact context menu options already exist.

Do they? Where? I can find no context menu option to reduce the playcount by 1.

C.

Re: Playback Statistics component: v3.x foo_playcount

Reply #138 – 2010-10-02 22:18:00

It is the "-" sign!
If you still can't find it that would be strange as you can't hide it in context menu preferences
You can just decrease rating! That's what dhromed probably meant, too.

Re: Playback Statistics component: v3.x foo_playcount

Reply #139 – 2010-10-02 22:30:21

Quote from: q-stankovic on 2010-10-02 22:18:00

You can just decrease rating! That's what dhromed probably meant, too.

Yeah, I'm talking about playcount.

C.

Re: Playback Statistics component: v3.x foo_playcount

Reply #140 – 2010-10-03 12:54:50

Ah, silly me. I confused rating with playcount. Brain fart. In addition to checking before I speak, I should understand what I'm looking at before I speak. :3

So yeah. a free text input field for playcount would be quite useful.

Re: Playback Statistics component: v3.x foo_playcount

Reply #141 – 2010-10-03 16:19:09

Quote from: dhromed on 2010-10-03 12:54:50

Ah, silly me. I confused rating with playcount. Brain fart. In addition to checking before I speak, I should understand what I'm looking at before I speak. :3

So yeah. a free text input field for playcount would be quite useful.

You mean like the <PLAY_COUNT> field?

Re: Playback Statistics component: v3.x foo_playcount

Reply #142 – 2010-10-03 16:31:14

Quote from: KarnEvil9 on 2010-10-03 16:19:09

Quote from: dhromed on 2010-10-03 12:54:50
... So yeah. a free text input field for playcount would be quite useful.

You mean like the <PLAY_COUNT> field?

I didn't think this was unclear:

Quote

Peter, would it be possible to include a context menu option (probably tucked away in a sub menu, for safety purposes) to decrease the playcount by 1. [...]

Perhaps I should have added that this would be recorded where foo_playcount records its stats (i.e. <PLAY_COUNT> field in the database) but that seemed self-evident.

C.

Re: Playback Statistics component: v3.x foo_playcount

Reply #143 – 2010-10-03 16:33:35

Context Menu->Import Statistics from File Tags

Re: Playback Statistics component: v3.x foo_playcount

Reply #144 – 2010-10-03 16:37:21

Quote

Context Menu->Import Statistics from File Tags

It can only increase playcount, not decrease it.

Re: Playback Statistics component: v3.x foo_playcount

Reply #145 – 2010-10-03 16:38:52

Precisely, and also I'd have to initially write stats to file tags, reduce them by one, and then as lvqcl and I have pointed out:

Quote from: carpman on 2010-10-02 17:16:33

Furthermore, it seems that the Import stats from Tags doesn't allow for importing data which has a lower value than what currently exists. So the "via tags method" doesn't work in this regard.

Re: Playback Statistics component: v3.x foo_playcount

Reply #146 – 2010-10-05 22:58:34

If I remove a directory from the music folders list in the media library, what happens to the stats of the tracks that have now been removed? Are they deleted from PlaybackStatistics.dat? I ask, in the event of something being removed from the media library list (even by accident), do I have to worry about losing my stats?

Re: Playback Statistics component: v3.x foo_playcount

Reply #147 – 2010-10-05 23:11:21

Within this thread is a more precise answer. From memory, I believe they stay in the .dat file for approximately 2 weeks.

terry

Re: Playback Statistics component: v3.x foo_playcount

Reply #148 – 2010-10-05 23:13:40

Quote from: carpman on 2010-10-03 16:31:14

I didn't think this was unclear:

Quote
Peter, would it be possible to include a context menu option (probably tucked away in a sub menu, for safety purposes) to decrease the playcount by 1. [...]

Perhaps I should have added that this would be recorded where foo_playcount records its stats (i.e. <PLAY_COUNT> field in the database) but that seemed self-evident.

Yes, you were clear. However, I wasn't responding to you, but rather to dhromed, who said it would be nice to have an editable field for playcount.

For your purposes, if the range of tracks you're wishing to reduce by 1 all have the same play_count, then you can simply highlight them all, and then manually reduce the number by 1 in Properties for all tracks at once. If they all have different counts, then, of course, you'll have to do each track individually. You probably already know that, but just in case...

Re: Playback Statistics component: v3.x foo_playcount

Reply #149 – 2010-10-05 23:40:28

Quote from: KarnEvil9 on 2010-10-03 16:19:09

Quote from: dhromed on 2010-10-03 12:54:50
Ah, silly me. I confused rating with playcount. Brain fart. In addition to checking before I speak, I should understand what I'm looking at before I speak. :3

So yeah. a free text input field for playcount would be quite useful.

You mean like the <PLAY_COUNT> field?

EDIT: No I got you were responding to dhromed. It just seemed confusing to merge "a free text input field for playcount" with the ability to reduce playcount by 1 - just wanted to clear things up.

Quote from: KarnEvil9 on 2010-10-05 23:13:40

For your purposes, if the range of tracks you're wishing to reduce by 1 all have the same play_count, then you can simply highlight them all, and then manually reduce the number by 1 in Properties for all tracks at once. If they all have different counts, then, of course, you'll have to do each track individually. You probably already know that, but just in case...

Apart from the idea of amending each track's playcount individually , this also assumes the info is already written to the file's tags. Additionally, even if you did that you still couldn't re-import them, as has already been pointed out:

Quote from: lvqcl on 2010-10-03 16:37:21

Quote
Context Menu->Import Statistics from File Tags

It can only increase playcount, not decrease it.

Quote from: carpman on 2010-10-03 16:38:52

Precisely, and also I'd have to initially write stats to file tags, reduce them by one, and then as lvqcl and I have pointed out:
Quote from: carpman on 2010-10-02 17:16:33
Furthermore, it seems that the Import stats from Tags doesn't allow for importing data which has a lower value than what currently exists. So the "via tags method" doesn't work in this regard.

Thus, there's no way to reduce playcount in the foo_playcount database. Thus my request.

C.

Notice