These currently seem to use the Date field rather than the Original Date / Original Year field - That would probably be a better choice to get music for a certain period and not include new remasters and re-releases of older music.
This can be worked around server side on MinimServer by re-mapping the dates but that would then impact versions where the date variance is useful.
I struggle to see how the decade view can work. The majority of music I have from the 1960’s comes from CDs produced in the 1990s or 2000s. The only date field in my tags is the CD issue date, which I suspect is what most people would have. At the moment Serento is showing the decade for these CDs as 90s/00s.
You say that Serento could use the Originaldate / Originalyear tag. Which seems a great idea, except I’ve never used them and wonder how many people actually do.
Unless Serento analyses each track on a CD and compares it to a database of when that track was recorded and then averages all those tracks to give a decade I struggle to see how it will accurately work for everyone. Then what happens to CDs that spans decades? I also fear that this is adding complexity few people care about.
For me having the CDs genre tagged for the appropriate decade is good enough.
Gaz
If you are using MusicBrainz then Original Date is usually set.
All my music is either tagged with both or I force make the Date tag the Original Date just for this reason.
The alternative to having this in-app is to play about with tags in MinimServer to make the Date’s all the same and prioritised. It’s on my “to play with” list so I’ll post up how it goes. It’s so much easier to try new things now the sync is so much faster and slicker.
Over the years, having found that one app/system didn’t support one tag or another, I’ve stripped back the tags I write to the bear essentials. I do not write things like Conductor, Orchestra, Original Date, Disc Subtitle, etc. I have spent a lot of time getting the Album Artist, Artist, Genre, etc, tags correct so I can easily find the music I want.
If the majority of users write the Original Date tag, and the data is correct, that would seem to be the best thing to use for Decade. If people do not use Original Date I think they will be confused about what Decade is for, especially as you can already sort via Year in the Album view.
Perhaps Lorin, in his research, can shed some light on what tags people commonly use.
I’ve already implemented this by allowing you to choose. If you prefer Original Date then that is going to be used for decades with fallback to Date if no Original Date is present. If you turn this setting on and you have no Original Date anywhere nothing changes for you. I think this is an acceptable solution.
Lorin
@Gaz You can also do this Server side on MinimServer like this - then add Original Date tags as and when you need them:
Replacing this: RecordingDate.merge={Date}
With this: Date.update={OriginalDate}, RecordingDate.merge={OriginalDate,Date}
In tagValue - Whether you use @lorin.bute 's app side implementation or this it seems that should make the Decade view be correct. Doing it server side also affects the date on the Albums themselves so they show in the order the albums were originally released not when a Re,aster came out (You can achieve the same thing in a better way using versions though when you have an original version as well, so it’s a preference choice really).
@lorin.bute - Is the Decades using Original Date in now or is it coming soon?
Thank you Lorin, that sounds like a great solution.
I thought you were having a rest 
Gaz
@tiefling Thank you for the info, I will give this a try. As Serento is now using Original Date I might as well make use of it.
Thanks
Gaz
I really wanted to rest but a user on the minimserver forum reported an issue which I knew was there but this time manifested often so I worked 4 days on it. I think I will upload a new version tonight.
I wouldn’t have worked on it if it did not mess with the core function of the app which is the music playback, but it does. It affects a very small number of renderers, mostly Linn. Because Linn exposes OpenHome and AVTransport devices as completely separate, I can’t rely on the other for certain functions and Serento was using this trick.
What that means is that Serento has to run all the playback functions on one or the other, never together on such devices like Linn. And I had to simulate the Linn streamer and other streamers and make them work together because using only OpenHome means that you have to support most of its features if not all of them.
So one feature of OpenHome is that the queue lives on the streamer not in Serento. That means that any app that supports OpenHome can read that queue and even interact with it. And so, Serento can now read what’s playing on the renderer even if the queue was sent by another application. It can also do basic playback functions on that queue. It will take over whenever something is being played using Serento.
It was a pain in the rear to make this all work but I think I have it working.
Regarding Original Date in decades: yes, it is included in the next version.
Lorin.
That sounds really slick.
As someone really bad at it himself - “Please take a break” though - it’s so important.
I may keep logging problems, but I’ll say if anything is critical and most things aren’t - If I don’t post when it occurs I just forget with my goldfish brain.