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: foo_skipcount (discussion) (Read 3069 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re: foo_skipcount (discussion)

Reply #25 –
Quote from: regor on
About oldest vs latest in single skipped tracks. Current situation (for a track skipped before updating):

Note the tags are fine now, the properties\detail panel is not. Reloading info does nothing.

With a new track, skipped after update, the situation is the same.

Can you test this release to see if the change I made fixes this problem? If that does not fix it, I have another idea that should address it but isn't exactly what I would prefer to write it as.

Quote from: regor on
%SKIP_TIMES_JS% output is not always a valid JSON value. Sometimes outputs an array [] and other times values like "1710492645000" . The properties panel displays the right values, but tags get through other components or SMP are wrong.

Test this release to see if it properly displays the JS field now. (this one includes 2.0.3-beta changes, but I wanted to separate them)

Re: foo_skipcount (discussion)

Reply #26 –
Quote
Can you test this release to see if the change I made fixes this problem? If that does not fix it, I have another idea that should address it but isn't exactly what I would prefer to write it as.

Tracks skipped before and after update still have with the bug.
Spoiler (click to show/hide)

Quote
to see if it properly displays the JS field now. (this one includes 2.0.3-beta changes, but I wanted to separate them)
Spoiler (click to show/hide)
With b4, %SKIP_TIMES_JS% is ok now as TF. Note %SKIP_TIMES_RAW% and %SKIP_TIMES% still require the same fix.

Also note the image now shows a track with 2 skips and the oldest skip is also not shown at the properties panel, although the tag is retrieved fine as TF. That seems to be a regression, since previously only tracks with a single skip had the 'oldest skip' bug.

Re: foo_skipcount (discussion)

Reply #28 –
Alright, try this release and let me know.

I deleted my database file and then installed 1.9.1, 2.0, and 2.0.1, skipped a track once and then loaded this version and I did not see the oldest track skip missing, let me know if it does for you still, I will be very confused if it is, but shall see.

Re: foo_skipcount (discussion)

Reply #29 –
All time tags are now valid JSON on TF.

The properties panel still missing oldest skip. Tried on new tracks after update (I'm using foobar 1.6 btw).
Spoiler (click to show/hide)

And now there is another bug, all times tags are overwritten with every new skip and only output a single timestamp now. Compare the previous image with new one and you will see the old timestamp is gone.
Spoiler (click to show/hide)

Re: foo_skipcount (discussion)

Reply #30 –
Okay, this is on me, I should have tested more thoroughly and asked more questions. I am fairly sure I figured out the original problem and reverted the regression area. Test this new beta release and please verify for me that the JSON, oldest skip, and overwriting timestamp display are all fixed. I debugged on my 1.6, but I want to confirm its all good

Re: foo_skipcount (discussion)

Reply #31 –
All problems now fixed on my side too, although there is one thing I just noticed when there are no skips on a track.

%OLDEST_SKIP% and %LATEST_SKIP% output "Never" instead of being empty and returning "?" when using without brackets. While I understand why you added that fallback value, it is not consistent with the way any other tag works.

For ex. using "%OLDEST_SKIP% PRESENT" as query, will return the entire library (which is not intended for tracks never skipped).
And "%OLDEST_SKIP% MISSING" outputs nothing. Etc.

I would say both should be empty (i.e. "?") if there are no skips.

Finally, something similar happens with %SKIP_COUNT%, which returns zero if there are no skips. But it is consistent with any of the playcount plugins, which also return zero.

Re: foo_skipcount (discussion)

Reply #33 –
You should not write a literal ? with metadb_display_field_provider. You should be returning false from process_field when there is no data like this...

https://github.com/jscript-panel/FB2K/blob/5dea4df06b2154f258a3b88841b8454311e9979e/PlaybackStatistics/MetadbDisplayFieldProvider.cpp#L34-L57

edit: I'm basing what I do on foo_sample from the SDK...

https://github.com/reupen/foobar2000-sdk-unmodified/blob/092ae1bf9a99b884bb55fd5344d80bc5e175b3f4/foobar2000/foo_sample/rating.cpp#L237-L252
 

Re: foo_skipcount (discussion)

Reply #34 –
Yep, I had figured I was doing something incorrectly and I was going to check how to properly. Thanks for pointing that out. 2.0.5 will be released shortly