[Martijn]

Well this would be a skin addition only (hopefully) so isn't that decoupled? I mean isn't confluence in the skin repo?

It isn't in repo but can be if we want.

[natethomas]

My understanding is that we've somewhat intentionally left Confluence out of the repo for a few reasons. Bandwidth being a major one. Platform stability being another. With that said, I'm assuming a feature change that purely affects the skin would probably be less negatively viewed than one that affects core.

[Martijn]

i think the problem more lies into the fact that if Confluence is in repo with a higher number and a user starts XBMC and starts it it suddenly gets a black screen and "hopefully" the skin update went fine that he regains the skin again.
So it's more of a fresh install issue. For scrapers and such this isn't as much of an issue as they don't blackout your screen

[Ned Scott]

I thought it was just because we never had a "bug" to fix in Confluence between releases that wasn't tied to a core XBMC change. That skin refresh bug that Martijn mentions sounds nasty, but hopefully that in itself is resolved for Gotham. I imagine that could be an issue for other skins as well?

Plus, it wouldn't really be a feature addition when it comes to skins. I would think it would be more akin to a configuration change? Up to the release managers, of course.

[topfs2]

i think the problem more lies into the fact that if Confluence is in repo with a higher number and a user starts XBMC and starts it it suddenly gets a black screen and "hopefully" the skin update went fine that he regains the skin again.
So it's more of a fresh install issue. For scrapers and such this isn't as much of an issue as they don't blackout your screen

If that is what happens I guess our update/install isn't really doing it proper

I'd expect it to keep using the installed one until the update is downloaded and installed properly? Otherwise this would happen to any other skin when they are updated?

[topfs2]

Plus, it wouldn't really be a feature addition when it comes to skins. I would think it would be more akin to a configuration change? Up to the release managers, of course.

Personally I think this should absolutely be decoupled with the release, that goes for any core-ish addon IMO. That is one of the strongest point of them being addons is so they can be released without core being updated

And we do this for the weather addons which we release with core, they could be updated later, so I see no reason why skin wouldnt' be allowed to do so?

[da-anda]

what happens if Confluence is in Repo, we did an intermediate update so that it is installed in "userspace" and user updates to a newer XBMC version with included new Confluence? Which Confluence version will XBMC use? I assume always the one in userspace which is overriding shipped versions, but we probably should better use the highest compatible installed version (regardless of shipped or userspace)?

[Martijn]

i think the problem more lies into the fact that if Confluence is in repo with a higher number and a user starts XBMC and starts it it suddenly gets a black screen and "hopefully" the skin update went fine that he regains the skin again.
So it's more of a fresh install issue. For scrapers and such this isn't as much of an issue as they don't blackout your screen

If that is what happens I guess our update/install isn't really doing it proper

I'd expect it to keep using the installed one until the update is downloaded and installed properly? Otherwise this would happen to any other skin when they are updated?

It just updates unannounced. It downloads the zip in the background, unzips it and then installs it all without any notifying that it is doing so. So suddenly you have a black screen when it replaces current version. Better would be that for skins we notify the user if he wants to update now. For other addons this is not important and should just beupdated.

what happens if Confluence is in Repo, we did an intermediate update so that it is installed in "userspace" and user updates to a newer XBMC version with included new Confluence? Which Confluence version will XBMC use? I assume always the one in userspace which is overriding shipped versions, but we probably should better use the highest compatible installed version (regardless of shipped or userspace)?

the highest version in userspace is used as it is for all addons. So say we update Confluence for Frodo in repo the user gets this version installed. When he then installs Gotham this version is used as that has a higher version. So in short it doesn't matter where it is installed as long as it has the highest version number.
So this is not only an issue for skins but for others as well. When a users downgrades he is stuck with possible higher versions of addons than the downgraded XBMC can support and is left with broken addons. This has been the issue since the beginning when the repo was introduced.

However this discussion is a little offtopic of what was suggested in the OP

