Plugin Update Notification/Updater

[redwing]

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.

[boroda]

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.

[AvikB]

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.

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 in

Code

C:\Program Files (x86)\MusicBee\Plugins

But if you use the new "add plugin" option from the plugin dialogue, it gets stored in this directory:

Code

C:\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:

Code

C:\Users\AvikB\AppData\Roaming\MusicBee\Meta

Since 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 is available or not. I don't know if there is another way to do it or not. 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".

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.


@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.
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.

[boroda]

Since 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.
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

i agree, its better solution.

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.

[boroda]

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).

[AvikB]

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.

Lets wait for Steven to shed some light on this.

[boroda]

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.

[AvikB]

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.

Just found this.
https://github.com/Fody/Costura
Basically it automatically merges all the dependencies into one assembly. It works without any configuration. Now my plugin looks like this:


Though having a subfolder structure would be nice.

[Bee-liever]

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 in

Code

C:\Program Files (x86)\MusicBee\Plugins

But if you use the new "add plugin" option from the plugin dialogue, it gets stored in this directory:

Code

C:\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:

Code

C:\Users\AvikB\AppData\Roaming\MusicBee\Meta

This approach doesn't work with the portable MB version.  You would need to include a check for the directory MB is installed in.
Using the last posted version of the plugin with a portable version of MB produces this error:

Code

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)

[boroda]

AvikB, use mbapiInterface.Setting_GetPersistentStoragePath() to get <AppData> folder. it will be either C:\users\some user\appdata\roaming\musicbee\ or <musicbee folder>\appdata\ for portable version.

[AvikB]

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.
Got a little busy with MusicBee WebUI

[frankcreed]

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 

[AvikB]

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

Ofc, the reason i haven't added it because it is still in development.

[derTyp]

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.

[AvikB]

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.