RuneAudio 0.5-beta for most Raspberry Pi models

[cmh714]

@janui, I dont use cifs/smb.....only the nfs

root@runeaudio(rw):~# cat /etc/fstab | grep -i -v 'cifs|nfs'
#
# /etc/fstab: static file system information
#
# <file system> <dir> <type> <options> <dump> <pass>
/dev/mmcblk0p1 /boot vfat defaults 0 0
var-tmp /var/tmp tmpfs nodev,nosuid,noatime,mode=1777,size=5M 0 0
logs /var/log tmpfs nodev,nosuid,noatime,mode=1777,size=5M 0 0
rune-logs /var/log/runeaudio tmpfs nodev,nosuid,noatime,mode=1777,size=5M 0 0
http-tmp /srv/http/tmp tmpfs nodev,nosuid,noatime,mode=1777,size=5M,uid=http,gid=http 0 0

[janui]

Sorry cmh714,

cat /etc/fstab | grep -i -v 'cifs|nfs'

Made a mistake with this command, it should be:

Code: Select all

cat /etc/fstab | grep -i -E 'cifs|nfs'

Should produce no output.
janui

[cmh714]

Sorry cmh714,

cat /etc/fstab | grep -i -v 'cifs|nfs'

Made a mistake with this command, it should be:

Code: Select all

cat /etc/fstab | grep -i -E 'cifs|nfs'

Should produce no output.
janui

That is correct

[janui]

Hi cmh714,

That is correct

Looked again at the code for mounting NFS and found a bug. The corrected code is now available, you can upgrade with a git pull, see the first post in this thread for instructions. Your NFS Mount flags will now be stored after a successful mount and displayed in the Advanced options of the Network Mounts in the Sources UI.
Unfortunately I do not expect this fix to have any effect regarding your slow boot time.
These commands may give you an insight into what is taking so long during the boot sequence:

Code: Select all

systemd-analyze blame

And:

Code: Select all

systemd-analyze critical-chain

For comparison, output from a Pi 2B:

Code: Select all

> systemd-analyze blame
          2.088s winbindd.service
          1.580s smbd.service
          1.328s dev-mmcblk0p2.device
          1.054s mpd.service
           624ms nginx.service
           562ms systemd-timesyncd.service
           518ms avahi-daemon.service
           515ms systemd-resolved.service
           510ms systemd-user-sessions.service
           504ms redis.service
           367ms php-fpm.service
           328ms nmbd.service
           319ms systemd-udev-trigger.service
           161ms systemd-udevd.service
           146ms boot.mount
           130ms systemd-journald.service
           128ms tmp.mount
           124ms sys-kernel-debug.mount
           121ms systemd-tmpfiles-setup-dev.service
           121ms kmod-static-nodes.service
           119ms systemd-remount-fs.service
            98ms systemd-tmpfiles-setup.service
            95ms alsa-restore.service
            84ms systemd-tmpfiles-clean.service
            78ms systemd-sysctl.service
            73ms systemd-update-utmp.service
            72ms systemd-modules-load.service
            58ms systemd-random-seed.service
            44ms sys-kernel-config.mount
            38ms var-tmp.mount
            36ms var-log.mount
            33ms rune_shutdown.service
            31ms srv-http-tmp.mount
            22ms dev-mqueue.mount
            21ms upmpdcli.service
            17ms shairport-sync.service
            15ms var-log-runeaudio.mount

And:

Code: Select all

> systemd-analyze critical-chain
The time after the unit is active or started is printed after the "@" character.
The time the unit takes to start is printed after the "+" character.

graphical.target @3.435s
└─multi-user.target @3.434s
  └─nginx.service @2.807s +624ms
    └─basic.target @2.782s
      └─sockets.target @2.782s
        └─avahi-daemon.socket @2.782s
          └─sysinit.target @2.780s
            └─systemd-timesyncd.service @2.216s +562ms
              └─systemd-tmpfiles-setup.service @2.106s +98ms
                └─local-fs.target @2.101s
                  └─boot.mount @1.954s +146ms
                    └─dev-mmcblk0p1.device @1.939s

