Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[gappie]

im having  a problem getting my head around this one. I understand that it is triggered after every file just played, not after a whole list is just stopped. But for what can we use it.
lets say i want to add the last played to my own list field [dates last played] to get a list when it was played. could that be possible (i dont have such a list, not sure if i want it, just an example).

or are there any other examples how to use this field.

i am intrigued

 
gab

[marko]

gappie, so good to see you. Hope you're keeping well.

That's exactly what I'm doing with it...

First, I created a new list-type field called Play History.
The rule in place at 'Library and Folders' is:
setfield(Play History,[play history];now())
EDIT: The above has been ditched in favour of the string below.
EDIT 2: The above has been ditched in favour of the string below.

Code: [Select]

setfield(Play History,formatdate([last played,0],yyyy//MM//dd HH:mm:ss);[play history])
I chose to use raw date data thinking that from there, it can be formatted any way I fancy.
Am no longer using raw data as the conversion overheads are just too high.

When things are played on JRemote, the field updates accordingly.
Any MC clients will need that rule applied in the client MC options. It then updates the field, which is subsequently sync'd back to the server instance.
The data is building up nicely.

Still a work in progress, but I'm currently working on a search list that will give us, for the first time ever, after years of waiting...
the means to get lists such as "the most played files of 2020" or any other year, or an auto-updating, rolling, "most played files in the last six months"

Much like yourself, I haven't come up with anything else useful to do with it, but this one... greatest hits of... playlists, has real potential.

At the moment, the only irritation I have bumped into is that each list will need a field created for it in order to sort it into a chart. Other than that, it's shaping up nicely.

-marko

[gappie]

Thanks Marko,

im doing fine. hope you do too.
that is interesting. i was not even sure it would work on the file just played, or something totally different. Wondering when it triggers, i mean just like number plays. or even after just a second. i will test that, ofcourse.

and when i have other ideas to do with it, i will post it here. Some contributions would be appreciated.

nice addition.

 
gab

[gappie]

Hey Marko, i started using making and using the history field you explained above. and started with copying all last played data to it. this will be fun

so history started today.

 
gab

[gappie]

At the moment, the only irritation I have bumped into is that each list will need a field created for it in order to sort it into a chart. Other than that, it's shaping up nicely.

And you use the new listfilter for that too, no? like in

Code: [Select]

listcount(listfilter([playhistory],0,math(now()-365),now()))
for how often a file is played the last 365 days.
this is fun.

 
gab

[marko]

Exactly that. Good eh?

[DangerJP]

Hi Marko,

Thanks for the tip on the setfield function!

I've wanted a playback history for so long, and now it's possible 

Quick question: Can MC converts dates in a list field, such as [Play History], to readable dates?
For now, I use FormatDate([Play History], ...), but it only converts the first date in the list (see image).

Thanks!

[marko]

Hi Marko,

Thanks for the tip on the setfield function!

You're most welcome

I've wanted a playback history for so long, and now it's possible 

Many of us have. Exciting times.
Initially, this does have potential, though I do have concerns regarding some things that will hopefully not become a problem in the future.
Concerns are, once we have built up enough data to work with, turning that data into useful and interesting 'Greatest Hits' kind of lists may become overly cumbersome.
The field will keep on growing, and growing, and growing... My experimentation so far goes along these lines:
To get data out of it, I have created a search list pane containing a separate search for each year from 2003 to 2022.
To sort that data so that the most played is listed first for each year, I have created separate custom fields to count the history... yup, a field for every year 
This system has an MC benchmark score between 5 and 6000, and with around 40k play history entries so far, it's getting noticeably laggy... I will keep plugging away as, at the moment at least, I'm confident we can work out ways to keep it quick.
Not looked at it yet, but also praying these port across to theater view nicely...

Quick question: Can MC converts dates in a list field, such as [Play History], to readable dates?
For now, I use FormatDate([Play History], ...), but it only converts the first date in the list (see image).

The quick answer is "Yes". Some more thoughts first...
I elected to save the raw date data thinking that from there, I could do pretty much as I pleased with it, without too much hassle. You could, of course, save formatted data directly into the history field, like so:

Code: [Select]

setfield(Play History,[play history];formatdate(now(),datetime))
As gappie mentioned before, we have a new ListFilter() function (thanks zybex/Matt) that really helps with extracting the data, along with the already existing ListMix() function, which is the answer to your question, if you are like me and prefer to keep saving unformatted data. Here's where I'm at so far...

At this time, there is a little problem with the listmix() function and forward slashes that is getting ironed out, so until then, they're best avoided.

How about an expression based pane using this expression:

Code: [Select]

listmix(formatdate([L1],yyyy\MM\dd HH:mm:ss),0,[Play History])&datatype=[list]It creates a calendar tree out of all the unfiltered, unformatted data.

Using this as an expression based list column will show you the number of times each file was played in 2021:

Code: [Select]

listcount(listfilter([Play History],0,convertdate(2021),convertdate(2022)))
This search:

Code: [Select]

[=listcount(listfilter([Play History],0,math(now()-180),now()))]=>=1will always return files played in the past six months. This is made a lot simpler by having the raw history data.

This search:

Code: [Select]

[=listcount(listfilter([Play History],0,convertdate(2021),convertdate(2022)))]=>=1 ~sort=[Chart 2021]-dwill return all files played in 2021, and sort them in descending order on the "Chart 2021" library field, which is an expression based field, created using:

Code: [Select]

listcount(listfilter([Play History],0,convertdate(2021),convertdate(2022)))
So, you can probably see that there is much potential in both directions...
The positive: It's great to finally have the data, and potentially exciting to see what ideas we can collectively come up with to make good use of it.
The negative: As the years roll by, could this slowly bring our MCs to a grinding halt? Extracting, and then dealing with the data is cumbersome.

Will update here with any progress I make on this project....

-marko

[zybex]

This works:

Code: [Select]

Listmix(FormatDate([L1],dd-MM-yyyy HH:mm,),0,[Play History])
Be aware that the ListMix() function has some issues... if you want dates with slashes you need this:

Code: [Select]

Listmix(FormatDate([L1],dd////MM////yyyy HH:mm,),0,[Play History])

[markf2748]

Here is a snippet that I use in a view expression column to summarize marko's [Play History] data for # of plays and endpoint dates (database "bookends") for listed tracks:

Code: [Select]

=IfCase(listcount([Play History]),6,
   2, listcount([Play History])x  FormatDate(listitem([Play History], 0), %x) if(math(equal( math(int(listitem([Play History],0))), math(int(listitem([Play History],-1)))) ), , - FormatDate(listitem([Play History],-1), %x)),
   1, FormatDate(listitem([Play History], 0), %x),
   0, never played)
Code assumes [Play History] is ordered in time, oldest first (index 0) to most recent last (index -1).  If order is ever broken, then you might have to use min/max, which is likely much slower, or re-order with listsort().

Displays like this (4x means played 4 times within the date range, no "x" means played once on date shown):

[DangerJP]

Just came back from summer vacation and saw your replies.

Wow, thanks Marko and everyone for your tips!

I feel like there is so much more potential for this feature

[marko]

You're welcome. This thread, for obvious reasons, could be a bit of a slow-burner whilst our history data accumulates. It would be neat if you shared any potential you are able to unlock

I have edited my post above, as I am now using this rule:

Code: [Select]

setfield(Play History,[play history];[Last Played,0])
Why? Well, I can be a bit OCD about things that make my library tick being as I expect them to be, so I set about a little bit of integrity checking....

I wanted to ensure that the history was building correctly, so built a query to show me any files where [last played,0] (the raw data) was less than any of the items in the history list. There shouldn't be any as the last played value should be in the history list, and should be the highest value, but not quite so....

I discovered that there is quite often a difference between the two, presumably because of the miniscule time difference between [Last Played] being set, and "Now()" being interpreted for the setfield rule. For example...

44429.6099999999933061
44429.6100000553633436

Both of those above return 21st August 2021 14:38:24

Using [Last Played,0] instead of now() seems to have that sorted out.

Thinking more about History lists, and the donkey work required to build them, I figured that once a desired period is in the past, the data for that period will never change, so maybe adding them as playlists would speed things up. The resulting playlist group can then be used to key views from.

-marko

[zybex]

For completeness, you can get the most recent date with:

Code: [Select]

ListItem([Play History], -1)Or the last 5 plays with:

Code: [Select]

ListLimit([Play History], -5)
The equivalent in readable dates is (using the new ListMix mode 8 - mode 0 also works with more slashes):

Code: [Select]

FormatDate(ListItem([Play History], -1),dd//MM//yyyy HH:mm)
Listmix(FormatDate([L1],dd//MM//yyyy HH:mm),8,ListLimit([Play History], -5))
Alternatively, you can define the [Play History] to keep the most recent date on top of the list instead of appending:

Code: [Select]

setfield(Play History,[Last Played,0];[play history])
The 4 expressions above would then change to:

Code: [Select]

ListItem([Play History], 0)
ListLimit([Play History], 5)
FormatDate(ListItem([Play History], 0),dd//MM//yyyy HH:mm)
Listmix(FormatDate([L1],dd//MM//yyyy HH:mm),8,ListLimit([Play History], 5))
You can also decide to keep just the last 100 plays or so, to avoid the field getting too unwieldy:

Code: [Select]

setfield(Play History,[Last Played,0];listLimit([play history],99))

[marko]

I used

Code: [Select]

listmath([play history],1) to get the most recent entry.

zybex, while I was working on the filters to ease my OCD 'need to know' that everything was behaving as expected, I offerred up a silent 'thank you' to you (and wer) for all the thought and effort that has given us some great ways to work with list type fields. That the same went out to Matt for making your visions a reality is of course, a given.

ListMix() is a lot more versatile than it first appears. I built an expression that tests each list item entry against last played, returning a list of one's and zero's. Any that contain a "1", don't match. All very good indeed. Thanks again.

-marko

[zybex]

Kudos all around, many contributed with suggestions

ListMath() will have to scan the entire list to find the max value, whereas if we assume the list is already sorted, we just need to pick the first or last item.

[marko]

Latest update:

With over 111,000 Play History entries across all media types, it's all too easy to bring MC to its knees for several minutes.

Initial findings are that, selecting a range of several thousand files with the tag window open will be quite painful. This is temporarily solved by removing the "Fields With Values" and "All Fields" groups

Hoping I can find a way to keep this up, and have those two groups present in the tag window. Will update again once I've had some time for a proper play around with this...

[marko]

Quick progress update:

Moving to playlists has definitely helped a lot, but not completely.

Sooo, once a year is done, its associated data becomes static and will never change.
For each year, create a library field (I just named mine after the year) and populate this with the listcounts from the play history field for that year.
Produce the list for that year ordered from most played that year to least,  and add those files to a playlist in that order.

Do this at the end of each year.
Two searches remain that are zero maintenance and will always be true, but as such, do require reading all of the play history values. They are:
Played in the last 180 day period
The current year to date

so far, things are still pretty snappy. The annual playlists can have several thousands of files, with very many 'single play' entries at the tail end.

Next, build a view scheme. I figured this would live in the "All Media" section of my tree, and the beginnings of it look like so:


Initially, the view is set to sort by [last played] (z-a). The listed files really make no sense until you start selecting stuff in the panes. "Play Charts" and "Top...." are search lists with their own sorting and sequencing specified, and their sort rules override the default sort set out in the customise view options.

At the moment, I can flit around from pane to pane and it all pretty much updates the list instantly and correctly. Hopefully that continues to be the case as more searches are added.


The tag window lag mentioned earlier is still an issue despite removing virtually all of the 'on demand' fields, and hiding others. I will try to hunt that down afterwards as I'd like to get the view working first.
EDIT
Tag Window lag is sorted. 'twas being caused by an old, unrelated regex experiment. Regex and me should be kept well apart

[marko]

Build 28.0.73 introduced an "Allow custom data to override the expression" option to expression based library fields.

I've been experimenting with that, and initially things are good. From a file list, we can simply replace the expression result with the actual expression result using a simple =[this] in an inline edit. All looks promising, but at this time, there is a problem with search results and pane population for fields with that option checked. If those can be fixed, this will negate the need to create playlists as, with a single run of a simple expression at the end of each year, the fields will become static data.

I will continue posting musings, ramblings and links here to keep everything handy. When it all settles down, we should have something pretty neat to play around with.

[gappie]

Build 28.0.73 introduced an "Allow custom data to override the expression" option to expression based library fields.

I've been experimenting with that, and initially things are good. From a file list, we can simply replace the expression result with the actual expression result using a simple =[this] in an inline edit. All looks promising, but at this time, there is a problem with search results and pane population for fields with that option checked. If those can be fixed, this will negate the need to create playlists as, with a single run of a simple expression at the end of each year, the fields will become static data.

I will continue posting musings, ramblings and links here to keep everything handy. When it all settles down, we should have something pretty neat to play around with.

now that is interesting. i sometimes see mc grind for a minute or 2 on a few calculations on the play historie. but my machine is really not so new anymore. anyway keep the playhistory and keeping it simple still make me happy. so a bump and a thanks to all the ideas.

makes mc fun.

 
gab

[marko]

Latest update from my end...

I've switched to storing the history in formatted entries rather than raw values. Why?

My [Play History] field has getting on for 150,000 entries across 22,000 files that currently have data. Asking MC to do anything that involves parsing all 150,000 entries hangs the program (...not responding, wait or close?). What to do about that?

Make the fields for each year, replace the expression result with the actual expression result and that's the counts all done and locked in ready for showing chart type lists. This has been working well, really well, with a very responsive view that allows filtering by media type, media sub-type, year played, and finally, top 10, 20, 40 or 100 files.

I recently found myself not only wanting the number of plays, but when played too. By using the raw data in the history field, the only way I could get that info was to run through all 150,000 (and ever increasing) entries, converting them to readable dates. This did not go well, at all!!

Hence the reason why, for now, my latest direction change is to store the history formatted, and in descending order. Descending order is better as, when used in the tag window, you get to see the six most recent entries in the list, with the rest available via tooltip.

[marko]

Expressions

Along with the switch to formatted values in the [Play History] field, the expressions to extract the data also change:

As mentioned above, to see when each file was actually played, simply add the [Play History] field to the tag window. My tag window "Playback" section has:
Number Plays
Last Played
History - defined by: listcount([play history]) Entries
Play History


Filtering and counting the data for each year is now achieved via simpler ListGrep() expressions:

Code: [Select]

listcount(listgrep([Play History],2020))
Setup one for each year. Remember, you can set these to be hidden fields so that they don't end up cluttering the list in the library fields manager. Add the column to a view before hiding them though as hidden fields do not show in the column picker list. Also, for a bit of a performance gain, tick the "Allow overwrite" option for each year field.

The two 'rolling' data fields, [Current Year] and [last six months] also changed, one got more complex...

Current Year is now:

Code: [Select]

listcount(listgrep([play history],formatdate(now(),yyyy)))
The following "Last Six Months" expression may well have room for optimisation, I don't know, but does work in this current iteration:

Code: [Select]

listcount(listfilter(listmix(convertdate([L1]),8,replace([play history],//,////)),0,math(now()-180),now()))

[marko]

The following "Last Six Months" expression may well have room for optimisation, I don't know, but does work in this current iteration:

Code: [Select]

listcount(listfilter(listmix(convertdate([L1]),8,replace([play history],//,////)),0,math(now()-180),now()))

The overhead on this one is just too high, and try as I might, I cannot reduce the passes over the [Play History] field in order to get the range. I did achieve a marginal improvement by ditching the "Replace()" expression, and instead of a converdate, did a Left() of eight characters and a formatdate of now() to match on those eight numbers, but it was still taking in order of seven or eight seconds to return the list.

I may revisit this at a later date, but, having spent way too much time on it with no reward, I've removed "Past 6 Months" entirely as for me, a formatted history field is more desirable than than this particular list. Shame, but, heyho.

-marko

[mark_h]

Keep the updates coming 

[GaryG45]

I agree with mark_h.  I'm a noob when it comes to customizing MC and using expressions, but this topic has my interest.

[lepa]

Variable solution for last 6 months (audio only) seems to be quite snappy for me. It is using raw values though. Was trying to create year calculations on same go so MC doesn't need go through history list many times per file but run in to problems with possibly ListMix bug or short coming

Code: [Select]

[=Save(Math(FormatNumber(Now()) + 1), v_MAX)1]=1
[=Save(Math(FormatNumber(Now()) - 180), v_MIN)1]=1
[=Save(ListCount(ListFilter([Play History],0 ,[v_MIN], [v_MAX])), v_Last6Months[filekey])1]=1

[marko]

Thanks for looking lepa. When I was using raw values it was also very quick for me too, I think, because we are just dealing with number ranges.

Shifting to formatted data has been troublesome for the past six months data extraction.

I've been thinking as far outside the box as I can for a solution, but nothing is working for me, at least, nothing that's fast anyway. Closest I got was to just let the expression engine eat the non-escaped forward slashes and match on the big number instead, but that was still way too slow.

[zybex]

Maybe this post makes more sense in this discussion:
https://yabb.jriver.com/interact/index.php/topic,124543.msg910229.html#msg910229

I makes me wonder if things like this wouldn't be best done on a timer; ie, everyday at 4am a script would run, compiling all stats and storing the counts and tops in some field that would then be used in Views. Is it that important to have an up-to-the-minute number of plays for each track since forever? And things like the playcount for past years won't ever change anyway. Updating once a day seems fine for this usecase.

[lepa]

@marko You could of course create yourself maintenance hell and update two fields after play
[Play History] and [Play History (raw)] 

That would prevent some conversions when calculating and you'd still see human readable Play History

[marko]

Have a date with my wife tonight, so no computing! I'm thinking that right now, not having a rolling six months is not going to make me suicidal, especially as what's left, including the always calculated year to date field is as fast as instantaneous thanks to the switch to listgrep, and replacing the calculated data for past years with the calculated data, it's pretty cool as it is.

I think running scripts to make it work would be a step too far in the complexity stakes that many might find a bit of a turn off.

The two fields idea hadn't occurred to me before. Would that really be hell? Might look at that next weekend....

A eureka moment may come along soon, but I'm happy to just let that bubble up when it's ready to.

[lepa]

The two fields idea hadn't occurred to me before. Would that really be hell? Might look at that next weekend....

Normally keeping sync with multiple data sources is asking for trouble if you can do it with one but i guess this isn't industry critical  so it isn't IMO an issue

[mark_h]

Normally keeping sync with multiple data sources is asking for trouble if you can do it with one but i guess this isn't industry critical  so it isn't IMO an issue

Haha - I know you are kidding here as you will recognise just how critical our collection data is to us 

[mark_h]

Here's my main use of the play history at the moment: Artist Popularity



This chart shows my most played artists for the past 365 days, compared to the preceding 365 days, and then various stats columns to go along with them, most of which are making use of JRiver's variable system to do the calculations.  This is essentially a proxy for Last.fm's yearly stats report now direct within JRiver thanks to the play history data. 

I did import my scrobble history from LastFM but only about 30% was a direct match for my current music collection (albums come and go, names change etc as I continue to curate the collection), but moving forward it will be increasingly up to date.

I have similar pages for 90 day popularity and also album popularity.

Every iteration of JRiver seems to add at least one killer feature for me, and the play history stuff is MC28s.

[lepa]

Some cool stats there 

[zybex]

I've published ZStats 1.0, a mini-tool to compile statistics from the [Play History] field and write them back to a field to be used in views/expressions/smartlists. It can also create a bunch of user-defined Top N playlists with the most played tracks for any given time range (daily/weekly/monthly/custom)

Please read the description and instructions in GitHub:
https://github.com/zybexXL/MCStats#zstats

This tool has no GUI - it's intended to be scheduled to run nightly to update all statistics in the library.
Release thread: https://yabb.jriver.com/interact/index.php/topic,131845.0.html

Enjoy the freebie 

[marko]

Feck me... zybex... Thank you, so much. Will try and make time for a play, but it might get kicked to the weekend after next.

I took a punt on a couple of 10Tb HDD from Western Digital's 'end of line' sale. That's great, and all, but what's not so great, is shunting terrabytes of data around to clear the smaller drives these will replace.

Can't wait to play with this though, will let you know once I'm on board.

-marko

[zybex]

Thanks Marko, no rush. The tool was actually written already back in November, and I've been waiting for Lepa to return to do some beta testing before publishing. Apparently I should have asked you instead

I've been waiting for HDD prices to go down to normal prices again to upgrade my NAS as well... I think I'll wait for the next Black Friday, hopefully things will be better by then.

[lepa]

Adding below to after play expression example will update five first items in the [Play Stats] which on default are [total];[year];[month];[week];[today]. Playlists are not updated but song related data can be real time then. Running ZStats later will re-calculate all the items (and playlist) of course and get you up to date.

Code: [Select]

SetField(Play Stats,ListMix(If([L2],Math([L1]+[L2]),[L1]),0,[Play Stats], 1;1;1;1;1))

[zybex]

Nice.
Since recalculating the Playlists with ZStats only takes a few seconds (the slow part is updating the [Play Stats]), you could run ZStats more often (hourly?) to just update the playlists, and run it nightly for the the full processing.

ZStats can take the config.ini filename as an argument:

Code: [Select]

Usage: ZStats [zstats.ini]
If no config file is given and no 'zstats.ini' exists in the current folder, a new sample one is created.
So all you have to do is:
- create zstats_playlists.ini with UpdatePlaylists=1 and UpdateStats=0
- create zstats.ini with UpdatePlaylists=1 and UpdateStats=1
- schedule "zstats.exe zstats_playlists.ini" to run hourly
- schedule "zstats.exe" to run nightly

Another way to do the same is to have 2 copies of ZStats in different folders with it's own zstats.ini config.
You can also have shortcut that you can just click to update the playlists on the spot, by having the shortcut execute "zstats.exe zstats_playlists.ini".