Snip will throw an exception when using iTunes sometimes about snip HOT 14 CLOSED

@dlrudie Is there a way to force load the COM library on start of Snip? The only problem I could see with this is another application using the library while it gets reloaded.

from snip.

That's possible but as soon as you load the COM library it will automatically start iTunes. I'm not sure people would like that; I know I wouldn't.

from snip.

Could it force load it when they select iTunes in the list like it did before?

from snip.

I've only seen this issue once or twice in all of my tests and I've seen nothing specific that triggers it. Users have reported it occasionally too but it always seems random. I'm not quite sure how to track down the issue.

from snip.

I too have had this issue, but every single time that iTunes is open at all.

Have a look at: http://support.microsoft.com/kb/198996

In summary(ish), problems with systray message pump activity while COM operations occur. Have forked and will hopefully get time to write something to test that idea out.

EDIT: Further reading indicates this is for an old version of windows. Presents almost the same though, always crashes for me when selecting iTunes from the systray menu.

In the mean time, some exception handling would be lovely :)

from snip.

Similar thing reported other places: https://obsproject.com/forum/threads/now-playing-music-for-spotify-itunes-winamp-on-stream.925/page-8

I have had a quick go at looking into the threading issue. No matter which thread attempts to load the COM object, if iTunes is already running, the COM object will throw an error and not instantiate.

Looks like the iTunes SDK is just a steaming pile...

from snip.

Added a COMException catch in commit 9facf7d that will just spit the message out, hopefully providing a more detailed reason as to why it's failing.

from snip.

I can typically replicate this error if Snip loaded the COM library, I exit Snip, compile a new version, and then run the newly compiled version.

It seems like the only thing I can really do is pop up a message saying that the user will need to exit iTunes and let Snip launch it instead.

from snip.

Thats exactly what I was thinking. Could have a button that says "Click
here to close iTunes and relaunch with Snip support", send iTunes a close
to the win handle, wait for the process to disappear and then instantiate
the COM object. That's going to need a disclaimer!

I have had a look around for alternative methods of pulling information
from iTunes, to no avail. I did wonder if the iTunes remote protocol had
been reverse engineered, as that would give you all the access you needed,
over a socket.

from snip.

I don't really want Snip to have the ability to exit applications. I think a message will suffice. If iTunes is running and this message appears, you can just exit iTunes and reselect it from within Snip and it will start iTunes for you. I find that convenient enough.

from snip.

Changes made in ae68641. Unfortunately it takes 120 seconds for it to timeout and there is no way to adjust that timeout. So after 2 minutes of unresponsiveness the MessageBox will appear.

from snip.

Think I've found the true cause of this. I notice that Snip requires execution as an elevated process. If i have iTunes running as an elevated process also, I never have the COM problem if iTunes is already running when Snip starts.

I'm assuming it has to run as an elevated process to call the Unsafe methods used to get information from winamp/foobar/spotify?

If i modify the Snip manifest to not require elevated access, it works first time every time. I wonder if there is an elegant way around that.

I've just tried winamp with both processes running as normal non-elevated, and the unsafe methods used to retrieve the window text from winamp work fine. If the same is true of spotify and foobar, perhaps this could be a considered change?

from snip.

I believe I had it require elevated privileges before because I was actually hooking the Spotify process and reading its memory. Since I've went away from that I actually can probably drop it back down.

from snip.

I went ahead and made a commit 9002793 for this and I'll see how this release goes with everyone testing it later.

from snip.