Project

General

Profile

Bug #1056

Audacious hangs on CTRl+F in big playlist with big files (mixes)

Added by Rueh Haene over 3 years ago. Updated about 3 years ago.

Status:
Rejected
Priority:
Major
Assignee:
-
Category:
-
Target version:
-
Start date:
January 28, 2021
Due date:
% Done:

0%

Estimated time:
Affects version:
4.0.4

Description

Problem

Hello there.

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=[1216437], 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.

Goal

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.

History

#1 Updated by Rueh Haene over 3 years ago

Addendum: The problem seems not to be directly related to the search function. When I want to sort by column, audacious hangs as well.

#2 Updated by John Lindgren over 3 years ago

Try to identify (binary search) what specific file(s) trigger the hang, and upload one of those as a sample, please, so we can reproduce the issue.

#3 Updated by Rueh Haene over 3 years ago

Thank you for the quick answer. I am not sure how I can do this binary search. Can you elaborate, please?

#4 Updated by John Lindgren over 3 years ago

Remove half the files in the playlist. Test whether the remaining half still contains the file(s) that trigger the hang. Repeat until you've found the file(s).

#5 Updated by Rueh Haene about 3 years 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 3 years 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".

#7 Updated by Rueh Haene about 3 years ago

I will try to come up with another example.

Nowhere in #5 I was talking about just ignoring big files, but ignore or throw an error message for files of any size that cause problems.

#8 Updated by John Lindgren about 3 years ago

Let's start by figuring out why this file "causes problems". Then we can talk about how to fix it.

#9 Updated by Rueh Haene about 3 years 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.

#10 Updated by John Lindgren about 3 years ago

Okay, closing this since there's not really any way to work on it without a reproducer.

#11 Updated by John Lindgren about 3 years ago

  • Status changed from New to Rejected

Also available in: Atom PDF