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 202868 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Playback Statistics component: version 3.0.1

Reply #100
Aha, now I understand. Well because the playback statistics are pinned to metadata (tag) rather than file paths now, I would expect that changing the relevant tags externally makes the modified items seen as new/different.
Full-quoting makes you scroll past the same junk over and over.

Playback Statistics component: version 3.0.1

Reply #101
changing the relevant tags externally makes the modified items seen as new/different.


This will turn my library upside down! I'm used to modifying tags whenever an error occurs to me; on the other hand, I like to sort my ML by the ADDED date to have my newest acquisitions on top. The new behavior of foo_playcount turns out to be quite a mess then (e.g. with double albums, having made a minor change only on one of the two albums). Any solution in sight? Could I store the playpack statistics settings on the NAS so I can share them with my computers? If not, which files do I have to transfer between the two local computers to have identical playback statistics on both computers (I don't care which song was played how often on whatever computer ...)

Thanks a lot for the help!

Playback Statistics component: version 3.0.1

Reply #102
If not, which files do I have to transfer between the two local computers to have identical playback statistics on both computers (I don't care which song was played how often on whatever computer ...)

You can import statistic from and export statistics too xml files using the context menu.
elevatorladylevitateme

Playback Statistics component: version 3.0.1

Reply #103
Bug report: I have two albums with the same artist and title but different track listings. However, statistics component does not differentiate the two.
I've duplicated this bug.
You do not have the same bug.
Moreover, this bug is now fixed. Thanks, Peter!

Playback Statistics component: version 3.0.1

Reply #104
Tracks with same %album artist% and %title%, different %artist% get the same statistic.
Why is this component go final while still so many known inconsistence, mixed up bug exist.

Playback Statistics component: version 3.0.1

Reply #105
A minor idea, what about an increase/decrease context button for the play count of the selected songs, like the rating ones.
Also it has been going round in my head for a while... it would be nice to be able to adjust how much playback time of a song is required to increase it´s play count.

Playback Statistics component: version 3.0.1

Reply #106
Why is this component go final while still so many known inconsistence, mixed up bug exist.


This is part of the reason why all I wanted was Playback Statistics 2.0 with relative paths fixed - something completely new can't possibly be perfect.

Even if 3.0 has no bugs / problem logic, I change tags more than filenames and would try to avoid using the component anyway...

Playback Statistics component: version 3.0.1

Reply #107
Why is this component go final while still so many known inconsistence, mixed up bug exist.


This is part of the reason why all I wanted was Playback Statistics 2.0 with relative paths fixed - something completely new can't possibly be perfect.

Even if 3.0 has no bugs / problem logic, I change tags more than filenames and would try to avoid using the component anyway...


I usually only set the tags once. There are many times where I'll have a lossy copy of something, and I'll replace it with a cd I've ripped to flac, so my file paths DO get changed, and not the way thats friendly to the old playback stats. I don't really use anything other than foobar2000 to touch my files so, tag editing is no issue and neither was moving/renaming within foobar2000 before. This functionality seems like a nice bonus for me, I'll let you know how it works out.

Playback Statistics component: version 3.0.1

Reply #108
Upgraded to 3.0, everything seemed in order, i didn't see too much hard drive activity for the stats conversion to take place, do I have to initiate that somehow? Also, there were files that lost their stats after upgrading the component; all the Alice and Chains albums. It's almost like this component has a grudge against these files because this has happened before with them in previous versions of the component. As far as I can tell, these are the only ones affected, kinda hard to compare. Luckily enough I made a backup of my previous version of foobar, so swapped back in, wrote the playback stats to the alice in chains files, upgraded the component again, then imported the tags from the files and removed them. I've learned my lesson in the past and set my backup app to make several weekly versions of the stats file so I can "go back in time" and get stats that have mysteriously disappeared. I'm hoping v3 will work out better.. so far its iffy.

edit: I tested this out with an album I copied, transcoded outside foobar and changed some tags. Imported the new files and they appear to have kept the stats where the tags were not changed. On the files where tags were changed, the stats came back after I copied back the original tags. Looks pretty good so far.

edit2: Another benefit I haven't really thought of, I can see all these stats when importing from the iphone, this will make refreshing it with music much easier.

Playback Statistics component: version 3.0.1

Reply #109
I am not sure this is the right place to ask, but what API does the new foo_playcount use to access the index-data\{GUID} file? Also, I too would like to know the hash algorithm used to produce the new track identifiers. Finally, while this certainly is somewhat off-topic, foo_jesus does not back up the index-data directory.

Playback Statistics component: version 3.0.1

Reply #110
Not sure, but there is a foobar develpment forum that might be best for most your questions.
A Mod will likely move if appropriate.

Regarding foo_jesus, you define what it backs up. Just add index-data directory to the configuration.

terry

Playback Statistics component: version 3.0.1

Reply #111
Regarding foo_jesus, you define what it backs up. Just add index-data directory to the configuration.
Thanks! (Still, it should probably be listed by default on new installations, but I should be getting back on topic.)

Playback Statistics component: version 3.0.1

Reply #112
sorry if I overlooked something, but is there a way to modify the default string when I access "show recently added"?

e\ actually, nevermind! how do I delete posts here? :/

Playback Statistics component: version 3.0.1

Reply #113
Also, I too would like to know the hash algorithm used to produce the new track identifiers.

Maybe the code is private work compared to publicly available algorithms of such type, and end user is hardly likely to get to it
What else could be the reason for not replying curious quests to playback statistics XML format secrets?

Playback Statistics component: version 3.0.1

Reply #114
i just updated this and it's no longer working like it used to.

i use CD Art Display extensively, and often use its GUI to write to %rating%. since updating, that doesn't work anymore.
the Properties dialog in foobar shows %rating% is set to '3', but the rating is not showing up in CAD or in foobar. what's up?

Playback Statistics component: version 3.0.1

Reply #115
Use $meta(rating) instead. Playback Statistics har its own database, which overrides tags. If you want to use PS' database, look at the context menu and find Rating.

Playback Statistics component: version 3.0.1

Reply #116
ok. but what if i don't want the database to override tags? am i just out of luck?
the new update breaks any external program which writes to %rating%. this is not an improvement.

i guess i'll just roll back to the previous version...

Playback Statistics component: version 3.0.1

Reply #117
the new update breaks any external program which writes to %rating%. this is not an improvement.

How can a foobar2000 component break external programs? 
If an external program doesn't work in the known and expected way after foobar2000 or one of its component updated so it would be the best for you to ask on Cd art display forum their devs to reflect the changes in new buildings. As far as i know the playbach statistics was never supported. Since this is the most popular component for rating tags cd art display would do a good job to give its users the option how the ratings should be setted.

Playback Statistics component: version 3.0.1

Reply #118
while stumbling over my choice of words, you're unfortunately missing the point.

CAD writes to %rating%.
foobar, with the new PBS component, cannot read %rating%. it has decided that the PBS database is more important.

since CAD is a universal app, not a foobar-specific app, it is unreasonable to ask CAD developers to change things so that ratings are written to the PBS database instead of to %rating%.

the problem is with PBS, not CAD. moreover, the solution should be implemented within PBS.

in the meantime, i am using the last good version...

Playback Statistics component: version 3.0.1

Reply #119
CAD writes to %rating%.
foobar, with the new PBS component, cannot read %rating%. it has decided that the PBS database is more important.

You can import ratings from a file's tag via the context menu. The database is simply preferred, since it is no longer tied to specific files.

last good version
The choice phrase of luddites everywhere.
elevatorladylevitateme

Playback Statistics component: version 3.0.1

Reply #120
CAD writes to %rating%.
foobar, with the new PBS component, cannot read %rating%. It has decided that the PBS database is more important.

You are confusing RATING as a field embedded in file itself and %rating% as titleformatting expression to retreive information that doesn't necessarily has to be from a file: "CAD writes to %rating%" doesn't make sense at all.

since CAD is a universal app, not a foobar-specific app, it is unreasonable to ask CAD developers to change things so that ratings are written to the PBS database instead of to %rating%.

It is neither an universal app nor a foobar2000 specific one: Cad is an app that communicates with foobar2000 - for that reason you need an additional dll in foobar2000s components folder. How can it be unreasonable to ask them? It is more unreasonable that foobar2000 development should take care about that. CAD needs a player to work but a player doesn't need CAD.

Edit:

Or maybe eyebex who wrote foo_cdartdisplay has to change his component

Playback Statistics component: version 3.0.1

Reply #121
in the meantime, i am using the last good version...


You might want to consider using the custom playback statistics component which gives you freedom in configuring how things work instead of having to accept a pre-defined way how things work.

Playback Statistics component: version 3.0.1

Reply #122
last good version
The choice phrase of luddites everywhere.


the old version functioned just how i wanted it to. the new version does not. should i refrain from objecting?

q-stankovic: your semantic deconstruction of my posts, while concise, don't really help.

i like ratings written to file tags. the idea of having tens of thousands of song ratings all packed in a single file terrifies me. even redundant backups can fail, and i don't want to lose that data.
so when PBS changes its rules and forces me to prefer its database instead of tags, i get a little grumpy. especially since i use PBS for playback statistics, not for its rating feature. i don't even know why it has a rating feature at all, since song ratings can be handled just fine without it. the rating feature should be entirely optional.

basically, the idea that a third party component prevents users from accessing a particular tag field just doesn't make sense to me. i know that i can chose not to use PBS if i don't like how it works, but i think that i should be able to use it without the component "taking over %rating%".

Playback Statistics component: version 3.0.1

Reply #123
q-stankovic: your semantic deconstruction of my posts, while concise, don't really help.

I have no idea how "semantic deconstruction" could characterize my arguments - they indeed have a content: nemphael already told you to use $meta(rating) to show rating in foobar2000 and CAD needs to retreive by same the way the information. Obviously foo_cdartdisplay sends %rating% to CAD and from now on it should better send $meta(rating).

Maybe this is going to help: When i find time i will register myself on CAD-forum to ask eyebex as he wasn't active on this forum for two years.

EDIT
I'm always surprised that the concept of fb2k moderator should be so different from the rest of the internet; opinionated vs. neutral. Who watches the watchmen?

What is the problem here? 
CAD only worked in the way you miss now because eyebex was nice enough to write a foobar2000 component that let CAD working with foobar2000 by adapting the component to foobar2000 how it was. Now something changed and he should do the same. Do you really think Peter Pawlowski should stop foobar2000 development just because some third party components might become incompatible? It's always the same old story!

Playback Statistics component: version 3.0.1

Reply #124
Seems to me the basic idea behind Peter's choice to move the unique identifier (UID) from filename to tag is a sound one, but at present it's too rigid to please all. There's an easy solution to this (which others have in part requested).

Allow the user to set which fields they want to use to define the UID. That way a user could create a tag called for example, "UID" and format it with for example %filename% - %title% - %whatever%. Then leave that be. Then if they wanted another track / album to share that/those UID(s) that would be up to them (and easy to copy-paste between different versions).

Thus they would be free to change all the rest of their tags and of course the filename and because the stats would be anchored to %UID% there would be no problem.

Thus the fundamental issue to solve such problems is to allow the user to define which %fields% determine the UID for the playback stats (and sure, make the way it is now the default).

Does that make sense?

C.
PC = TAK + LossyWAV  ::  Portable = Opus (130)