+100500. and it would be useful if dashboard for add-ons supports 'last updated' tag along with 'version'."last updated" is already supported. it is not user editable. The system automatically sets the last updated date.
but the only problem is that It will require extra work from addon devs. If the add-on devs are willing to do this i can make a plugin for the musicbee that will notify if a newer version is available or not.this would be great. just foresee that some add-on devs wont support update notifications. such add-ons (eg. without proper manifest/xml/etc.) must be marked in add-on updater somehow.
but i have seen a lots of the time add-on devs not using the "version" field properly or increment them after each update. My initial goal is to make a updater plugin eventually. :-\I don't see this as a problem, because if you care about your addon and want updates to reach your users, you can add/update a few strings. If not, you/your addon simply won't profit from update notifications/auto-update.
but the only problem is that It will require extra work from addon devs.
i frequently update some plugin page (eg plugin description) without updating download link. will site change 'last updated' tag in this case?+100500. and it would be useful if dashboard for add-ons supports 'last updated' tag along with 'version'."last updated" is already supported. it is not user editable. The system automatically sets the last updated date.
(https://i.imgur.com/XvRCed4.png)
Yes, it should. The "last updated" field does not rely on changing the download link.
i frequently update some plugin page (eg plugin description) without updating download link. will site change 'last updated' tag in this case?
To get this going I don't think we should talk about auto-upgrades first. This has so much implications like packaging format, support for old versions, security, hosting services, etc. As a first step it would be nice to get a notification for users if there is an update available.
<?xml version="1.0" encoding="UTF-8"?>
<addon-data>
<name>Addon anme goes here</name>
<id>addon id according to the website dashboard</id>
<version>1.0.1</version>
</addon-data>
addon_*.xml
In my opinion it would be better to have this functionality in the core MusicBee program. Given the importance of such a plugin, everyone should get this functionality out of the box. On the other hand I would like something, that basically all add-ons should use, to be open source. So maybe it would be possible to develop an updater plugin in a github repo and get it preinstalled with every new release of MusicBee like the last.fm plugin or theatermode. I think this would be the optimal solution.
Ideally there would be a possibility(API function) to get the PluginInfo instance of all installed plugins. This class has most of the information needed (version, name, supported api) and every Plugin already uses it. Maybe Steven can add an AddonID field for the ID on the website to the class.That would be the ideal solution. In this case we wouldn't need the .xml file and reduce clutter. on the other hand all of the plugins need to adapt to these changes.
but i have seen a lots of the time add-on devs not using the "version" field properly or increment them after each update. My initial goal is to make a updater plugin eventually. :-\ but the only problem is that It will require extra work from addon devs.I don't see this as a problem, because if you care about your addon and want updates to reach your users, you can add/update a few strings. If not, you/your addon simply won't profit from update notifications/auto-update. Also there could be workarounds for already installed addons or addons of which the id can not be determined, e.g. doing a search for the name on the website, asking the user which of these addons it is and saving the mapping in an internal DB.
Yeah good idea. I think we need to establish a standard way to store the addon data that can be readable by the updater. I am thinking of XML file that stores the important data, maybe something like this:Code<?xml version="1.0" encoding="UTF-8"?>
<addon-data>
<name>Addon anme goes here</name>
<id>addon id according to the website dashboard</id>
<version>1.0.1</version>
</addon-data>
if needed we can add more field in future.
Also the .xml file naming scheme should be something likeCodeaddon_*.xml
then the updater plugin can search through the directory and looks through all the files by that naming scheme and checks if a new version available or not. It shouldn't be too hard.
maybe i have misunderstood what is being proposed, but i had understood that when a plugin (or skin) is updated on the addons page, that the update would get included in a queryable xml block, similar to https://getmusicbee.com/rss/
if thats the case, i am happy to have MB query that xml data and for anything matching the user's installation and alert them.
yes, Steven, at least i expect something like this.
So the updater can read the xml, query the website (over the existing API) for the latest version, compare it to the one in the PluginInfo and then display a notification.but this wont work for theater modes, visualizers and skins. i don't think its very hard for devs to include 1 small xml file into add-on zip.
I would not add the version to the xml because you would have to change the version in two files and we already have the version in the PluginInfo class. This way you could even generate the xml and download it over the website when you create a plugin, because it would never change.
@Steven;
How about allowing, optionally, each plugin to use its own sub-folder under MusicBee\Plugins folder?
Some plugins are using the same filename for different files and Plugins folder is quite messy.
So the updater can read the xml, query the website (over the existing API) for the latest version, compare it to the one in the PluginInfo and then display a notification.but this wont work for theater modes, visualizers and skins. i don't think its very hard for devs to include 1 small xml file into add-on zip.
I would not add the version to the xml because you would have to change the version in two files and we already have the version in the PluginInfo class. This way you could even generate the xml and download it over the website when you create a plugin, because it would never change.
also i wouldn't rely on add-on version at all. for example there is no versions at all for most skins. update date is most important for comparison of versions.
@AvikB, so would the xml block you describe be available similar to: https://getmusicbee.com/rss/ ? I would suggest including the update date/time in UTC format as well in case the plugin developer forgets to increment the version infoYes, kind of similar.
@Steven; How about allowing, optionally, each plugin to use its own sub-folder under MusicBee\Plugins folder? Some plugins are using the same filename for different files and Plugins folder is quite messy.
Then skins (both xml & xmlc) & TM need to include just name and version at the beginning of the code? Maybe name could be optional if it's the same as filename? I think that's the case for most skins except skin sets.Some skins are in binary format. so that won't work.
but this wont work for theater modes, visualizers and skins. i don't think its very hard for devs to include 1 small xml file into add-on zip.
also i wouldn't rely on add-on version at all. for example there is no versions at all for most skins. update date is most important for comparison of versions.
Yes i think Steven and you are right about using the update date.So the updater can read the xml, query the website (over the existing API) for the latest version, compare it to the one in the PluginInfo and then display a notification.but this wont work for theater modes, visualizers and skins. i don't think its very hard for devs to include 1 small xml file into add-on zip.
I would not add the version to the xml because you would have to change the version in two files and we already have the version in the PluginInfo class. This way you could even generate the xml and download it over the website when you create a plugin, because it would never change.
also i wouldn't rely on add-on version at all. for example there is no versions at all for most skins. update date is most important for comparison of versions.
@AvikB: if you write example update notifier plugin to integrate it into mb later, write it in visualbasic as mb is written in vb.About that..... i am not comfortable with VB :P . I will write it with C# and WPF. maybe winforms but i like WPF better so there you have it. I don't think it needs to be integrated directly into MusicBee. It should be a standalone plugin, maybe included with MusicBee by default.
for update notifier ui: i think that displaying message box with updates at mb startup would be very boring. its better to have a button on mb title bar with image of balloon and number of updates. user can click this button to view the window with all updates. just like in visual studio. also an option to ignore given update (not to remind about it anymore) might be useful.I will keep that in mind. But before that we need a working solution first ;D
Then skins (both xml & xmlc) & TM need to include just name and version at the beginning of the code? Maybe name could be optional if it's the same as filename? I think that's the case for most skins except skin sets.Some skins are in binary format. so that won't work.
I don't understand why that won't work. Steven, can't MB read version info in xmlc file if it's included in the source skin file?
I dont see a id working as a matching criteria unless some changes were made to the plugin "about" information block, but i don't think i want to do that due to breaking existing old plugins.
i can provide an option in the dashboard to auto generate the XML file. you can just download it and include it in your addon.
I am not getting why its really necessary to include an xml manifest file with a plugin. Isnt it enough that when a plugin (or skin) is updated on the add-ons page, that a queryable xml file is updated with the plugin (or skin) name and the date/time it was updated. Then all MB needs to do is query the xml file and compare the updated names with the last updated time that MB will cache and anything newer, alert the user. If you have more advanced things in mind then fine, but otherwise it seems on the surface to be more complicated than needed.The problem is how are you going to query that xml file? Right now the data is stored in the Database with an unique ID, and the only way to query the data is to use the ID. You can not query using the name.
No that would be bad idea. The XML file will store the "last updated" date as well, which will be modified by the updater. If i put that in the SKIN XML file, then i would need to modify it as well. Which i don't think is a good idea.
You mean include it as a separate xml file? So for each skin file, there's additional xml file just for update notice and users should keep them as well? I don't think that's a good idea for skins and TM views (though it won't matter for plugins). It would be better including the code in the skin file. Still I don't get why you think old xmlc files would matter. With no such info in the file, then no update notice. What am I missing here?
i dont know how you did it, but http://getmusicbee.com/rss updates every time i update the musicbee versionIt is a bit different. since it only shows the latest version of musicbee.
I dont need to query by name - i just need a full list of names and when they were last updatedthat is not possible right now. Also i don't think that is a good idea. Right now there is 100+ addons and to get full names of each and last update date it will run 100+ quarries each time it will get the list.
i dont need the add-on id - i just need a full list of plugin names and when each one was last updated. I can match the plugin name against the cached values MB keeps from the plugin About block Of course the plugin author will need to make sure the name on the add-ons page matches the one provided in the About blockalso how are you going to see if the current plugin is the latest or not? If i get the last update date, what are you going to compare it with?
What I thought was plugin/skin authors put id/version info to the xml file (skin file for skins). Then MB reads and compares it with the server file to see if there's version update for the id and alert the user. Then no need for additional updater just for alert unless it can actually update plugins.welp we already discussed that instead of using versions we will use "last update date".
The XML file will store the "last updated" date as well, which will be modified by the updater.
I could manually maintain a mapping file that maps add-on id to plugin name/ skin name
MB would load the mapping file from the getmusicbee.com website
Its not ideal but i dont think its too much of a burden to do
However if you are proposing a live query to support this, i dont think its a good idea as there will be a huge number of hits as MB would run the query every time MB is started. The add-ons page is already quite slow to load some times.
I always had in mind you would be appending to a text file each time a add-on is updated and that MB would load the file, so if thats not the case it might be better to go back to your original idea.
Do you have any particular reasons fro disliking it? It will be only few byte or kb at best. and since it resides in the plugin/skin directory it won't make unnecessary folders in some obscure temp directory.The XML file will store the "last updated" date as well, which will be modified by the updater.I don't like this idea at all that requires keeping additional xml file for each skin/TM file just for update alert. I'd rather opt out.
For the benefit, it's too much hassle for managing and organizing add-ons. Whenever you re-organize them, you have to find and move that xml file too. Also I don't want to make my already cluttered skin/TM folders more messy by adding those files. I'd rather check add-on updates manually.I will left the decisions to the add-on devs. But you will be able to just delete the manifest file when installing, that will remove auto update feature.
that will remove auto update feature.
I agree with redwing and think 'File Version' is the better way to go rather than "last updated" date. It can be read from .dll's, from .xml's (if included) and I'm sure Steven could adjust the SkinCreator so that it would work with .xmlc skin files. Having the plugin scan the MB installation folder's Plugins and Skins sub-folders and compile a manifest of file versions that are already there is got to be easier than adding in extra .xml tracking files for every plugin/skin/theatermode.
I think it's already hard enough getting the devs (some of them anyway :) ) to put a version number into the skin, let alone wanting them to include an extra file in the downloadWell can't really do anything if they aren't willing to add a tiny bit extra work. I can just notify about the addons that have the manifest file in that case and ignoring others without it.
for 'addon_*.xml' manifest: maybe its better to use some suffix rather than prefix for manifest files? its not very important for plugins, but it will be much easier to move skin to other folder as 2 files (skin/manifest) will be located next to each other in windows explorer.Well for naming scheme, there is no need for suffix or prefix. The file will have the same name as the plugin or skin. the extension will be .meta
I am going to hold until Steven clarifies on it.clarify on what?
Welp after some thought i decided to use manifest file. No need to make any additional changes to API yet.I am going to hold until Steven clarifies on it.clarify on what? are you looking for an API that returns a list of all plugins, skins, TMs with the addon-id, name, version and date last modified?
<?xml version="1.0" encoding="UTF-8"?>
<addon-data>
<name>Addon Name</name>
<id>put your addon id</id>
<version>put your addon version</version>
</addon-data>
@AvikB, i think update notifier must take into account the minimum required musicbee version and display only supported add-ons or somehow mark unsupported ones.I am not sure how musicbee handles unsupported addons? Does not musicbee already check if an addon is unsupported and disables it?
mb doesn't support any compatibility check for skins/theater modes. it would be just the info that mb is needed to be upgraded also.@AvikB, i think update notifier must take into account the minimum required musicbee version and display only supported add-ons or somehow mark unsupported ones.I am not sure how musicbee handles unsupported addons? Does not musicbee already check if an addon is unsupported and disables it?
If needed i can add support for it but i am not sure how it can help since it is just for update notification.
Just a quick note on the warning. You don't really need the first sentence - the second sentence says the same thing. In warnings, less is more. The longer it is, the more people tend to ignore it, strangely. It might also be cool to include a list of plugins that are installed but do not support the update check, maybe with a link back to the plugin page as a "manual check" or to contact the developer. That way, the end user knows "Yes, the update checker plug-in sees that these unsupported plugins exist and the update checker is functioning properly, the reason there is no update listed for these is that they are not supported." I don't know if that's possible or not, but it would be more user-friendly. Great stuff, there. Nice.I am not sure if it is possible. For example the addon manager only look for meta files so it can be used for skins and theather modes. But without it not sure how i am going to get the data needed.
mb doesn't support any compatibility check for skins/theater modes. it would be just the info that mb is needed to be upgraded also.Yeah that is possible. I will look into it tonight.
Ok i have a very basic working demo ready.
https://mega.nz/#!CFwDQRgB!jVglRERRL-8GkS6GGOKW6Wv4mp-rhF8zQxhDkg8UBOg (https://mega.nz/#!CFwDQRgB!jVglRERRL-8GkS6GGOKW6Wv4mp-rhF8zQxhDkg8UBOg)
This is the updater file. You can try it out.
You can try it on your own addon. Here is the XML file structure.Code<?xml version="1.0" encoding="UTF-8"?>
<addon-data>
<name>Addon Name</name>
<id>put your addon id</id>
<version>put your addon version</version>
</addon-data>
you can get the addon ID by going to your addon page and check the URL. you should see a number there. That is the ID
(https://i.imgur.com/0iZk9VO.png)
The XML file extension should be .meta, you can name it whatever you like. No need for prefix or suffix.
it should look something like:
(https://i.imgur.com/QNkZlva.png)
Right now you can access the updater from the menu:
(https://i.imgur.com/s06cxvP.png)
you can check if an update is available or not. and the download button will open the addon page:
(https://i.imgur.com/1Zc5B7R.png)
This is a very basic implementation.
Good idea. I will look into it.
mb must hide folders which are marked hidden in file system in 'skins' folder. also it would great to have 3 tabs: available updates, ignored updates and add-ons, which don't support update notifications.
<?xml version="1.0" encoding="UTF-8"?>
<addon-data>
<name>Taskbar Progress</name>
<id>97</id>
<version>1.0</version>
<ignore-update>false</ignore-update>
</addon-data>
AvikB, i think that i meant by 'unsupported' the add-ons without metadata.I have no idea how i can get the data regarding this?
just list all skins/plugins which don't have associated .meta files on 3d tab. maybe its wont be very quickly, but its local operation, so the speed must not be the problem.I guess it is possible to look for files with mb_*.dll and list them as installed plugin.
Code<?xml version="1.0" encoding="UTF-8"?>
<addon-data>
<name>Taskbar Progress</name>
<id>97</id>
<version>1.0</version>
<ignore-update>false</ignore-update>
</addon-data>
the "ignore-update" tag should decide if notification will show or not. (ofc notification is not added yet) Right now you can manually set if it will notify you or not.
only "ignore-update" will be modified runtime. And yes it was my intention to revert it to default once user updated the addon.
I don't think it's a good idea to store this in the xml because it will get overwritten every time the plugin is updated (because the .meta would be in the same zip as the new plugin). The xml should only contain values that are not changing at "runtime" of the plugin or user settings, it should be deployable as part of a plugin update.
Maybe you could support it yourself without add-on devs' help by adding a button to each add-on page that auto-generates the manifest file. Then users who want to use the "updater" plugin could download the file using the button and put it in the folder and add-on devs won't have to include it to their add-ons.0_0 this is brilliant idea. I need to include a tutorial message for the user though. but it could be done.
Although addon devs need to update the versions properly through the dashboard.
Yes, that would be the only thing add-on devs need to take care of to make this feature working. Then all add-ons will become "supported add-on" as long as they get posted on the add-ons page. The only thing missing is how to handle add-ons included in the MB installer. This part will need add-on devs' (or Steven's) help. The meta files for those add-ons will need to be included in the installer to notify users what add-ons need to get updated even after fresh installation if they have installed the updater plugin. How about using a single fixed location for storing all meta files? Maybe it could use something like "MusicBee\Plugins\Meta" for all meta files for every kind of add-ons including the ones included in the installer. Then the updater plugin could also help to download and update the meta file when the user updates an add-on using the plugin.
plugin must search for multiple metadata files for the same add-on, compare their last changed date and choose the latest metafile, if metadata files may be placed in any subfolder of 'musicbee' folder. i mean that there may be situation when .meta files are duplicated (i.e version info is different, but all other meta-tags are the same). i would generate .meta files for all available add-ons, include them into update notifier package and install them to 'musicbee\meta' or 'musicbee\plugins\meta' folder on update notifier installation.
C:\Program Files (x86)\MusicBee\PluginsC:\Users\AvikB\AppData\Roaming\MusicBee\Plugins\C:\Users\AvikB\AppData\Roaming\MusicBee\MetaSince the addon updater also looks for unsupported addons, it does this by looking for "mb_*.dll" and "xml/xmlc" file. and checks if the same file name but with .meta extension But this ensures that the meta file MUST have the same name as the addon. Only difference should be the extension. So for example if an addon is named "mb_TaskbarTidbit.dll", the meta file name must be "mb_TaskbarTidbit.meta".i dont see any problem with this.
Also right now if you use "add plugin" option from musicbee and select a zip file that has a plugin and a meta file, it stores everything in a flat directory. Steven needs to add some functionality to store the meta file in a separate directory like the one i said above.i hope Steven is ready to slightly improve mb to support this.
@boroda74 i am not going to use the last udpdated date for compare, but i am planning to use the addon version for this. This gives the devs more control. The last updated date is not controllable, and not suitable for this sort of purpose.i agree, its better solution.
As for duplicated meta file, if you use MusicBee's inbuilt "add plugin" option, it should be dealt by MusicBee. MusicBee should aslo replace the meta file with the new meta file in the zip
One thing i don't like about MusicBee is the plugin folder structure. Right now i am working on a Web UI for MusicBee and it has several .dll files and it all clutters the plugin directory. Maybe Steven can move them to a subfolder when using the "add plugin" option.this had been asked many times. its not the problem to install plugin in own subfolder. the problem is that mb wont recognize or use such plugins. hope support for this will be added eventually.
(https://i.imgur.com/CUM65Tv.png)
p.s. ofc right now only main plugin .dll may be placed to 'plugins' folder, while all other libs/resources may be placed to some subfolder, but it will much harder for devs to load dynamic libraries in this case (.net will not be able to load them automatically).
this had been asked many times. its not the problem to install plugin in own subfolder. the problem is that mb wont recognize or use such plugins. hope support for this will be added eventually.:'( I think by default when using the add plugin dialogue MsuicBee should the plugin under the same folder name as the plugin itself. For example. "mb_TaskbarTidbit.dll" should be placed under "mb_TaskabrTidbit" folder. and then place the dll and other dependencies inside that directory. It will be much easier to organize and also it remove the biggest issue that is the same dll can be included in multiple plugins.
For example. "mb_TaskbarTidbit.dll" should be placed under "mb_TaskabrTidbit" folder.yes, exactly this had been asked many times not for plugins only, but for theater modes also (obviously skins already can be placed into any subfolder). it would be the best way to organize add-ons. ofc very simple plugins without additional libraries could be placed directly into 'plugins' folder.
One thing i don't like about MusicBee is the plugin folder structure. Right now i am working on a Web UI for MusicBee and it has several .dll files and it all clutters the plugin directory. Maybe Steven can move them to a subfolder when using the "add plugin" option. (https://i.imgur.com/CUM65Tv.png)Just found this.
I am thinking of storing all the .meta file in a single folder. Right now MusicBee stores plugins and skins on 2 different locations. You can manually place the plugins inThis approach doesn't work with the portable MB version. You would need to include a check for the directory MB is installed in.CodeC:\Program Files (x86)\MusicBee\Plugins
But if you use the new "add plugin" option from the plugin dialogue, it gets stored in this directory:CodeC:\Users\AvikB\AppData\Roaming\MusicBee\Plugins\
Since the AppData directory does not require any admin privilage, it is also used by the Windows Store version. Right now the addon updater looks for plugins in both location.
I am planning to use this location to store the .meta files for all addons:CodeC:\Users\AvikB\AppData\Roaming\MusicBee\Meta
MusicBee v3.2.6616.36172 (Win10.0), 19 Feb 2018 13:41:
System.IO.DirectoryNotFoundException: Could not find a part of the path 'C:\Users\*\AppData\Roaming\MusicBee\Plugins'.
at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
at System.IO.FileSystemEnumerableIterator`1.CommonInit()
at System.IO.FileSystemEnumerableIterator`1..ctor(String path, String originalUserPath, String searchPattern, SearchOption searchOption, SearchResultHandler`1 resultHandler, Boolean checkHost)
at System.IO.Directory.EnumerateFiles(String path, String searchPattern, SearchOption searchOption)
at MusicBeePlugin.MainWindow.GetAllAddons() in F:\Projects\VisualStudio\MB_AddonUpdater\MB_AddonUpdater\MB_AddonUpdater\MainWindow.xaml.cs:line 163
at MusicBeePlugin.MainWindow.LoadAddonList() in F:\Projects\VisualStudio\MB_AddonUpdater\MB_AddonUpdater\MB_AddonUpdater\MainWindow.xaml.cs:line 109
at MusicBeePlugin.MainWindow.<ReloadListAsync>d__5.MoveNext() in F:\Projects\VisualStudio\MB_AddonUpdater\MB_AddonUpdater\MB_AddonUpdater\MainWindow.xaml.cs:line 97
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.AsyncMethodBuilderCore.<>c.<ThrowAsync>b__6_0(Object state)AvikB, use mbapiInterface.Setting_GetPersistentStoragePath() to get folder. it will be either C:\users\some user\appdata\roaming\musicbee\ or \appdata\ for portable version.I have not added portable version support yet. I will try to add that later this week.
I realize that this plugin is still in its initial stages, but you'll probably want to include a mb_AddonUpdater.meta file in a future release :POfc, the reason i haven't added it because it is still in development.
An option to include a changelog for a version would be nice, maybe through the website or even parsing a CHANGELOG.md file on github.I can show the readme section that is on the addon page. I can't show changelog since it is not saved.
Would it be possible to integrate a changelog in the addon settings on the website, additionally to readme?An option to include a changelog for a version would be nice, maybe through the website or even parsing a CHANGELOG.md file on github.I can show the readme section that is on the addon page. I can't show changelog since it is not saved.
Would it be possible to integrate a changelog in the addon settings on the website, additionally to readme?Yes, i can add that functionality.
Although addon devs need to update the versions properly through the dashboard.
Yes, that would be the only thing add-on devs need to take care of to make this feature working.
I think i ignored the version change due to the lack of people using it or probably misunderstand it's usage. but yeah going forward only version change will matter.Regarding this, how about treating only an update with a version change as an "update" of the add-on? Currently any changes in the add-on page through the dashboard are counted as an update and those come first as recently updated ones even if there's no changes in the file. If you agree on this, that could be changed regardless of this plugin development.Although addon devs need to update the versions properly through the dashboard.Yes, that would be the only thing add-on devs need to take care of to make this feature working.