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 131729 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re: foobar2000 v2.0 bugs

Reply #300
2.0 Beta 12 fails to read my windows network share where my media library resides. The error text is "Unable to open item for playback (I/O error (win32 #24)):". Neither mounted drive nor UNC path works.
It has always worked fine with 1.x versions.
What Windows version and what kind of network shares (hosted on what machine)?
Which version of foobar2000, 32-bit or 64-bit? Does the other version work?
Error 24 is ERROR_BAD_LENGTH, sounds like a bug in my code, but can't quite figure out what it is and it doesn't seem to happen for anyone else.
foobar2000: 64-bit
Windows 10 21H2 with SMB/CIFS 1.0 compatibility package installed
The shares are hosted on a linux router, mounted read-only (can't tell the sort of the smb server, it's closed source, yet works ok with any windows app). Edit: R/W mount doesn't work either.
Didn't test it in foobar 32-bit.Edit: Foobar 32-bit fails with the same error.

Re: foobar2000 v2.0 bugs

Reply #301
Edit: This is a valid bug affecting other queries not just path, thanks for reporting. Will be fixed soon.
Oh thx! I have a lot of %path% filtering not working now.
%path% as part of the search index, what does it mean, why, what's the advantage, what can we use it for?

Re: foobar2000 v2.0 bugs

Reply #302
%path% as part of the search index, what does it mean, why, what's the advantage, what can we use it for?
It means that plaintext searches (ones without expressions/operators) scan file paths.

It also means faster searches including %path%, using full text index instead of testing one-by-one if each track in the library passes criteria. Your search query is internally translated to actual SQL expression if not using anything not supported by search index. Watch console output when performing search to see some basic feedback on library index operations.
Microsoft Windows: We can't script here, this is bat country.

Re: foobar2000 v2.0 bugs

Reply #303
Beta 15 posted.

Status:
Search bugs = fixed.
Playback statistics bugs = acknowledged, pending for next update.
Network share = please get beta 15, it will crash encountering this error and generate a bug report. Auto submit the report and I'll have a better idea what's going on.

Thanks.
Microsoft Windows: We can't script here, this is bat country.

Re: foobar2000 v2.0 bugs

Reply #304
Search bugs = fixed.

OK, I have enabled the new path/index advanced option now. Still problems with paths - in playlist:

- I've got a big playlist with tracks somewhere in "M:\Music\Klassik\Blah..."
- I've got ReFacets set to "Playlist" and this filter:

Code: [Select]
%path% HAS \Klassik\

Filter shows no entries in the Refacets. If I turn the filter off, all attributes of playlist entries appear.

Do I need to re-index maybe? (EDIT: No, no change)

Re: foobar2000 v2.0 bugs

Reply #305
When on Linux / wine some components miss foobar color scheme and are using system default.
See attached: "Selection Properties" and "Playlist Manager" properly use Blue color scheme whereas "Console" and "Album List" are not properly painted. The "Album List" seems to have texts properly colored, only the background unused by text remains white.
Same behavior in both 32- and 64-bit versions.
The bug is present in all betas (15 is the last tested).

Re: foobar2000 v2.0 bugs

Reply #306
I have 7z/rar's with .wma's inside which are not appeared in Album List in "by folder structure" view.
Also I have .zip's with many zxtune-associated file types. They also not appeared in Album List at all (in different view modes).
If I unpack them from .zip - all fine.
Also I have playlists from foobar 1.6 32 bit with parsed files from that .zip's - they played OK.
Tested on latest beta 15 - same.

Re: foobar2000 v2.0 bugs

Reply #307
Also I noticed big font in track properties tabs.

Re: foobar2000 v2.0 bugs

Reply #308
Beta 16 out

Change log

I'll skip change log copypasting and just say what is still pending investigation:
  • some playback statistics & rating glitches
  • Wine color glitches (but sadly Wine issues might be not easily fixed on my end...).
  • Directory Opus interaction.

If there's something else important that I missed, mentioned earlier in this thread, please repost.

I added splitter locking, but I'm not sure that's what some of you people are after. The ability to lock width/height of stuff was a bit of a side effect of old splitter implementation, I can add some other way to do this, without having to add splitter.
Microsoft Windows: We can't script here, this is bat country.

Re: foobar2000 v2.0 bugs

Reply #309
Peter
Seems files from zip/7z/rar archives fixed in Album List in "by folder structure" view in beta 16.
But not for file types registered in zxtune plugin.

