INTERACT FORUM
More => Old Versions => JRiver Media Center 25 for Windows => Topic started by: haggis999 on September 24, 2019, 05:09:34 pm
-
I initiated the following thread over 6 years ago to ask if there was a neat way of displaying the total number of discs in a view (and I do mean the disc total, not the album total). The reply from MrC was a bit over my head back then, but I have finally got around to implementing his proposed solution.
It almost does the job, as the view he described shows how many albums contain 1 disc, how many contain 2 discs, how many contain 3 discs, and so on. However, what it fails to do is to actually calculate the total number of discs. Can anyone suggest a way to achieve that goal?
https://yabb.jriver.com/interact/index.php/topic,79763.msg542331.html#msg542331 (https://yabb.jriver.com/interact/index.php/topic,79763.msg542331.html#msg542331)
-
You may be able to do it with a new feature that is coming. See this thread for details https://yabb.jriver.com/interact/index.php/topic,122303.0.html
-
You may be able to do it with a new feature that is coming. See this thread for details https://yabb.jriver.com/interact/index.php/topic,122303.0.html
Many thanks for that suggestion.
The devil is in the detail with such matters, so I can understand your caution in saying that ItemCount() may provide a solution to my problem. We will have to wait and see. Have you any idea when it will become available?
-
ItemCount does exactly one thing: It counts files returned by a search expression. As such, I'm afraid it won't easily solve this problem, unless you get really creative with the expression to somehow only return one file per disc for counting purposes.
-
You could search for track #1. Each individual disc is going to have a first song. Assuming you don't number the first song on disc #2 12 if the disc #1 has 11 tracks.
-
MrC showed you how to use Global Variables to do discs per album. You can also use Globals to total things up. I find the syntax to be very difficult to figure out. I've done it a few times successfully, but I forgot it after not using it for a few months. I don't really want to invest time in it again.
In this thread, MrC explains it in a lot more detail:
https://yabb.jriver.com/interact/index.php?topic=77826.0
You can almost certainly use this to total up your disc count per album into a total discs variable.
Good luck to you.
Brian.
-
I'm wondering about:
ItemCount(AlbumKey() - [Disc #])
I'll test tomorrow and reply here.
-
I suppose it depends what you mean by "in a view". If a view shows 3 albums, and each album consists of 2 discs, do you want to see a 2 next to each album, or do you want to see a 6 somewhere?
If it's the latter, the total number of discs across all albums, you can do that in a panes view by setting one of the panes to this expression: Albumkey()-[Disc #]
This essentially creates a unique ID for each disc, and counts the total number of them. So if you have no other filters active, it will show the total number of discs in the view.
If you meant the former, you can do this with GroupCount(Disc #) and adding that as part of your expression to display. It will show you the total number of discs associated with each album.
The problem with GroupCount is that it only works properly in Theater View. MC has a bug, sp if you put that expression as part of the thumbnail text in standard view, it produces incorrect results.
If Matt will correct that Standard view GroupCount bug, you'll be good to go. (GroupSummary is also affected by a similar bug in Standard View which I mentioned in another post, Matt, if you're listening).
-Will
-
I suppose it depends what you mean by "in a view". If a view shows 3 albums, and each album consists of 2 discs, do you want to see a 2 next to each album, or do you want to see a 6 somewhere?
If it's the latter, the total number of discs across all albums, you can do that in a panes view by setting one of the panes to this expression: Albumkey()-[Disc #]
This essentially creates a unique ID for each disc, and counts the total number of them. So if you have no other filters active, it will show the total number of discs in the view.
If you meant the former, you can do this with GroupCount(Disc #) and adding that as part of your expression to display. It will show you the total number of discs associated with each album.
The problem with GroupCount is that it only works properly in Theater View. MC has a bug, sp if you put that expression as part of the thumbnail text in standard view, it produces incorrect results.
If Matt will correct that Standard view GroupCount bug, you'll be good to go. (GroupSummary is also affected by a similar bug in Standard View which I mentioned in another post, Matt, if you're listening).
-Will
In your example, I would want to see the disc total of 6 presented somewhere in the view.
Your suggested expression of Albumkey()-[Disc #] does indeed achieve that, though at the expense of displaying the rather random looking list of Albumkey() values. My music collection is primarily classical, with artist lists that tend to be much longer than for non-classical genres. Most of the Albumkey() values are significantly truncated in the view and fail to properly identify the album.
My preference would be to have a view that combined MrC's simple presentation of multi-disc albums (as shown in the attached image) with an additional column that displayed disc totals.
EDIT: Note that the view shown in the attached image does not actually require anything as complicated as MrC's expression coding. All my music files include a [Total Discs] metadata item that can simply be added to any view.
-
I'm wondering about:
ItemCount(AlbumKey() - [Disc #])
I'll test tomorrow and reply here.
This does not work in the new ItemCount expression. So we'll need to keep thinking.
I almost wonder if "Total Discs" should just be a library field?
-
Yaobing pointed out that "Total Discs" is already a library field. It's blank on the multi-disc set I'm playing from now, but maybe if we just filled it in?
-
Yaobing pointed out that "Total Discs" is already a library field. It's blank on the multi-disc set I'm playing from now, but maybe if we just filled it in?
I rip my CDs using dBpoweramp and it usually manages to automatically generate a suitable value for 'Total Discs' (the same applies to a similar metadata field called 'DiscTotal'). On the occasions when I find this value is blank in JRiver Media Center I fill it in manually.
I also recently created a metadata field called 'MyDiscTotal'. It was initially set to the same value as 'Disc Total', but then I manually deleted the values for those albums I don't want to include in my overall disc totals. All my SACDs have been ripped three times: as FLAC files, stereo DSFs and multichannel DSFs. These appear in JRiver Media Center as three different albums. To avoid overstating my album and disc counts I only have a value in 'MyDiscTotal' for the FLAC versions of my SACD rips.
-
I'm going to make MC update the already existing Total Discs field when it starts up. It's not marking the files dirty for tagging, so should hopefully be a pretty light action.
This way the field will always be filled and you can use it in any view.
Thanks for the prompts on this :)
-
Your suggested expression of Albumkey()-[Disc #] does indeed achieve that, though at the expense of displaying the rather random looking list of Albumkey() values. My music collection is primarily classical, with artist lists that tend to be much longer than for non-classical genres. Most of the Albumkey() values are significantly truncated in the view and fail to properly identify the album.
Use this expression instead
right(Albumkey() - [Disc #],2)
-
Use this expression instead
right(Albumkey() - [Disc #],2)
Sadly, that doesn't work for me.
It removes the ugly-looking Albumkey() listing, but that has the side-effect of replacing the vital overall disc total in the top line with the number 6 (which is the number of lines required to display the discs-per-album selection options of 1 - 5, plus a rather obscure selection option of '-').
-
Sadly, that doesn't work for me.
It removes the ugly-looking Albumkey() listing, but that has the side-effect of replacing the vital overall disc total in the top line with the number 6 (which is the number of lines required to display the discs-per-album selection options of 1 - 5, plus a rather obscure selection option of '-').
Sorry, I really don't understand what you're saying here.
-
Sorry, I really don't understand what you're saying here.
I may have explained it badly. Perhaps the attached images of your view and the view generated using wer's suggestion of Albumkey()-[Disc #] will help to make things clearer.
-
Moe, I believe the problem is that the result from your expression is wrong. He wants to see 838, not 6.
Your suggested expression of Albumkey()-[Disc #] does indeed achieve that, though at the expense of displaying the rather random looking list of Albumkey() values. My music collection is primarily classical, with artist lists that tend to be much longer than for non-classical genres. Most of the Albumkey() values are significantly truncated in the view and fail to properly identify the album.
My preference would be to have a view that combined MrC's simple presentation of multi-disc albums (as shown in the attached image) with an additional column that displayed disc totals.
Haggis, the summary function in panes view counts unique values. 200 discs, each with a disc # of 2, is one unique value, not 200. So The expression I gave you provides the unique values to count.
Your initial request was to get a count. You've got it, in the first line. Now you're adding that you want it to look pretty. ;)
GroupCount would do what you want, but Matt would need to fix the bug so it works in Standard View. Ask for that to happen. Matt is terrific, so hopefully if he notices this he will offer to fix it.
-
Yes, I got that...
-
Moe, I believe the problem is that the result from your expression is wrong. He wants to see 838, not 6.
The summary function in panes view counts unique values. 200 discs, each with a disc # of 2, is one unique value, not 200. So The expression I gave you provides the unique values to count.
Your initial request was to get a count. You've got it, in the first line. Now you're adding that you want it to look pretty. ;)
GroupCount would do what you want, but Matt would need to fix the bug so it works in Standard View. Ask for that to happen. Matt is terrific, so hopefully if he notices this he will offer to fix it.
838 is indeed the required total, or at least it is close to the disc total I have calculated in a semi-manual fashion (I'm still trying to work out why both totals are not exactly identical).
Theater View is unfamiliar territory for me. I did make a quick check of Tools>Theater View, but it left me at a loss as to where to start with implementing your GroupCount suggestion.
-
Haggis, I explained about using the GroupSummary function (the brother to GroupCount) in the following thread, so you might find it educative about using these expressions in Theater View.
https://yabb.jriver.com/interact/index.php/topic,122114.msg844905.html#msg844905
I will add that you could Frankenstein something together by creating a user-defined calculated field using my expression above as a value, and then add a pane or expression column that uses a couple of ListItem expressions to extract the number from between the parens of that field and display that cleanly, but that seems like a lot of work to me when the number is already being displayed per the expression above.
I'll leave that as an exercise to the reader. :)
Best thing would be if GroupCount worked. That's exactly what it's for.
-
I'm going to make MC update the already existing Total Discs field when it starts up. It's not marking the files dirty for tagging, so should hopefully be a pretty light action.
This way the field will always be filled and you can use it in any view.
Thanks for the prompts on this :)
When you say that the field will always be filled, do you mean that MC will calculate an appropriate value for 'Total Discs', based on 'Disc #' values?
-
Exactly. Most CD's will be one, but if there are multiple discs it will be more.
-
So Matt, it sounds like that would calculate total discs per album. That's a great addition.
Haggis is looking for total discs per view though, total count of all the discs in all the albums in the view.
I can't think of a way to derive that from your Total Discs field except by using global variables to count them all up, so I'm not sure that will be a solution for Haggis' desire, beyond what we've already given him.
-
When you say that the field will always be filled, do you mean that MC will calculate an appropriate value for 'Total Discs', based on 'Disc #' values?
I wrote a Global Variables expression quite some time ago to populate [Total Discs]. Oh wait, I remembered wrong. It was total tracks in an album that I calculated:
https://yabb.jriver.com/interact/index.php?topic=100174.0
But later someone asked about total discs and I wrote that too:
https://yabb.jriver.com/interact/index.php?topic=100206.0
Again, global variables in MC are hard for me, so I don't remember the details. But the concepts in those threads and the linked thread from the first one can be used to build an expression for "all discs added up amongst all albums" as the OP wants.
Brian.
-
FYI Matt says the GroupCount in Standard View bug will be fixed in the next build.
-
I wrote a Global Variables expression quite some time ago to populate [Total Discs]. Oh wait, I remembered wrong. It was total tracks in an album that I calculated:
https://yabb.jriver.com/interact/index.php?topic=100174.0
But later someone asked about total discs and I wrote that too:
https://yabb.jriver.com/interact/index.php?topic=100206.0
Again, global variables in MC are hard for me, so I don't remember the details. But the concepts in those threads and the linked thread from the first one can be used to build an expression for "all discs added up amongst all albums" as the OP wants.
Brian.
I spent quite a bit of time a couple of days ago trying to understand the concepts contained in MrC's original coding suggestions, but deciphering his expression syntax was a challenge, particularly because of the large number of nested bracket pairs. Trying to work out which was the closing bracket for each opening bracket made my eyes hurt. I'm having similar problems with the lengthy expressions in your linked threads.
I'll keep trying to develop my expression syntax skills, but I might end up just waiting for the GroupCount bug to be fixed...
-
Trying to work out which was the closing bracket for each opening bracket made my eyes hurt.
Haggis, download the Notepad++ editor app. It does syntax highlighting that will visually show you which parenthesis, brackets, etc match up. It's very helpful in such situations. You can google it.
Just put your cursor next to a bracket, and it will highlight the matching bracket.
-
Haggis, download the Notepad++ editor app. It does syntax highlighting that will visually show you which parenthesis, brackets, etc match up. It's very helpful in such situations. You can google it.
Just put your cursor next to a bracket, and it will highlight the matching bracket.
My normal practice in such situations has been to copy a long expression to Word and then manually give each pair of brackets a unique colour. I also make all brackets stand out by making them bold and in a larger font. When trying to understand a complex expression there is an advantage to simultaneously highlighting all the bracket pairs.
I've installed Notepad++, as you suggested. It only highlights one bracket pair at a time, but it will definitely be helpful in speeding up the above process. Many thanks for making me aware of this app.
BTW, what we Brits call brackets (or round brackets) are usually called parentheses in the USA. What Americans call brackets are called square brackets in the UK. Two people divided by a common language...
-
Check out this Notepad++ language file that was created for MC. It will give you really good syntax coloring.
https://yabb.jriver.com/interact/index.php?topic=108016.0
To install, click "Language" in the menu bar of Notepad++ and then choose "Define your language". On the screen that pops up click import and point to the file you download above. You may have to restart ++ at this stage. Then reopen, paste in the code and choose the JRiver entry under language
-
In the past when building big MC expressions, I would work on them in a text editor. While doing so, I edited them like "real code" keeping the parenthesis organized on separate lines. A poor example:
PadNumber(
Math(
round(
([Bookmark] / ([Duration, 0] * 1000)) * 100
)
)
,2
)
Breaking it up like that helps you figure out which arguments belong to which functions. This one is one of Glynor's that's in my library for his percentage watched features.
Back to doing development on this:
I would then condense it into a single line below the main code, and cut and paste that into an expression column in MC to test it. As I worked on it, I would update the main "code" block, then condense and test it. Until I finally got it right. Expression columns are VERY helpful in figuring this stuff out. When it doesn't work you can break it up functional unit by functional unit and make those expression columns. Then you can see where it needs adjustment and fix it. Then finally put the units together and make sure the whole works.
I hope some of this makes sense.
Brian.
-
Check out this Notepad++ language file that was created for MC. It will give you really good syntax coloring.
https://yabb.jriver.com/interact/index.php?topic=108016.0
To install, click "Language" in the menu bar of Notepad++ and then choose "Define your language". On the screen that pops up click import and point to the file you download above. You may have to restart ++ at this stage. Then reopen, paste in the code and choose the JRiver entry under language
I've just installed the JRiver Media Center language file for Notepad++, but the highlighting of each pair of round brackets is rather random. The example below highlights 7 right hand round brackets, but only 3 left hand brackets.
[=save(math(max(max(0[disc #],1),load(v_discs_[album artist (auto)]_[album]))), v_discs_[album artist (auto)]_[album])1]=1
Clicking the mouse on one bracket should highlight the matching bracket of that pair. In some cases, that works fine. In others, no match is found or the wrong bracket is highlighted. Reverting to the default language file made no difference to that behaviour, so this looks like a bug with Notepad++. This is also probably the reason why the JRiver Media Center language file highlighting is erratic.
EDIT: The erratic behaviour is limited to round brackets. Square bracket highlighting works fine.
-
As mentioned earlier, I disliked the appearance of AlbumKey() in a view using the expression Albumkey()-[Disc #]. However, I have just found that the following expression has the same ability to show my total disc count in the top row, followed by a much more readable album listing for classical music. In reality, I used a larger number of periods before AlbumKey() to ensure that it never appears on screen. At present, I don't actually need to add AlbumKey() to ensure that the expression will uniquely identify all my albums, but as my collection increases there is a greater risk of having more than one album that shares the same name and the same artist.
[Album]-[Album Artist (auto)]-[Disc #]...................................................................AlbumKey()
I have now created a view using that expression to define one column, plus another column simply based on Album. The top row thus gives me both my total disc count and the total number of albums containing those discs.
I think that will serve my needs until the GroupCount in Standard View bug is fixed.
-
AlbumKey() is just a shortcut to writing "[album artist (auto)] - [album]". https://wiki.jriver.com/index.php/Miscellaneous_Functions#AlbumKey.28.E2.80.A6.29
So adding all periods and AlbumKey() in your expression isn't doing anything. You are already specifying both fields, [Album] and [Album Artist (auto)].
Alas, the Notepad++ Language file isn't perfect, and you have found the worst part of it. It is on my list of things to improve at some time. Maybe.
Lepa improved the Language file and attached it to this post: https://yabb.jriver.com/interact/index.php/topic,119385.msg841053.html#msg841053
It doesn't fix everything though.
-
AlbumKey() is just a shortcut to writing "[album artist (auto)] - [album]". https://wiki.jriver.com/index.php/Miscellaneous_Functions#AlbumKey.28.E2.80.A6.29
So adding all periods and AlbumKey() in your expression isn't doing anything. You are already specifying both fields, [Album] and [Album Artist (auto)].
Alas, the Notepad++ Language file isn't perfect, and you have found the worst part of it. It is on my list of things to improve at some time. Maybe.
Lepa improved the Language file and attached it to this post: https://yabb.jriver.com/interact/index.php/topic,119385.msg841053.html#msg841053
It doesn't fix everything though.
Thanks for clarifying the definition of AlbumKey(). I had assumed it was a little more sophisticated than a "generally unique" album / artist combination string. In an attempt to improve the chances of obtaining a unique identity for each album, I tried using the following expression (even though 244 of my albums have no value for 'Catalog #').
[Album]-[Album Artist (auto)]-[Disc #]-[Catalog #]
Interestingly, that added 4 to my total disc count. I'm guessing that this means the simple AlbumKey() approach had failed to generate unique values, but I've not yet worked out an easy way to identify the 4 extra discs.
EDIT: I've just found that at least one of my 'extra' 4 discs was actually caused by an album with 26 tracks, only 24 of which contained a value for 'Catalog #'. It appears that there is nothing to ensure that 'Catalog #' is the same for all tracks.
EDIT2: All 4 of these apparent 'extra' discs were caused by this same issue. It looks like adding 'Catalog #' to the expression might cause more problems than it cures. Errors in Album and Album Artist tend to be obvious, as they screw up the listings in MC. Errors in more obscure metadata fields are much more difficult to spot.
I tried the updated version of the MC language file for Notepad++, but it made no difference to my bracket highlighting issue. This is not too surprising, as I had previously observed that the fault appeared to lie with NotePad++. The new language file actually made things worse, as most of the expression text is now in reverse video (white text on a dark purple-blue background).
-
Haggis,
The problem is not that adding a particular field to an expression produces incorrect results. The problem is your files are tagged inconsistently. MC counts unique values in a field. So if you're going to count based on a particular field, make sure all the files are tagged, and tagged accurately.
Pretty much any field can be used properly in the expression, as long as your tagging is consistent and accurate.
Good luck...
-
By the way, the bug affecting GroupCount and GroupSummary in Standard View has been fixed in 25.0.106.
-
Haggis,
The problem is not that adding a particular field to an expression produces incorrect results. The problem is your files are tagged inconsistently. MC counts unique values in a field. So if you're going to count based on a particular field, make sure all the files are tagged, and tagged accurately.
Pretty much any field can be used properly in the expression, as long as your tagging is consistent and accurate.
Good luck...
I understand that. My point was that errors in some tags are quite difficult to spot. The tagging inconsistencies for 'Catalog #' have probably been in my MC catalogue for years without causing any problems. If I was going to depend on the accuracy of that tag then I would probably have to try and create a view that highlighted any album with inconsistent values for 'Catalog #' (though it's not immediately obvious how to do that).
By the way, the bug affecting GroupCount and GroupSummary in Standard View has been fixed in 25.0.106.
That's good news. However, an upcoming holiday break may mean that I won't be able to check this out for a couple of weeks.
BTW, I must thank you again for your original suggestion to use the expression Albumkey()-[Disc #]. That was the key step in reaching my current solution :)
-
Yeah spotting tag inconsistencies can be hard. I made a view that just lets me scroll through a long list of tags... discrepancies are easier to spot when they're moving, just visually.
Also if you really want to be thorough you could export all the fields to excel via a csv playlist and use the tools there to flag inconsistencies.
You could also make your own catalog# (or other) field and make it relational, so setting it once will set for everything in the album. That could be done for every file in your library at once with an expression, I think.
Anyway good luck... Glad I could help.
-
Finding inconsistent [Catalog #] values is easy.
Change your Album View from a List Style of "Thumbnails" to "Details". (Maybe copy the standard Album View so you can change the copy and delete it later.)
Add the [Catalog #] field to the View.
Sort by the [Catalog #] field in the top pane, ascending or descending to bring the problem Albums to the top. Most values in the View will be the actual catalog number, which shows that all files in the Album have the same value in the field. Those Albums that say "Varies" have more than one value for the files in the Album.
Fix the problem albums by viewing the file details in the bottom pane and editing the incorrect or missing values.
Done
You could also make your own catalog# (or other) field and make it relational, so setting it once will set for everything in the album. That could be done for every file in your library at once with an expression, I think.
Having a relational Catalog number field is a good idea, for audio. I'm not sure if that affects other media types. Copying values between fields is easy. See my post: https://yabb.jriver.com/interact/index.php/topic,114408.msg846898.html#msg846898
-
Those Albums that say "Varies" have more than one value for the files in the Album.
That's a good idea for this case. I was thinking more of my own problems in that area, ensuring certain naming conventions are followed. Since in those cases the values are different but rule based, VARIES doesn't help me.
-
Yeah, my post was specific to Haggis999's concern.
Much harder when you are using variable value based on an expression or manual naming convention. You might be able to use a check field. Probably a topic for a different thread.
-
Finding inconsistent [Catalog #] values is easy.
Change your Album View from a List Style of "Thumbnails" to "Details". (Maybe copy the standard Album View so you can change the copy and delete it later.)
Add the [Catalog #] field to the View.
Sort by the [Catalog #] field in the top pane, ascending or descending to bring the problem Albums to the top. Most values in the View will be the actual catalog number, which shows that all files in the Album have the same value in the field. Those Albums that say "Varies" have more than one value for the files in the Album.
Fix the problem albums by viewing the file details in the bottom pane and editing the incorrect or missing values.
Done
That's a very neat solution. Thanks for that.
Having a relational Catalog number field is a good idea, for audio. I'm not sure if that affects other media types. Copying values between fields is easy. See my post: https://yabb.jriver.com/interact/index.php/topic,114408.msg846898.html#msg846898
Despite having created many of my own metadata fields in MC over the years, I'd never paid much attention to the 'Relational' setting. I note that 'Catalog #' has that setting fixed at non-relational, i.e. applied at file level rather than album, artist or series level (I'm guessing that you are prevented from altering that setting because it is a standard MC tag that they don't want you to alter). It seems odd that it has not been fixed at album level, but as you say, that might not work well with non-audio media.
As wer suggested, creating my own version of 'Catalog #' under another name would allow me to make it an album-level tag.
This has proved to be a very useful thread. Thanks to everyone for all the helpful advice :) :)
EDIT: I've just noticed that several of my classical box sets (which have the same album name for each disc in a set), have different 'Catalog #' values for each disc. This means that it would not be appropriate to create a relational clone of 'Catalog #' that applies at album level.