Crash on OpenBSD

[vext01]

$ ~/.local/bin/nanodlna list
nano-dlna log will be saved here: /tmp/tmp02_tdvqe/nanodlna-2021-10-08_11-36-16.log
Traceback (most recent call last):
  File "/home/edd/.local/bin/nanodlna", line 8, in <module>
    sys.exit(run())
  File "/home/edd/.local/lib/python3.8/site-packages/nanodlna/cli.py", line 150, in run
    args.func(args)
  File "/home/edd/.local/lib/python3.8/site-packages/nanodlna/cli.py", line 55, in list_devices
    my_devices = devices.get_devices(args.timeout)
  File "/home/edd/.local/lib/python3.8/site-packages/nanodlna/devices.py", line 77, in get_devices
    s.setsockopt(socket.IPPROTO_IP, socket.IP_MULTICAST_TTL, 4)
OSError: [Errno 22] Invalid argument

Any ideas?

[gabrielmagno]

Unfortunately I have never tested nano-dlna on OpenBSD.

I have created a new branch (bugfix/openbsd) to test some fixes. First, let's see if the source of the problem is simply the command to set the TTL.

@vext01 would you mind cloning this new branch, installing and testing it?

git clone https://github.com/gabrielmagno/nano-dlna.git
cd nano-dlna
git checkout bugfix/openbsd
sudo python setup.py install

Then try doing a nanodlna list again.

Thank you!

[vext01]

Hi,

Thanks for looking into this!

I didn't want to write to /usr/local, so I just did pip install --user .. Shouldn't make any difference I think.

Anyways, now we have no crash, but it doesn't see any devices:

$ nanodlna list
nano-dlna log will be saved here: /tmp/tmpwha95f37/nanodlna-2021-10-18_16-16-30.log
$

In the log file:

[ 2021-10-18 16:19:33,945 ] INFO : Scanning devices...
[ 2021-10-18 16:19:38,954 ] INFO : Number of devices found: 0

There should be two render devices. gupnp-av-cp can see them.

[gabrielmagno]

Thanks for testing it for us @vext01 !

I didn't want to write to /usr/local, so I just did pip install --user .. Shouldn't make any difference I think.

Perfectly fine!

So, after removing the TTL line the crash disappeared. That's good to know, because now I will try to figure how to set the same thing in OpenBSD.

But first, let me just try to understand why your render device dit not appear.

A question about your local network setup: are the computer (where you are running nano-dlna) and the render device (where you want to play the video) connected directly to the same router/switch/acces-point in your network, or are they connected into different router/switch/acces-point (meaning that they would be separated by at least 2 "hops" of distance)?

Also, would you mind sharing the output of the following command:

gssdp-discover -n 10

Feel free to remove or redact from the output any personal information that you are not comfortable sharing (e.g. IP adresses).

[gabrielmagno]

Forgot to mention, but gssdp-discover is part of the gupnp-tools project (https://github.com/GNOME/gupnp-tools), so since you already have gupnp-av-cp, I believe you will already have gssdp-discover available.

[gabrielmagno]

@vext01 I have added a candidate fix into the bugfix/openbsd.

Can you git pull the branch, reinstall nano-dlna, and check if it works now?

Thank you.

[vext01]

Alas, nanodlna list still returns no devices.

Running with -b, here's the log:

[ 2021-10-20 09:59:29,774 ] INFO : Scanning devices...
[ 2021-10-20 09:59:29,774 ] DEBUG : Configuring broadcast message
[ 2021-10-20 09:59:29,774 ] DEBUG : Sending broadcast message
[ 2021-10-20 09:59:29,774 ] DEBUG : Waiting for devices (5 seconds)
[ 2021-10-20 09:59:34,779 ] INFO : Number of devices found: 0

are the computer (where you are running nano-dlna) and the render device (where you want to play the video) connected directly to the same router/switch/acces-point in your network, or are they connected into different router/switch/acces-point

My network is flat, but involves a mesh network of 2 access points. I don't know if that makes a difference? Regardless running gupnp-av-cp on the same computer does work. The computer I'm running minidlna on is on a wired ethernet connection, and the renderers are on wifi, but the wired and wireless networks are the same /24 subnet.

The two renderers I'm testing with are bubbleupnp on an android phone, and a Hiby R3 Pro.

Interestingly, gssdp-discover -n 10 doesn't find the renderers. I think this is because of:

$ gssdp-discover -n 10
...
Using network interface re0

My system has two ethernet interfaces: re0 and em0. The renderers wouldn't be found on re0 (only on em0). Could it be that the upnp library defaults to the first network interface it finds? Do you need to tell it to scan all interfaces?

FWIW, if I do gssdp-discover -n 10 -i em0, then I see a ton of upnp devices, including ones with the USN suffix: urn:schemas-upnp-org:device:MediaRenderer:1 and with correct-looking IP addresses too.

For example the Hiby R3:

$ gssdp-discover -n 10 -i em0
...
resource available
  USN:      uuid:HiByMusic-XXXXXXXX-XXX-XXXX-X::urn:schemas-upnp-org:device:MediaRenderer:1
  Location: http://192.168.1.2:49153/description.xml

Hope that helps.

[gabrielmagno]

Hi @vext01.

Sorry for the late follow up on this.

I have added a new fix into the bugfix/openbsd. Basically, I bind to 0.0.0.0 by default now (instead of empty string), and also, if a host is provided, use that as the IP to bind.

First try normally as before:

nanodlna -b list

If it does not work, try this (replacing 10.x.x.x by the local network address of the interface em0)

nanodlna -b -H 10.x.x.x list

Could you git pull the branch, reinstall nano-dlna, and check if it works now?

Thank you.