BMT 4.9.8 Released (No Fixes)

[stuckless]

Not much interesting, as far as BMT is concerned. This is really a maintenance release because of a large configuration refactoring that happened in the phoenix apis.

Before I get into those changes, I'll make note that there is one new enhancement in BMT. A SageTV Plugin Browser has been added to the Configuration section. It allows you to browse the plugins, view their images, videos, plugin details, etc. You can also search for plugins as well using the search text text. A feature of the search is that you can pass a search like, 'depends: sagex-api' to get a a list of plugins that depends on sagex-api (or whatever plugin id you pass). The plugin viewer is mostly information at this point.


Now for the phoenix configuration changes. These changes are in 3 areas.

1. Default Fanart location changed
2. Default cache area changed
3. Configurations (ie vfs, mediatitles, etc) can be loaded from a userdata area.

The purpose of these changes is to better facilitate user configurations and plugin contributions to Phoenix. A new directory, SAGE_HOME/userdata/Phoenix, will now be the default location for caches, fanart, and user changes.

Default Fanart location changed
The previous fanart location was STVs/Phoenix/Fanart and now it's userdata/Phoenix/Fanart. You can still use the older location, but I'd recommend, when you get time, that if you are using the old default location, then you move the files to the new location, and then update the fanart folder using the web ui, to use the new location.

Default cache area changed
The old cache area was cache, and the new location is userdata/Phoenix/cache. This means that all cached fanart from the image apis, and cache metadata retrievals will now be in this folder. You may notice a slight performance hit as your plugins rebuild their fanart caches (if they relied on the phoenix image apis).

Configurations (ie vfs, mediatitles, etc) can be loaded from a userdata area.
Phoenix configurations for all aspects of phoenix uses a 3 tier configuration loading mechanism. A System area, User area, and a Plugin area. Typically, you should never edit/add/delete files from the System area, which is STVs/Phoenix, instead you should simply copy/edit the file in the userdata/Phoenix area.

So, for MediaTitles.xml, if you have it in the STVs/Phoenix/scrapers/ area, then you should copy it to the userdata/Phoenix/scrapers/ area.

Similarly, if you've modified or added scrapers to the STVs/Phoenix/scrapers/xbmc/tvfilenames/ (or moviefilesnames) area, then you should copy those to the userdata/Phoenix/scrapers/xbmc/tvfilenames area.

You can hopefully see the pattern. The User area, userdata/Phoenix completely mirrors the structure of the System area, STVs/Phoenix.

As for plugins, if a plugin wanted to contribute a new scraper (as an example), then they'd deploy a file to their resource path area, ie, something like, PLUGIN_RESOURCE_PATH/Phoenix/Configuation/pluginconfig.xml

The configurations are loaded in the following order, System, Plugin, then User. Plugin Configurations cannot replace System configurations, and User configurations can replace anything. ie, as a user, you can override change any aspect of phoenix, but plugins can simply extend it.

While migrating your configuration changes to the userdata area is optional, i'd strongly recommend it. It makes for an easier removal of phoenix (if you have to) while still preserving your userdata files. ie, You install phoenix, and then delete the STVs/Phoenix directory (if sage doesn't do it).

