No more UPNP client after December Vero V update

Help and Support
1

Hi all.
New user of a Vero V here. Couple of issues. First off all was working great till I did the December upgrade … and now I get a blank screen when trying to browse my DLNA server… No response, no navigation options, just blank. This is different from what happens when the DLNA server is disabled by the way, which suggests it’s not a network problem … (and other internet stuff still works). I can login over ssh for example …

So, I enabled some debug logs but maybe not the right ones I got the following in temp/kodi.log : the UPNP client isn’t failing by the look of it it’s just going nowhere. Perhaps this isn’t the right debug logs … let me know.

Note also that reboots don’t change the behaviour, the DLNA server is working fine for all the other clients in the network, and redefining the DLNA server in Vero (adding a new one on the same address) doesn’t change the behaviour either.

The DLNA server is a Debian/Stable box running Gerbera. It’s not been changed.

T:28963 debug : HandleKey: return (0xf00d) pressed, window 10025, action is Select
T:28963 debug : CGUIMediaWindow::GetDirectory (upnp://d4786023-ec13-4b4f-9f16-42bf5b01a218/)
T:28963 debug : ParentPath = [sources://video/]
T:29099 debug : Thread waiting start, auto delete: false
T:29099 debug : Thread waiting 3555717376 terminating
T:29101 debug : Thread BackgroundLoader start, auto delete: false
T:29101 debug : Thread BackgroundLoader 3675070720 terminating
T:29005 debug : Thread JobWorker 3877630208 terminating (autodelete)
T:29006 debug : Thread JobWorker 3869237504 terminating (autodelete)
T:29004 debug : Thread JobWorker 3903836416 terminating (autodelete)
T:29036 debug : Thread JobWorker 3616321792 terminating (autodelete)
T:28963 debug : ------ Window Init () ------

As another aside, I seem to have a compatibility issue with an external drive I tried to install. Looks like the kernel on the Vero is a 4.9, and there’s a lack of support for some XFS filesystem options.

[93477.593327] XFS (sda1): Superblock has unknown read-only compatible features (0x8) enabled.
[93477.593725] XFS (sda1): Attempted to mount read-only compatible filesystem read-write.
[93477.593727] XFS (sda1): Filesystem can only be safely mounted read only.
[93477.593743] XFS (sda1): SB validate failed with error -22.

I imagine there is a mkfs option I can tweak and recreate the external filesystem without the unsupported feature. Anyone have the exact feature to disable to hand?

So that’s another little thing. This hasn’t ever worked since getting the Vero V, obviously… Interestingly the Vero package sets don’t seem to include mkfs.xfs otherwise I’d just have redone it myself …

One final comment. When UPNP browsing worked, it seemed to take quite a long time to start playing some files. Maybe the files themselves … but they play fast on other devices so I am inclined to think it’s the OSMC stack…

Prior to this upgrade, it was working great. One of the few devices that will output proper Full HD 3D from an MKV file with MVC video inside. Nice!

1 Like
2

If I browse for a new UPNP server, it locates my server fine, and I can browse content. It just won’t show up in the UI when browsing under “Videos”…

3

Some logs might provide some insight regarding DLNA not working. We haven’t made any changes to Kodi or OSMC that should impact this behaviour.

Regarding XFS - I don’t include most mkfs tools by default in OSMC but suspect the necessary tools are in Debian’s APT repositories. You could try something like sudo apt get install xfs.

We plan to update Vero V to the 5.15 kernel in the near future. This will have improved XFS support.

4

Did you add it as a source?

Sam

5

Yes added it as a source and it behaves like the old one did.
I’ve enabled debug logs for UPNP and it’s now producing copious output … where to upload to?

6

Use MyOSMC - Log Uploader and share the URL

1 Like
7

I’ll take a look at doing that now it’s accruing upnp logs. However, I have only had the thing five minutes really so is there a “full reset” that I can do to remove any chance of some setting somewhere getting in the way?

8

Well a total full reset would require a reinstall via USB Stick.
A nearly full reset can be done via Settings → MyOSMC → Updates → Manual Controls → Reset Kodi on next reboot

9

Well, I might give this a try. Have to say I wonder if this is an incompatibility between gerbera 1.12 and the upnp libraries in OSMC though. I’ve just refreshed the config on gerbera and still nothing changed.

10

Well, case proven … kodi reset, re-add the UPNP server … no change. I’ll get some debug logs sorted.

11

2023-12-16 11:39:41.221 T:2752 error : GetDirectory - Error getting upnp://d4786023-ec13-4b4f-9f16-42bf5b01a218/75662/

This may be relevant. I also see this:
2023-12-16 11:39:41.184 T:3377 info : [neptune.http]: requesting URL http://192.168.10.10:49152/upnp/control/cds
2023-12-16 11:39:41.185 T:3377 warning : [neptune.http]: NPT_CHECK failed, result=-20302 (NPT_ERROR_EOS) [(stream.ReadLine(line, NPT_HTTP_PROTOCOL_MAX_LINE_LENGTH))]

I wonder if this is indeed HTTP max_line_length related.

12

Hmm, what’s interesting is that I now have a single video listed under one saved UPNP listing for this server. Just one video out of over 1200. Create another duplicated listing on the same UPNP server and there’s no content at all under that one.
I went and configured SMB instead, which is busy indexing all my content as I speak. I remember now how unintuitive all this stuff is.

13

If you want to look at a more robust UPnP / DLNA solution than what comes native in Kodi, you are welcome to try out the Mezzmo Kodi addon. While it is designed to support Mezzmo DLNA servers it has support for many other UPnP / DLNA servers including Plex, Kodi etc… I author the addon but haven’t tested it with the server you are running but it should be fine.

The Mezzmo Kodi addon has its own discovery mechanism and will discover all UPnP / DLNA servers on your network. No sources or similar required in Kodi. It has a full UPnP debugger so we can see exactly what your server is sending for troubleshooting.

Here’s the Getting Started Wiki page, in case you are interested.

Thanks,

Jeff

14

I am having the same issue. Gerbera is the UPnP server. Everything was working fine immediately before the update, and after the update it’s impossible to browse a UPnP source, the browse list immediately returns empty.

I was only able to play a video by adding a “new” source, browsing into the Gerbera service all the way to a leaf directory and directly adding that leaf directory into Videos, at which point I could play the videos it directly contained. I have removed and re-added the UPnP sources in the UI, restarted Kodi, rebooted, no effect. The only thing that changed from the working to the non-working state is that I accepted the 2023-12 OSMC upgrade.

I will upload logs next time I get a chance but this problem should not be hard to reproduce, it’s really a clear A/B signal.

15

Does the most recent Kodi v20 on other platforms display this behavior or is their something specific to just OSMC?

1 Like
16

I don’t have another kodi to compare, but certainly all my other devices can still browse the gerbera service succesfully, including stuff like my ancient panasonic plasmas with their horrible old slow UI.

17

Try a Kodi for a desktop distro. The one for Windows should be up to date, Linux distros may lag but will likely have similar dependencies to OSMC’s Kodi.

18

You don’t have a device running Android, iOS, Windows, OSX, etc. that you can install Kodi on and see if it also has this issue or not?

I’m not familiar with this software but I poked around a little in the documentation and saw that they are doing client detection. Perhaps it is seeing this client different than it had been and changed how it is trying to interact? If so there is a way to change this behavior on your server…
https://docs.gerbera.io/en/stable/supported-devices.html

19

DLNA / UPnP is based upon a client talking to a server and so with the millions of clients and thousands of servers, there are bound to be incompatibilities. There are protocols and specs such as SSDP, SCDP and more which allow information to be passed between a client and a server to address things like the capabilities, services, administrative information and more including artwork / icons.

Even with this issues can arise between the client and the server. To address this there are two typical approaches. First on the server side, there is often a manual option to define a specific client type if something fails in the discovery process. The Mezzmo server, for instance, has over 360 profiles to help match the server to almost any client. In addition it has many customizations beyond the standard profiles. Other servers handle it differently and some not at all.

On the client side the client can adapt to the XML information presented by the server. This is where I spend a bit of time adapting the Mezzmo Kodi addon to various UPnP servers. It’s also why I added the server response logging to help me troubleshoot specific server responses. I can see exactly what the server is handing back.

Sometimes the issue might be a particular field may not show up in Kodi like genre. I find that the UPnP server coder chose a slight variation on the XML tag for responding with the genre information. Others the server software doesn’t a specific set of data with any XML tag. For example I’ve tested some where the server sends no actor / actress information. To me that is a brain-dead server and of minimal use.

Anyway, I am happy to help here.

Thanks,

Jeff

1 Like
20

What a mess…! Isn’t this what standards are supposed to fix! lol
I did try Kodi on android and it didn’t want to talk to any UPnP servers at all. I didn’t find the time to prod it further yet.
Interesting point on the gerbera client detection, that might be worth me throwing in a change to experiment with. I would guess that OSMC is being detected as a generic player, whilst my panasonic devices and bubble upnp etc have dedicated profiles.