search

masmu / pulseaudio-dlna

A lightweight streaming server which brings DLNA / UPNP and Chromecast support to PulseAudio and Linux
GNU General Public License v3.0
1.25k stars 162 forks source link

Device discovery very slow (Yamaha RX-V573) #125

Closed itzoke closed 9 years ago

itzoke commented 9 years ago

Discovery of the above mentioned device is very slow (minutes). It will not be added to the devices.json file when --create-device-config or --update-device-config is used as arguments to pulseaudio-dlna. There doesn't seem to be a timeout option usable with these two arguments.

Executing the following works like a charm and the device is added instantly:

pulseaudio-dlna --renderer-urls http://10.10.0.69:8080/MediaRenderer/desc.xml

A log is available here: http://sofia.valkyr.se/pulseaudio-dlna-render-url.log Another log when it was discovered some time after pulseaudio-dlna was started is available here: http://sofia.valkyr.se/pulseaudio-dlna.log Both logs where generated with --debug 2>&1 |tee

Just let me know what more info you need and I shall provide.

masmu commented 9 years ago

Did you install from a package or did you clone from git?

itzoke commented 9 years ago

Clone from git.

masmu commented 9 years ago

Could you do a git pull and try the latest master again? Which distro are you using?

masmu commented 9 years ago

Btw, are you using a firewall / iptables?

itzoke commented 9 years ago

I will do that as soon as I get home (approx 3 hours).

Running Debian sid and the only iptables rule is related to ssh as far as I remember. Will double check that as well.

masmu commented 9 years ago

Al right. If you block incoming connections make sure you opened 8080/tcp and 1900/udp. As I have seen in the logs, 8080/tcp should be open as you were able to stream to the yamaha device. Also 1900/udp seemd to be open since your Chromecast was discovered.

When you start pulseaudio-dlna it sends a specific multicast message which makes your devices respond. But it will send this message just at start up because new devices will send those responses on their own and they do this in general in specific time intervals. I assume the yamaha devices was not discovered at start up (for whatever reason) but later when the device sent a message by itself. That's why it took so long to discover it. Since multicast is unreliable by nature this might be a case where the device it not getting discovered. How are the devices connected to you LAN? Wifi? Cable? That chance is much higher when those are connected via Wifi. Is your network special in some regards? Like something else than a router and the devices connected via Wifi or cable? Wifi extenders perhaps?

I am not wondering about the device not getting added to the devices.json, since it could not get discovered in a 5 second time period.

Does the Chromecast always get discovered?

itzoke commented 9 years ago

Same result after git pull.

No rules at all in iptables. Both the chomecast and the Debian laptop has been on wireless and the Yamaha receiver is connected via cable. I just tried hooking the laptop via cable and it's still the same.

The Chromecast always gets discovered.

masmu commented 9 years ago

Lets check if that has something to do with my new detection mode. Please do a 

git checkout 0788a6c604c841fc5560a2c542edaf8a39888a59

and try again.

masmu commented 9 years ago

Btw, are you familiar with git?

itzoke commented 9 years ago

I'm familiar with the basics. I have not used the branch functions but it's on my TODO list.

masmu commented 9 years ago

Ok, no problem. Then I will be a little bit more detailed when giving instructions. So, does the old version work?

masmu commented 9 years ago

Is there a SERVER mode you can the device set to? What firmware is running on the Yamaha device? I am currently googling around and it seems that Yamaha devices have issues not being found when not running the latest firmware.

itzoke commented 9 years ago

When you say the old version, which one is that? The only problem is that the device takes a very long time to discover. Other than that it works like a charm. Using the NET button on the remote I can switch between SERVER, NET RADIO, and Air Play. SERVER is the mode I've been using.

Actually did a firmware upgrade on the device last night. Not sure how to get the current fw version from the device.

itzoke commented 9 years ago

Just found it. It says 1.14. Trying to run the update option from the menu again to see what happens.

masmu commented 9 years ago

Change to the directory you cloned the repo to and do:

cd <git-repo>
git checkout 0788a6c604c841fc5560a2c542edaf8a39888a59
make
bin/pulseaudio-dlna

The latest firmware for that device is 1.16. Quoted from official changelog:

