Comments
-
Greg Hurrell
Yes, kqueue does allow you to monitor files for modifications and Synergy Advance already does use it for some things.
In the case of the library XML file I don't think it would be so useful though because in my testing I see that iTunes doesn't flush changes out to the file as soon as you make them. In some cases it may only write the changes out to disk on exit.
Basically the approach I was going to use is to refresh only when the user asks, with the additional feature that if you try to play a track from the submenu and it doesn't work (a sure indication that the library has changed) that Synergy Advance will automatically offer to refresh when that happens.
-
Nigel
in my testing I see that iTunes doesn't flush changes out to the file as soon
as you make them. In some cases it may only write the changes out to disk on exit.
If that's the case, doesn't that mean that manually refreshing would be no more successful than automatic refreshing? In the best case scenario with manual refreshing, the user will hit refresh just after iTunes has written a change out to disk, whereas in most other cases they will either be seeing outdated information, or hitting refresh when no changes have been made. If this is the case, auto-refresh is still optimal (though of course it would be nice if iTunes wrote out changes reliably).
Or do you do something else tricky when the user performs a manual refresh, like read the copy of the database iTunes holds in memory? If so, I can see why auto-refresh could be worse than manual refresh.
-
Greg Hurrell
Nah, I don't do anything tricky. The truth is that reading the XML file is not exactly a supported way of getting information from iTunes but it's the only way to get information about a huge number of tracks all at once (if you did it with Apple Events you would take all day to do it and use lots of CPU).
The other thing about auto-refreshing is this: do you really want the entire menu refreshing every time the file gets modified? Imagine the worse case scenario: that the file gets flushed to disk because someone removes a comma from the album title in iTunes. You then rebuild the all those submenus (something which I know you've said takes a long time; bug #209).
Having said that, it's not hard to implement this feature. I will make it a checkbox in the advanced preferences, but it will definitely default to being off because I think it will cause more trouble than it's worth...
-
Greg Hurrell
(In reply to comment #2)
If that's the case, doesn't that mean that manually refreshing would be no more successful than automatic refreshing? In the best case scenario with manual refreshing, the user will hit refresh just after iTunes has written a change out to disk, whereas in most other cases they will either be seeing outdated information, or hitting refresh when no changes have been made. If this is the case, auto-refresh is still optimal (though of course it would be nice if iTunes wrote out changes reliably).
I forgot to respond to this in my last comment. Like I said, reading the XML file is a bit of a necessary evil. It's not documented and there's no way of knowing what iTunes' policy is for flushing to disk. Having said that, I believe that iTunes only flushes when it exits. This means there is always a risk of seeing outdated information regardless of whether you do a manual or automatic refresh. About the only time you can be sure that things are up-to-date is at the very beginning when you first launch iTunes and Synergy Advance.
And often on the next launch the database IDs are different. This can be a problem for Synergy Advance because it might be left running while iTunes is shut down, relaunched, shut down, relaunched. If the database IDs change then the menu items won't work when you select them.
Even so, there is no way of knowing *when* the database IDs will change because we don't know what the official iTunes policy (nor if/how it will change in future versions).
-
Nigel
The other thing about auto-refreshing is this: do you really want the entire
menu refreshing every time the file gets modified?
Good point. It might not be a good thing if you make a lot of changes to your library and the file is updated fairly constantly. Hadn't really considered the drawbacks of that WRT bug #209.
I suppose it's not a big deal in the end, so if it involves a lot of extra dev. time probably not worth it. But if it's fairly easy, then it will be nice to have the option in the advanced prefs (and it would be nice if enabling auto-updating applied to any other modules that read the XML file, assuming some of the other ones you're developing do this).
It's times like this I imagine you really wish iTunes provided more granularity programming-wise. Would be nice to have access to more programming notifications, and things like the browser view.
-
Nigel
It's not documented and there's no way of knowing what iTunes' policy is for
flushing to disk. Having said that, I believe that iTunes only flushes when it exits.
I'm sure you know more than me WRT this issue, but it seems to often write changes out to disk before it exits. iTunes has a habit of occasionally locking up after I use it for a while, requiring me to force quit. I always find the changes I've made have persisted after re-launching, even though it hasn't quit nicely. I'm talking about things like new, deleted, or modified playlists. Or does it always write changes to its proprietary database file immediately, and only write to the .xml file on quit?
Re: Database IDs - that's interesting. I didn't know about that aspect of things. I suppose that makes things pretty messy and makes the usefulness of an auto-update feature questionable.
-
Greg Hurrell
Changing assignment to reflect my new email address.
https://wincent.dev/a/news/archives/2006/05/change_of_email.php
Add a comment
Comments are now closed for this issue.