1)
Playlist management is screwed up, "Load Playlist" doesn't work properly. It replaces the first two items with the name of the playlist file (ex: Test1.fpl) and rearranges the items in the playlist.
(http://i.imgur.com/Yd24nwO.png)
(http://i.imgur.com/Cz1ItSl.png)
2)
If I add items manually they convert but when I drag&drop from the library it gives "Object not found" error. Even for the playback.
I just did re-add the library from scratch, all seems fine now.
False alarm, when foobar2000 is restarted the library is gone, all items are missing from playing or converting.
3)
Loading time goes from 0.00:44 to 0.00:33 (which is good). Memory usage is the same, ~46MB.
"Also, selecting a large number of tracks and going to "properties" takes ages, as it indexes each file. This operation used to be near-instant."
Exactly. This is massively annoying.
I selected 176.000 files, instead of a few seconds it took 4m50s.
Memory usage is ~650MB until unselected, more than double than before.
The taskbar icon is green as if it was still processing something (maybe because foobar2000 nearly crashed before showing the properties dialogue).
It goes away after selecting another file and viewing its properties.
Memory usage after that is ~435MB, still a lot more than before.
This needs to be resolved, the main point of this update was to make foobar2000 more suitable for large databases, the opposite happened.
Also, the media library is still initializing, long after I started the program.
Loading properties for the first time on 50,000 files takes about 5 seconds on my i3-3220 3.3GHz with 8GB of RAM. All of the tracks are on a 1TB WD Black Edition, one of the faster HD's when it came out. I don't have any lyrics, and less than half have any sort of comments tag.
The library searches I've tried are instantaneous. This seems faster than before, but I can't be sure because I recently upgraded my cpu, so I'm often surprised by how fast most operations seem nowadays.
I imagine it's worth mentioning if you have any autoplaylists, playlists, or other library viewers, as well as how many, their size, etc. I use one playlist and no autoplaylists (I keep them listed in a WSH panel, and open them as needed). With entire library listed in a Facets panel, all selected, and Properties open, I'm using only 100MB of RAM.
I've noticed a big improvement in startup times for my portable install (went from 1.24 to 1.3). To follow DustMagnet:
Loading properties for the first time on 10,000 files takes about 1 second on my AMD FX-8120 with 8GB of RAM (foobar2000 is on Samsung SSD, tracks on Seagate 7200 HDD). It's noticeably snappier at startup with 3 large autoplaylists and also running Yirkha's foo_dynfil (doing some calcs -- don't know if that's benefited from recent changes).
Thanks Peter.
C.
Playlist management is screwed up, "Load Playlist" doesn't work properly. It replaces the first two items with the name of the playlist file (ex: Test1.fpl) and rearranges the items in the playlist.
Fixed for the next version, thanks for reporting.
Peter, possible bug (certainly a change in behaviour from previous versions):
Situation:
Drag and drop playlist tracks from one (v.1.3) installation of foobar2000 to another (in this case 1.2.9):
Previous behaviour:
The playlist track order used to be maintained across the different installations (say a portable to your main installation);
Since 1.3
Now the tracks get re-ordered, seemingly by %path%.
C.
Peter, possible bug (certainly a change in behaviour from previous versions):
Situation:
Drag and drop playlist tracks from one (v.1.3) installation of foobar2000 to another (in this case 1.2.9):
Previous behaviour:
The playlist track order used to be maintained across the different installations (say a portable to your main installation);
Since 1.3
Now the tracks get re-ordered, seemingly by %path%.
C.
Thanks for the report - this is another symptom of the "load playlist" bug reported earlier. Already fixed.
On my portable installation, the update doesn't work at all. It says that it does not have access to the files when I want to play one. The status of the library is "error". When I delete the library and add it again it works but only till the next start of Foobar2000. Then the same happens again.
On my portable installation, the update doesn't work at all. It says that it does not have access to the files when I want to play one. The status of the library is "error". When I delete the library and add it again it works but only till the next start of Foobar2000. Then the same happens again.
Exactly like my 2nd point, it's the one of the most important features.
And that's probably another symptom of the playlist load failure?
Folder monitoring doesn't seem to work properly. I unpacked a few folders, both my automatic folders with a Path or with a search string still show the deleted archives, but don't show the upacked files.
This is a big issue, I hope this gets fixed soon.
Can't edit my post, but monitoring seems to work, but takes ages (1 or 2 hours for ~800MB packed folders).
The beta shows a message "Cannot write changes to the library (access denied)" every time I close it.
lyrics seem to be broken. The field shows up in the properties panel with a content of ".". The track properties dialog (after F2) shows the content correctly.
Upon opening the working set of foobar2000 1.2.9 is approx. 172k and pretty steady.
Upon opening the working set of foobar2000_v1.3_beta_1 starts at about 270k and grows to 400k within a few seconds.
The console has a very long list of items like
"Location not parsable: "\Zips\...", reason: Object not found"
apparently one per item on the disk where my portable install of foobar2000 exists.
Perhaps it's related to one of my library music folders being "..\" (since I install foobar2000 at the top of my music library.)
When loading a playlist file (in this case a m3u) in v1.3 Beta so does it pop up at the bottom of fb2k playlist window and sometimes so doesn't the track number show even if they are available in the tags.
(http://i.imgur.com/GgDQZQZ.png)
Beta 2 will be out at the end of the week.
Various bugs (crashing, bad behavior of playlist loader, "object not found" spree when using relative paths in Media Library) will be corrected, thanks for the feedback.
The future of changed lyrics etc tag handling is yet to be determined. If this change bothers you, please stick with 1.2.9 until this is sorted out one way or another. Properties dialog opening causing reload of info from your whole library is indeed unacceptable.
Nice. Please consider adding the COMMENT field to the database, or at least make it longer.
A lot of people (like me) use it to store the tracklist of mixes. It is now impossible to search for those tracks.
If you don't want to do that, add an option to make that possible for people like me (with the obvious consequences regarding memory/speed).
I guess the correction covers this as well, but just wanted to inform, if not.
Media Library:
Path = ..\..\..\Opus
Status = Error!
The beta shows a message "Cannot write changes to the library (access denied)" every time I close it.
I'm not getting it on close, but I am getting it sporadically while foobar2000 is running. Clicking Retry usually works, but sometimes it comes back up two or three times.
Nothing is showing up in my console log about this, so I don't know if there's some kind of debugging I have turned off that would help.
i just moved from 1.1.18 to 1.3 (was afraid of ffmpeg quality a little bit). "Generic performance optimizations, mainly affecting very large playlists and libraries." and "Playlist & Media Library search dialogs no longer block UI when performing lookups." motivated me to upgrade... and have to say that i'm disappointed. after start foobar is using my hdd like crazy for some noticible time, without any information in console of whats going on, and searching in music lib is not faster at all! however when i search there i noticed huge ram usage and program ui still freezes. can't see any improvements, but since its beta i will just be patient and hope for more polishing.
by the way, how do i remove ugly speaker icon next to volume control on status bar? keep up the good work and thanks for foobar in general!
except for the start, foobar behaves exactly as in the post above
after starting, foobar uses 200mb ram. when searching, at least 9 times out of 10, ui freezes right after typing the first letter and if it doesn't freeze it lags
furthermore ram usage spikes to 320 mb and drops to 200 again as soon as the freeze/lag is over
funny thing, because yesterday it worked way better (better, however not 'good')
additionally, yesterday foobar crashed (not responding) for the first time in a long time. i actually can not recall when it did the last time.
this happend when i was moving files around. i forgot that 'move everthing in the source folder' was checked...foobar had to move 6+ gb...
unfortunately, i didn't send the crash report
PAUSE doesn't work as expected.
Foobar 1.3b1 paused restarts itself after a certain amount of time (not always the same).
Problem never seen before.
Regards, Andrea
I'm not getting it on close, but I am getting it sporadically while foobar2000 is running.
Yeah, that happens to me, too.
PAUSE doesn't work as expected.
Foobar 1.3b1 paused restarts itself after a certain amount of time (not always the same).
Problem never seen before.
Regards, Andrea
I can verify this also.
Beta 2 out : bug fixes + made the properties dialog behave more gracefully with large libraries again.
Re pause issue:
Sorry, cannot reproduce this issue, please start a thread in tech support, following tech support guidelines (full list of components etc).
Hi,
With the new beta versions, a problem has appeared for me.
When foobar starts up and no file is playing:
1. If I double click on a file in the playlist it plays fine, however at the end of the track it goes to the
next track but then immediately skips to the next and the next, till the end of the playlist. while it does this I can hear tiny bits of the songs being played.
I say tiny but I mean 100th of a seconds worth.
2. If i click the play button or the random playback button it selects a track and then begins to skip immediately to the next track as above. it does not play the first track at all.
this happened with beta 1 as well
scrub all that it was foo_skip tracks that was causing the problem!
Sorry, I should have checked first.
It seems all good now, thank you Peter. Will keep using beta 2 and testing.
Why the new one creates the folder "playlists-v1.3"?
It seems all good now, thank you Peter. Will keep using beta 2 and testing.
Why the new one creates the folder "playlists-v1.3"?
The new format of playlists is incompatible with older foobar2000 versions. The existing playlists & Media Library data is kept for downgrade compatibility, so if you install 1.2.9 again, you'll see the last written pre 1.3 playlists & library.
Perfect, that's what I thought. Thank you.
1.3 Beta 1:Peter, possible bug (certainly a change in behaviour from previous versions):
Situation:
Drag and drop playlist tracks from one (v.1.3) installation of foobar2000 to another (in this case 1.2.9):
....
C.
1.3 Beta 2Peter this has been "fixed" (maybe -- because I never tested 1.3 to 1.3) ONLY if the other version is 1.3.
So 1.3 beta 2 hasn't fixed the following: Drag and drop playlist tracks from one (v.1.3) installation of foobar2000
to another (in this case 1.2.9):Previous behaviour:The playlist track order used to be maintained across the different installations (say a portable to your main installation);
Since 1.3Now the tracks get re-ordered, seemingly by %path%.
C.
EDIT: spelling
carpman, the issue is fixed with beta 2. I tested it less than a minute ago and it's all good.
Well I hate to break it to you, but I just dragged and dropped a list of files from foobar2000 1.3 BETA 2 to:
a) foobar2000 v1.14 portable, and
b) foobar2000 v1.26 portable
And previously with foobar2000 1.3 BETA 1
The same drag and drop to:
c) foobar2000 v1.14
d) foobar2000 v1.29 (non portable)
And the files were re-ordered by path in all instances.
So I appreciate your reassuring words eahm, unfortunately they don't match my reality.
I doubt this has any bearing on the matter, but just in case Peter:
OS: Windows 7 x64
Let me know if you need any other details.
C.
Clarification: playlist loading bug only affected dropping files to foobar2000 1.3 beta 1 and it's gone in beta 2. Reordering when dragging between different foobar2000 instances is a separate matter and will be looked into, thanks for reporting.
The "cannot write to library (Access Denied)" problem re-appeared.
Playlist search behaviour is weird when searching for something and then changing the playlist tab.
The current beta does not seem to support MPEG-DASH files, feeding them to foobar2000 will result in the following console message:
Location not parsable: "D:\Music\various_artists\test_dash.mp4", reason: Unsupported format or corrupted file (array access out of range)
Format : dash
Codec ID : dash
ID : 1
Format : AAC
Format/Info : Advanced Audio Codec
Format profile : LC
Codec ID : 40
The header for MPEG-DASH files reads:
ftypdash iso6mp41
DASH files play fine in Media Player Classic - Home Cinema.
The audio can be extracted with MP4box and muxed into a regular MP4 container to make them play in foobar2000, but that's a bit cumbersome
Clarification: playlist loading bug only affected dropping files to foobar2000 1.3 beta 1 and it's gone in beta 2. Reordering when dragging between different foobar2000 instances is a separate matter and will be looked into, thanks for reporting.
Perfect, thanks. I couldn't reproduce that exact problem and I thought it was related with the playlist issue in beta 1 and was already fixed in beta 2.
I've sent few crash reports about this:
- Add playlist (radio for example, like radio paradise from here: http://www.radioparadise.com/rp_2.php?#name=Listen) (http://www.radioparadise.com/rp_2.php?#name=Listen))
- DON'T LOAD/PLAY the playlist
- Right click, Properties
- foobar2000 crashes.
Is foobar2000 getting slower opening internet streams? It may be just placebo but it seems to me, I've just tested XMPlay and the time is the same, again, it may be just placebo and probably is because foobar2000 is still a beta.
I've sent few crash reports about this:
- Add playlist (radio for example, like radio paradise from here: http://www.radioparadise.com/rp_2.php?#name=Listen) (http://www.radioparadise.com/rp_2.php?#name=Listen))
- DON'T LOAD/PLAY the playlist
- Right click, Properties
- foobar2000 crashes.
Is foobar2000 getting slower opening internet streams? It may be just placebo but it seems to me, I've just tested XMPlay and the time is the same, again, it may be just placebo and probably is because foobar2000 is still a beta.
Yep, the same happens to me, using beta 2.
I've sent few crash reports about this:
- Add playlist (radio for example, like radio paradise from here: http://www.radioparadise.com/rp_2.php?#name=Listen) (http://www.radioparadise.com/rp_2.php?#name=Listen))
- DON'T LOAD/PLAY the playlist
- Right click, Properties
- foobar2000 crashes.
Is foobar2000 getting slower opening internet streams? It may be just placebo but it seems to me, I've just tested XMPlay and the time is the same, again, it may be just placebo and probably is because foobar2000 is still a beta.
Beta 3 fixes the issue. Thank you Peter.
Peter, FYI (I'm sure you know ... but):
http://www.hydrogenaudio.org/forums/index....st&p=848264 (http://www.hydrogenaudio.org/forums/index.php?showtopic=103083&view=findpost&p=848264)
Not fixed in Beta 3.
C.
so am i the only one experiencing very intense hdd work with recent foobar betas? and according to console, nothing is going on...
Peter, FYI (I'm sure you know ... but):
http://www.hydrogenaudio.org/forums/index....st&p=848264 (http://www.hydrogenaudio.org/forums/index.php?showtopic=103083&view=findpost&p=848264)
Not fixed in Beta 3.
You have to help me here, I am trying to reproduce the issue but I can't.
Here's what I do:
- Install 1.3.0 beta 3 portable on D:\foobar200013
- Install 1.2.9 portable on D:\foobar200012
- Load one album on foobar2000 1.3.0 beta 3
- Don't grab the full album from the title but grab songs 1 to 6 for example
- Drag&drop them to 1.2.9
- I see 1 to 6 like I see them on 1.3.0 beta 3
What am I missing?
Spurious/oversized metadata such as whole EAC logs entries are now dropped from foobar2000's cache, for better search performance and lower resource usage.
Beta 3: the feature is now customizable by editing LargeFieldsConfig.txt in foobar2000 profile folder.
How can I edit LargeFieldsConfig.txt if I want the facets filter to search lyrics? I tried to include lyrics in the "list of basic meta fields" and increasing the basicMetaMax up to 100000 but it doe not seem to do anything.
i hope you restarted like it said? i just deleted both lists and set the defaultMetaMax to a high value. and it now displays fields that beta1&2 did not. (edit: when i say "it", i mean 3rd party components)
i don't even use large fields but i do need it for testing certain things i mess around with and it's now working fine for me.
Of course I restarted. I tried to delete both lists as you did and increased defaultMetaMax to 10000000 and it still doesn't work.
Re LargeFieldsConfig.txt
You also need to forcefully reload info from your whole library content for this to take effect. E.g. by opening the Properties dialog and using the appropriate command from the Tools menu.
Re drag and drop to an old version
I've found the exact bug, unfortunately it needs to be fixed in the fb2k instance receiving drops. It currently occurs only when dragging from a newer version to an older one. If there's one more 1.2.x update with bug fixes, I'll be sure to include this fix.
Thanks again for reporting it.
Re LargeFieldsConfig.txt
You also need to forcefully reload info from your whole library content for this to take effect. E.g. by opening the Properties dialog and using the appropriate command from the Tools menu.
Ok it worked by reloading the info. However this info is cleared upon restarting foobar2000. Is there a way to make it permanent?
Here's what I do:
- Install 1.3.0 beta 3 portable on D:\foobar200013
- Install 1.2.9 portable on D:\foobar200012
- Load one album on foobar2000 1.3.0 beta 3
- Don't grab the full album from the title but grab songs 1 to 6 for example
- Drag&drop them to 1.2.9
- I see 1 to 6 like I see them on 1.3.0 beta 3
What am I missing?
You're testing to see if 1.30 sends over the tracks to 1.29 in %path% order by dragging a selection of files already in %path% order and wondering why they are still in %path% order. Try a completely random set of tracks and then put z:\zzz\zzz\zzz\zzz.mp3 at the top of that playlist and see if it's at the top once dragged from 1.3 to 1.29.
C.
I've found the exact bug, unfortunately it needs to be fixed in the fb2k instance receiving drops. It currently occurs only when dragging from a newer version to an older one. If there's one more 1.2.x update with bug fixes, I'll be sure to include this fix.
Thanks again for reporting it.
Personally, I'll just update the older versions to 1.3's. Thanks for looking into it.
C.
Monitoring doesn't seem to be working..ripped a couple of cd's to library and had to restart FB to get them to show in media library
Re LargeFieldsConfig.txt
You also need to forcefully reload info from your whole library content for this to take effect. E.g. by opening the Properties dialog and using the appropriate command from the Tools menu.
Ok it worked by reloading the info. However this info is cleared upon restarting foobar2000. Is there a way to make it permanent?
OK this is in fact tougher than I thought.
1. Edit LargeFieldsConfig.txt
2. Start foobar2000.
3. Reload info from every track in existence, playlist or library.
4. Delete 'library' subfolder of your profile folder -
while foobar2000 is still running after having reloaded info.
5. Close foobar2000, causing it to save its configuration.
Now the changes should stick. Thank you for your patience. I'll be sure to put better info about this in the txt file.
> Now the changes should stick. Thank you for your patience. I'll be sure to put better info about this in the txt file.
How about making the whole thing easier?
For example, I want to add the whole COMMENT field to my DB. Why not add a page into preferences where you can add/modify the fields?
Monitoring doesn't seem to be working..ripped a couple of cd's to library and had to restart FB to get them to show in media library
I can confirm this in beta 3.
Monitoring doesn't seem to be working..ripped a couple of cd's to library and had to restart FB to get them to show in media library
I can confirm this in beta 3.
Same here.
Since 1.3 beta 1 setting album rating in Facets works buggy.
i.e. setting an album completely 5 rated: the album gets cluttered in a way that it appears twice in its column, one part with only 1 track of the album is shown 5 the second part remains unrated. The rating itself works - it's a display problem.
Used Column Pattern: >>>$if2(%rating_stars_fixed%,' ')<<<
This worked fine with Facets in all versions before 1.3
Edit: Existing rating is displayed fine - effect is only with new rating
> Now the changes should stick. Thank you for your patience. I'll be sure to put better info about this in the txt file.
How about making the whole thing easier?
For example, I want to add the whole COMMENT field to my DB. Why not add a page into preferences where you can add/modify the fields?
Any alteration of large field handling scheme requires foobar2000 restart and complete reload of info from all your files. You're not expected to alter this setting on daily basis; it is a pain to do and will always be just because of the workload fb2k must perform for the new configuration to take full effect. I hope we can come up with reasonable defaults so 99% of our users never have to touch that file.
Re Media Library no longer noticing changes - acknowledged, investigating it now, thanks for reporting.
I am absolutely loving these new updates and the control I now have over the caching of metadata.
However, I can confirm the fact that the Media Library doesn't automatically update itself when new items are added. Once this is fixed, there will be no reason for anyone not to update.
Beta 4 up.
Beta 3 Media Library monitoring regression has been corrected.
Editing LargeFieldsConfig.txt now triggers a behind-the-scenes reload of info from your whole Library + Playlists content.
Beta 4 up.
Beta 3 Media Library monitoring regression has been corrected.
Editing LargeFieldsConfig.txt now triggers a behind-the-scenes reload of info from your whole Library + Playlists content.
Thank you!!! Monitoring is functioning once again! Thank you!!
Beta 4 up.
Beta 3 Media Library monitoring regression has been corrected.
Editing LargeFieldsConfig.txt now triggers a behind-the-scenes reload of info from your whole Library + Playlists content.
Thanks !
I was so confused I thought there was a problem with every AAC encoders I was using. 1.3 beta doesn't show "+PS" in the "Codec profile" field when the AAC is HE v2. 1.2.9 works.
I was so confused I thought there was a problem with every AAC encoders I was using. 1.3 beta doesn't show "+PS" in the "Codec profile" field when the AAC is HE v2. 1.2.9 works.
Thanks for reporting. Something has gone funny with our FFmpeg patches as stock FFmpeg doesn't support AAC profile detection at all, I will look into it.
Wow, seeing all these bug reports make me feel very lucky - IN YEARS of using foobar2000 I've had right next to zero issues, and I have pretty large library and huge amount of large playlists. So to comment on the last beta all I can say it's much, much faster (startup, shutdown and search). Upgrading from 1.2.9. Awesome.
Wow, seeing all these bug reports make me feel very lucky - IN YEARS of using foobar2000 I've had right next to zero issues, and I have pretty large library and huge amount of large playlists. So to comment on the last beta all I can say it's much, much faster (startup, shutdown and search). Upgrading from 1.2.9. Awesome.
Final versions are always really stable, usually only betas have bugs because he implements new features
LargeFieldsConfig.txt
Will this untypical way of setting preferences in foobar2000 remain in further releases or will the settings be placed in advanced preferences?
^it's already been discussed.
How about making the whole thing easier?
For example, I want to add the whole COMMENT field to my DB. Why not add a page into preferences where you can add/modify the fields?
Any alteration of large field handling scheme requires foobar2000 restart and complete reload of info from all your files. You're not expected to alter this setting on daily basis; it is a pain to do and will always be just because of the workload fb2k must perform for the new configuration to take full effect. I hope we can come up with reasonable defaults so 99% of our users never have to touch that file.
From what I've heard, that setting wasn't originally something that was meant to be changed. It's not meant to really be changed often, if at all. And from what I've heard, it's not going to have an in-player editor, so that's why it's in a text file instead of Advanced Preferences.
LargeFieldsConfig.txt
Will this untypical way of setting preferences in foobar2000 remain in further releases or will the settings be placed in advanced preferences?
I would also want this resolved differently if possible. Media library glitch was surprise, but I hope that in stable we wont need to handle text files for new features as we aren't running Linux
the addition albums of file explorer:
(https://dl.dropboxusercontent.com/u/23231705/images/____from_explorer.png)
the addition albums from library:
(https://dl.dropboxusercontent.com/u/23231705/images/____from_library.png)
albums have been recently added to the library. deleted a folder library and index-data. restarting foo, no changes. v1.3 beta 4
*albums have been recently added to the library.
they were downloaded from torrent into folder library when foobar2000 played
with other albums (which have long been added) - no problems
they were downloaded from torrent into folder library
Don't do that.
they were downloaded from torrent into folder library
Don't do that.
to version 1.3 I had not a similar problem (~8 years)
old bug present since "close minimizes" was introduced:
Default user interface>Minimize to notification area - unticked
Advanced>Display>Default user interface>Close minimizes - ticked
In theory with this setting "minimize" should minimize to start bar, but "close" should send app to tray. but foobar will go to tray only if the first checkbox is ticked... and then its impossible to hide app to start bar.
hope i described it clear enough.
The "Access denied" problem has yet to be fixed.
Looking forward to the final release of Foobar 1.3.
I'm really happy about the changes related to large library handling.
I have around 120K FLAC files in my library and Foobar was really struggling with the library - most of the time it was not able to save the library during exit.
The problem is that some utilities save audio analysis/fingerprint data (AcoustID info) in file TAGs and Foobar was loading all this info into the cache making it huge and full with useless info.
A couple of years ago I posted a question if it was possible to prevent Foobar from reading specific TAGs into the cache and I was told it was not possible.
As a workaround I ended up splitting my Music folder into multiple separate library folders by letter (e.g. Music\A, Music\B and so on) which solved my problem temporarily and allowed Foobar to save the library on exit successfully - most likely Foobar is creating a separate cache per library folder internally.
But even so, handling remains quite slow and memory consumption is quite large (around 600MB). I'm glad to see these issues are currently being addressed - thanks for making this great product even better!
In v1.3 beta 4: If I tag an album with the Musicbrainz plugin, I'm unable to Replaygain it. Each file produces a "Could not update tags (File is already in use)" error message. Restarting foobar2000 fixes it.
As mentioned there is a dot in large fields when loading whole library to properties dialog. Nevertheless i cann see the full lyrics when opening just few albums. Is there a limit of tracks?
EDIT:
Another question: is There another difference than the size limit for meta fields between basic meta fields and those that don't appear in neither list? And what happens if the size exceeds in one field?
Beta 5 looks good to me, my only issue was the SBR+PS tag.
PS
The website has a typo, beta 5 instead of beta 4 on 2013-10-31.
As mentioned there is a dot in large fields when loading whole library to properties dialog. Nevertheless i cann see the full lyrics when opening just few albums. Is there a limit of tracks?
I assume you want to look at the new feature "Preferences/Advanced/Display/Properties dialog/Always preload complete info up to N tracks"
This reported behavior (http://www.hydrogenaudio.org/forums/index.php?showtopic=103083&view=findpost&p=848704) still exists in beta 5 - had to go back to 1.2.9 again.
beta 5 bug report:
LargeFieldsConfig doesn't appear to work if the field ends in a space. (I'm trying to cause "XID " (trailing space) to not cache.)
HI
I noticed some cosmetic change in UI. Properties panel if docked shows in place of multiline comment only dot. I know this wasnot in older version. Can this plz be reverted back to old fashion (or configurable style whichever user prefers) so that I could always see first line of comment (optionally followed by ellipsis if multiline)
Properties panel if docked shows in place of multiline comment only dot.
I can not reproduce that behaviour with beta5. So it might be only in certain situations. I did not use 1.3 beta with my "big" library yet.
Peter, maybe you would care to drop a few lines about what the entries in LargeFieldsConfig.txt make foobar2000 1.3 do. (either here of in the file itself) Like, are the max values per field or for the whole group? Do they affect playlists or just the library database? A little bit of understanding could prevent us to do unnecessary or stupid things to our LargeFieldsConfig :-)
BTW should early beta testers delete (or rename) their LargeFieldsConfig.txt when updating to get the new defaults? (I did just in case).
FWIW some maybe useless tags I found, that may be common, were ISRC, ENCODER, ENCODED BY. Also personally I don't care much about totaldisc and totaltracks although I usually keep those tags.
Possible Spam fields:
ACOUSTID ID (MusicBrainz' latest audio fingerprint) <- It is still findable through %spamfield% PRESENT, right?
ASIN (Amazon ID)
BARCODE
COMMERCIAL INFORMATION URL
FBPMQUALITY
MUSICBRAINZ TRM ID (MusicBrainz' oldest audio fingerprint)
MUSICIP PUID (MusicBrainz' second audio fingerprint)
TRAKTORID
TRAKTORPEAKDB
TRAKTORPERCEIVEDDB
WM/ENCODINGTIME
WWW
Present in files downloaded from YouTube:
AUDIODATARATE
DURATION
HEIGHT
LENGTH
MINOR_VERSION
STARTTIME
TOTALDATARATE
TOTALDURATION
VIDEODATARATE
WIDTH
although i sometimes search for those because only properly tagged files show up
I'm having trouble with some ogg files which were working perfectly fine with previous versions of foobar (and still work well with other players). They sound sped-up and distorted. Other ogg files work fine, though.
Playlist search behaviour is weird when searching for something and then changing the playlist tab.
Didn't anyone else notice this?
In 1.2 and below when opening a playlist search, typing something and then switching playlists would search for the pattern in the new playlist.
Since 1.3 it doesn't do that anymore.
The old behaviour was really really really useful and I hope this gets fixed for the 1.3 final!
Another thing I noticed is that contrary to what the changelog states, searching of huge libraries actually does make the UI block. At least when typing the first few letters only some of them appear. Then it blocks and initiates a search, and after the results are displayed the rest of the typed letters are inserted and another search is run. It would be nice if the textbox wouldn't freeze while typing.
Another thing I noticed is that contrary to what the changelog states, searching of huge libraries actually does make the UI block. At least when typing the first few letters only some of them appear. Then it blocks and initiates a search, and after the results are displayed the rest of the typed letters are inserted and another search is run. It would be nice if the textbox wouldn't freeze while typing.
I can't reproduce this problem, even with 50K tracks in a playlist. The database is on an SSD, though. I wonder if that's the difference.
Edit: Sorry, that doesn't make sense. Obviously the playlist is in RAM.
I can not reproduce that behaviour with beta5. So it might be only in certain situations. I did not use 1.3 beta with my "big" library yet.
I'm afraid I can't instruct you how to reproduce this, but on my foobar this appears since some build always like is on the picture
(http://content.screencast.com/users/uu1qKRgw/folders/Default/media/455d11d6-bdee-4b0a-b364-16b9dc1b67f7/11.17.2013-09.png)
I would be satisfied if the docked instance displayed the comment same manner as popup panel
you need to tinker with LargeFieldsConfig.txt inside your foobar profile folder. edit it while foobar is closed and on the next start, it should force a rebuild of your whole library to cache longer tag fields.
Another thing I noticed is that contrary to what the changelog states, searching of huge libraries actually does make the UI block. At least when typing the first few letters only some of them appear. Then it blocks and initiates a search, and after the results are displayed the rest of the typed letters are inserted and another search is run. It would be nice if the textbox wouldn't freeze while typing.
I can't reproduce this problem, even with 50K tracks in a playlist. The database is on an SSD, though. I wonder if that's the difference.
Edit: Sorry, that doesn't make sense. Obviously the playlist is in RAM.
I can very well reproduce it here even with only 30k tracks in my playlist.
The title of the search window switches to "Playlist search (working)" and while it say's that, any character you type simpy won't appear until it switches back to "Playlist search (X results)". I checked if it was related to the result grouping I'm applying, but it's not it.
Playlist search behaviour is weird when searching for something and then changing the playlist tab.
Didn't anyone else notice this?
In 1.2 and below when opening a playlist search, typing something and then switching playlists would search for the pattern in the new playlist.
Since 1.3 it doesn't do that anymore.
The old behaviour was really really really useful and I hope this gets fixed for the 1.3 final!
Yeah, I already posted something about it. So far, no comment.
Do betas still expire? We're nearing a month if so.
If any changes are coming, will it be possible to add a tag field which contains a trailing space into LargeFieldsConfig.txt?
Beta 6 posted as beta 5 was about to expire.
Some of the reported bugs have been fixed. Unfortunately I'm short on work hours that I can spare on foobar2000 lately.
I assure you that the remaning issues/complaints/requests will be looked into before 1.3 final.
Although in the change log it is written as:
Corrected gapless playback of HE-AAC files made with iTunes.
it doesn't seem to be corrected on 1.3b6.
(Strictly speaking I tested on the files encoded by qaac that is confirmed to be played back gaplessly by iTunes, since iTunes HE encoder has issues).
Mail a sample file to webmaster@foobar2000.org please. Thanks.
When I convert separated tracks into a multi-track files, all of converted large fields become ".". Is it a bug?
When I convert separated tracks into a multi-track files, all of converted large fields become ".". Is it a bug?
Working as intended. To see the real contents instead of ".", fully load the info from the properties window's menu.
When I convert separated tracks into a multi-track files, all of converted large fields become ".". Is it a bug?
Working as intended. To see the real contents instead of ".", fully load the info from the properties window's menu.
Thank you for your advice.
However, the values of these fields are not unstored in the cache, but actually set to ".".
after the upgrade to f2k 1.3 beta, all playlists were moved to the new folder playlists-v1.3. i closed f2k, delete old playlists, and moved into it new, and then deleted the folder playlists-v1.3. after f2k restarting, playlists-v1.3 folder was created again. it is not convenient for me, because i use Autosave & Autobackup where specified folder playlists. if i change autobackup settings from playlists to playlists-v1.3, when a new version of f2k (1.4 or higher), which will create a playlists-v1.4 and etc., playlist's backup will not be done.
As wildcards are supported you could use playlists* as the pattern.
fbuser
it works. thank you!
When I convert separated tracks into a multi-track files, all of converted large fields become ".". Is it a bug?
Working as intended. To see the real contents instead of ".", fully load the info from the properties window's menu.
Thank you for your advice.
However, the values of these fields are not unstored in the cache, but actually set to ".".
How do you convert multiple tracks into a multi-track file? I'd like to try this.
When I convert separated tracks into a multi-track files, all of converted large fields become ".". Is it a bug?
Bug acknowledged, thanks for reporting.
Although in the change log it is written as:
Corrected gapless playback of HE-AAC files made with iTunes.
it doesn't seem to be corrected on 1.3b6.
(Strictly speaking I tested on the files encoded by qaac that is confirmed to be played back gaplessly by iTunes, since iTunes HE encoder has issues).
Have already PMed with Peter, but I also note here for anyone who cares:
This was my mistake, sorry. I tried it on specific samples that happened to yield very obvious click between transition, and misdirected by that.
Beta 7 out. All issues reported so far should be fixed. If I've missed anything, please remind me, thanks.
LargeFieldsConfig.txt + fields with trailing spaces => you can now enter such as "FIELD ".
This bugs me for some years now, and I wonder whether it can be fixed:
$sub(%length_seconds%,%playback_time_seconds%)
Shows correct remaining time on 100% of audio files
While
%playback_time_remaining%
Is off by 1 second in like 50% of cases
Just two things:
Is the playlist-v1.3 folder going to be renamed only playlist? I hate to keep both folders or delete one manually.
Is LargeFieldsConfig goin to be integrated in the foobar2000 options, like someone else already suggested?
Thanks.
Wouldn't it hurt backwards compatibility if playlist-v1.3 was renamed to playlist? I'm fairly positive that you can delete the latter without any side issues whatsoever.
Also, it was already mentioned that LargeFieldsConfig.txt is not a setting meant to be changed often, so there's no need to expose it via the main preferences.
Beta 7 out. All issues reported so far should be fixed. If I've missed anything, please remind me, thanks.
LargeFieldsConfig.txt + fields with trailing spaces => you can now enter such as "FIELD ".
Something I noticed in B6 (having skipped B4 and B5), haven't verified in B7: after playing 'some' (between 10 and 50) tracks with Album Replay gain the gain 'suddenly is ignored mid-track. Even when a new track in the same album is started, the gain does not return until I stop playback and restart it. I don't have to exit and restart foobar.
I know, a very 'fuzzy' bug report but I don't have any more details right now.
Beta 7 out. All issues reported so far should be fixed. If I've missed anything, please remind me, thanks.
LargeFieldsConfig.txt + fields with trailing spaces => you can now enter such as "FIELD ".
Something I noticed in B6 (having skipped B4 and B5), haven't verified in B7: after playing 'some' (between 10 and 50) tracks with Album Replay gain the gain 'suddenly is ignored mid-track. Even when a new track in the same album is started, the gain does not return until I stop playback and restart it. I don't have to exit and restart foobar.
I know, a very 'fuzzy' bug report but I don't have any more details right now.
Are you using full buffering to RAM or something? Here's something that will produce a behavior similar to the one you mentioned:
You are playing a track which
does not have RG info. You scan the track for RG and apply the info to its metadata. Now, the portions of the track which are already buffered will play as if they didn't have any RG (ignoring the fact that you just applied it to them), but once you've exhausted the buffer and it's filled again, everything will be alright.
Are you using full buffering to RAM or something? Here's something that will produce a behavior similar to the one you mentioned:
You are playing a track which does not have RG info. You scan the track for RG and apply the info to its metadata. Now, the portions of the track which are already buffered will play as if they didn't have any RG (ignoring the fact that you just applied it to them), but once you've exhausted the buffer and it's filled again, everything will be alright.
can't confirm that, i have full filebuffering up to 99999 KB, and i'm playing a mp3 with ~10 MB, immediately after scanning and applying replaygain information to the file, the volume changes
Beta 7 out. All issues reported so far should be fixed. If I've missed anything, please remind me, thanks.
LargeFieldsConfig.txt + fields with trailing spaces => you can now enter such as "FIELD ".
Something I noticed in B6 (having skipped B4 and B5), haven't verified in B7: after playing 'some' (between 10 and 50) tracks with Album Replay gain the gain 'suddenly is ignored mid-track. Even when a new track in the same album is started, the gain does not return until I stop playback and restart it. I don't have to exit and restart foobar.
I know, a very 'fuzzy' bug report but I don't have any more details right now.
Are you using full buffering to RAM or something? Here's something that will produce a behavior similar to the one you mentioned:
You are playing a track which does not have RG info. You scan the track for RG and apply the info to its metadata. Now, the portions of the track which are already buffered will play as if they didn't have any RG (ignoring the fact that you just applied it to them), but once you've exhausted the buffer and it's filled again, everything will be alright.
I don't know which setting you're referring to but the "full file buffering" in Advanced / Playback is set to 0K. I haven't changed any settings between the last stable version and the recent beta's.
Edit: And the effect is the other way around: the tracks have had RG all the time, causing them to play 'louder'. I noticed it because of the drop in loudness.
I don't know which setting you're referring to but the "full file buffering" in Advanced / Playback is set to 0K. I haven't changed any settings between the last stable version and the recent beta's.
What happens if you set "full file buffering" to a non-zero value, 1000 kb or something?
There seems to be a problem when using metadb_io_v2::update_info_async() - I've only just started using beta7 following a bug report, so I can't comment on previous betas. I've stepped through the code in the debugger to make sure I wasn't doing anything retarded and I don't seem to be.
The tags updated don't change in the properties dialogue, despite the console saying the file has been reopened following an edit. I haven't tested extensively, but a restart can sometimes get the properties dialogue to show the updated tag (it doesn't always). It didn't seem to make a lot of difference whether the tag was specified in the large fields text file - there were still problems when I removed the lyrics and unsynced lyrics tag names.
Thanks for all your efforts and if you need anymore info let me know
As you've noticed, tag updates vs large field handling is a touchy subject.
With the new simplified info cache, we need to make sure that someone does not accidentally overwrite actual tags with cut down info from the cache - if the file already contains a field that's too long to fit in the cache, it's forcefully retained - unless the calling component uses a new 1.3 API to report itself as large field aware.
Stuff that you can do to mitigate this issue:
* Use the new metadb_io flag: op_flag_partial_info_aware = 1 << 3
It tells metadb_io that you're aware of partial info semantics and that large fields present in the files should not be forcefully preserved.
* Call input APIs by yourself instead of metadb_io info update, there's nothing between you and the tag writers then. You must then make sure that metadb_io gets the hints about changed file properties. This is actually pretty straightforward, not much to go wrong talking to input_info_writer etc by yourself.
This is probably the preferred method for you if you're writing a lyrics handling component, since you already have to talk to the inputs directly to read oversized fields correctly.
Sounds like a bit of a nightmare for you! Is there any particular disadvantage to using the op_flag_partial_info_aware flag? It seems to work very well with my existing code. Presumably when you set this flag it's reloading the file_info directly from the music file - then editing + saving it (updating the database accordingly)? Is that the difference between the two options you gave - whether it uses an existing an file_info or loads it from file? (assuming I implemented a similar method to update_info_async)
No particular disadvantage to using that flag, it's meant for the exact case when your component is compatible with behaviors introduced in fb2k 1.3; not specifying that flag activates backwards compatibility workarounds.
1.3.1 beta 1:
- "Format from other fields..." doesn't work (doesn't rename). The test was done right clicking from Properties\Metadata\Track Title. 1.3 stable works perfectly.
1.3.1 beta 1:
- "Format from other fields..." doesn't work (doesn't rename). The test was done right clicking from Properties\Metadata\Track Title. 1.3 stable works perfectly.
Can anyone confirm this? Because I don't know why but it seems to be working now, I swear it didn't when I wrote that, I've double checked all the tags, command, files, everything.
I regularly use that function (and have been on 1.3.1 beta 1 since it was released), but I haven't noticed a single problem. The pattern you were using must have been wrong; well, either that, or you were seeing things.
1.3.1 beta 1:
- "Format from other fields..." doesn't work (doesn't rename). The test was done right clicking from Properties\Metadata\Track Title. 1.3 stable works perfectly.
Can anyone confirm this? Because I don't know why but it seems to be working now, I swear it didn't when I wrote that, I've double checked all the tags, command, files, everything.
I regularly use that function (and have been on 1.3.1 beta 1 since it was released), but I haven't noticed a single problem. The pattern you were using must have been wrong; well, either that, or you were seeing things.
+1, I have a sequence of "Format from other fields" based edits I do every time I acquire/import new music (which I do every few days it seems.) I never noticed a problem in any of the betas.
LargeFieldsConfig.txt is a pain in the a**, for such a major new change in doing things, the repercussions are not exactly well documented.
I've tried adding a few items:
fieldBasic=comment
fieldBasic=DISCOGS_RELEASE_NOTES
fieldBasic=DISCOGS_RELEASE_CREDITS
After nearly 2 hours of watching my HD spin which I assumed were the new large fields being added (media library was 'monitoring'), I still ended up with a '.' where I expected info from DISCOGS_RELEASE_NOTES field. Checking the files, %DISCOGS_RELEASE_NOTES% was quite large.
If a tag is included and it is larger than basicMetaMax, is it partially displayed or completely ignored?
Assuming I can figure out the size of the largest field I want to include to set basicMetaMax=x, does that mean the cache is overly large for all of my fields?!
Also, any tips for determining what my max basicMetaMax should be set to based on existing tags?
----
Related *BUG* seems to be when rendering fields that are not cached or included in LargeFieldsConfig.txt, e.g.:
(example via Text Display component:)
[%comment% ]
['Release notes:' %DISCOGS_RELEASE_NOTES% ]
['Credits:' %DISCOGS_RELEASE_CREDITS% ]
if comment is too big and results in '.' being displayed, the rest is ignored even though they exist and are within the size limit.
Did you restart foobar after editing the config as it's specifically stated in it?
Is 1.3.1 beta 1 most probably going to be the final stable? Just asking because it's almost a month and it's going to expire.
Thanks for the release Peter.
1.3.1 beta 1:
- "Format from other fields..." doesn't work (doesn't rename). The test was done right clicking from Properties\Metadata\Track Title. 1.3 stable works perfectly.
The renaming works but there is something else. Every Properties>Metadata>Name>"Value (Track Title, Album Title etc.)" I right click to get to "Format from other fields..." I always and only see "Track Title" in the preview. Am I missing something?
you always see an Item column in the preview - which shows the title.
you should be looking at the New value column when you enter something in the Pattern box.
(https://dl.dropboxusercontent.com/u/22801321/2014/january/format.png)
Ok only the "New Value" column got it. It's been a long time since I've tried to do anything else other than "Track Title" from that particular menu and I thought I remembered it changed every time the right click selection was different to begin with.
Thank you very much marc2003.
edit:
It's confusing BTW, it should change based on which value you right click to get to that screen.
it should change based on which value you right click to get to that screen.
there's a strong possibility of what you select being empty so it's not much use as a point of reference. i guess title is used because if it's empty then the filename will be used.
edit: when i said you, i meant people in general.