I’m rewriting an old application. The next-gen evolution here is that instead of a time-based loop, I’m rewiring the flow of execution to take cues via pyinotify. (I was terribly proud of calculating the average song length in my library and using that to decide the loop timing.)
I followed the example code and read the documentation. I found that the key takeaways were
- I was to use WatchManager.add_watch to monitor my file. In this case, that’s ~/.quodlibet/current. The documentation clearly states that files and directories both are watchable – though the tutorials only seemed to cover directories.
- I watched for the event pyinotify.IN_MODIFY – because I would be waiting for a file modification.
When I tried a dummy run just to see things in action, the event process was triggered as expected. However, processing had fallen through to the “default” event – not IN_MODIFY as I wanted. To make matters worse, no further events were ever seen again (even when they should have happened). I was only getting the one event – and the wrong event, at that.
There’s no head-scratching here. When I added some more verbosity, my gross mistake became very clear. The process of changing ~/.quodlibet/current is to write the new one out to a tempfile and then swap it into the “real” current file. This is two(-ish) events in ~/.quodlibet, and neither of them is a modify to ~/.quodlibet/current.
EDIT: I think the once-off happens because your watch is invalidated. When the tempfile clobbers ~/.quodlibet/current, the underlying file is no more – so you’re watching a ghost whose name was already usurped on the filesystem.
The correct approach is to watch ~/.quodlibet and match on the exact file being reported in the event fire.