When I do File->Add files.../Add folder... - zxtune-registered file types successfully added to playlist.


Re: foobar2000 v2.0 bugs

Reply #311
Thanks for these fixes, Peter!

Playback statistics bugs = acknowledged, pending for next update.
Do you plan to go back to non path-bound playback statistics? The new system is very inflexible. You can't move folders or files outside of foobar2k. And tracks in archives can't even be moved with the internal tool.

Re: foobar2000 v2.0 bugs

Reply #312
Many thanks!
- B16 has fixed my issues about filtering by path.
- Welcome change of the properties column font. I also didn't like the big one.

Re: foobar2000 v2.0 bugs

Reply #313
Foobar2000 2.0 Beta 16 - still the same bug in Directory Opus:

Selecting multiple audio files and hitting Enter in Directory Opus makes foobar2000 2.0 go through the audio files one by one and only playing the last one.

No such problem in foobar2000 1.6.

Re: foobar2000 v2.0 bugs

Reply #314
Thanks Peter. The locked splitters work fine that way. I can live with it, though I would point out the new method has disadvantages when resizing the window. i.e. Say you previously had 3x3 element layout, and wanted to lock the outside elements (to say 50px), with only the middle element scaling - this is no longer possible. On resizing / maximizing they all "scale proportionally" whereas previously the locked elements would keep a fixed width / height. (A minor issue I can live with like I said, but the old saying "if it ain't broke, don't fix it" kind of comes to mind ;) )

A few ReFacets remaining issues (aside from extra feature requests) -

I believe there needs to be a "Default sort order" option box in Preferences > Media Library > ReFacets (like Facets) - column library viewers need a way to sort the playlist. If user wants to auto- sort playlist by %date% for example, this is currently not possible. (Several mentions in ReFacets topic). ->
Are there plans to add the "Default sort order" option from Facets to Refacets so that the playlist view can be automatically sorted?

Toolbar buttons have black drop arrows. ->
UI glitch: In dark mode the Library and Filters dropdown uses black (=invisible) arrows.

Toolbar does not expand and locked toolbar reverts position on restart. ->
A toolbar glitch: The filter dropdown, selecting a new filter which has a longer character length doesn't increase the size of the box, so the dropdown selector gets hidden. If the width is manually increased (moving the search bar to the right), that's OK until FB2K is restarted, then it reverts back to the width of the currently displayed filter. Locking the toolbar doesn't help, it just makes it impossible to expand the dropdown.

Finally an old curiosity / glitch I noticed - there appear to be two styles of Album List? ... In View > Layout > Quick Setup, clicking through the "Main Layout" options, one Album List has grey background, while the other has white background. Also, add an Album List to a blank splitter = grey. Then use Replace UI Element on it with Tabs = white.

Re: foobar2000 v2.0 bugs

Reply #315
Thanks for these fixes, Peter!

Playback statistics bugs = acknowledged, pending for next update.
Do you plan to go back to non path-bound playback statistics? The new system is very inflexible. You can't move folders or files outside of foobar2k. And tracks in archives can't even be moved with the internal tool.

Vote for non path-bounding playback statistics. And I really don't want write ratings to the file.

Yesterday I changed folder name, and found all my song ratings in the folder were lost. Thousands of ratings were made by effort during these years, that was not Foobar2000 1.6 behavior. Please consider undo that.

As to saving ratings to the file tag, that's not a good choice for me at least. I would like foobar2000 to handle my playback statistics, not writing the file tag and change the file everytime I play it or rate it. Otherwise it would brings big trouble for me to do the file incremental backup, the file will be re-backup every it is modified, that's really silly. Please consider.

Re: foobar2000 v2.0 bugs

Reply #316
As to saving ratings to the file tag, that's not a good choice for me at least. I would like foobar2000 to handle my playback statistics, not writing the file tag and change the file everytime I play it or rate it. Otherwise it would brings big trouble for me to do the file incremental backup, the file will be re-backup every it is modified, that's really silly. Please consider.

foo_external_tags might be a thing for you? Tags in a database or in files in the same folder. Gives an opportunity to back up tags only.
https://foobar.hyv.fi/2.0/?view=foo_external_tags

Re: foobar2000 v2.0 bugs

