Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: "Sanitize tags" issues (Read 1705 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

"Sanitize tags" issues

Hi!

After much hesitation, I made the switch to the 64-bit foobar. As expected, I ran into some serious problems. One of them is the "sanitize tags" function. While I like the idea, it frequently tells me, "Error processing file: File is already in use," and then creates .tmp files in the source folder.

Sometimes foobar crashes entirely, and upon restart, I'm told some components were damaged and I need to reinstall the program. Any suggestions?

Re: "Sanitize tags" issues

Reply #1 –
When you switched to 64-bit, did you install it on top of an existing 32-bit version?  Many older plugins are no longer needed (like foo_sanitize which is built-in now), and the directory structure of older 32-bit versions has changed too, although attempts are made to change/accomodate the latter (not always successfully) during an over-the-top install process.

I went to 64-bit Foobar with a clean portable install, and used my existing 32-bit version as a guide for what I needed to do to copy its functionality and theme with new components.  This was not the PITA I expected and actually went pretty smoothly.  I have been running v.2.2 Preview 64-bit ever since and the thing is rock stable.

Re: "Sanitize tags" issues

Reply #2 –
"Upgrading" from 32-bit version should cause no issues actually. Old 32-bit component won't work, but that isn't a problem as they are simply not loaded.

Normally when reporting a problem one should provide some basic information like what foobar2000 version is used, what components are installed, what was done to what kind of files, is the problem reproducible, etc.

But in this case for tag sanitation failure I think the best first debugging step is for you to open Preferences, navigate to Advanced -> Debugging -> Crash on tag read/write error. You should submit any crashes you get, and if you wish, you can share the text log here too.

Components getting corrupted in a crash sounds very strange. That may be whole another problem. You should share the exact error messages/logs without altering the wording.

Re: "Sanitize tags" issues

Reply #3 –
I removed the old foobar with Revo Uninstaller, removed all remaining traces of it, restarted Windows, and installed the new one.

I didn't alter the wording of the error message, just removed the path to the files as I deemed this irrelevant.

I've tried this a couple of times but the result remains the same:

https://imgur.com/a/SK1ksOz

Then I used the ReplyGain scanner on this particular album and foobar crashed.

My components:

Code: [Select]
Core (2024-05-02 12:08:22 UTC)
    foobar2000 core 2.1.5
foo_converter (2024-05-02 12:08:54 UTC)
    Converter 2.1.5
foo_dsp_eq (2024-05-02 12:08:58 UTC)
    Equalizer 1.2.3
foo_dsp_std (2024-05-02 12:09:02 UTC)
    Standard DSP Array 2.1.5
foo_fileops (2024-05-02 12:09:06 UTC)
    File Operations 2.1.5
foo_freedb2 (2024-05-02 12:09:10 UTC)
    Online Tagger 0.10
foo_input_std (2024-05-02 12:08:50 UTC)
    CD Audio Decoder 2.1.5
    FFmpeg Decoders 6.0
    FLAC Decoder 1.4.3
    Monkey's Audio Decoder 10.30
    Opus Decoder 1.4
    Standard Input Array 2.1.5
foo_masstag (2022-09-19 10:01:44 UTC)
    Masstagger 1.9
foo_scrobble (2022-09-05 22:43:00 UTC)
    Scrobble 1.6.0.22456
foo_ui_std (2024-05-02 12:08:34 UTC)
    Album List 2.1.5
    Decoding Speed Test 2.1.5
    Default User Interface 2.1.5
    File Integrity Verifier 2.1.5
foo_unpack (2024-05-02 12:09:18 UTC)
    ZIP/GZIP/RAR/7-Zip Reader 2.1.5

Re: "Sanitize tags" issues

Reply #4 –
Quote from: Mike_de on
Quote from: Mike_de on
Sometimes foobar crashes entirely, and upon restart, I'm told some components were damaged and I need to reinstall the program. Any suggestions?
I didn't alter the wording of the error message, just removed the path to the files as I deemed this irrelevant.
I meant the error message you get about component damage. That is not normal.

Quote from: Mike_de on
I've tried this a couple of times but the result remains the same:

https://imgur.com/a/SK1ksOz
This is not crashing. foobar2000 is telling you that the process has no permission to touch the files. Tag editing needs file system write access.

Quote from: Mike_de on
Then I used the ReplyGain scanner on this particular album and foobar crashed.
The crash log you attached was expected since you now have the debug option enabled that crashes on tagging failure. Thankfully it also reveals why you keep getting those "File is already in use" errors: you are playing the file you are trying to sanitize. That operation needs exclusive access to the file, you can't play a file when using it.

Looks like the error message about file being already in use is unrelated to your normal crashing. You can disable the debug option to crash on tag read/write error.

Only other submitted crash logs from you that I see are related to the Playlist Attributes component. If that component crashes during sanitation operation it could be the cause of the leftover temp files. The cleaning operation uses temp files when it has to rewrite the entire file for safety. If it didn't a crash would cause file corruption instead.

Re: "Sanitize tags" issues

Reply #5 –
Is updating a playing file really a problem? I had an issue with attaching album art to playing files and I asked Peter why using public SDK code failed and using native context menu/properties dialog did not. He was using some previously internal only API but it has been available for some years now...

https://github.com/marc2k3/foobar2000-sdk/blob/main/foobar2000/SDK/file_lock_manager.h

Re: "Sanitize tags" issues

Reply #6 –
Quote from: Case on
Quote from: Mike_de on
Quote from: Mike_de on
Sometimes foobar crashes entirely, and upon restart, I'm told some components were damaged and I need to reinstall the program. Any suggestions?
I didn't alter the wording of the error message, just removed the path to the files as I deemed this irrelevant.
I meant the error message you get about component damage. That is not normal.

Quote from: Mike_de on
I've tried this a couple of times but the result remains the same:

https://imgur.com/a/SK1ksOz
This is not crashing. foobar2000 is telling you that the process has no permission to touch the files. Tag editing needs file system write access.

Quote from: Mike_de on
Then I used the ReplyGain scanner on this particular album and foobar crashed.
The crash log you attached was expected since you now have the debug option enabled that crashes on tagging failure. Thankfully it also reveals why you keep getting those "File is already in use" errors: you are playing the file you are trying to sanitize. That operation needs exclusive access to the file, you can't play a file when using it.

Looks like the error message about file being already in use is unrelated to your normal crashing. You can disable the debug option to crash on tag read/write error.

Only other submitted crash logs from you that I see are related to the Playlist Attributes component. If that component crashes during sanitation operation it could be the cause of the leftover temp files. The cleaning operation uses temp files when it has to rewrite the entire file for safety. If it didn't a crash would cause file corruption instead.
The thing is, all of this a) makes no sense or b) isn't correct. I wasn't playing anything while testing this. Besides, I didn't change anything on my system other than installing the new Foobar version. The old version never acted up like this. Never, not once in well over a decade!

