Set up the basics - now what?

General
1

Hi, after several frustrating hours, I have finally set up the basics of Mopidy on my Pi. I set up from scratch rather than using the MusicBox image so my fault. I didn’t want to loose what I already had on the Pi though. I can connect to the server on port 6680. I can select a local track in the musicbox webclient which will play (with mediocre quality) on a pair of headphones connected to the jack on the Pi. So far so good.

So now how do I get the track to play in the browser so that it can be accessed on any device in the home? I would like to access the MP3 music repository on the Pi from both from my Linux PC as well as the iPad. I would like other members in the home to easily access the music repository as well.

All the solutions I have seen so far revolve around getting music to play from the jack socket on the Pi which is rather pointless given the poor quality, although I can see some possibilities with standalone speakers in various rooms.

Do I need to install some more software to make this work?

2

You can stream audio from the server but the primary use case is to output the audio on the server itself. If you want to stream audio then take a look at the documentation on the subject.

The Pi audio output is much improved in recent Raspbian builds but you must remember that port is not strictly a headphone port. Feel free to read up on the difference. There are a wealth of USB soundcards as well as Pi speciic HAT soundcards that offer better audio quality. Personally I’m not convinced they are still worth the money considering the software improvements that have been made but I appreciate people’s ears are not the same.

3

Thanks for the pointer to the documentation, although this was a source of frustration yesterday. For example, it didn’t mention that one has to install gir1.2-gstreamer-1.0 and gir1.2-gst-plugins-base-1.0 as dependencies for mopidy. Some of the config examples seem conflicting as well, for example one page shows the config parameters as ‘audio/…’ whereas another shows the section header as ‘[aud1o]’, i.e. with a ‘1’, which I thought was a typo. It turns out that ‘[aud1o]’ is, in fact, correct! It took me a while to figure things out and get it up and working properly. Still it gave on a basis to work from and for that I am grateful. I will work though the IceCast config using the documentation although it is not quite clear to me from that as to what one is supposed to do to access the music?

4

I updated the Raspberry Pi documentation very recently and I didn’t observe any problems with the package dependencies when running through and updating the steps for installation on Stretch. In fact I can see the following are correct:

$ apt-cache depends mopidy
mopidy
  Depends: adduser
  Depends: debconf
  Depends: gir1.2-gst-plugins-base-1.0
  Depends: gir1.2-gstreamer-1.0
  Depends: gstreamer1.0-plugins-good
  Depends: gstreamer1.0-plugins-ugly
  Depends: lsb-base
  Depends: python-gst-1.0
  Depends: python-tornado
 |Depends: debconf
  Depends: <debconf-2.0>
    cdebconf
    debconf
  Depends: init-system-helpers
  Depends: python-pkg-resources
  Depends: python-pykka
  Depends: python-requests
  Depends: <python:any>
    python:i386
    python
  Depends: <python:any>
    python:i386
    python
  Recommends: gstreamer1.0-alsa
  Recommends: gstreamer1.0-pulseaudio
  Recommends: gstreamer1.0-tools
  Suggests: mopidy-doc

https://apt.mopidy.com/dists/stretch/main/binary-armhf/mopidy_2.1.0-2_all.deb

I am of course assuming you installed from apt.mopidy.com rather than trying to install from source…?

Where is [aud1o] correct?

I don’t use the icecast streaming myself but if it’s ip=127.0.0.1 port=8000 then I guess you tune in to http://127.0.0.1:8000.

5

Yes, I installed from the repository. Interesting that they are listed as dependencies, yet they were not installed with the package. Just to confirm I did do a dist-upgrade before proceeding, so I should have the lasted versions of everything.

Regarding [audio] have a look here:
https://docs.mopidy.com/en/latest/config/

The example at the top of the page shows [audio], whereas under audio configuration it has each parameters as ‘aud1o/…’.

When I had the section set to [audio] as per the example, it was flagged as an error when I tried to start mopidy. I changed it to [aud1o] and the error went away. Since I have done quite a bit with the config file and also upgraded mopidy from the mopidy repo, I have just changed that back again to [audio] and the local scan does not seem to complain anymore, so maybe it was something in the eariler version of else in the file that caused it to mis-behave.

BTW, I have set up the icecast software as per instrcutions, and have icecast running, but am not seeing the mopidy in the mountpoint list.

6

I’m assuming you mean APT repository by this and not git repository.

I’m not sure what’s going on here because I don’t see that. You should be able to see for yourself the documentation source code at https://raw.githubusercontent.com/mopidy/mopidy/master/docs/config.rst. You can also see the default config at https://github.com/mopidy/mopidy/blob/v2.1.0/mopidy/config/default.conf#L15. I can’t explain why this is wrong in your browser.

The last release of Mopidy was quite some time ago, I don’t understand where an upgrade would have come from. I’m hoping this might shed some light on your dependency problem.

Post your mopidy config (or sudo mopidyctl config if using the service). The IP 127.0.0.1 means you need to be accessing the stream from the raspberry pi, not another computer. I guess you need to use the actual IP address of the Raspberry Pi if you want to access it from another machine. As I said, I don’t have any experience with it.

7

Sorry, should have said that I initially installed from the Pi repository. The weird thing is that when I ran mopidy from the command line you got version 2.xx, but if I started it as a service then I got 0.9.x or something. Since I wanted to run it as a service I updated from the mopidy repository as per instructions on the mopidy website. I then got the same 2.x.x version regardless of which way I started it. Strange, but true.

