I’m facing a nasty Problem after my last Update of Volumio to Version 2.513.
The Playback is stopping randomly after a few hours.
It happened with older versions also after the system was running a few weeks and a reboot cured the error.
But now nothing of the known workarounds (clear browser cache, reboot volumio, are helping.
I don’t have any Plugins installed except the preinstalled YT Playback.
The Files are stored on a USB Drive. No Network Mount is configured.
I have a second Pi running with volumio.
I just discovered that it has the same “bug”.
The Livestream (di.fm Stream) stopped after about 3-4 hours playing.
The thing is, that both installations are running since some time and got several updates.
Maybe something gets buggy, after the system was updated via the web interface.
It would be cool if some else would try to setup a volumio with an older image and update it to see if this error is happening too.
I will setup a fresh install in the next days and test if the error is vanished.
I also managed to get rid of the error when trying to (un)install plugins.
It was because I had set a custom passwd for the volumio User.
But again, this didn’t change a thing. The error still occures.
I’m having the same problem after updating to 2.555. I only have the GPIO plugin installed. Sometimes it will play for an hour or so and sometimes it will stop after a song or two. I’m using a NAS type setup.
@michelangelo
I am having the same issue. The behavior is the same on three (3) deployments: 2x i386 with SMSL and Topping DAC, and 1x Pi with the identical SMSL DAC. Initially, the behavior under 2.513 started out as 1) playback delayed upon play; 2) playback of next song delayed (sometimes a few seconds, sometimes up to 2 minutes or longer); 3) no playback at all.
Behavior 1) and 2) present on two (2) deployments; behavior 1) - 2) on one deployment and as of today 3).
Behavior 1) and 2) started out on 2.512, so I thought upgrading to 2.55 would resolve the issue, but 1) and 2) still present and apparently one setup got progressively worse and now 3). So 2.55 did not improve anything but it also didn’t introduce 3) right away. This may suggest that the behavior gets progressively worse. I have ruled out DACs. I am happy to upload logs or give more details about my hardware, although personally, I think we can rule out the hardware. I really hope somebody from the Volumio team could respond and offer a solution. I would hate to re-deploy for three devices.
Don’t know if this can help… I am running the same version of Volumi on a RPI3B+ (fresh install, not an update) and I have noticed also this behaviour (stops playings at the end of a track while the queue is not empty), but only in special situations.
Generally, this happens only when there was an update of the database running recently. Without any update, I don’t have the issue. When there has been an update, this issue may happen, but not every time.
To be more precise, my music is on an attached USB drive, but my “reference” is on a NAS. After each boot of Volumio, I fetch from the NAS any new album (using rsync), and, in the case that new tracks were copied, I run “mpc update”.
So, I have noticed that, when this update (“mpc update”) is actually performed, I can happen the issue (playback stops at end of track). But not all the time.
Edit - Deleted all User Settings seems to solve the problem.
Same Problem here since end of 2018.
Hifiberry Amp+, control via Android App. no Plugins installed. Seems for me to be a Problem with Volume Control. logs.volumio.org/volumio/4TcaIjo.html
hope it can be solved
kind regards Peter
I have what might be a similar issue. Running the current version of Volumio on a original RPB+ , with a USB wifi and Dac. Playback is from SMB shares over wifi. The playback queue will randomly stop for no reason , always in between tracks never cutting off a playing track. There are no errors reported in the logs and volumio just continues sending tracks to MPD after it has stopped. I think its some sort of timing issue with volumio not sending the next track to MPD before the one playing is done. If I use an MPD client and send a playlist of 100 tracks to MPD everything works fine so it cant be a hardware issue.
I may have found a partial solution, changing the ‘buffer before play’ under general playback options from %10 to %20 seems to mostly solve the problem.
I concur, although there may be more than one issue at play. The behavior on my Pi is such that at boot the startup chime no longer plays. Again, I’ve ruled out the hardware.