This firmware includes the following improvements.

  1. Improves connectivity and stability with AV Controller App
  2. Improves DLNA network function stability
  3. Other bug fix
masmu commented 9 years ago

Btw, is there an Android phone around? If yes, you could install BubbleUPnP (free) and see if this is able to discover the device.

itzoke commented 9 years ago

Re-ran the network update on the device and it still says 1.14. Did you happen to find where fw 1.16 can be downloaded?

Still the same after checking out the older version. Not discovering the device at startup.

BubbleUPnP did not discover the receiver on start.

masmu commented 9 years ago

I am glad that also BubbleUPnP fails. So, it is very likely that it is a firmware problem, since BubbleUPnP is really excellent.

I found it on the Yamaha Website. But check that twice, as this is your device! :wink:

itzoke commented 9 years ago

FW is now 1.16 on the receiver. With the checkout you mentioned before it now gets detected at once.

I also tested after running git checkout master; make after which it is not detected at startup.

Some notes on the update in case someone else need to do this. I had some problem getting the update to run from USB as instructed in the update guide. It turned out that the receiver did not like a USB-stick with a partition table. So I had to create the FAT system on the device directly using mkfs.msdos -I /dev/sdX. After that the update procedure worked.

itzoke commented 9 years ago

UPDATE: It seems that I was just lucky right after the update. I tried two times and it got detected at once. However, when I try it again it doesn't get detected at startup anymore.

masmu commented 9 years ago

The following sounds stupid, but try running pulseaudio-dlna. Even when it does not get discovered just let it run. Unplug the ethernet cable at the Yamaha reciever and replug it. Was reported by many people to work for them... until Yamaha releases a proper firmware.

masmu commented 9 years ago

Does that work?

masmu commented 9 years ago

There is one more thing: Try to set your device to SERVER mode. I had an issue with another Yamaha user where the remote controlling of the device failed if another mode was set. But it always worked when set to SERVER mode. Discovering was always fine, though.

itzoke commented 9 years ago

I will try that tomorrow morning (Central European Time ) and report back.

masmu commented 9 years ago

I have fixed a bug which could possibly caused the issue. But since BubbleUPnP didn't find the device either, I don't know if it solves it. But it is worth a try:

cd <git-repo>
git checkout feature/ssdp-listener
git pull
make
bin/pulseaudio-dlna
itzoke commented 9 years ago

Replugging the cable seems to work. I'm guessing that the device sends a broadcast when the interface comes up.

The feature/ssdp-listener checkout only results in that neither the RX-V573 or the Chromecast gets discovered at startup. It does detect the RX-V573 when the cable is replugged.

I've done some more testing and it seems that the 0788a6c604c841fc5560a2c542edaf8a39888a59 is working. I've now started it 5-7 times and it gets detected at startup every time. Switching to master and the discovery fails at startup. Switched back to 0788a6c604c841fc5560a2c542edaf8a39888a59 and it works again. Last time I tried it failed after testing master. This does not seem to be the case now as I've restarted pulseaudio-dlna several times with successful discovery every time.

masmu commented 9 years ago

Replugging the cable seems to work. I'm guessing that the device sends a broadcast when the interface comes up.

Correct. People reported that you achieve the same when using the web interface and just hitting the apply button in the network section. But just a workaround.

Please use the feature/ssdp-listener for further testing. Your detected host ip is now used for socket binding. The one which is also in the logs.

11-13 13:16:59 pulseaudio_dlna.application                    INFO     Using version: 0.4.6+git-4ae75b27602dff7d61027665e9be8e869fd5ca55 (ssdp-listener)
11-13 13:16:59 pulseaudio_dlna.application                    INFO     Using localhost: 192.168.1.5:8080

Regarding to your logs, nothing you should care about. But if your computer has multiple interfaces there is a chance that the socket was bound to wrong interface.

Besides that I have created a few new flags to easily adjust some settings regarding discovery.

Please play around with those values a little bit and see what it does. The bug i was speaking of created 3 sockets all listening for devices and therefore it might be that some responses were received by the wrong socket. On the other hand, every socket requested the devices 5 times. So, 3 * 5 = 15 discovery packets were sent. So, If your wifi suffers from high packet loss it might be a good idea to largely increase --ssdp-amount.

