Project

General

Profile

Support #1167

4.2-beta1 (git version) too slow to read playlists with many files (no matter what format)

Added by Jonathan Archer over 2 years ago. Updated over 2 years ago.

Status:
Closed
Priority:
Minor
Assignee:
-
Category:
-
Target version:
-
Start date:
April 09, 2022
Due date:
% Done:

0%

Estimated time:
Affects version:
4.1

Description

4.2-beta1 (but it also happened in 4.1) is too slow to read playlists with many files and it doesn't matter whether the files are small mp3s or large WAV files. The more the files, the slower to read them. When you click such a playlist, a small dialog appears which reads "[number] of files found" and until that dialog disappears, playback doesn't start. Based on this behavior my guess is that Audacious is pre-loading all the files. This could be some kind of feature but IMO it's not working as intended. I just ran a playlist with 14 files and playback started 30 seconds AFTER I clicked the playlist. Imagine how long someone will have to wait if they have playlists of 50 files or more...
For comparison, 3.10.1 didn't do such things. I have playlist with 62 files which 3.10.1 was starting instantly, no pre-loading of files.

P.S. This problem seems to happen immediately after rebooting linux. If you reboot and when the desktop appears you run a long playlist, that small dialog appears.

History

#1 Updated by John Lindgren over 2 years ago

  • Tracker changed from Bug to Support

I can't reproduce this at all. I loaded a playlist of 62,000 files, double-clicked on one, and playback started instantly.

#2 Updated by Thomas Lange over 2 years ago

I can't reproduce this neither. Have you tried if this occurs with a clean configuration?

mv ~/.config/audacious ~/.config/audacious.backup

#3 Updated by Jonathan Archer over 2 years ago

Thomas Lange wrote:

I can't reproduce this neither. Have you tried if this occurs with a clean configuration?

[...]

I did reset the configuration and that seems to be fixed now. But now this "${filename} (${file-ext})" doesn't display the file extension. It used to display it before I reset the configuration.

#4 Updated by Thomas Lange over 2 years ago

It's file-name. not filename.

${file-name} (${file-ext})

#5 Updated by Jonathan Archer over 2 years ago

Thomas Lange wrote:

It's file-name. not filename.

[...]

It works with 'filename' as well. But I was talking about the other thing: ${file-ext} doesn't display the file extension. I had it put in brackets, so that it shows the extension like this: (wav). But now, after the config reset, it won't show anything.

#6 Updated by John Lindgren over 2 years ago

  • Status changed from New to Closed

The original problem is resolved. Closing.

Also available in: Atom PDF