SSODS 2.19 + SS 6.5.4 + CS407 : Random Song Mix => Systematic rebuffering...

[ocococ]

I am experiencing a strange problem only when I am using random song mix feature. Indeed, at the beginning of each song, there is a systematic rebuffering of the song after 1 second of play.
Moreover, other random rebufferings happen quite frequently during play.

My squeezebox is wireless (signal strength >=90%) but I tested with a network cable, it is exactly the same.

Obviously, it works like a charm with other playlists.

Any help appreciated.

Ocococ.

[flipflip]

Maybe SS is using more (too much) CPU while randomising the playlist. You can login to the the DS with telnet and then issue the command "/volume1/SSODS/bin/top". This will display a list of processes, ordered by CPU usage. Check if you notice a significant difference while playing a normal playlist vs. playing a random song mix. Usually CPU should be around a few percent for the Slimserver perl process.

flip

[ocococ]

A partial dump of top command as you suggested while playing normal playlist :

Tasks: 91 total,  2 running, 89 sleeping,  0 stopped,  0 zombie
Cpu(s): 1.0%us, 0.8%sy, 0.0%ni,97.6%id, 0.6%wa, 0.0%hi, 0.0%si, 0.0%st
Mem:   127004k total,  121868k used,    5136k free,     840k buffers
Swap:  393464k total,   36512k used,  356952k free,   27528k cached

PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
2464 admin     15   0 70536  54m 2624 S  5.6 44.0   8:21.49 perl                                                       
2902 root      24   0  5612  868  632 R  5.6  0.7   0:05.79 flac

It seems quite normal but i'm just intrigued by used mem compared to total mem.

Now while changing song in random mix song mode : It's difficult to dump precise %CPU but it seems each time there is rebuffering, mysqld process uses more than 70% for a short period of time. Moreover perl process can be up to 90% very shortly.

For information : If I try to play again a song from the random playlist that have been already played, that seems to never cause rebuffering.

Another intriguing point : Since I have my NAS, I never had this problem until recently. But each week I add a lot of new files in slimserver (almost all .flac files).
I now have more than 800 albums and about 7000 songs.
So I naively ask the question : Is there any limitation in the number of songs that slimserver can handle ?

Ocococ

[flipflip]

The task list looks okay.. You can change the averageing (i.e. display update) time by pressing "d" and then entering a number (e.g. 60 for 60 seconds). You'll get more meaningful values like this.

Memory used vs. memory total looks okay to me, too. What's so interesting about this? We have rather little memory on these boxes, so most of the memory is actually used (data and programme code) and only a small part is left for buffers (i.e. I/O cache). The more interesting readings is the swap usage: here ~36 MB of used memory (again: data and code) are swapped. Compare the VIRT and RES of individual processes. They indicate the total memory allocated by the process and the part of it which is actually in RAM, respectively. So, for Perl/SS this is 70 MB and 54 MB. The point is that if a process has to swap in/out a lot, this will use IO bandwith and possibly also CPU. If I remember correctly, this CPU usage won't show up for the process but rather as one of the percentages in the header (of the top screen). In your case the CPU is 98% idle, so that's probably not the problem. I'm not sure how to monitor swap activity with ps, but I think there's a script SSODS/bin/watch_swap.sh which can do this (not sure if it still works with modern SSODS :-). Another command to monitor the processes and system activity is "htop". Note, this has some weird key bindings on the DS (not all F-Keys work, see the help screen of it).

I don't know the limit for the number of tracks. Probably it's only limited by disk space (either for the .flacs or the database files, whichever comes first :-). However, more tracks means a larger database means more CPU and IO time to query the database. So database related things probably get a bit slower with more tracks. I guess this goes for the random playlist mode (not sure how it is implemented but I guess it queries the db for each track).

So my recommendation is to find out where the bottleneck is:

Try to increase the average time (60..300 seconds) to get better readings in top.

Regards,
flipflip

P.S. If you enclose text mode screen output in [ code ] ... [ /code ] (without whitespace between [ and ]) its much better readable..

[ocococ]

Thank you for your advice.

After a lot of experiments, I found that disabling CLI plugin reduced a lot of rebufferings even if can't explain why.

There are still rebufferings though in random mix mode but now they are at the very beginning of songs, so there are almost no 'audible' cuts when changing song.

Ocococ