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: foobar2000 v2.0 bugs (Read 131691 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re: foobar2000 v2.0 bugs

Reply #400 –
Quote from: Peter on
Regarding DSP changes-
For performance reasons, I made DSPs receive a 'flush' event when cycling tracks instead of total reinit.
Could this have anything to do with the VST plugins behaviour when the DSP chain is changed and new tracks played in v2 64-bit VST adapter .10.1?(https://hydrogenaud.io/index.php/topic,123342.msg1021139.html#msg1021139)?

Re: foobar2000 v2.0 bugs

Reply #401 –
Not sure if this has been reported but the seekbar seems to visually refresh (glitch, if you will) if you drag the blue indicator bar along it. It doesn't do this in the stable release. Thanks!

Re: foobar2000 v2.0 bugs

Reply #402 –
Quote from: Peter on
Regarding DSP changes-
For performance reasons, I made DSPs receive a 'flush' event when cycling tracks instead of total reinit.
This should be the same behavior as when seeking. If some DSPs handle this badly, they also handle seeking badly as far as I know.
Please report this as a bug to DSP authors. If the problem persists, I'll investigate reverting to the old behavior.
For MathAudio, that's a frequently used plugin and I will try to contact the author when I am able.

However, I don't think the other author still supports the Stereo Convolution plugin. The link in the about section is dead. If the new DSP behavior is here to stay, that means I'm effectively stuck on beta 20 forever since the plugin is essential to me.

Regardless, thank you so much for your hard work. I appreciate and value everything you have done to create and support foobar2000.
Think millionaire, but with cannons.

Re: foobar2000 v2.0 bugs

Reply #404 –
Quote from: Bogozo on
Quote from: Cannonaire on
I don't think the other author still supports the Stereo Convolution plugin.
foo_dsp_stereoconv was recently recompiled by Case for fb2k v2 - https://foobar.hyv.fi/2.0/?view=foo_dsp_stereoconv
Whoa! I had no idea! Thank you! :D

It looks like it still has the popping problem with v2.0 beta 23 as expected, but I will contact CASE when I am able to see if they can solve the issue.
Additional information: Seeking shows no signs of popping with it in beta 20.
Think millionaire, but with cannons.

Re: foobar2000 v2.0 bugs

Reply #405 –
@Peter: will v2 32 & 64 bit also be receiving the option to not apply the new DSP flushing action when changing tracks, as you have now done for 1.6.16 (and thank you for that!)?

Re: foobar2000 v2.0 bugs

Reply #406 –
Quote from: Raznurok on
Not sure if this has been reported but the seekbar seems to visually refresh (glitch, if you will) if you drag the blue indicator bar along it. It doesn't do this in the stable release. Thanks!
Yes, I can confirm, this happens here too.
Beta 23, Windows 10, AMD cpu and dgpu.

Re: foobar2000 v2.0 bugs

Reply #407 –
foobar2000 v2 beta23
Ubuntu 22.04.1

Last modified (edited) and Created are equal.
Media Library is broken.
SHURE SRH1840, SENNHEISER HD660S2, SENNHEISER HD 490 PRO, DT 1990 PRO, HiFiMAN Edition XS, Bowers & Wilkins P7, FiiO FT5, 水月雨 (MOONDROP) 空鳴 - VOID, Nakamichi Elite FIVE ANC, Bose QuietComfort 45 (made a Upgrade/Balanced Cable by myself)

Re: foobar2000 v2.0 bugs

Reply #408 –
Hi,
fb2k v2.0 beta 23 64bit Win 10

no full start of foobar - no music where be shown, fb2k not fully loaded - no error.log

media library is broken (content.sqlite is greater 50MB) from external drive
after deleting this file foobar starts normally.
After re-reading and external drive is off:
no full start of foobar - no music where be shown, fb2k not fully loaded - no error.log

Re: foobar2000 v2.0 bugs

Reply #409 –
Has anyone else noticed an issue with seek speed in 2.0? Not seen this happen in the stable version but beta 23 (at least) sometimes has a noticeable pause whilst seeking. A restart sometimes fixes this but not always. Not sure what triggers this as it'll sometimes go away on its own, and it happens with both local files and files on a network drive.

Re: foobar2000 v2.0 bugs

Reply #410 –
Hi, I'm receiving an error message after the clean installation of v2.0 beta 23 64bit Win 10 because the file shared.dll could not be found during the start of foobar.
With Beta 17 and less it is working. I have recognized that this version uses the timestamp 09.12.2022 14:13 for shared.dll and 09.12.2022 14:14 for foobar2000.exe which means that the file shared.dll is older.

With Beta 23 both files are using the timestamp 13.01.23 12:36

Re: foobar2000 v2.0 bugs

Reply #411 –
1. playlist: groups; Abrupt jumps by changing something that affects the said group's text.
2. On low memory mode editing tags doesn't do at first, must has try again to actually applies its tags.

Regards

Re: foobar2000 v2.0 bugs

Reply #412 –
Beta 24 and still have this annoyance.
whenever i change the text on the groups, the playlist jumps to whatever position losing completely the tracking where i was.

edit reason: typo on beta number.

Re: foobar2000 v2.0 bugs

Reply #413 –
Quote from: beat8000 on

With Beta 17 and less it is working. I have recognized that this version uses the timestamp 09.12.2022 14:13 for shared.dll and 09.12.2022 14:14 for foobar2000.exe which means that the file shared.dll is older.


I have just changed the timestamp of the file shared.dll after the Beta 24-x64 installation to 18.01.23 15:25 but I'm still receiving the same system error "... shared.dll missing..." in German.
I assume that there is another error because the file obviously is existing.

Re: foobar2000 v2.0 bugs

Reply #414 –
Quote from: beat8000 on
Quote from: beat8000 on

With Beta 17 and less it is working. I have recognized that this version uses the timestamp 09.12.2022 14:13 for shared.dll and 09.12.2022 14:14 for foobar2000.exe which means that the file shared.dll is older.


I have just changed the timestamp of the file shared.dll after the Beta 24-x64 installation to 18.01.23 15:25 but I'm still receiving the same system error "... shared.dll missing..." in German.
I assume that there is another error because the file obviously is existing.
I have just found a workaround for this system error.
During the update e.g. from Version 17-x64 to 24-x64 the optional features must be switched off during the first custom install. Afterwards a second install with activated optional features will complete the install without the shared.dll system error immediately or after the next Foobar start.

Re: foobar2000 v2.0 bugs

Reply #415 –
Crossposting this possible bug report to this thread, as this may have been the better place to put it:

Quote from: Takaji on
I'm not exactly sure when this behaviour started (possibly when I switched to foobar2000 v2.0?), but I've noticed that if I modify the %album% tag of an album, then %added% also changes to the date that I modified the tags - I assume because the database sees this as a new entry. Is there a way to disable/fix this?

I thought maybe the playback statistics database would've relied on another way of identifying a track/album instead of by the tags - perhaps by a hash or something like this?

I noticed a typo in an album title, and now %added% shows that the album was added to my library today, instead of back in 2018. I have an autoplaylist which organises my music by %added%, and this then gets messed up.

Quote from: Takaji on
I can confirm that this is happening with 2.0 beta 24 and foo_playcount 3.1.3.

Steps to reproduce:
1. Change the title of an album (%album%) in the media library (in this case I added "(Test)" to the end of the album name)
2. Playback Statistics field will show an Added date that reflects when you changed the album name.

Changing the album name back to its original value restores the correct playback statistics.

Re: foobar2000 v2.0 bugs

Reply #416 –
I am not an expert user but apparently updating foobar to 2.0 I lost the ability to play.iso dsd files that i could previously play and convert - despite my trying I cannot get the grayed out components to play again. Any help?
Thanks
Burgundio

Re: foobar2000 v2.0 bugs

Reply #418 –
At the end of a big move job, fb2k (edit: x64 beta 24) will for hours and hours stay "unresponsive" but not completely:

* In the alt-tab cycle the main window shows up, but I cannot select it.
* I mouseover the icon in the taskbar it shows that there is a (edit:) File Operations Setup window that I cannot access.
* CPU usage stays at 12 to 15 percent; I have 8 threads, so I can only guess that it occupies one thread doing its thing and then a little bit on something else

But after fighting the task bar a little bit, I get
* this blank "window"-alike thing (to the left in the picture)
* and then to play music! And skip tracks and ... (to the right)



Re: foobar2000 v2.0 bugs

Reply #419 –
Hi, I want to report a bug (x64 Beta 24):

The option "Save playback state when closing foobar2000 and resume on next startup" doesn't work. Whenever I play a track, close foobar, reopen it, the track starts from the beginning again.

Re: foobar2000 v2.0 bugs

Reply #421 –
I just noticed it *does* work if I launch foobar2000.exe, rather than the mp3 file directly. I thought the latter should work, too. My mistake I guess.
 

Re: foobar2000 v2.0 bugs

Reply #424 –
Another MD5 issue, with WavPack calculating it in the same endianness as the source file. It seems that foobar2000 - like FLAC - calculates it little-endian, and so fails to verify these WavPack files.
The problem has been around ever since WavPack got CAF support, but the combination foobar2000, CAF, WavPack and MD5 is scarce. Now with WavPack supporting AIFF, it could happen more often - indeed this is an issue I discovered upon verifying some of my encodes - some artist gave me something that was in AIFF - not thinking it up first and trying to provoke it (although I should have!).

foobar2000 does handle how FLAC and WavPack differ in MD5 for unsigned signals (that is, 8-bit WAVE), so I guess it is intended to verify the files that are indeed OK.


As for TAK: foo_input_tak makes MD5 show, after reloading tags - and I can then remove the component as long as I don't reload tags from files once again.