bugfix: Check if mutable reference to pending_notification is None

[hcwesson]

This is a small change intended to fix #3 - please feel free to critique and/or modify this PR as needed!

Similar to the change and metadata checks in SignalHandler, it adds an early return in the event that the mutable reference of self.pending_notification is None.

I'm not certain, but my suspicion is that the per-sender metadata caching may have something to do with the problem. I think the issue might be triggered when a single sender is responsible for sending property changes for multiple media player states (as is the case with Chromium, for instance, when tabs for a video site and a music service are both open).

These changes might not fully address the root cause, but after testing both dev and release builds locally, the panic described in #3 no longer occurs and I haven't noticed any regressions so far.

[l1na-forever]

Hiya! Thanks so much for the detailed report, and patch ^^.

I'm not certain, but my suspicion is that the per-sender metadata caching may have something to do with the problem. I think the issue might be triggered when a single sender is responsible for sending property changes for multiple media player states

That could be the case! From my read of handle_signal, the pending_notification field will be populated from empty if the MPRIS message contains either player metadata or a status change. If the message contains either of those elements, pending_notification will either be set, updated, or cleared with a proper early return. Therefore, I'm wondering if Chromium can send a message that contains neither of those elements (or mpris-notifier is failing to parse those elements in some contexts).

Would you be able to attempt to reproduce while running dbus-monitor | grep PlaybackStatus? This'll give me an event dump of what mpris-notifier received, and should confirm if that's the cause.

Either way, patch looks good since there definitely shouldn't be an unchecked unwrap on pending_notification. Thanks again!