Reply #317
As to saving ratings to the file tag, that's not a good choice for me at least. I would like foobar2000 to handle my playback statistics, not writing the file tag and change the file everytime I play it or rate it. Otherwise it would brings big trouble for me to do the file incremental backup, the file will be re-backup every it is modified, that's really silly. Please consider.

foo_external_tags might be a thing for you? Tags in a database or in files in the same folder. Gives an opportunity to back up tags only.
https://foobar.hyv.fi/2.0/?view=foo_external_tags

Thanks for the recommendation. I'll try it out. Still, it would be better if foobar2000 2.0 could undo that change.

Re: foobar2000 v2.0 bugs

Reply #318
Is there any news/update on the situation of ratings from previous installations being imported with decimals like 1.5, 2.5, 3.5 etc.? Is a fix coming or is the expectation that users re-apply all track ratings manually to fix it?

Also +1 for external tags, great component, my backup strategy would be a nightmare without it since I store stats in tags (for peace of mind.)

Thanks.

Re: foobar2000 v2.0 bugs

Reply #319
@Peter
No automatically reloading info from files when re-adding them into playlist (behavior no presented in 1.6.x) - https://hydrogenaud.io/index.php/topic,122970.0.html

Inconsistent appearance of Album List tree - https://hydrogenaud.io/index.php/topic,123169.0.html

Console UI element doesn't use theme color setting for background unless in dark mode.

I don't insist those are problems, but i would like to know if this is intended behavior.

Re: foobar2000 v2.0 bugs

Reply #320
Hello,

sorry if this has already been covered here. I have happily been using foobar2000 for many years. Unfortunately with the update to v.1.6.14 I was experiencing constant crahes. I have thus decided to upgrade to v2.0 beta16.

It seems if the problem with crashes is now gone, but most of my playback history is gone. I still have a copy of the v.1.6.14 installation. Should I try to install v2.0 again? Is there something I should keep in mind to successfully migrate the playback data to the new version or is this a known issue that will be resolved in future releases?

Re: foobar2000 v2.0 bugs

Reply #321
Foobar2000 2.0 Beta 16 - still the same bug in Directory Opus:

Selecting multiple audio files and hitting Enter in Directory Opus makes foobar2000 2.0 go through the audio files one by one and only playing the last one.

No such problem in foobar2000 1.6.
Right click, "Open in foobar2000" with multi selection = good behavior, my shell extension is invoked once with multiple files.
Hitting enter with multi selection = bad behavior, my shell extension is invoked multiple times with single files.
I'd have to wait for more files instead of starting playback instantly. Sounds to me like it's their bug not mine?
Microsoft Windows: We can't script here, this is bat country.

 

Re: foobar2000 v2.0 bugs

Reply #322
Foobar2000 2.0 Beta 16 - still the same bug in Directory Opus:

Selecting multiple audio files and hitting Enter in Directory Opus makes foobar2000 2.0 go through the audio files one by one and only playing the last one.

No such problem in foobar2000 1.6.
Right click, "Open in foobar2000" with multi selection = good behavior, my shell extension is invoked once with multiple files.
Hitting enter with multi selection = bad behavior, my shell extension is invoked multiple times with single files.
I'd have to wait for more files instead of starting playback instantly. Sounds to me like it's their bug not mine?

Very possible, but "their bug" is not present if using Foobar2000 1.6.

Hence something must have changed in Foobar2000 2.0 that specifically results in this "Hitting enter with multi selection = bad behavior, my shell extension is invoked multiple times with single files".

Re: foobar2000 v2.0 bugs

Reply #323
Very possible, but "their bug" is not present if using Foobar2000 1.6.

Hence something must have changed in Foobar2000 2.0 that specifically results in this "Hitting enter with multi selection = bad behavior, my shell extension is invoked multiple times with single files".
I rewrote the whole shell extension in v2.0, so the shell now talks to foobar2000 using a different protocol: IExecuteCommand instead of IContextMenu. This has many advantages, most importantly avoids unnecessary loading of our code into Explorer.exe and every other app invoking these shell ops.

Mitigation on my side is possible, at cost of degraded performance (wait for more files before taking action).

I already use such workaround when adding files from command-line: foobar2000.exe <path-to-file>. The whole point of implementing the shell extension is being able to reliably send multiple files without hacks or delays.

While Directory Opus is awesome technology, this really looks like their bug. By convention, pressing enter or doubleclicking should perform the same action as the bold command in the context menu, no? Here it clearly does something different.
Microsoft Windows: We can't script here, this is bat country.