You reply about the “aud1o” issue made me wonder whether this was a browser font issue, so I copied one of the lines where it said aud1o into a text browser and sure enough got “audio”. Mystery solved. If i could attach an image I would post a clip here for you to see. The references you have linked, being monospaced text are quite clear. Thanks.

I appreciate that the issue may be at the icecast end, but here is my mopidy config:
(password has been obfuscated)

[core]
cache_dir = /var/cache/mopidy
config_dir = /etc/mopidy
data_dir = /var/lib/mopidy
max_tracklist_length = 10000
restore_state = false

[logging]
color = true
console_format = %(levelname)-8s %(message)s
debug_format = %(levelname)-8s %(asctime)s [%(process)d:%(threadName)s] %(name)s\n %(message)s
debug_file = mopidy.log
config_file = /etc/mopidy/logging.conf
debug_file = /var/log/mopidy/mopidy-debug.log

[local]
enabled = true
library = json
media_dir =/home/music/share
scan_timeout = 1000
scan_flush_threshold = 100
#scan_follow_symlinks = false
excluded_file_extensions =
.directory
.html
.jpeg
.jpg
.png
.bmp
.log
.nfo
.txt
.sh

[audio]
mixer = software
mixer_volume =
#output = autoaudiosink
output = lamemp3enc ! shout2send mount=mopidy ip=127.0.0.1 port=8003 password=********
buffer_time =

[http]
enabled = true
hostname = 0.0.0.0
port = 6680
static_dir =
zeroconf = Mopidy HTTP Server on Aurora

[musicbox_webclient]
enabled = true
musicbox = false
websocket_host =
websocket_port =
on_track_click = PLAY_ALL

#[proxy]
#scheme =
#hostname =
#port =
#username =
#password =

[dirble]
enabled = false
api_key = 709e39216d19b68a47471341ca
countries = UK,PL
timeout = 5000

8

Did you already try playing a song directly via gstreamer instead of Mopidy to verify IceCast? More info: https://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-good/html/gst-plugins-good-plugins-shout2send.html

9

Ok, I have been able to move this forward a bit thanks to the help of folks over on #icecast.

This command allowed me to test the connection to icecast:

# gst-launch-1.0 audiotestsrc ! audioresample ! lamemp3enc ! shout2send mount=/mopidy ip=127.0.0.1 port=8003 password=********

There were two issues.

Firstly, I had inadvertently placed the section within the comment markers after the examples in the icecast.xml file. Moving the section below the end marker enabled the mount and the fallback /silence.mp3 mount could not be seen.

Secondly, it seems that the password in the output line in the [audio] section must be the password found in in the icecast.xml config file. This information is currently omitted from the instructions. Since this did not initially work, I had assumed that maybe admin level access was required so had used the admin password, although I was not comfortable with it.

The command shown in the instructions assumes the username is ‘source’ hence the username= parameter is not required.

Specifying user admin will not work. Once the username was removed and the source password specified, the login now succeeded. Once that part was sorted, I now had a connection between mopidy and icecast, which could be seen in the log:

127.0.0.1 - - [01/Jun/2018:12:12:01 +0100] “SOURCE /mopidy HTTP/1.0” 200 19 “-” “GStreamer 1.4.4” 172

Now that was working, the mountpoint could be seen in the public home in icecast, but not in the Admin home mountpoint list - yet.

When a track is played, there is no audio in the browser, however, this seems to create a stream and a /mopidy mountpoint is now shown in Admin home mountpoint list. When you click on the M3U button there, and choose ‘open with’, selecting the media player, this appears to open the stream and play it in the said media player. Any tracks that are subsequently selected and played in musicbox webclient will now play in the open media player session.

Ok, this is rather cumbersome, but at least I have a working audio stream. So, why do the tracks not play in musicbox in the browser when they are selected?

10

Because that’s not the primary aim of the software. The browser interface is just basically (another) remote control.

11

Ok, thanks. My expectation was (perhaps because of being a novice with streaming) that when I played tracks then I would get audio via the browser to the PC soundcard or iPad speakers. But instead I got silence and was wondering why it was not working. Maybe I am looking at the wrong solution?

Musicbox webclient behaves a bit oddly too although that is not a mopidy issue. When you click a single track, the whole lot is added to the queue and starts playing sequentially. I did eventually realise that one had to click the arrow on the right to add a single track.

Anyway, mopidy does seem to be doing what it is supposed to and seems to work OK so thanks.

12

HTTP streaming has been on the roadmap for some time but it’s not a high priority since there’s the shoutcast workaround and as I said, Mopidy is not focused around this particular use case. Not all software that plays music also streams music over HTTP.

Regarding Mopidy-Musicbox-Webclient, sounds like you want to change the on_track_click config setting to something else.

In both cases, I hope you can appreciate not everyone wants the same thing.

13

kigostick, yes, that is understood, and thanks for the hint regarding on_track_click. As I said I’m a bit of a novice when it comes to audio streaming so I perhaps mis-understood the purpose of modpidy. This has been a bit of a learning curve but I did get a result in the end, even though it was perhaps not the one I was looking for so thanks for the supporting comments.

1 Like