No more UPNP client after December Vero V update

There are parts of the DLNA standards which are pretty good like SSDP discovery of DMPs, DMRs, DMSs and DMCs. Where things get a bit askew is in the metadata area where there are a variety of XML tags which can do the same thing and item level artwork is generally proprietary. The good news is that the major media servers like Plex, Mezzmo, Jellyfin and similar have done a pretty good job of standardization on tags but they aren’t 100%.

The Kodi on Android could be an SSDP discovery issue if Kodi isn’t seeing the servers at all. There are other UPnP/DLNA apps for Android. I don’t know if the server you are using has an Android app. The others mentioned above all have Android native clients, as well many folks like the Bubble UPnP Android app. For Apple there are a number of UPnP native clients.

Thanks,

Jeff

Kodi is aware of the server, you can actually even succesfully browse the upnp source to select items to add to the “Videos” section, and it even sees all the files and folders totally fine to browse that way. The issue comes only once you’ve added it to Videos permanently and then you go back to select it to play something. What is sees then, is nothing at all.
So there’s something different in the way it’s browsing for the UPNP server discovery, compared to the way it’s querying for the actual Videos playback code.

1 Like

Hi, same issue is in Vero 4K+. But issue isn’t in December version of OSMC but issue is in OSMC skin. Other skins shows movie files over uPnP.

I submitted issue on GitHub - December version of OSMC Skin don't shows media files over uPnP · Issue #471 · osmc/skin.osmc · GitHub

1 Like

Github is only for confirmed bugs, you should first share here debug logs showing the different behavior between skins. As it is working here:

I spent some time looking at this. It definitely is an OSMC skin or UPnP XML parsing issue. The problem is only with the OSMC skin. In debug mode I see it pull the items from the server but there isn’t enough debugging info to say whether it is an XML parsing issue or a skin display issue of the XML. I don’t see the issue with other skins and the December update. The August update and the OSMC skin work fine rendering UPnP content, as others have indiacted.

Also the Mezzmo Kodi addon works fine with the OSMC skin and the December update, I tested it with Mezzmo, Plex and Jellyfin. The reason it operates differently is that it has its own XML parsers and renders differently within Kodi.

Thanks,

Jeff

2 Likes

Here are my debug logs. I have done nothing here other than:

  • Attempt to browse to Gerbera source previously being used (it’s empty now)
  • Add a new source, browsing to the Gerbera source and adding it again under another name
  • Attempt to browse to the Gerbera source under the new name (it’s also empty)

https://paste.osmc.tv/ulecomijak

This all worked fine with the 2023-08 build but broke immediately when 2023-12 was installed.

I changed to the Estuary skin and everything immediately began working again.

1 Like

I assume enable UPNP specific logging?

I am lost here, which UPNP server did you test against? As you can see I tested against Jellyfin and it is working with the OSMC skin.

I redid the testing with UPnP verbose enabled. UPnP is very verbose but nothing stood out other than an occasional message:

[Warning] CGUITextureManager::GetTexturePath: could not find texture ‘noop’

I tested Jellyfin, Mezzmo and Plex. All behaved the same, no contents displayed when browsing the servers using the OSMC skin. Using Confluence or the Mezzmo Kodi addon with the OSMC skin are fine.

Here’s Jellyfin with both skins.

Jeff

That is really odd as it is working fine here, maybe different Jellyfin version?

Ok, I was just able to replicate it in another window totally unrelated to UPNP so I think we might have been looking in the wrong area.

I have this issue with Serviio. And I tested Mezzmo, Emby next. All servers has same issue.
But I installed Jellyfin for end and thats work fine.
All server in last versions.

Perhaps. I have Jellyfin setup as a server for another server behind it, in this case a Kodi UPnP server. This is part of my test environment for testing / developing the Mezzmo Kodi addion with other UPnP servers. I don’t run Jellyfin natively with it hosting media internal to Jellyfin.

Thanks,

Jeff

I presume the Mezzmo testing was with Kodi native UPnP browsing with a Mezzmo server leveraging the OSMC skin and not with the Mezzmo Kodi addon, which should work ?

Thanks,

Jeff

Yes, I don’t had using Mezzmo Kodi addon.
Mezzmo used much more CPU sources - approximately 50 %. I uninstalled it and installed Jellyfin wich works now.

I’d need to know more to understand the 50% usage. I suspect that was either active playlists or transcoding when it shouldn’t. With Kodi there shouldn’t be any transcoding and you can disable it on a client-by-client basis in the server. You can see with this performance stress test that the CPU is only running at 14% while serving 6 streams and doing a 10TB dick copy in the background.

If you want to investigate this more, we can take it over to the Mezzmo support forums.

Thanks,

Jeff

It was file ffmpeg.exe. Transcoding was disabled. And this process had running in time when I didn’t had playing any media file.
I uninstalled Mezzmo and I using Jellyfin now.

Ok. Since it was ffmpeg that is likely due to chapter preview thumbnails being enabled and Mezzmo was going through your media to create the chapter images since this was likely after adding new media to your Mezzmo library. If you have a number of large full bitrate Bluray rips or similar this can take some time to create them since it has to read your media files to find the images for each chapter.

I disable that feature and don’t use chapter preview thumbnails. I presume there was a system task running in the status window ?

Thanks,

Jeff

Maybe I hadn’t disabled this feature, I don’t know anymore.

It’s enabled by default and most people don’t disable it until they see the issue. This is common.

Thanks,

Jeff

1 Like

Hey, there… The responsible skinner here. As it seems, this is indeed a skin related bug that I can reproduce here - although I don’t use UPnP plug-ins.

Before I offer a fix, I’d like to be sure I do cover all cases that I can’t really test here. To be able to do that, I’d appreciate your help. :slight_smile:

First, please enable the skin debug labels in the OSMC Skin: go to the skin settings where you’ll find this setting (Settings → Interface → Skin → Configure Skin → Backup/Reset → Debug Labels) and enable it. Then navigate back to the folders that you encountered the issue with and take screenshots of some of them with skin debug labels enabled. :+1:t2:

With the help of those screenshot I can figure out which (undocumented) content types I’ve missed to cover in the skin - that’s the reason why some windows are staying empty.