[Ned Scott]

Two more UPnP issues I've noticed:


Sorting no longer works in Gotham:

On the XBMC-"client" side, if I go to Files -> my UPnP server -> Videos -> TV shows (or movies) -> Title -> (or any view, really), I can't sort by year. The option is still there in the lefthand sidebar/blade menu, but it doesn't do anything. It only sorts by name. I've tested different combinations and found this:

Host library v12 -> Client v12 = year is sortable
Host library v13 -> Client v12 = year is sortable
Host library v13 -> Client v13 = year is not sortable
Host library v12 -> Client v13 = year is not sortable



Watched/resume marks not always shown:

I'll have to test this more throughly, because one time I got it to work, but most of the time when going XBMC v13 (host library) to XBMC v13 (client), watched and resume marks won't show in the folder/node you are playing them in. They are recorded on the server side, and if you change to an alternative node it will show you the correct watched or resume marks. When a resume status is set on the server, but is not displayed on the client, XBMC will not ask to resume playback at that point.

Like I said, once it worked and they updated in the same node view as I watched them, but most of the time this doesn't happen. I'll try to isolate the behavior, but I wanted to mention it as it sounds like it might simply not be updating from the server most of the time?

Restarting the client XBMC will also cause the marks to show up.

[Montellese]

Sorting no longer works in Gotham:

On the XBMC-"client" side, if I go to Files -> my UPnP server -> Videos -> TV shows (or movies) -> Title -> (or any view, really), I can't sort by year. The option is still there in the lefthand sidebar/blade menu, but it doesn't do anything. It only sorts by name. I've tested different combinations and found this:

Host library v12 -> Client v12 = year is sortable
Host library v13 -> Client v12 = year is sortable
Host library v13 -> Client v13 = year is not sortable
Host library v12 -> Client v13 = year is not sortable

Should be fixed by ce4cdf6a0e853f97df36a19852065e8e35676c11. I checked the code in Frodo and I can't see how this works/worked as that code hasn't changed in a long time.

[Ned Scott]

Sorting no longer works in Gotham:

On the XBMC-"client" side, if I go to Files -> my UPnP server -> Videos -> TV shows (or movies) -> Title -> (or any view, really), I can't sort by year. The option is still there in the lefthand sidebar/blade menu, but it doesn't do anything. It only sorts by name. I've tested different combinations and found this:

Host library v12 -> Client v12 = year is sortable
Host library v13 -> Client v12 = year is sortable
Host library v13 -> Client v13 = year is not sortable
Host library v12 -> Client v13 = year is not sortable

Should be fixed by ce4cdf6a0e853f97df36a19852065e8e35676c11. I checked the code in Frodo and I can't see how this works/worked as that code hasn't changed in a long time.

Works perfectly! Great work, as always.

[natethomas]

This is an issue I'd like to re-bring up, given recent Play Using discussions on Slack/IRC.

In particular, given that there's evidently a keyboard command to send media to other players already, I'd like to make that command an OSD button.

It seems like the only possible hold-up to doing so would be hesitancy to make a button that sometimes doesn't work (since there won't always be other UPnP players available), so I assume a core change would need to be made to tell the skin whether or not other players exist, then the button could appear and disappear similar to how 3D works right now.

@Montellese or @mkortstiege, either of you guys interested in helping with the underlying code? I'd guess this would be a lot easier than creating something entirely new for the info screen.

[Montellese]

What we would need is

• an info boolean which indicates whether there are any remote players.
  
• an action / builtin that opens the context dialog with the remote players
  

Everything else would be up to the skin.

[da-anda]

instead of a boolean we could maybe also use an integer that holds the number of remote players. That way it can be used as toggle and skins can use it to show extra info

[Ned Scott]

Here's another take on UPnP targeting that might be interesting to consider: http://forum.kodi.tv/showthread.php?tid=234399

I'd still like to see the idea discussed in this thread to come to light, but a "target mode" also sounds pretty useful.