Bug 10502 - Setting to close iTunes after usage by SC
: Setting to close iTunes after usage by SC
Status: CLOSED FIXED
Product: Logitech Media Server
Classification: Unclassified
Component: iTunes
: 7.4.0
: All All
: P2 normal (vote)
: 7.4.0
Assigned To: Michael Herger
:
Depends on:
Blocks: 10187
  Show dependency treegraph
 
Reported: 2008-12-30 14:31 UTC by Fred
Modified: 2009-10-05 14:36 UTC (History)
2 users (show)

See Also:
Category: ---


Attachments
Patch to add pref to quit iTunes after scan (3.04 KB, text/plain)
2009-01-05 15:06 UTC, Fred
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Fred 2008-12-30 14:31:25 UTC
The current code is capable of closing iTunes after using it during the scan but it's always bypassed. I would like to have the option of closing it after usage, as a setting. The default value can be not to close it if wanted.

I can submit a patch, I am just checking this is OK to implement or if something even better is already in the works.
Comment 1 James Richardson 2009-01-04 18:10:27 UTC
Fred: please provide a patch and we can look at implementing it.
Comment 2 Fred 2009-01-05 15:06:37 UTC
Created attachment 4557 [details]
Patch to add pref to quit iTunes after scan

Attached a patch. Tested only under OS X but should work on Windows as well .
Comment 3 James Richardson 2009-01-06 07:39:51 UTC
Andy/Michael, can you look at the attached patch?  This would solve bug 10187
Comment 4 Andy Grundman 2009-01-06 07:42:02 UTC
That's reasonable I guess.  The reason it doesn't close by default is that it might close iTunes while the user is using it for something, and that would be a worse bug report.
Comment 5 Michael Herger 2009-01-06 07:45:30 UTC
IMHO we don't need a new pref (Matt would kill us!), but silently close iTunes if it wasn't open before we started.
Comment 6 Andy Grundman 2009-01-06 07:52:40 UTC
Yeah that was my original thought too, and I actually implemented support for that in the Mac script.  I didn't add that check to the win32 version though.
Comment 7 Fred 2009-01-06 08:03:00 UTC
The check does not really matter. I mean if the problem is closing iTunes while the user uses it, then it may not matter what opened it, the user might start to use it finding it open and be surprised by it getting closed. The pref exposes the logic, being off by default means some conscious decision is required to turn it on, decision hopefully remembered the day iTunes closes "unexpectedly".

I do however agree it's an advanced sort of preference. We could use the presence of some file and describe it on the wiki, that would leave it off the GUI.
Comment 8 Dan Evans 2009-01-06 10:11:49 UTC
This is a good idea.  However, it will not solve bug 10187.  That still requires some UI improvement, imo.
Comment 9 Weldon Matt 2009-07-29 15:57:27 UTC
(In reply to comment #5)
> IMHO we don't need a new pref (Matt would kill us!), but silently close iTunes
> if it wasn't open before we started.

This is the correct behavior...
Comment 10 Michael Herger 2009-07-30 04:17:38 UTC
shut down iTunes if it had been started through us
change 27937 - OSX
change 27938 - Win32

Unfortunately Win32::OLE->GetActiveObject() isn't working as expected (see eg. http://www.opensubscriber.com/message/perl-win32-users@listserv.ActiveState.com/501266.html). In many cases iTunes will be connected to using the new() method though it's already running. Therefore we have to scan the process list in order to get to know whether iTunes was running or not.
Comment 11 James Richardson 2009-10-05 14:36:02 UTC
This bug has been marked as fixed in the 7.4.0 release version of SqueezeBox Server!
    * SqueezeCenter: 28672
    * Squeezebox 2 and 3: 130
    * Transporter: 80
    * Receiver: 65
    * Boom: 50
    * Controller: 7790
    * Radio: 7790  

Please see the Release Notes for all the details: http://wiki.slimdevices.com/index.php/Release_Notes

If you haven't already, please download and install the new version from http://www.logitechsqueezebox.com/support/download-squeezebox-server.html

If you are still experiencing this problem, feel free to reopen the bug with your new comments and we'll have another look.