[jurialmunkey]

Yep... that was the issue, but i am curious... why this was preventing the info properties to show in MyVideoNav?.
I thought the widget container ID property was required only for the widgets to work. Will i have a problem if I remove it?

TMDbHelper.WidgetContainer property tells TMDbHelper which container ID to do the lookups for (e.g. $INFO[Container(ID).ListItem.Title] etc.).

If WidgetContainer is clear then TMDbHelper uses the container ID of the current viewtype as per <views>. =
If WidgetContainer is set but that ID doesn't exist then there's nothing to lookup so properties are cleared.

In v5+ from my repo, there is now an additional setting you can toggle to make the property on a per window basis:
Skin.SetBool(TMDbHelper.UseLocalWidgetContainer)

Enabling that setting means instead of SetProperty(TMDbHelper.WidgetContainer,ID,Home) you can use SetProperty(TMDbHelper.WidgetContainer,ID) so that each Window has it's own separate WidgetContainer property.
 

What do you mean?. I thought the TMDbHelper.Service method was the best way to go. Or not?

In v5+ there's now two different ways to use the Service. There's the classic property method you're using which outputs to Window(Home).Property(TMDbHelper.ListItem.PROPERTY)

Then there's the new Container Method:
https://github.com/jurialmunkey/plugin.v...ner-method

With the container method, instead of outputting details to Window Properties it sets an actual ListItem directly to a hidden container ID you specify. So for instance
Skin.SetString(TMDbHelper.MonitorContainer,99950)

You then create a hidden list in the background with id="99950" then TMDbHelper will add the details as a ListItem to that list so that you can reference it the normal way instead of window properties e.g.
$INFO[Container(99950).ListItem.Art(poster)]
$INFO[Container(99950).ListItem.Genre]
$INFO[Container(99950).ListItem.UniqueID(tmdb)]
$INFO[Container(99950).ListItem.Property(Genre.1.Name)] etc

Both approaches have advantages and disadvantages. The upside to the container method is that the infolabels match standard infolabel names and the transition between items when scrolling in a list is generally smoother and faster than window properties. The downside is that it needs a hidden container in each window/dialog, and transitions between windows/dialogs are bit janky because it needs to update each container for each window/dialog separately.

IF Window Properties works well for you, then there's no real reason to change - I plan on continuing to support both methods. The change was mostly because I needed something to handle blur/crop in a way where the transition between items in a list was cleaner and smoother.

Sorry for the repeatedly questions but like i said it's been a while and i am trying to keep up with things.

No worries at all! Happy to explain.