High disk usage (~200kB/s) due to often settings save.

[askvortsov-ideas]

High disk usage (~200kB/s) due to often settings save.

[fossfreedom]

yep - looking at the code the culprit is probably the elapsed_changed method.

Need something in there that is not CPU hungry to determine if 1 second has elapsed before calling save-rhythm

[askvortsov-ideas]

Use https://developer.gnome.org/gio/unstable/GApplication.html#GApplication-shutdown signal of https://developer.gnome.org/rhythmbox/unstable/RBApplication.html to save elapsed? And let it save freely on playlist/song/palystate change?

[fossfreedom]

hmm - that looks ok for a controlled shutdown.

Obviously - on a rhythmbox crash the track will not resume from where it last was playing.

Speculating ...maybe rather than the idle-add method currently used - use something like Gdk.threads_add_timeout_seconds - just wondering if despite potentially being call lots of times during the elapsed_changed method - the thread itself would only "fire" once the timeout (1 second for example) has been reached.

[askvortsov-ideas]

I don't think starting last song on crash (which shouldn't be a common situation) is that bad.

As for threads_add_timeout_seconds - if I understand documentation correctly, then every thread created will run after previous release the lock. So there will be not only high disk usage, but also RAM for holding all these threads contexts. :)

But it maybe a good idea to use interval-called function to save elapsed time.

[fossfreedom]

So there will be not only high disk usage, but also RAM for holding all these threads contexts. :)

yuk!

yep threads_add_timeout_seconds called once a second could do this rather than connecting to the elapsed_change event.

Another method would be to set a variable at start "save_rhythm = False".

Then on entering the elapsed method - test if this var is True --> exit

Then change idleadd to threads_add_timeout_seconds and set save_rhythm to True.

When the thread is invoked, change save_rhythm to False before the thread exits.

Think either way will work better.

[askvortsov-ideas]

Yes, setting a 'do job' flag for elapsed task is good idea too. But, anyway, these solutions look too complex. I'd better loose playback time of last song then get some unknown problems because of threads.

[fossfreedom]

ok - had a closer look - just added a print statement at the top of save_rhythm - its only being called once a second.

How are you monitoring disk-usage?

[askvortsov-ideas]

With https://launchpad.net/indicator-multiload. htop says both RB and dconf constantly has ~180 in IO column.

[fossfreedom]

hmm - thanks

looks like its dconf that is the expensive part here. Writing a simple string seems to want to write out large amounts of data.

Think the answer here is to remove the frequently used dconf read-write and instead read-write to a cache file.

[askvortsov-ideas]

But when to dump cache to dconf? Or would you prefer to not save anything there?

[fossfreedom]

for the most part I think probably not to use dconf for the frequently used fields KEY_BROWSER_VALUES, KEY_PLAYBACK_TIME, KEY_LOCATION, KEY_PLAY_STATE which are used in save_rhythm and get_source_data.

Not sure without a bit more investigation whether to write some-sort of custom read-write routine or if a simple json.dumps --> write to disk is cheaper in terms of CPU/disk io. Probably holding the above fields in an array and using json.dumps is more pythonic