itzoke commented 9 years ago

I've been playing around with feature/ssdp-listener and I have no luck in getting the RX-V573 to be detected at startup of pulseaudio-dlna. It is also struggling to discover the Chromecast, which it always discovered in the other versions.

I'm currently running both the laptop and the RX-V573 on wired LAN to avoid potential packet loss over wifi.

masmu commented 9 years ago

Could you disable iptables completely for testing purposes and restart? I just wanna make 100% sure that this is not a firewall issue. I really don't get why it is working here flawlessly and your devices are not discovered at all.

The major difference between these 2 versions is that the old one uses a random source port to query for devices. The new one binds to udp/1900 for that. I changed that because of people using iptables and they were not able to add a proper rule because the source port was choosen randomly. Are there other local applications using port udp/1900?

fuser 1900/udp

will print you the process ids of processing using udp/1900.

What you also can check: Uncomment line 53 sock.bind((self.host, self.SSDP_PORT)) (or delete it) in discover.py, save and restart pulseaudio-dlna. After that use the --create-device-config flag (that module is just used there). That is pretty much like the old version did work.

itzoke commented 9 years ago

Iptables has already been disabled.

It seems that the Chromecast stops being detected after a couple of restarts within a short period of time. I would guess that there is some kind of limit in the Chromecast causing this.

fuser 1900/udp shows no running processes unless pulseaudio-dlna is running.

Commenting out sock.bind((self.host, self.SSDP_PORT)) results in the RX-V573 and the Chromecast being added to devices.json. However, when I started pulseaudio-dlna shortly after that no devices were discovered during startup.

masmu commented 9 years ago

Sounds good. I know this is just working for the --update-device-config and --create-device-config, but that is progress. So, this was kind of expected and is fine. Now I have a point to start from. The real question is, why does it fail when binding to a specific port?

I have some ideas regarding to that... Sadly I have to do it tomorrow. So, please stay tuned.

Am 13. November 2015 18:47:17 MEZ, schrieb ltzoke notifications@github.com:

Iptables has already been disabled.

It seems that the Chromecast stops being detected after a couple of restarts within a short period of time. I would guess that there is some kind of limit in the Chromecast causing this.

fuser 1900/udp shows no running processes unless pulseaudio-dlna is running.

Commenting out sock.bind((self.host, self.SSDP_PORT)) results in the RX-V573 and the Chromecast being added to devices.json. However, when I started pulseaudio-dlna shortly after that no devices were discovered during startup.

Reply to this email directly or view it on GitHub: https://github.com/masmu/pulseaudio-dlna/issues/125#issuecomment-156499158

itzoke commented 9 years ago

Sounds good. I will most likely be afk for most of the time during the weekend but I will try to check in once in a while and answer any questions you may have.

masmu commented 9 years ago

I have updated the branch. Could you please do the following:

cd <git-repo>
git checkout feature/ssdp-listener
git stash #will remove the code changes you made and save those in the stash
git pull
make
bin/pulseaudio-dlna
masmu commented 9 years ago

If that does not work change the line 47 in discover.py from USE_SINGLE_SOCKET = True to USE_SINGLE_SOCKET = False and try again.

itzoke commented 9 years ago

No luck either with True or False value of USE_SINGLE_SOCKET.

Commenting out sock.bind((host, self.SSDP_PORT)) on line 80 results in the RX-V573 being added to devices.json.

masmu commented 9 years ago

Whats about binding it, but using a different port. sock.bind((host, 9200))?

itzoke commented 9 years ago

I changed line 80 to each of the following sock.bind((host, 9200)) and sock.bind((host, 9100)). Both alternatives seem to work regardless of True or False setting of USE_SINGLE_SOCKET. Also tried port 1901 and it works. Port 1900 does not work for some reason.

masmu commented 9 years ago

So, i guess if you are using sock.bind((host, 0)) (zero selects a random free port) it also works?

itzoke commented 9 years ago

Yes, that works. Guessing it will work as long as the random port isn't 1900.

masmu commented 9 years ago

Ok, I guess the way to go is implementing a flag for people using a firewall and therefore must be able to use a specific port. All others should be fine with using 0.

masmu commented 9 years ago