Are the permissions for the users set correctly? Perhaps the mpd user does not have the permission to create its log file? Or the location does not exist?
the location of the log file is invalid and therefore MPD can’t create one and crashes
The fix I was proposing should help here - basically currently mpd.service is enabled and launches on boot.
Instead, we can disable the service and let the backend mpd plug-in start and stop the service once all config files are setup. This should avoid any race conditions and also avoid having to create dual configurations - one in build and one in volumio2 repos…
I am away from a device to check, but adding systemctl disable mpd.service anywhere in finalize.sh should disable the service on boot…
If I get the things right, MPD crashes at its first startup with the mpd.conf that is delivered with the build. This mpd.conf obviously contains some information that causes the crash (wrong location of logfile, may be wrong or missing information about soundcard “0”…).
Stopping the MPD afterwards doesn’t help because it has crashed already when it tries to start at boot time.
What about preparing and delivering a “correct” and “robust” mpd.conf with the build process so that MPD can read it at first startup and work with the information without crashing?
The only other possibility I see is to prevent MPD of starting at boot time. But that would probably mean that there is no startup sound (or it is postponed to a very late time…)
Cheers,
Robert
Indeed - it uses the default one that is packaged with the MPD version that is installed.
You would need a minimal mpd.conf that is run by mpd.service at startup, and then volumio.service will kill it and restart it with the correct mpd.conf again when has the proper configuration.
Instead, you could just have Volumio start up MPD as usual when it is ready - no race conditions, and also no need to keep two copies of the correct mpd.conf - one in the Build repo, and other in the Volumio (nodeJS) repo - this IMO is asking for trouble, and will go out of sync fast and lead to needless bug chasing.
This is exactly what the fix I was suggesting will do - it delays the start of mpd to only AFTER the Volumio core has set things up - this should remove and race condition, and makes things more deterministic.
The startup sound is a non issue as it doesn’t use mpd but via aplay 
Hi @ashthespy
ok, I see.
So how will we proceed? Can I test your solution proposal on my own or do we need a new build for that?
By the way: Why don’t we use the solution that gkkpch did prepare - it worked…
Cheers, Robert
Update to latest 3.X version, that will work.
Latest version:
https://updates.volumio.org/x86_amd64/volumiobuster/3.061/Volumiobuster-3.061-2021-04-12-x86_amd64.zip
Yes it works. Only issue i had was once flashed to emmc it hangs after restart. (but this i assume was due to the library being populated at the time) Did a hard reset. Then everything worked.
Hi,
here my test results regarding Volumiobuster-3.061-2021-04-12-x86_amd64.img
Management summary:
- no deadlock after first start
- frequently loss of music library
- frequent deadlock (no playback, no lib)
- change of “playback options” heals this, a few minutes later again deadlock (no playback).
- it seems that we are on a good way, but the system is neither stable nor robust yet.
Details:
after first start (directly after flash)
- assistent is runnig without interruption
- playback is ok (webradio, tidal)
- lib is showing the USB Stick media but NOT the media on the external USB HD
- “update” scans the externel USB HD (it was mounted automatically but not scanned)
volumio@smx:~$ systemctl status mpd.service
● mpd.service - Music Player Daemon
Loaded: loaded (/lib/systemd/system/mpd.service; enabled; vendor preset: enabled)
Active: active (running) since Mon 2021-04-12 18:21:54 UTC; 39s ago
Docs: man:mpd(1)
man:mpd.conf(5)
Process: 3443 ExecStartPre=/usr/bin/touch /var/log/mpd.log (code=exited, status=0/SUCCESS)
Process: 3444 ExecStartPre=/bin/chown volumio /var/log/mpd.log (code=exited, status=0/SUCCESS)
Main PID: 3446 (mpd)
Memory: 8.5M
CGroup: /system.slice/mpd.service
└─3446 /usr/bin/mpd --no-daemon
Apr 12 18:21:54 smx systemd[1]: Starting Music Player Daemon...
Apr 12 18:21:54 smx mpd[3446]: Apr 12 18:21 : exception: Decoder plugin 'wildmidi' is unavailable: configuration file does not exist: /etc/timidity/timidity.cfg
Apr 12 18:21:54 smx systemd[1]: Started Music Player Daemon.
volumio@smx:~$
volumio@smx:~$ ls -al /media/
total 144
drwxrwxrwx 1 root root 1024 Apr 12 18:20 .
drwxr-xr-x 1 root root 1024 Apr 12 18:18 ..
drwxrwxrwx 1 root root 12288 Mar 17 16:09 MUSIK
drwxrwxrwx 1 root root 131072 Jan 1 1970 ultra
volumio@smx:~$ lsblk -r -no PATH,KNAME,TRAN,TYPE,FSTYPE,ROTA,HOTPLUG,RM
/dev/loop0 loop0 loop squashfs 1 0 0
/dev/sda sda sata disk 0 0 0
/dev/sda1 sda1 part vfat 0 0 0
/dev/sda2 sda2 part ext4 0 0 0
/dev/sda3 sda3 part ext4 0 0 0
/dev/sdb sdb usb disk 1 1 0 <- external USB HD
/dev/sdb1 sdb1 part ntfs 1 1 0
/dev/sdc sdc usb disk 1 1 1
/dev/sdc1 sdc1 part vfat 1 1 1
/dev/sdc2 sdc2 part ext4 1 1 1
/dev/sdc3 sdc3 part ext4 1 1 1
/dev/sdd sdd usb disk 1 1 1 <- external USB Stick
/dev/sdd1 sdd1 part exfat 1 1 1
volumio@smx:~$
- playback is dead: http://logs.volumio.org/volumiobuster/xszpomN.html
- after change of “playback option” playback is working again: http://logs.volumio.org/volumiobuster/bQtZY0v.html
- a few minutes later (started a “update” of the lib, playback is dead again: http://logs.volumio.org/volumiobuster/qdpK0AR.html
- change of “playback options” is healing it again: http://logs.volumio.org/volumiobuster/3MzyyI0.html
There is still something that torpedoes the mpd or the alsa queueing. Change of the “playback option” heals it for a few minutes (or a few titles to play), then it hangs again.
Again playback is dead:
http://logs.volumio.org/volumiobuster/QCKoLST.html
nearly at the end of this log - may be this is a hint where to look for?:
mpd: ../src/event/SocketMonitor.hxx:101: unsigned int SocketMonitor::GetScheduledFlags() const: Assertion `IsDefined()' failed.
One more thought: The earlier beta versions from 3.046 to 3.055 did not show this instabilities (playback dying…).
Cheers,
Robert
I have a Tidal problem (not big but it is an issue I think). I am running volumio3 When I select an artist in tidal and go to the album list I only get <translate.common.albums> Not shure if this is a beta issue.
Hi @Tecko ,
thanks for posting.
See also my post in “general issues” of the beta
Probably this is not an x86 specific issue but nevertheless a volumio 3 issue in the beta phase.
Have fun,
Robert
PS: Could you please provide us with the exact version you are using?
I am using version 3.053 x86_amd64. I update today 14/4 to 3.055. Now 3.061 that is the latest?
Deleted
Still overwriting /boot/userconfig.txt
on X86? There is no userconfig.txt
But you mean RPi, afaik there is still an issue open with it, there was a fix but I’m not sure if it has been integrated, @ashthespy may know more.
wrong channel… my bad.
There’s a new version (3.063) on the server. Could someone please tell us the changelog coming from 3.061? At the first glance I canot see any difference - my focus is on the x86 issue regarding playback and lib generation…
In 3.063 playback is dying after choosing 1 webradio and after that trying to play a tidal track.
Cheers,
Robert
Hi them all,
found Volumiobuster-3.066-2021-04-15-x86_amd64.img on the beta server and tested it.
Setup:
- x86
- volumio on USB stick 1
- USB stick 2 with 30 music files
- USB HD with some 38k music files
Log after startup and playing some titles (everything is still working):
http://logs.volumio.org/volumiobuster/WQXKBYJ.html
- first setup assistent runs through without interrupts.
- playback of webradio ok
- playback tidal ok
- USB stick 2 is scanned automatically, but only 20 of the 30 files were found and indexed in the lib
- USB HD is mounted but not scanned automatically.
- unmounted USB HD and “update” the lib: 30/30 files on USB stick 2 were found and indexed
- mounted the USB HD again and “update” the lib: al files were found and indexed in the lib.
- playback of tidal / webradio / local files seems to be more stable. But after some 20 jumps between local files, tital titles and webradios the local lib is gone and playback of tital, webradio, local files is no longer possible.
- again changing the “playback options” heals it and playback is working again.
- jumping quickly (after first 1-2 seconds of the tracks) between some tidal titles lets playback die again.
- if you don’t hurry and let the tracks at least 10s play before switching to another everything is fine.
Log when playback is no longer working:
http://logs.volumio.org/volumiobuster/Me3cKhJ.html
Log when playback is broken again:
http://logs.volumio.org/volumiobuster/bKCD70i.html
Sorry to say that this 3.066 with MPD 0.21.18 is only a little bit better than the 3.063 in regards of the playback stability. The last stable version I had was the 2.857 with MPD 0.21.16. But anyway there have been more changes than the MPD version of course. May be the root cause of the playback problems is not the MPD version alone.
Let me know if I can provide you with more information…
Good luck! We will solve this together!!!
Cheers,
Robert
I want to let know I have no problems with intelnuc10i3 running 3.066-x86_AMD64 Have tidal, qobuz running without significant problems. I have mixcloud, bandcamp en youtube2,ytcr -plugins running. Only thing I do not get going is the spotify plugin and spotify connect plugin. But I hope that will be fixed in the near future. For me Volumio is the most complete system to listen to audiophile music.