janui

[cmh714]

very odd, I still am not see it....would love it to come up faster but I can live as is..s
root@runeaudio(rw):~# systemd-analyze blame
8.916s mpd.service
2.201s logrotate.service
1.523s dev-mmcblk0p2.device
1.281s netctl-auto@wlan0.service
578ms avahi-daemon.service
534ms winbindd.service
476ms systemd-timesyncd.service
463ms systemd-resolved.service
435ms php-fpm.service
415ms bootsplash.service
392ms boot.mount
371ms smbd.service
352ms systemd-udev-trigger.service
342ms nmbd.service
289ms nginx.service
238ms rpcbind.service
201ms tmp.mount
197ms sys-kernel-debug.mount
195ms systemd-udevd.service
189ms dev-mqueue.mount
179ms rpc-statd.service
176ms systemd-journald.service
158ms alsa-restore.service
135ms systemd-tmpfiles-setup-dev.service
111ms systemd-modules-load.service
109ms kmod-static-nodes.service
101ms systemd-tmpfiles-setup.service
99ms systemd-random-seed.service
78ms systemd-sysctl.service
74ms systemd-rfkill.service
67ms systemd-update-utmp.service
56ms systemd-tmpfiles-clean.service
53ms systemd-user-sessions.service
47ms systemd-remount-fs.service
39ms srv-http-tmp.mount
38ms var-log.mount
34ms sys-kernel-config.mount
33ms redis.service
25ms var-log-runeaudio.mount
19ms var-tmp.mount
17ms shairport-sync.service
root@runeaudio(rw):~# systemd-analyze critical-chain
The time after the unit is active or started is printed after the "@" character.
The time the unit takes to start is printed after the "+" character.

graphical.target @4.917s
└─multi-user.target @4.916s
└─nginx.service @4.626s +289ms
└─network.target @4.602s
└─netctl-auto@wlan0.service @3.320s +1.281s
└─basic.target @3.261s
└─sockets.target @3.261s
└─dbus.socket @3.260s
└─sysinit.target @3.245s
└─systemd-timesyncd.service @2.768s +476ms
└─systemd-tmpfiles-setup.service @2.648s +101ms
└─local-fs.target @2.643s
└─boot.mount @2.250s +392ms
└─dev-mmcblk0p1.device @2.238s

[R101]

Hi Janui,

Is there any news about 0.5 support for m3u8 streams? I am still using 0.4b to listen to these, but I assume that support for earlier versions of Rune will discontinue at some point.

If I disable ffmpeg in 0.4b, it behaves the same as 0.5 does. I don't know if that could be a clue to the problem.

[janui]

Hi R101,

Is there any news about 0.5 support for m3u8 streams?

No real news at the moment, but we are still working on it.
m3u/m3u8 steams are not the only issue with the current version of MPD, there are also problems casting MP3 over UPnP/DLNA and there is also interest in Tidal, Google Play and qobuz support.
I have tried several times to upgrade MPD, including ffmpeg, but it breaks the build.
Upgrades for UPnP/DLNA and shairport-sync would also be welcome.
I am hoping to get an upgraded kernel the very near future, this will include upgraded versions of all packages. It will need a full testing cycle, so it will take some time. It will probably be released as 0.6b.
janui

[Vhond]

Still sometimes the mounting problem after rebooting the RPI. Removing the mount and adding it again 'solves' the problem but that mustn't be the way...

[janui]

Hi Vhond,

Still sometimes the mounting problem after rebooting the RPI. Removing the mount and adding it again 'solves' the problem but that mustn't be the way...

Yes, I agree.
Unfortunately I cannot reproduce the problem, if you could supply any sort of diagnostics when it happens it would be greatly appreciated.
janui

[Vhond]

What kind of diagnostics do you prefer?