getmusicbee.com
MusicBee & Add-Ons => Customizations => Plugins => Topic started by: Mayibongwe on November 03, 2024, 08:35:05 AM
-
Hi Guys,
This is for the bunch that likes to keep up to date with Steven's updates.
I know there's already a feature intended for this in the preferences screen > general > application > check for updates on startup ...
But I've never seen the fruits of its labour - not sure when or where that notification is supposed to reflect (never seen one in the past 3 years of my MB use).
Download Link (https://getmusicbee.com/addons/plugins/521/musicbee-patch-update-notification/)
(https://i.imgur.com/zpXZJZy.png) (https://i.imgur.com/wSSTsgQ.png) (https://i.imgur.com/ZwTfoQk.png)
Installation
- Download the "mb_MusicBeePatchUpdate_v1.1" zip file and select it from MusicBee -> Edit -> Preferences -> Plugins -> Add Plugin.
- In the same preferences screen, go to the Tags (1) tab > Define New Tags ... set up a virtual tag as follows: $IsNewVersionAvailable()
- Then display that virtual tag in the Track Information panel (this is optional, you can display it wherever you like).
- Note that the virtual tag will only return a value when a new patch is available. When you are on the latest version, nothing will display.
- Also note that this is for notification purposes only. The plugin won't download the update for you.
How to Get a Direct Download Link
- Create a virtual tag as follows: $GetNewVersion() which will be a clickable link if displayed on the track info panel.
- To make it clickable, go to Preferences > Tags (2) > configure fields ... > change your virtual tag data type from "string" to "url"
How to Modify the Message Returned
- $IsNull($IsNewVersionAvailable(),"Already on the latest version",$IsNewVersionAvailable())
To display something else when there isn't a newer version.
- $RxReplace($IsNewVersionAvailable(),"^.*$","New Version Out Now")
To override the message when an update is available
-
Ooh, this is very clever Mayibongwe.
Thanks for creating and sharing.
This probably deserves a sticky in Tips & Tricks and in the FAQ.
Two comments:
I don't think the described step to extract the file after downloading is necessary?
I pointed 'add plugin' at the .zip and it worked fine.
About the '... days old' indication:
That looks a bit off.
I ran the plugin on a quite recent 3.6.9059 P install, and the virtual tag says "New patch available! (337 days old)", while the used version is from (I think) a couple of weeks ago, and the latest patch update is from today?
-
I don't think the described step to extract the file after downloading is necessary?
I pointed 'add plugin' at the .zip and it worked fine.
Quite right. That's a copy & paste on the readme I've been reusing over and over since the first plugin I worked on.
Otherwise, yes, selecting the .zip directly is sufficient - I'll tidy up that read me.
About the '... days old' indication: That looks a bit off.
I ran the plugin on a quite recent 3.6.9059 P install, and the virtual tag says "New patch available! (337 days old)", while the used version is from (I think) a couple of weeks ago, and the latest patch update is from today?
Perhaps the creation date of the MusicBee.exe I'm making the comparison with is a bit flawed.
I initially worked with the modification date which I thought threw things off on my side.
Can you confirm the creation and modification date of your .exe?
-
And two more things:
1.
I am not sure about this, but I seem to recall that it is now possible to create such a virtual tag that contains a clickable link?
If that is indeed the case, there could be link to the "index of patches" page?
Or to some post or FAQ that explains how to exactly update MusicBee?
2.
It should probably have some warning that this is useless for 'Store' versions?
-
Both good points. Let me see how to work 1.
-
Perhaps the creation date of the MusicBee.exe I'm making the comparison with is a bit flawed.
I initially worked with the modification date which I thought threw things off on my side.
Can you confirm the creation and modification date of your .exe?
Ah yes, that must be it:
(https://i.imgur.com/WZ00TSC.png)
PS
Off-topic, but I notice my screenshots like this one now come out slightly enlarged and a bit fuzzy/unsharp.
I don't think I have changed anything.
Could someone confirm it is looking like that for them too?
If it does not and it looks pixel-perfect sharp for you, perhaps it is something my browser suddenly does?
-
Ah yes, that must be it:
And the modification date, that's much more recent?
____
can't comment much on the screenshot size myself.
I recently changed laptops and have a much larger screen size than before (it will be a while before I stop seeing everything large-sized like the moon).
-
And the modification date, that's much more recent?
Yeah, if I am not mistaken that will be the date when Steven created that updated version of MusicBee.exe.
One point of warning: I believe that I have tweaked the way my Windows install handles these date created/modified by means of a registry edit.
So someone should probably confirm they are seeing the same that I am seeing here.
-
I also notice that on the Plugins page, there is currently no ''Support forum' button that directs to the forum topic.
-
can't comment much on the screenshot size myself.
I recently changed laptops and have a much larger screen size than before (it will be a while before I stop seeing everything large-sized like the moon).
If you have your dpi set to 100% you should be able to see it.
For me this one is fuzzy and slightly enlarged:
(https://i.imgur.com/AM5mzOc.png)
And clicking this one links to the pixel-perfect original:
(https://i.imgur.com/AM5mzOcm.jpg) (https://i.imgur.com/AM5mzOc.png)
So if the two look identical for you, I suspect there must be something going on caused by some Firefox update.
-
A new version has been uploaded (v.1.1)
#1 if you're using the store version, the virtual tag should return a value like "MusicBee store version not supported".
there is no direct way to determine the type of MB edition (the .exe does not specify the letter on the file attributes, and the API does not share this as far as I can see).
so instead, I've queried the MusicBee ErrorLog for a version type (which phred can back me up as the sure way to determine a user's install type).
the day we get a user without a populated error log, Steven's quest will be complete!
#2 there is now an additional function call to get a direct link to the patch site $GetNewVersion()
although this will have to be a separate virtual tag if you plan to make the tag clickable in the track info panel.
see instructions on how to do this on the start post.
#3 the date comparison is now made against the last modified date on the MusicBee.exe
-
I also notice that on the Plugins page, there is currently no ''Support forum' button that directs to the forum topic.
This is now fixed and points to this thread - thanks.
...but I seem to recall that it is now possible to create such a virtual tag that contains a clickable link?
You've got a good memory: https://getmusicbee.com/forum/index.php?topic=36011.0
I also needed to remind myself how one does that (I'll post some instructions on the start post just now)
-
So if the two look identical for you, I suspect there must be something going on caused by some Firefox update.
Yep, on a 100% DPI setting here.
And those two are identical on my G.Chrome. I've opened each of them on a new tab (to ensure I'm viewing the full size) and there's no difference at all.
-
Yep, on a 100% DPI setting here.
And those two are identical on my G.Chrome. I've opened each of them on a new tab (to ensure I'm viewing the full size) and there's no difference at all.
Thanks for confirming.
I removed and re-installed Firefox, and that didn't solve it.
Then I changed Windows dpi settings a couple of times and did some restarts, and finally I am back to pixel-perfect.
So the culprit was Windows, not Firefox.
My apologies for adding this off-topic stuff to your thread.
-
#3 the date comparison is now made against the last modified date on the MusicBee.exe
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?
Or perhaps it could show both dates, so that it shows how far the user is behind?
something along the lines of:
'date of your current version: …'
'date of the latest patch update: …'
-
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.
-
#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.
-
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.
-
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 ;-)
-
#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?
-
#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.
-
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.
-
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?
(https://i.imgur.com/Y0UO7Wg.png)
If that is the case, perhaps a reliable date can be derived from that?
-
the first number after 3.6 increments each day
-
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
-
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, 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?
-
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
(https://i.imgur.com/4AkvIlB.png)
-
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...)
-
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?
-
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?
If you apply the colour markup code as part of the virtual tag definition (rather than the Track Information panel configuration) then it should work.
-
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?
If you apply the colour markup code as part of the virtual tag definition (rather than the Track Information panel configuration) then it should work.
Thanks, now just have to wait until a new version is released. :)