Author Topic: Auto-save settings & database option  (Read 18431 times)

romney_yw

  • Jr. Member
  • **
  • Posts: 34
Why aren't changes to the database and settings files written to disk straight away, making an auto-save option unnecessary.  ???

MusicBee just makes incremental changes to a database and some XML files so I'm curious as to the rationale for it to wait until the program closes.

That would waste system resources and annoy the user because MB would then have to keep overwriting setting files and database file with almost every edit and adjustment as it has to know the last used configurations and has to keep database in sync with every tag changes made, which would be dreadful especially to people with a huge collection (a large database file).

But the same issues would also apply for an auto-save function. If MB saves when the user clicks "Save", the user will at least have some visibility of the cause...... With auto-save, these issues would suddenly occur without any warning as a result of the background process triggering after X minutes, and the user may not realise why his system is not responding. Which will surely be much more frustrating ......

But it is equally frustrating to lose a large number of changes, if MB crashes at the end of a particularly long editing session. At least with a manual "Save Changes" function, the user would have some degree of control over when the changes are saved, and would be less surprised by a temporary loss of performance while this is carried out. This would be rather more graceful than the current need to restart MB - whether by closing and opening manually, or triggering the restart function by hot-key..... (and this current need to restart is not at all obvious to the uninitiated user either!)

I agree with zak - changes to the database and settings files should be written to the disk straight away. However, I accept that there maybe some need to compromise for reasons of performance etc.

I think currently clicking on save button on any dialogs immediately updates relevant settings files. If you had changed the toolbar button coloring option from preferences, instead of from its context menu, and had clicked on save button, the settings file would have been updated right away. Also I don't see much need for a command to save configurations because currently you can exit and relaunch MB with a hotkey that will update not only settings but also database.

Redwing - your earlier comment suggests that MB behaves differently when the toolbar configuration is changed via the Edit button on Edit Preferences- Layout 1 from what happens if I rghit-click the toolbar and choose Configure Toolbar from the context menu - even though both operations appear to arrive at the same Set Toolbar Buttons dialog. Are you sure that is correct? {Ah yes - because the changes are only saved to disk when I click "Save" on Edit Preferences I suppose.]

I believe that configuration settings are stored in relatively small XML or INI files, and I don't think there is any reason why such changes could not be saved to the relevant files immediately the user clicks "Save"? But I have no detailed knowledge of the file structure, so I could well be a bit wide of the mark here....

I can appreciate the problem with the database file, and trying to keep it in sync with tags in hundreds (or thousands) of separate music tracks. It does seem a little inefficient to have to save the entire database file every time the user makes a change to the tags in one track. Would it be possible for individual changes to be saved as incremental updates, which are rolled into the main database file when MB exits - or if unsaved increments are found on start-up (presumably following an unexpected shutdown)?

Actually, if the changes to tag data are saved immediately to the individual track file, MB could check the database against the individual tracks on restart (with an appropriate warning to the user) if an earlier unexpected shutdown was detected. Each track is effectively its own set of incremental changes, and the database could be verified against them when inconsistency might reasonably be anticipated. (A bit like the way that Internet Explorer offers to restore your last browsing session when it detects that the last shutdown was unexpected.)

Sorry for the long post, but there are some serious questions here which need to be properly understood in order to suggest the best solution to the problem. I'm now even less convinced that auto-save is the correct way forward......  ::)

redwing

  • Guest
@romney_yw:

All I'm requesting here is to automate what's currently possible - exit and relaunch MB repeatedly - to save settings and database during a session. And I am pretty sure Steven would be more than capable of handling those technical issues, if this feature ever got to be implemented.

Zak

  • Global Moderator
  • Sr. Member
  • *****
  • Posts: 2450
Why aren't changes to the database and settings files written to disk straight away, making an auto-save option unnecessary.  ???

MusicBee just makes incremental changes to a database and some XML files so I'm curious as to the rationale for it to wait until the program closes.

That would waste system resources and annoy the user because MB would then have to keep overwriting setting files and database file with almost every edit and adjustment as it has to know the last used configurations and has to keep database in sync with every tag changes made, which would be dreadful especially to people with a huge collection (a large database file).

System resource use wouldn't be affected at all, because it would (or should) already be doing that - each time you edit a track, the corresponding details in the database will be updated, albeit only in memory which is why changes are lost if MusicBee crashes. It wouldn't be "syncing" the database with the track tags as a separate batch operation at a later time.

I can appreciate the problem with the database file, and trying to keep it in sync with tags in hundreds (or thousands) of separate music tracks. It does seem a little inefficient to have to save the entire database file every time the user makes a change to the tags in one track.

Databases don't work like that - only parts of the file containing changed data get written back to the disk. On a modern PC the time to do so would be measured in milliseconds.

On the other hand, MusicBee's database could be doing something funky which is why I posed the original question.
Bee excellent to each other...

romney_yw

  • Jr. Member
  • **
  • Posts: 34
Redwing - I fundamentally agree with the need to address this problem. I'm just not convinced that an autosave every x minutes is the best solution.

I agree with zak - the system should be able to write changes either to configuration or tag data to the disk, whenever a user clicks "Save". I know that database management systems work in that way (hence my earlier thoughts on incremental changes). I don't know enough about MB file structure to understand whether this approach would require a major change or just a simple tweak ...... There is presumably a good reason why it currently behaves as it does.

And I also agree that Steven is more than capable of handling whatever technical issues are involved. MusicBee is simply amazing, and the speed with which he is able to implement patches is stunning. I wouldn't dare to offer advice in that respect.

