More > JRiver Media Center 21 for Linux
MC21 on Raspbian disapears from Playing Now list. PCs connect fine.
designmule:
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:
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:
awkward,
all my MC linux boxes are 12 hours off....
mwillems:
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: --- 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
--- End code ---
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:
Sorry, forgot to mention it does not give any problems.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version