Thank you for your donation!


Set logging in upmpdcli.conf but /var/log/moodeupnp.log
#1
I've been trying to send files to the moode upnp renderer using an app control point and been getting Internal Server Error : 500 when I call SetAVTransportURI or SetNextAVTransportURI. I can happily use BubbleUpnp to do this, so I'm sure the issue is with my code. To try and get a grip on things I tried to turn on logging via upmpdcli.conf by changing the settings to: 


Code:
# <var name="logfilename" type="fn"><brief>Log file
# name.</brief><descr>Defaults to stderr. This can also be specified as -d
# logfilename.</descr></var>
logfilename = /var/log/moodeupnp.log

# <var name="loglevel" type="int" values="0 5 2"><brief>Log
# level.</brief><descr>Can also be specified as -l loglevel.</descr></var>
loglevel = 5

But there's no logfile in /var/log.  I have restarted Moode post config file change. Any suggestions on why there's no log file? Clearly I've done something dumb, but what?
Reply
#2
I've been using Moode as a upnp renderer for ages now and have never experienced this sort of issue, and given both BubbleUpnp and Upmpdcli (Moode) have been developed to specifically utilise OpenHome I'm a bit perplexed. I've never bothered with setting a log for Upmpdcli and can't advise about that, but would suggest you install Bubble UPNP server (https://www.bubblesoftapps.com/bubbleupnpserver/) and use it to set up a proxy to your media server - and see whether Moode works with that. Good luck
Reply
#3
@Steven Crook

I'm not sure I wholly understand what you're trying to do with the code that's failing to connect, but the problem with upmpdcli writing to /var/log/upmpdcli.log appears to be simple. You can see from 'ps aux' that the upmpdcli process is running as user 'upmpdcli'.  It doesn't appear user 'upmpdcli' has write permission in /var/log. Try writing the log to /tmp.

Regards,
Kent
Reply
#4
(05-04-2020, 10:35 PM)Zigzag Wrote: I've been using Moode as a upnp renderer for ages now and have never experienced this sort of issue, and given both BubbleUpnp and Upmpdcli (Moode) have been developed to specifically utilise OpenHome I'm a bit perplexed.  I've never bothered with setting a log for Upmpdcli and can't advise about that, but would suggest you install Bubble UPNP server (https://www.bubblesoftapps.com/bubbleupnpserver/) and use it to set up a proxy to your media server - and see whether Moode works with that. Good luck

I've been tinkering with some Upnp code for my phone, and have got to a point where I want to have a remote renderer jump through a few hoops for me. I use Moode to stream to my HiFi, so that was naturally my first choice. Clearly my code is broken and I was trying to get an idea what was wrong with the upnp calls I was sending to Moode and turning on the upmpdcli logging seemed like a good place to start.

It's most emphatically *not* a question of there being a problem either with Moode or my media server (minimserver).

But thanks for the suggestions.
Reply
#5
I got diverted onto something else, and never managed to resolve this, though I did fix the errors (in my code) that were causing me to want to look for the log file in the first place.

But, while tinkering I thought I'd try something with upmpdcli. I kill the instance that moode runs, and start one from the command line
Code:
sudo upmpdcli -c /etc/upmpdcli.conf

Oddly, the log information goes to the console (rather than to the one specified in the config file) and I've been able to redirect it to a file and tail that. So result of a sort.

So then I thought I'd try adding the parameters to the command line. Logging still goes to the console and no log file is created. I had already created the logs directory and given the world and their grannie write access to it.
Code:
sudo /usr/bin/upmpdcli -c /etc/upmpdcli.conf -l 4 -d /home/pi/logs/upmpdcli.log

So, finally, I went back to the config file and commented out the logfile and log level entries and started it again, same commandline as above. Still no logfile created, output goes to stdout.

So I'm confused, but wondering if that's why I'm not seeing a logfile with the instance started by Moode, that no matter what, the logfile goes to stdout...

Ideas would be appreciated. The reason I've gone back to this is that my Upnp control point is seeing occasional EarlyEOF errors reported when sending commands to the OhNetPlaylist service that's part of upmpdcli. Neither the upnp stack not the jetty stack underneath it are being very helpful, so I thought I'd look at upmpdcli.

I think I can get by on starting upmpdcli and backgrounding from the commandline, but you know, completeness...
Reply
#6
Kent's right, upmpdcli doesn't run as root so will not have write permission to /var/log.
Choose a different, writable location for your log file or change permission of the /var/log directory.
Reply
#7
(06-20-2020, 06:43 AM)vinnn Wrote: Kent's right, upmpdcli doesn't run as root so will not have write permission to /var/log.
Choose a different, writable location for your log file or change permission of the /var/log directory.

So should the Moode release be changed so that upmpdcli *can* write to a logfile? 

I should point out that in an earlier post I said that I'd already tried an alternative writeable location. I'd even tried running upmpdcli from the commandline and *still* couldn't get it to write to a logfile.

Anyway, chmodded away at /var/log directory, restarted upmpdcli and there's still no logfile.

Code:
pi@moode:/var $ ls -ld log
drwxrwxrwx 8 root root 4096 Jun 20 09:59 log
pi@moode:/var $ pwd
/var

And in the config file:
Code:
# <var name="logfilename" type="fn"><brief>Log file
# name.</brief><descr>Defaults to stderr. This can also be specified as -d
# logfilename.</descr></var>
logfilename = /var/log/moodeupnp.log

# <var name="loglevel" type="int" values="0 5 2"><brief>Log
# level.</brief><descr>Can also be specified as -l loglevel.</descr></var>
loglevel = 4

Ideas?
Reply
#8
A quick test of my suggestion to write to logfilename = /tmp/moodeupnp.log resulted instead in a file named /tmp/upexplo.log??? That suggests to me that upmpdcli isn't parsing its configuration file correctly.

I want to build the current version of upmpdcli and its supporting libraries and test whether logging has changed before I query Francois (the upmpdcli developer). I built it before but in a well-intended but misguided housecleaning exercise wiped out the disk volume I was using in my testing.

Regards,
Kent
Reply
#9
Thanks for checking, I just tried the same here and got the same result. What does it have against /var/log after I changed the perms or into my own home directory I wonder.

It's been too long since I was coding for Unix systems, I'm terribly rusty :-|

I'm not really set up for doing UNIX builds any more, otherwise I would have had a go at this. I got as far as looking at version numbers and release info, and it seems like there's enough changes to make an update worthwhile.
Reply
#10
Not to worry. It's already in the pipeline. There's pressure from users on two fronts---OpenHome features and the streaming services plugins Smile

Several of us have built and tested the current release of upmpdcli and its associated libraries and I posted the build instructions to the team somewhere not too long ago.

Regards,
Kent
Reply


Forum Jump: