Invalid handling of files with hashes # in names

[Maciej Klimczuk]

When converting files with hashes in names, and when specific preferences are chosen, SoundConverter hangs. These preferences are:
- Into folder XYZ (does not contain any characters requiring escaping, e.g. /home/avaer/desktop),
- Do NOT create subfolders,
- File names: Same as input, but replacing the suffix,
- Replace all messy characters,
All preferences are shown here:
http://avaer.net/stuff/tmp_1505_5fsLlFXo_sndcnvrtr/options.png

SoundConverter hangs after finishing conversion of first file (window does not respond). Screenshot: http://avaer.net/stuff/tmp_1505_5fsLlFXo_sndcnvrtr/mainWindow.png . Afterwards, a specifically named file is created, in my case "Various Artists - LiquidFusiion Free Compilation " (notice the space at the end).

SoundConverter did NOT hang, when I selected "Create subfolders" option.

Used version of SoundConverter: 2.1.3 (from Arch Linux repository)

[Louis A (loalvi)]

I had this problem recently. Linux Mint 20.3, SoundConverter 3.0.2.
After some testing, it seems like the problem (from what I understand) does not come from the file name, but from the folder name.

Three test cases to reproduce and understand the issue:

1. A folder 'music' with files 'track #1.flac' and 'track #2.flac'. The conversion to mp3 works normally.

2. A folder 'mus#ic' with a single file 'track1.flac'. The conversion works, but:
- the resultiing file is called 'mus' (folder name before the '#')
- if the destination folder is "same as source", the file will actually be put in the parent of that folder

3. A folder 'mus#ic' with files 'track1.flac' and 'track2.flac'. Let's suppose that conversion of track 2 end after conversion of track 1.

--------- The logs for case 2., if that helps:

SoundConverter 3.0.2
/usr/share/soundconverter/python/soundconverter/ui.py:1465: Warning: g_value_type_transformable: assertion 'src_type' failed
  builder.add_from_file(gladefile)

(SoundConverter:9168): Gtk-WARNING **: 20:51:44.439: ../../../../gtk/gtkliststore.c:834: Unable to convert from (null) to gchararray
walking: 'file:///tmp/tmp.8rUPsFqd8j/mp%233'
analysing file integrity
Queue start: 1 tasks, 16 thread(s).
launching: 'giosrc location="file:///tmp/tmp.8rUPsFqd8j/mp%233/track1.flac" ! decodebin name=decoder ! fakesink'
adding: 1 files
have_type: audio/x-flac mp#3/track1.flac
mime: .flac audio/x-flac
Queue done in 0.025s (1 tasks)
Added 1 files in 0.04s (scan 0.01s, add 0.03s)
Queue start: 1 tasks, 16 thread(s).
launching: 'giosrc location="file:///tmp/tmp.8rUPsFqd8j/mp%233/track1.flac" name=src ! decodebin name=decoder ! audiorate ! audioconvert ! audioresample ! lamemp3enc encoding-engine-quality=2 target=quality cbr=false quality=5 ! xingmux ! id3mux ! giosink location="file:///tmp/tmp.8rUPsFqd8j/mp%233/track1.flac~657148~SC~"'
found_tags: mp#3/track1.flac
    {'artist': 'Karnivool'}
    {'title': 'Goliath'}
    {'album': 'Sound Awake'}
    {'year': 2009, 'date': '2009'}
    {'track-number': '2'}
/tmp/tmp.8rUPsFqd8j/mp#3/track1.flac~657148~SC~ -> /tmp/tmp.8rUPsFqd8j/mp#3/track1.mp3
Creating folder 'file:///tmp/tmp.8rUPsFqd8j'?
Queue done in 5.028s (1 tasks)
closing...

The resulting file from track 1 will be as described above. But after track 2 is converted, the app freezes; maybe because the file name already exists?

Case 2. is probably the most interesting. I don't have the knowledge to locate the issue precisely, but devs probably do.