Topic: MC21 on Raspbian disapears from Playing Now list. PCs connect fine. (Read 8928 times)

designmule · « **on:** November 02, 2015, 10:33:10 am »

Hello

Recently I began running JRiver on a pi using Raspbian. My preference is to control the pi as a DLNA renderer either from MC21 running on a Windows box or via JRemote. However, the pi doesn't seem to stay connected the the Windows box (it frequently appears and disappears from the playing now window).

I have a second PC which I use as a DLNA renderer and it stays connected just fine. When the pi was running volumio it stayed connected just fine. I don't think this is a JRiver thing but maybe a Raspbian thing as the other PC works and volumio worked. I installed Samba and Winbond hoping that a more visible pi would stay connected but that doesn't seem to be the case.

I've read the thread about IGMP snooping causing problems. Disabling it on my network did not seem to solve the problem (and I need IGMP on for my DVR to work).

Do any of you pi users have any suggestions?

mwillems · « **Reply #1 on:** November 02, 2015, 10:49:53 am »

Is your pi connected via WiFi? If so can you ping the Pi when it disappears? It may just be a connectivity issue with the Pi's wi-fi adapter (i.e. it may not be getting a good signal).

If you're using wi-fi, try the two tweaks I suggested in this post: https://yabb.jriver.com/interact/index.php?topic=98358.msg682806#msg682806

They produced a much more stable wi-fi connection for my Pi. Far and away, though, a wired connection is much more stable.

designmule · « **Reply #2 on:** November 02, 2015, 10:54:21 am »

Thank you.

My pi is wired. I haven't tried pinging it when it disappears, I will though. It is still visible in the network map on the Windows box when it is not visible in the playing now window.

mwillems · « **Reply #3 on:** November 02, 2015, 02:03:46 pm »

Quote from: designmule on November 02, 2015, 10:54:21 am

Thank you.

My pi is wired. I haven't tried pinging it when it disappears, I will though. It is still visible in the network map on the Windows box when it is not visible in the playing now window.

That's very odd then, I've never failed to see one of my wired Pis in JRiver. I'll be interested to see if you can ping it when it "goes dark."

designmule · « **Reply #4 on:** November 02, 2015, 06:44:59 pm »

Just got the chance to test this. From the windows box I am able to ping the pi by name even when it is not showing up in the playing now window. I also VNC'd into the pi just to double check that JRiver is running, it is. On the pi, under media network I have "Use media network..." checked and under advanced I have only "DLNA Renderer..." checked as I don't think I need any of the other options enabled.

Currently I do not have the pi loading the library from the main server as I prefer to push to it via DLNA. Do you load the library on your pi(s)? I have tried this in the past and felt like the pi connects more frequently but it is not absolute. Additionally, when I ran volumio I only pushed to it.

I hope that no one thinks I am saying snobbily "well volumio could do it, why can't JRiver?" I really only mention volumio because it is sort of a custom distro which I mean more to compare to Raspbian maybe they have more network stuff included or configred.

I appreciate the help and I'm happy to try out any additional suggestions.

Matt

mwillems · « **Reply #5 on:** November 02, 2015, 07:01:32 pm »

Quote from: designmule on November 02, 2015, 06:44:59 pm

Just got the chance to test this. From the windows box I am able to ping the pi by name even when it is not showing up in the playing now window. I also VNC'd into the pi just to double check that JRiver is running, it is. On the pi, under media network I have "Use media network..." checked and under advanced I have only "DLNA Renderer..." checked as I don't think I need any of the other options enabled.

Currently I do not have the pi loading the library from the main server as I prefer to push to it via DLNA. Do you load the library on your pi(s)? I have tried this in the past and felt like the pi connects more frequently but it is not absolute. Additionally, when I ran volumio I only pushed to it.