On a side note, I provided two crash logs: one attached to this thread and one here. They're different. Just because they share the same name doesn't mean they're the same file.

Re: "Sanitize tags" issues

Reply #7 –
Quote from: marc2k3 on
Is updating a playing file really a problem?
For tag sanitizer it is. Has been for the separate component and still is for the built-in feature. Normal tag updating of course has been possible while playing close to forever.

Re: "Sanitize tags" issues

Reply #8 –
Quote from: Mike_de on
The thing is, all of this a) makes no sense or b) isn't correct. I wasn't playing anything while testing this. Besides, I didn't change anything on my system other than installing the new Foobar version. The old version never acted up like this. Never, not once in well over a decade!
Your imgur screenshot clearly shows "access denied" errors. That means access is denied. Only way such error can be shown is if access to the files is denied. foobar2000 bitness or version doesn't matter. What matters is the user account running the player or if the player is run with normal access token or elevated (as administrator).

I may be wrong about you trying to sanitize a file while it's playing. I made the assumption based on your posted crash log showing that you are playing a track that was just indexed by the media library before playback and indexed again very shortly after it was opened for playback. Media library should only index tracks initially or when the files change.

If you get the error about file being in use foobar2000 will not write those temp files. If it's not foobar2000 opening your files then foobar2000 minidumps can't detect who has the file open. But you can use Process Monitor to solve that.

I also don't know what's wrong with my comment about broken components. If foobar2000 reports such thing it would be helpful to see the exact error message it reported. And it absolutely is not normal for components to get corrupted. foobar2000 doesn't do that, broken hardware might. There have been some reports about configuration supposedly getting corrupted. At the moment it might be only related to 32-bit version running in undocumented low memory mode and still running out of memory.

Quote from: Mike_de on
On a side note, I provided two crash logs: one attached to this thread and one here. They're different. Just because they share the same name doesn't mean they're the same file.
I am well aware. That thread is about Playlist Attributes crashing. If the component has a crashing bug its author hopefully fixes it.