Audacious hangs on CTRl+F in big playlist with big files (mixes)
I have a playlist with more than 5000 mixes. Since they are mixes, the average filesize of each file is bigger than in other playlists, where I only have single tunes.
The "new" CTRL+F search function makes audacious completely hang at 100% CPU load, when I want to search a mix. Searching in other playlists works perfectly fine.
The last thing I can see when opening audacious with "strace":
RTID, parent_tid=, tls=0x7ffbb5064700, child_tidptr=0x7ffbb50649d0) = 1216437 futex(0x5560391135a0, FUTEX_WAKE_PRIVATE, 1) = 1 futex(0x7ffbcab1816c, FUTEX_WAIT_PRIVATE, 0, NULL
It seems to be waiting for something. Maybe reading through all the files?
The "old" search function worked perfectly for me for all sizes of playlists, no matter of the size of the single files.
I am running audacious version 4.0.5, but I could not choose that in the list, therefore 4.0.4.
Verify, if there was introduced a bug with the new search function. If it is a bug, try to fix it or make it work like before.
I set Priority to Major, but I would like to set it to Critical, as it is really annoying and forces me (and hopefully others) to scroll through the whole list to find single entries.
#5 Updated by Rueh Haene about 1 month ago
I have tried a bit around and it appears to be a single file, that causes the hang. The file command says:
Audio file with ID3 version 2.3.0, contains:RIFF (little-endian) data, AVI, 640 x 358, 25.00 fps, video: XviD, audio: MPEG-1 Layer 3 (stereo, 48000 Hz)
The file is actually a video (> 600mb), which is corrupted. For some reason the video was name as an mp3 file. After removing the file from the playlist, searching is now working like a charm.
Well, I should not have video files in a music playlist in the first place, but however, the player should not react like this when encountering such files. Previous versions of audacious seemed to just ignore this (I can not proof that).
I my opinion, audacious should either ignore such files, or even better, throw an error message instead of freeze.
Since the file is too big, I can not upload it to the ticket for further analysis.
For me, the problem is solved, but a little fix in the software might be necessary.
Thank you for your advice!
#6 Updated by John Lindgren about 1 month ago
If you can come up with a smaller test case to recreate the problem, or a debugger backtrace showing in which part of the code the hang occurs, we might be able to fix this.
I don't think we want to skip files based purely on file size. As soon as we do that, we will get bug reports that "Audacious doesn't play this 800 MB file anymore, previous versions worked fine".
#9 Updated by Rueh Haene 26 days ago
I am not able to produce a sample. The only thing I see when running with audacious -VV was endless counts of this (after clicking on the file):
DEBUG vfs.cc:130 [fread]: <0x7f42c0002de0> read 1 elements of size 1 = 0
Eventually it aborted and threw the following:
ERROR mpg123.cc:194 [DecodeState]: mpg123 error in file:///home/user/audacious_failing_sample.mp3: Error reading the stream. (code 18)
If that doesn not help anyhow, please close the ticket.