But I do feel we need to understand what we are lobbying for...... I'm sure that we are all broadly in agreement - as always, the devil is in the detail ....

Steven - I imagine that you have been monitoring this discussion. Do you have any thoughts about how best to address this problem?

carderne

  • Guest
Just another +1 to this topic from me. Where I live power outages are common, so I quite often lost my play counts and now playing lists. I haven't lost my appearance settings in a while, but it has happened in the past.

And amazingly, I just had my first BSOD in months, while typing this message, and lost my playing list... Firefox was clever enough to keep what I'd written in this box, which seems a lot more complex than keeping track of what I'm playing outside of RAM. Surely?


mmoole

  • Newbie
  • *
  • Posts: 4
+1

on my machine it often happens that I am shutting down windows and then musicbee gets force-quit because it is a bit slow on the slow machine. Like this, I often loose whats was played an listen to the same music again and again..  ::)  ;D


BlueZephyr

  • Newbie
  • *
  • Posts: 10
Just another +1 to this topic from me. Where I live power outages are common, so I quite often lost my play counts and now playing lists. I haven't lost my appearance settings in a while, but it has happened in the past.

How about save play counts and current playlist when a song ends? I don't think updating play counts or the active playlist would be cpu/disk intensive at all. I know I hate it when I accidentally click restart (antivirus/firewall/windows update) and forget MusicBee was running and then it closes without saving those things.

Steven

  • Administrator
  • Sr. Member
  • *****
  • Posts: 34313
I forgot to mention that v3.1 already auto-saves the database every minute after the last activity that causes the database to be updated.

For settings, they are saved when you exit the preferences dialog, but currently directly updating settings in a panel will not save until MB exits

redwing

  • Guest
I forgot to mention that v3.1 already auto-saves the database every minute after the last activity that causes the database to be updated.

For settings, they are saved when you exit the preferences dialog, but currently directly updating settings in a panel will not save until MB exits

That's great improvement! I think that covers most of this wish. Thanks for letting us know the new feature.

exscape

  • Newbie
  • *
  • Posts: 5
+1 for improving this, still, though I don't believe autosave after e.g. 20 minutes is the solution. The solution stated by Steven above sounds perfect, but it doesn't work that way for me! I'm on version 3.2.6902 and am still having issues.

For example, I changed the rating of a song at 21:47. At 21:54, after playing a couple of other songs, I killed MusicBee, and that rating I changed was gone.
I have MusicBee set to store ratings in the database, rather than in file tags.

Earlier today, I changed the layout of "Upcoming tracks" to show the track rating below the time, clicked Apply and Save (as I always do). Hours later I killed MusicBee, and that layout change reverted back, so settings can also be lost. Just to test, I made a similar change, clicked Apply, clicked Save, waited 2 minutes, and killed MB. Result: the change reverted back to how it was before.

Simultaneously with the "crash" mentioned earlier, I lost ratings on at least 20 tracks, along with "Last played" info and play count for more than the entire day, with the most recently played song being shown as yesterday afternoon -- I've been listening most of the day today, and all evening yesterday, so that's definitely not correct.

This exact issue of losing ratings etc. is why I switched from foobar2000 recently, so it'd be awesome if it could be fixed here (again?). :)

BTW, if anyone's wondering why I would kill MusicBee, the answer is plugin development. I've changed my build script to not kill it by force, but regardless, this issue will also bite people when computers crash, at power outages, if MusicBee crashes (hasn't happened to me) or perhaps during Windows updates, so IMO it's worth the attention.

UPDATE: I noticed there are 3.3 betas available, so I installed the latest (3.3.6962).
I played a few full songs, so there were >5 minutes for the first play to count. I also changed a rating as I started the playback, and the contrast for a text in the upcoming songs panel, followed by Apply and Save.
So about 10 minutes after those changes, I killed MusicBee, and everything reverted back.
Last Edit: January 31, 2019, 10:21:00 PM by exscape

phred

  • Global Moderator
  • Sr. Member
  • *****
  • Posts: 9305
So about 10 minutes after those changes, I killed MusicBee, and everything reverted back.
When you state you're "killing" MB, please describe exactly what you're doing. File > Exit? Click on X in upper right corner? CTRL-ALT-DEL?
Download the latest MusicBee v3.5 or 3.6 patch from here.
Unzip into your MusicBee directory and overwrite existing files.

----------
The FAQ
The Wiki
Posting screenshots is here
Searching the forum with Google is  here

exscape

  • Newbie
  • *
  • Posts: 5
So about 10 minutes after those changes, I killed MusicBee, and everything reverted back.
When you state you're "killing" MB, please describe exactly what you're doing. File > Exit? Click on X in upper right corner? CTRL-ALT-DEL?
taskkill /f /im:musicbee.exe
Same as ctrl+alt+del and "End Process" under the "Details" tab.
Also the same effect as having a hard MB crash, pulling the power plug, or having a BSOD, as far as MusicBee is concerned.

Steven

  • Administrator
  • Sr. Member
  • *****
  • Posts: 34313
Working fine here.
Keep in mind if you update the playing file, the file save is delayed until after the song completes.
Approx 1-2 minutes after any changes are saved MB will flush to disc the database cache. If you make further changes to any file before that 1-2 minutes is up, the flush is delayed another minute and so on. Once approx 10 minutes has past, the database is forceably flushed.
I wont spend any further time looking into this.