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: updating files takes ages now.. why? (Read 2023 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

updating files takes ages now.. why?

Hi Guys,

lately every time i start a track it takes a few but sometimes up to 8 seconds before a files is played..
I get a windw that says:

"
updating files
processing <filename>
"

That is not how its supposed to be.. How did this happen? I would like it to play instantly again like before. Any idea how to do this or what to look for?

im using the following components:
facets
playback statistics
playback statistics custom
preview
quicktagger
waveform seekbar  (it also happens with tracks where the waveform was extracted beforehand)

If you need more information, let me know! it is beginning to be a real problem...

It seems to happen predominantly with thracks that haven't been played before...

Thanks again!

updating files takes ages now.. why?

Reply #1
Isn't having two playback statistics components kind of redundant (my bet would be the two may interfere somehow)?

Did you install or change anything before your problem surfaced?

Where are the files stored (what device)? Is it dying?

updating files takes ages now.. why?

Reply #2
Have a look at File > Preferences> Tools > Playback Statistics > Automatically Synchronize file tags. If it's enabled, you could very well see such delays.
That's so plausible, I can't believe it.

updating files takes ages now.. why?

Reply #3
Have a look at File > Preferences> Tools > Playback Statistics > Automatically Synchronize file tags. If it's enabled, you could very well see such delays.

File > Preferences> Advanced > Tools > Playback Statistics > Automatically Synchronize file tags.

C.
PC = TAK + LossyWAV  ::  Portable = Opus (130)

updating files takes ages now.. why?

Reply #4
Thanks for the correction, carpman. That was a silly error.

It seems to happen predominantly with thracks that haven't been played before...


This makes sense. By default, foobar2000 will use padding when updating mp3 tags:
Files > Preferences > Advanced > Tagging > MP3 > ID3V2 revision and quirks > Use padding [X]
This adds extra space so that future tag updates can be written directly to the file. This is fast enough that you may not perceive a delay.

However, the first time you play a track and synchronize the tags, it probably doesn't have padding, so foobar2000 has to rewrite the file. This takes much longer. This often causes a noticeable delay, so foobar20000 pops up an "updating" message so that you don't think that the player is ignoring your desire to Play the track.
That's so plausible, I can't believe it.

updating files takes ages now.. why?

Reply #5
Ah, thanks guys. Makes total sense.

This was not enabled, so that was not it.
File > Preferences> Advanced > Tools > Playback Statistics > Automatically Synchronize file tags.

So it's the padding then....

So can i make foobar do this padding thing whenever a track is added to any (auto)playlist?
And while we are on the subject, could i have foobar do the same for waveform seekbar too and any other component i might wanna use in the future?

So that whenever i want to start to play a track it will have calculated and done everything beforehand?
That is very useful to me because i use foobar a lot to search for music. To listen rapidly through 100's of new tracks every day. This means skipping a lot. And me having to wait a lot for foobar to calculate everything. (I know i can manually get the waveform seekbar to extract the waveform from a selection, but i have music coming in continuously. It would be really convenient to have everything already done whenever i play whatever track)

@Daeron
About the redundancy of the playcounters.. I am searching through so many tracks, it is useful to me to have all kinds of data available. One playcounter i use for a track played a significant part of, and the other for when a track is started. Seems there is no interfering issue here.. only thing is that Playback_statistics_custom cannot write its "track started" tag if waveform seekbar is extracting and writing the waveform of a track it has not been extracted from yet. Because they do it at the same time, when a track is started, but i hope to solve this.

So can i get foobar to do all necessary operations automatically whenever a track comes in (i.e.: finishes downloading)?

Thanks again!!!

updating files takes ages now.. why?

Reply #6
Hmm. Well, I'm surprised that tag synchronization is not your problem. The "updating" messages are a clear sign. I had that very issue long ago (maybe 10 years ago?), although I can't recall if it was a default behavior or something I had set. It was probably something I did. In any case, I saw "updating" messages and noticeable delays.

I understand your desire for pre-processing. The issue is that foobar2000 rarely does anything that isn't user-initiated. It's an established design principle.

But I have to believe that something about your setup is causing your delays. I have a modern but low-end i3 PC (plenty fast for normal computing), and while my system drive is an SSD, all of my MP3's are on an old Western Digital hard drive. Never ever have I seen an "updating" message or any appreciable delays.

My next thought is that Daeron is correct: the two playlist statistics plugins are causing conflicts. I suggest you uninstall one of them and see what happens.

My next speculation is that your music collection is on a networked device. I've seen delays from my tablet, although never the "updating" message. Beyond that, I'm at a loss.
That's so plausible, I can't believe it.

updating files takes ages now.. why?

Reply #7
Well, if i disable playbacks_custom then i have no problem.

If i enable playback_custom again and disable foo_playcount, then there is no improvement. I still get the "updating files" window.

With or without foo_playcount, I get the messages just the same. Sometimes a fraction of a second, sometimes several seconds and sometimes nothing at all.

So there is no conflict, it is playback_custom... (by the way, i had the first played, last played and playstamp tags disabled all the time. Only the playcounter enabled and that has a different tagname then foo_playcount so there was no conflict there)

My files are on a local high speed drive (Don't know the exact type but it is one with a ridicously large cache, shouldn't be a problem, because it isn't with any other operation within foobar)

The fact that i sometimes have to wait for several seconds indicates.... something? I don't know?

My bet is, if there is another customizable playcounter out there, it could be solved.

So 3 questions:
- can i solve the problem in foo_playback_custom.dll on my computer?
- if not, are there other counters to try out? preferably highly customizable
- when removing foo_playcount; all the count-data on the music have disappeared.. i wasn't expecting that. Why is that? I am removing the component.. don't want the data it has fabricated so far to be removed also... It is not a huge problem this time, but i would like to understand why this happens for future use...

Well, thanks again all! U are a great help, especially DustMagnet and Daeron who have been answered almost all my topics!
This is all very important to me to get right!


PS  And on a sidenote: about waveform seekbar pre-processing: i now just extract the waveform manually on all files now and then. It seems only to affect the new ones. Automatically would be better, but this is okey for now

updating files takes ages now.. why?

Reply #8
I'm glad we could help in some way.

Sorry, I don't know of any other playlist counters.

I would guess that the foo_playcount database is deemed to be too large to just leave it laying around after you uninstall it. For my collection of 52K tracks it's only 20MB, but I can imagine prancing nerdholes* making a ruckus about it.

If you want to recover the database, I recommend Recuva. It's created by Piriform, the folks who coded the respect CCleaner utility (aka CrapCleaner). Scan for "database.dat." With luck it won't be overwritten and recoverable.

And actually, now that I think about it, you could pre-process all of your files (assuming that padding is the issue): display all tracks in a playlist, select all, and add a dummy tag. It doesn't matter what it is or contains, and you can later delete it. The point is that it would force foobar to add padding to all tracks. How long this will take depends on the size of your collection. You could start it before you go to bed and let it run overnight.

(*) A friend coined this phrase to describe the hordes of internet folks who love to be outraged.
That's so plausible, I can't believe it.