The configuration changes, as mentioned, was refactored this way in preparation for the private beta of phoenix (which hasn't happened yet), since once you get phoenix, you'll probably be configuring menus, views, etc, and I wanted to ensure that you could do that without actually editing the system files.

[JREkiwi]

Originally Posted by stuckless

Configurations (ie vfs, mediatitles, etc) can not be loaded from a userdata area.
Phoenix configurations for all aspects of phoenix uses a 3 tier configuration loading mechanism. A System area, User area, and a Plugin area. Typically, you should never edit/add/delete files from the System area, which is STVs/Phoenix, instead you should simply copy/edit the file in the userdata/Phoenix area.

So, for MediaTitles.xml, if you have it in the STVs/Phoenix/scrapers/ area, then you should copy it to the userdata/Phoenix/scrapers/ area.

Isn't this contradictory?
Configurations (ie vfs, mediatitles, etc) can not be loaded from a userdata area, but copy your MediaTitles.xml to the userdata area, or is there some other mediatitles you're talking about.

Does this update also include the change to requiring phoenix-core for metadata lookup and download?

John

[Spectrum]

Originally Posted by stuckless

Default Fanart location changed
The previous fanart location was STVs/Phoenix/Fanart and now it's userdata/Phoenix/Fanart. You can still use the older location, but I'd recommend, when you get time, that if you are using the old default location, then you move the files to the new location, and then update the fanart folder using the web ui, to use the new location.

I moved my fanart folder to the new location and set the property in the webui. The webui immediately started using the new fanart location, but fanart stopped being displayed in the Sage UI. I created a directory junction (yay Windows 7) from the old location to the new location and Fanart came right back. Don't know if this is related to something in the phoenix core or if it has to do with the Phoenix Fanart Plugin. I tried restarting the service and it had no effect. Want me to turn on logging and send you something?

Edit:
Further testing makes it look like the Phoenix Fanart Plugin is at fault. I removed the directory junction and tried browsing with diamond and fanart showed up as expected. Switched back to stock ui with PFP loaded and no fanart.

[stuckless]

Originally Posted by JREkiwi

Isn't this contradictory?

Typo on my part... the 'not' should NOT be there. ie, all configurations can now be loaded from the userdata area.

Originally Posted by Spectrum

I moved my fanart folder to the new location and set the property in the webui. The webui immediately started using the new fanart location, but fanart stopped being displayed in the Sage UI. I created a directory junction (yay Windows 7) from the old location to the new location and Fanart came right back. Don't know if this is related to something in the phoenix core or if it has to do with the Phoenix Fanart Plugin. I tried restarting the service and it had no effect. Want me to turn on logging and send you something?

Edit:
Further testing makes it look like the Phoenix Fanart Plugin is at fault. I removed the directory junction and tried browsing with diamond and fanart showed up as expected. Switched back to stock ui with PFP loaded and no fanart.

I use the Phoenix Fanart Plugin as well, and I tested this on 2 servers. They both worked in my case, but the plugin did have to rebuild the caches which made the UI a little sluggish the first time I used it.

All fanart plugins use the same Fanart apis to resolve fanart, so I can't really explain why your one plugin would still be looking at the old location, instead of the new location. Did you check the fanart directory setting from the stv ui and see if it was actually pointing to the right location?

[Spectrum]

Originally Posted by stuckless

I use the Phoenix Fanart Plugin as well, and I tested this on 2 servers. They both worked in my case, but the plugin did have to rebuild the caches which made the UI a little sluggish the first time I used it.

All fanart plugins use the same Fanart apis to resolve fanart, so I can't really explain why your one plugin would still be looking at the old location, instead of the new location. Did you check the fanart directory setting from the stv ui and see if it was actually pointing to the right location?

I was watching the caches and it was definitely not slow cause of a cache rebuild, it was not fetching. I checked in the UI (didn't know that property was available in the UI) and it was set as the root SageTV/SageTV directory. Even after I changed it in the UI going back to that property defaults to the SageTV directory. Also changes made in the sage UI don't reflect in the webui.

I changed it to the new location in both places, renamed the directory junction so the old path is non-existent and now things seem to be working. Not sure why changing the properties in one location is not affecting the other, but it's working and that is what matters

[stuckless]

Originally Posted by Spectrum

I was watching the caches and it was definitely not slow cause of a cache rebuild, it was not fetching. I checked in the UI (didn't know that property was available in the UI) and it was set as the root SageTV/SageTV directory. Even after I changed it in the UI going back to that property defaults to the SageTV directory. Also changes made in the sage UI don't reflect in the webui.

I changed it to the new location in both places, renamed the directory junction so the old path is non-existent and now things seem to be working. Not sure why changing the properties in one location is not affecting the other, but it's working and that is what matters

This is a little hard to explain, but I'll give it a shot.

SageTV has the concept of "contexts", where each client and the server has it's own 'context'. Properties that are read/written are done so in a specific context.

So, bmt, does not not have a STV ui, and as such, everything that it reads and writes is done so in the context of the server, which means that its configuration changes end up the SageHome/sage.properties.

Clients (ie, pc clients and extenders) that fetch properties, do so in their own client context. If a client doesn't have a particular property set, then it will automatically go the server's context and resolve the property. This is why when you first install bmt, and you set the fanart directory from the web ui, it's set in the server, and all clients will see that value. BUT, if a client needs to use its own Fanart directory, then it can override the server's default value and use its own value. For example a server may set the fanart to C:\Fanart but a client might use a mapped drive and the client might set the value to f:\Fanart.

When a client changes their fanart location is not reflected in the server's context, but rather that value is stored in the client's properties. This is why a client can have a different value than what is set on the server. Likewise, once a client sets their own value, then any changes to the server's property is NOT reflected on the client.

I hope this helps to understand why a client and server can have 2 different values and why changes to one may not show up for the other.

[Spectrum]

Yep different contexts explains it and makes sense. Good thing to have until it get's in the way Thanks for the explanation and the patience!