Regression: Can't save any change of Song Info in MP3 file

[rosti-il]

This is a regression in the latest 4.4 version of Audacious in the functionality that worked properly in the previous 4.3.1 version of Audacious. When I try to save any change of the Song Info in a local MP3 file, an error appears, as shown in the attached screenshot.

My system is Windows 10 Pro 22H2 64-bit.
Audacious 4.4 was installed by running the audacious-4.4-win32.exe installer after the previously installed 4.3.1 version was uninstalled.

[radioactiveman]

I could reproduce the error with Audacious 4.4 on Windows. The log inspector reveals that calling tmpfile() fails with the message "Permission denied". It works when running Audacious as admin (this is not recommended though).

@jlindgren90: Can you reproduce this? Since the code has not changed for years, could it be caused by the change to 64-bit?

audacious/src/libaudcore/vfs_local.cc

Lines 141 to 154 in 471a5fb

	VFSImpl * vfs_tmpfile(String & error)
	{
	FILE * stream = tmpfile();
	if (!stream)
	{
	int errsave = errno;
	perror("(tmpfile)");
	error = String(strerror(errsave));
	return nullptr;
	}
	return new LocalFile("(tmpfile)", stream);
	}

[jlindgren90]

It probably has something to do with the newer 64-bit MinGW platform, yes.

Possibly we need to use a different location for temporary files on Windows. I don't know when I will have time to look into the issue further.

[rosti-il]

This regression is likely related to the following bug in MinGW:
msys2/MINGW-packages#18878

[jlindgren90]

We can probably use https://docs.gtk.org/glib/func.file_open_tmp.html instead.

[rosti-il]

Maybe the best solution would be switching from MINGW64 into UCRT64 on the MSYS2 platform when building for Windows? At least the MSYS2 project itself recommends to use UCRT64 instead of MINGW64.

[radioactiveman]

Maybe the best solution would be switching from MINGW64 into UCRT64 on the MSYS2 platform when building for Windows? At least the MSYS2 project itself recommends to use UCRT64 instead of MINGW64.

I agree and can confirm it indeed fixes this issue. See the referenced pull request.

[rosti-il]

Nice!
Waiting for the next release with this fix. Is there any planned date?

[radioactiveman]

@rosti-il: Not planned yet, but I guess we can prepare a new release in the next weeks.

@jlindgren90: Do you think we can release 4.4.1 from master? Strictly speaking we have not only bug fixes there, but the other changes are mostly straightforward or backports of existing features from Qt interfaces.