MusicBee Patch Update (Virtual Tag Notification)

[tjinc]

Nice plugin - just something to bear in mind: When using Windows Explorer to extract the contents of the downloaded patch (zip) file, the file modification dates are set to 'now' (the date/time that the files are extracted). This could obviously throw out this plugin.

The solution is either to remember to 'unblock' the downloaded patch file before extracting the contents (right-click on the zip file > Properties > check the 'Unblock' option) or to use a decent third party compression/archive program (7-Zip, WinRAR). Both these methods will result in the original date created and date modified values being retained.

[phred]

#1   if you're using the store version, the virtual tag should return a value like "MusicBee store version not supported".

Very clever plugin, Mayibongwe.

It's nice that once the user has downloaded and installed it they will get a warning that if they're using the Store version the plugin won't work.

BUT, you can save the Store version users some time by posting a warning on the plugin's download page. Not that they'll all read it, but there really should be a warning/notice before they download.

Otherwise, nice job.

[Mayibongwe]

Yep, I now get '14' days, which seems correct. So that indicates how old the version is that the user is currently running.
But it doesn't say when the latest patch update was released. That might be relevant information too?

More accurately: it indicates the elapsed days between the last MB update (extraction date per tjinc - so not necessarily the day Steven released the last update) and the latest one.
I'm already logging those two dates on the log file in ...AppData\mb_Check4Updates
Should I expose this info as two separate virtual tag functions? It would be an easy addition (though not information I would be interested in myself)

When using Windows Explorer to extract the contents of the downloaded patch (zip) file, the file modification dates are set to 'now'
(the date/time that the files are extracted). This could obviously throw out this plugin.

I hear you tjinc. But so long as the extraction was done on the same day that the user downloaded the patch,
they will still get an accurate reminder of how many days have elapsed since their last update.

BUT, you can save the Store version users some time by posting a warning on the plugin's download page.
Not that they'll all read it, but there really should be a warning/notice before they download.

Good point phred. I've updated the important notes section of the add-on to mention this as well.

[hiccup]

More accurately: it indicates the elapsed days between the last MB update (extraction date per tjinc - so not necessarily the day Steven released the last update) and the latest one.

I'm not sure I understand what that says about the dates.
It doesn't indicate how old the version is that the user is currently running? Or does it somehow?

Maybe do something like this?:
New patch available! (5 days old - your version: 2024-10-25)
or
New patch available! (5 days old - your version is 21 days old)

But, please do what you believe is best.
I am probably not really in the target group for whom this plugin is intended ;-)

[Mayibongwe]

#1   It doesn't indicate how old the version is that the user is currently running? Or does it somehow?
...
#2   New patch available! (5 days old - your version is 21 days old)

#1   No, not exactly. If I update my .exe the same day that Steven issues the patch, then it will indeed indicate how old it is in comparison to the most recent patch.
        But if for example, I decide to download a patch that was released 5 days ago, today.
        Then this virtual tag will imply that the old version is 1 day old if another patch releases tomorrow.

        So no, to be exact, it will only tell us when somebody last downloaded a patch. I can't think of any way to get the release date of the .exe if its
        creation_date and modification_date is susceptible to 'tempering' as described by tjinc depending on how one unzips the files.

#2   The figure 21 above is actually what the 5 represents.
        Perhaps New patch available! (last updated 21 days ago) is a more accurate description?

[hiccup]

#1   No, not exactly…

I'm sorry, I'm probably a bit thick today.

Does that mean:
- there is no way to get a reliable release date for the .exe that a user is running?
- the release date of the latest available patch update will always be reliable?

I lean towards it only displaying any date (or passed period) that is absolute and reliable.
As soon as dates or periods passed are relative to another, but not both are absolute 'correct' release dates because they will depend on when a user installed or downloaded it, it will probably result in confusion.

[Mayibongwe]

Does that mean:
- there is no way to get a reliable release date for the .exe that a user is running?
- the release date of the latest available patch update will always be reliable?

For 1, yes, not that I can think of. Unless someone else has ideas on how we can obtain that info if not from the file attributes of the MusicBee.exe
The creation date and modification date don't seem to be all that 100% reliable.

For 2, yes, thankfully that is correct as I'm getting the release date of the latest version directly from the index page on the website.

[hiccup]

For 1, yes, not that I can think of. Unless someone else has ideas on how we can obtain that info if not from the file attributes of the MusicBee.exe
The creation date and modification date don't seem to be all that 100% reliable.

I have some vague recollection that the numbers after 3.6 here could be some 'coded' manner of representing some sort of date, or period passed?



If that is the case, perhaps a reliable date can be derived from that?

[Steven]

the first number after 3.6 increments each day

[hiccup]

the first number after 3.6 increments each day

Yeah, in the mean time I had figured out that that number of days counts back to probably November 24, 1997.
Not sure why that is, but can you confirm that?

edit
So the version number seems to be constructed like this:
For e.g. 3.6.9074.33566
3.6 - major and minor update versions
9074 - days passed since 1997-11-24
33566 - seconds that have passed on the specific time of day the update was created
 

[Mayibongwe]

Thank you hiccup and Steven.
I've now released a v1.2 which relies on the current MusicBee.exe's file version attribute in order to determine an accurate date of release.

hiccup, apparently that incremental figure started counting from 01/01/2000.
That's according to: https://stackoverflow.com/questions/1276437/compile-date-and-time
I've verified that against a date calculator and it matches the build number on the MusicBee.exe and its released date.

[hiccup]

hiccup, apparently that incremental figure started counting from 01/01/2000.
That's according to: https://stackoverflow.com/questions/1276437/compile-date-and-time
I've verified that against a date calculator and it matches the build number on the MusicBee.exe and its released date.

Not ashamed to admit that I didn't use any available braincells to come up with this riddle, but I used some website that suggested it could calculate days between dates.
And that came up with 'day 9991' being April fools day 2025 counting from 'day 1'.
And I didn't even use some basic common-sense to check if that seemed even ball-park correct.
So, I wasn't using my brain, and that website was probably using ChatGPT.

A perfect display of Sign "☮︎" the Times?
We are doomed.

edit
According to my Casio calculator, 9991 divided by 365 is 27.3726something.
So your 01-01-2000 also can't be correct.
Are we apes?
Do we want to be apes?

[Mayibongwe]

According to my Casio calculator, 9991 divided by 365 is 27.3726something.
So your 01-01-2000 also can't be correct.

Wait, where are you getting 9991 from? The latest patch version uploaded yesterday has 9074:
https://www.timeanddate.com/date/durationresult.html?d1=1&m1=1&y1=2000&d2=04&m2=11&y2=2024

[hiccup]

Wait, where are you getting 9991 from? The latest patch version uploaded yesterday has 9074:

Probably the fruits of being the owner of some sort of fuzzy brain.
(sometimes useful, sometimes frustrating)
Ah well, at least I'm doing slightly better than ChatGPT. (for the time being...)

[iamambuser]

HI thanks for the neat little plugin. I have a question. I tried adding color to the clickable link you suggested, but the it then no longer is clickable. Is there a way to get it to be clickable and have a color other than the default?