I do both: I have the pi's logged into the server's library and I push to them via DLNA sometimes. Having them logged in makes them easier to control with JRemote (playback is more responsive), but I do also push to them as DLNA renderers (the two methods aren't mutually exclusive). Once upon a time one of my Pi's had issues when more than one JRiver instance in the house was configured as a DLNA controller. It would go dark like you're describing periodically until I disabled some of the extra controllers, but that Pi exhibited the same behavior with Volumio as with JRiver, so we're probably not seeing the same issue.

Maybe someone else has some thoughts, but it sounds like for whatever reason the multi-cast packets are getting eaten, but other traffic is getting through fine which could be a router issue. Either that or the JRiver instance on the Pi is "freezing" periodically and not responding to network traffic.

designmule · « **Reply #6 on:** November 02, 2015, 07:31:03 pm »

I'll go ahead and have the pi connect to the library and see to what degree that helps.

I felt like disabling IGMP snooping helped (I left it off for 24 hours and the pi was pretty accessible). However, right before I turned the IGMP snooping back on for a 24 hour test the pi disappeared. This led me to believe IGMP snooping is not the issue + I have to have it on or my DVR doesn't work, it and my cable boxes all run over IP (Google fiber) so turning it off isn't a great option for me.

I read that I can test multi-cast on linux by entering netstat -g When I do so eth0 is listed three times. The first address is 239.255.255.250 the second address is 224.0.0.251 which I think is the multicast address and the last is all-systems.mcast.net.

From the Windows box typing in netsh interface ip show joins I get three addresses 224.0.0.1, 224.0.0.252 & 239.255.255.250 the all-systems.mcast.net provided by the pi seems a little out of left field. Maybe that all-systems.mcast.net is the issue. I'll have to look into it. Out of curiosity, if you enter netstat -g on one of your pi(s) what do you get?

mwillems · « **Reply #7 on:** November 02, 2015, 07:38:20 pm »

I get something similar:

Code: [Select]

IPv6/IPv4 Group Memberships
Interface       RefCnt Group
--------------- ------ ---------------------
lo              1      all-systems.mcast.net
eth0            1      239.255.255.250
eth0            1      224.0.0.251
eth0            1      all-systems.mcast.net

JRiver, under services and plugins-->Media Network will show you all the traffic it's sending and receiving so there may be a clue there. Also, you should really run a wireshark trace if you're comfortable with that sort of thing.

Mark_NL · « **Reply #8 on:** November 03, 2015, 02:46:22 am »

Could it be a DNS (cache) problem?

Suggesting this seen the same-like behavior while fiddling around using Wifi and Ethernet at the same time;
due to some mistakes I made the armboard had troubles resolving it’s own hostname.

designmule · « **Reply #9 on:** November 03, 2015, 11:26:32 am »

Quote from: mwillems on November 02, 2015, 07:38:20 pm

JRiver, under services and plugins-->Media Network will show you all the traffic it's sending and receiving so there may be a clue there. Also, you should really run a wireshark trace if you're comfortable with that sort of thing.

I had a chance to look at this briefly before I left for work this AM. I'll have to look more closely this evening. I've run wireshark before but I'm not very familiar with it. Would I run it on my windows PC and look for multicast traffic from the pi?

Mark_NL, thank you for the suggestion. I'm able to ping the pi via DNS name so I think that is sorted out. Am I missing something?

mwillems · « **Reply #10 on:** November 03, 2015, 11:32:47 am »

Quote from: designmule on November 03, 2015, 11:26:32 am

I had a chance to look at this briefly before I left for work this AM. I'll have to look more closely this evening. I've run wireshark before but I'm not very familiar with it. Would I run it on my windows PC and look for multicast traffic from the pi?

You could run it either place or both (it would tell you different info depending on where you ran it).

designmule · « **Reply #11 on:** November 03, 2015, 09:28:31 pm »

I took a look at the traffic under services and plugins-->Media Network and noticed that the time and date on the pi were not correct. Resolving this has kept the pi connected for several hours. I'm not sure that I am ready to say this is resolved but it looks promising. I'll follow up after more time and report the results.

Mark_NL · « **Reply #12 on:** November 04, 2015, 01:48:55 am »

Nice you found the hiccup , and your are right : i can’t think of a scenario where your PI could not resolve it’s own hostname where all other computers can.
(due to the mistakes I ended up with 2 resolv.conf on different locations, one used by eth0 and one by wlan0, in you’re straight forward setup this can’t be the cause)

If it happens again: It doesn’t hurt to try to ping the hostname form the PI or take a look at the DNS registration on the PI (getent hosts yourhostname)

mwillems · « **Reply #13 on:** November 04, 2015, 07:25:20 am »

Quote from: designmule on November 03, 2015, 09:28:31 pm

I took a look at the traffic under services and plugins-->Media Network and noticed that the time and date on the pi were not correct. Resolving this has kept the pi connected for several hours. I'm not sure that I am ready to say this is resolved but it looks promising. I'll follow up after more time and report the results.

The pi doesn't have a hardware clock, so if you haven't set up some kind of external clock synchronization (e.g. NTP) this will eventually become a problem again. I hadn't thought about it because I was fairly certain that the default NOOBS Raspbian install had NTP already setup, but I may be misrecalling.

I'll keep my fingers crossed that solves it!

Mark_NL · « **Reply #14 on:** November 04, 2015, 08:17:42 am »

Is the time zone set according to your location?

designmule · « **Reply #15 on:** November 04, 2015, 09:23:51 am »

I reset my time zone in pi-config (or whatever it's called, I'm at work and don't have access to the pi) and specified NTP servers in North America. The pi stayed connected for several hours but by morning it was no longer connected.

I looked at the SDDP statistics on the pi and saw that at 12:02 it tried to do something (probably it's "I'm here announcement") and it was stuck "processing" so there was no activity for seven hours. The odd thing here is that it said 12:02 PM when it should have said 12:02 AM so the clock is still not right. I rebooted the pi and it connected immediately.

I'm not sure the connection issue is time related but I suspect that it is. I'm pretty sure it is related to SDDP. Next time I am able to check it (either over lunch or when I get home from work) I anticipate that it will be stuck "processing" again at 12 something PM (AM according to the pi).

I'll keep you all updated. I appreciate all the help and in the end I hope this thread will do some good for others as well.
Matt

designmule · « **Reply #16 on:** November 04, 2015, 07:15:28 pm »

The pi has remained connected for about 12 hours now. We got through noon with no trouble (I thought there might be some). I'll be curious to see what happens at midnight.

Here's a curious thing...from a command line on the pi if I enter "date" I get an accurate time and date. Looking at the the Media Network Server info the time stamps for activity are for 12:24:03 AM when the actual time is 6:24 PM. So JRiver has the wrong idea of what time it is even though the pi seems to know ok.

I wonder if any of you pi users can take a look at the server activity on your pi and see if it matches the actual time. Because I had to change the time configuration on the pi, I'm wondering if JRiver uses the configuration at time of install (which in my case was wrong).

Mark_NL · « **Reply #17 on:** November 05, 2015, 03:26:40 pm »

awkward,

all my MC linux boxes are 12 hours off....

mwillems · « **Reply #18 on:** November 05, 2015, 03:35:25 pm »

All my MC linux boxes seem to be reporting UTC rather than local time (about a 5 hour difference where I am), which may just be an issue with how MC queries time on Linux. For example, using timedatectl on one Linux box I see:

Code: [Select]

      Local time: Thu 2015-11-05 16:31:14 EST
  Universal time: Thu 2015-11-05 21:31:14 UTC
        RTC time: Thu 2015-11-05 21:31:14
       Time zone: US/Eastern (EST, -0500)
 Network time on: yes
NTP synchronized: yes
 RTC in local TZ: no

Which says that my Motherboard's hardware clock is in UTC, and the system converts that to local time, which is apparently the norm with computer time-keeping: https://wiki.archlinux.org/index.php/Time

MC on that system is reporting the UTC/Hardware Clock time rather than the local time. Dual booting into windows on the same machine, MC shows the correct time, but that's probably because windows using a different time-keeping standard than Linux (localtime vice UTC + adjustment).

The linux machine in question has no network sync problems with other MC clients, so the UTC/local time issue isn't necessarily fatal. A general lack of synchronization/reliable time-keeping might be fatal though.

Mark_NL · « **Reply #19 on:** November 05, 2015, 04:11:07 pm »

Sorry, forgot to mention it does not give any problems.

designmule · « **Reply #20 on:** November 05, 2015, 07:53:19 pm »

The timedatectl command results in "command not found" but I've checked the pi very regularly at the same time each evening and when I looked up UTC time during that period it matched up to what was shown in JRiver so it must be using UTC time.

Though I haven't been able to sit at the computer for hours on end and see if the pi disappears, I have been connecting to it via JRemote periodically throughout the day without problem. It has stayed connected four 24 hours. However, I have changed nothing since the last disconnect (where the JRiver SDDP server reported "processing").

I'm thinking the frequent disconnects might have been related to the time being way off. Though if it uses UTC maybe that shouldn't be the case... I'll keep an eye on things and continue to report back but I am optimistic this problem is licked.

I have a second pi I will be setting up once my HIFIberry Dac+Pro arrives. This might give me the chance to do more local troubshooting if the problem persists.

I appreciate all the attention and effort to resolve my issue.
Matt

designmule · « **Reply #21 on:** November 11, 2015, 08:09:08 pm »

I thought I'd follow up here and let anyone who comes across this thread with similar issues know what my resolutions are.

I posted this thread because my initial issue was that my pi was frequently (minute to minute) connecting to the playing now list on Windows install and then disconnecting. The two things I changed which seemed to resolve this were 1.) ensuring that the system time on the pi was set correctly and 2.) having the pi connect to the library server on the Windows box (even though I don't use the pi this way). I can't say for sure which corrected the problem but having changed both I did not experience frequent (minute to minute) connects and disconnects.

As the troubleshooting moved forward I experienced what appeared to be disconnect on a more drawn out basis (12 hours or so). Initially I thought this was the same problem as above but later I realized that JRiver was freezing up. The only way I could make JRiver reconnect was to reboot the pi.

I made two settings changes which seems to have resolved this second issue 1.) I disabled playback from memory in JRiver 2.) I removed a line from my pi config file which I added to reduce the GPU memory (my pi is headless, I didn't think the GPU needed much memory). With these two changes JRiver on the pi has been up and running without disconnects for several days.

In both cases there are two possible fixes. I can't tell you for sure that it is one, the other or both that took care of the problem but I'm offering up a couple of troubleshooting options for two different issues.

I hope this helps someone in the future (I'm a big believer in forums) and I want to thank those of you who spent time trying to help me resolve the problems I was experiencing.

Matt

JimH · « **Reply #22 on:** November 12, 2015, 04:31:06 am »

Thanks for posting your solutions.

INTERACT FORUM

Author Topic: MC21 on Raspbian disapears from Playing Now list. PCs connect fine. (Read 8928 times)