Continuous Buffering
-
I just upgraded to Version 1.2.12. I'm waiting to see what happens now.
-
Strawberry stopped two times today, about 15 minutes apart.
-
Strawberry stopped three times in the last 24.
Could there be something connected with the playlist list causing this? It is a very large playlist.
-
It is still happening at random times.
-
@jonas, Strawberry, the 0% buffering issue persists. It stopped twice in the last hour. Previously, it ran for approximately 36 hours without issue.
I have switched from Fedora 40 to Linux Mint 22 LMDE, and I'm still experiencing the same issue. SO, it doesn't seem like the operating system is the problem.
I run Strawberry on this system 24/7. There is nothing in my logs that indicates anything related to Strawberry. The same thing happens when I start Strawberry with the --verbose option. It just stops. Clicking the stop button and then clicking the play button restarts playback on the same track it stopped on and is always successful. Play continues for a random number of tracks before it happens again.
-
Still doing the buffering thing. Sometimes it stops several times a day.
I have some large playlists (all smart). I have tried different sizes, but they have had no effect.
-
@rlkeeney very unlikely mate, but: any chance it's a hardware issue, and it's randomly finding segfaults on the disk? Worth running a chkdisk on it just to rule it out?
-
@Sharky-PI said in Continuous Buffering:
@rlkeeney very unlikely mate, but: any chance it's a hardware issue, and it's randomly finding segfaults on the disk? Worth running a chkdisk on it just to rule it out?
Chkdisk is a Windows command. However, it did get me thinking and checking things, and I found out that smartd was not running.
The smartd daemon monitors the health of storage devices (like hard drives and SSDs) using SMART (Self-Monitoring, Analysis, and Reporting Technology). It runs in the background, periodically checks disk health attributes (e.g., temperature, error rates), and can send alerts or log warnings if it detects potential issues. This helps prevent data loss by identifying failing drives early.
-
@rlkeeney said in Continuous Buffering:
Still doing the buffering thing. Sometimes it stops several times a day.
I can understand your frustration with this issue and you have my sympathies as I understand how maddening it can be when your favorite software refuses to co-operate. However . . . without providing more information beyond "it's stuck buffering", makes it very difficult for @jonas to figure out what is actually happening.
Without being too pretentious, it may be helpful to know what your hardware setup is, i.e., computer make/model, processor type, installed RAM etc., sound output device (internal soundcard, external DAC with connection type like USB, SPDIF, HDMI out to an AVR, etc.), where the file library is located; network share and filesharing protocol like SMB or NFS, local internal storage, USB or Thunderbolt connected external storage, etc.
In order to provide Jonas with more information as to what exactly Strawberry is doing when it throws its buffering message, you may have to run Strawberry with the Linux debugger, gdb, in order to get some usable information for Jonas to act on. You may even have to resort to installing a debug version from RPM to really drill down to what the root cause is. (Debug RPMs are available on the Github release page.)
I really can't provide much help with installing and using debug versions of Strawberry on Linux and how you would configure gdb to gather the necessary info because I'm just a dabbler in Linux with Raspberry Pi devices—I was able to get Strawberry installed and running on the PI, but other aspects of the OS made it unsuitable for my needs. Jonas would be the expert source on how to do this, but I don't want to make more work for him than he already has.
Maybe there are some members here that have the requisite Linux experience to help get you started in setting up a debug installation that will help you and Jonas get to the bottom of this vexing issue. We'd all like to see it solved as it would benefit everyone who loves Strawberry and appreciates Jonas' herculean effort in making this software available to all of us.
-
I know you are trying to be helpful, and I thank you for that. However, I am only posting here to keep the thread alive.
As a retired Linux/Unix Systems Programmer, I have extensive experience with Linux. I have been using Linux since shortly after Slackware was released. If there were an error, I would have found it. I am not your typical user, and my system is not typical. I can provide any info Jonas might need. However, I doubt Jonas could duplicate my system. For example, I have 48GB of RAM, 19 TB of active storage, 28 TB of offline storage for backups, and a few TB of network-shared storage.
BTW, my music is on a local attached (SATA) hard drive.
Strawberry worked fine for years, and then the buffering thing started while I was using Fedora. I later switched to Linux Mint LMDE 22.1 because I support people who have Linux Mint and only support one Fedora system.
-
@rlkeeney said in Continuous Buffering:
I have extensive experience with Linux. If there were an error, I would have found it. I am not your typical user
That solves it, then.
If you have enough space, then try copying a large portion of your collection (if not all) to your system drive and see if that fixes the issue... but remember to exclude that from backups if you already have it stored elsewhere...
You say you saw this issue in Fedora, and are now running Mint - so the issue is not the installation, though obviously $USER data is always suspect... but this doesn't sound like a Strawberry issue to me; not that it has none, just none like this.
I recently had issues with Plex, buffering and messing around... wasted a lot of time troubleshooting, why wouldn't movies play on the TV downstairs? Then it started local playback issues and I started playing files manually; but the final straw came with this:
sudo smartctl -a /dev/sdXI am experienced. I had not found any errors for 2 weeks, and in the next few days the drive failed to the extent that I replaced it after only extracting about 25% of the data (i.e. the important data - the rest is very easily replaced).
Just doing an rsync backup of my collection took about 3-4 hours in total. Actually, 20 minutes for the copy and the rest for getting past bad sectors.
I now have qDiskInfo installed too - a nice front end for smartctl, so I'd recommend you add that to your ToDo list
Now I'm watching this old dog (I think from 2013):
It's been on the 'failing' list now for over a year - let's see. I hate to replace stuff prematurely.
