After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 571107 - Command-line Interface: --stop-when-finished ineffective
Command-line Interface: --stop-when-finished ineffective
Status: RESOLVED DUPLICATE of bug 541279
Product: banshee
Classification: Other
Component: general
1.4.2
Other All
: Normal normal
: 1.x
Assigned To: Banshee Maintainers
Banshee Maintainers
Depends on:
Blocks:
 
 
Reported: 2009-02-09 22:05 UTC by Chris Neary
Modified: 2009-02-10 19:55 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Chris Neary 2009-02-09 22:05:53 UTC
Please describe the problem:
I cannot get the --stop-when-finished flag to work. I tried the following to no avail:

banshee --stop-when-finished true
banshee --stop-when-finished 'true'
banshee --stop-when-finished 1
banshee --stop-when-finished

Steps to reproduce:
1. Open a terminal
2. Type the command banshee --stop-when-finished


Actual results:
There is a short pause of about 3 seconds, after which the following debug output is displayed.

banshee --stop-when-finished true

Unhandled Exception: System.ArgumentNullException: Cannot handle a null message; maybe the bus was disconnected
Parameter name: msg
  at NDesk.DBus.Connection.HandleMessage (NDesk.DBus.Message msg) [0x00000] 
  at NDesk.DBus.PendingCall.get_Reply () [0x00000] 
  at NDesk.DBus.Connection.SendWithReplyAndBlock (NDesk.DBus.Message msg) [0x00000] 
  at NDesk.DBus.BusObject.SendMethodCall (System.String iface, System.String member, System.String inSigStr, NDesk.DBus.MessageWriter writer, System.Type retType, System.Exception& exception) [0x00000] 
  at IPlaybackControllerServiceProxy.set_StopWhenFinished (Boolean ) [0x00000] 
  at Halie.Client.HandlePlayerCommands () [0x00000] 
  at Halie.Client.Main () [0x00000] 
  at (wrapper managed-to-native) System.AppDomain:ExecuteAssembly (System.Reflection.Assembly,string[])
  at System.AppDomain.ExecuteAssemblyInternal (System.Reflection.Assembly a, System.String[] args) [0x00000] 
  at System.AppDomain.ExecuteAssembly (System.String assemblyFile, System.Security.Policy.Evidence assemblySecurity, System.String[] args) [0x00000] 
  at (wrapper remoting-invoke-with-check) System.AppDomain:ExecuteAssembly (string,System.Security.Policy.Evidence,string[])
  at System.AppDomain.ExecuteAssembly (System.String assemblyFile) [0x00000] 
  at (wrapper remoting-invoke-with-check) System.AppDomain:ExecuteAssembly (string)
  at Booter.Booter.BootClient (System.String clientName) [0x00000] 
  at Booter.Booter.Main () [0x00000] 


Expected results:
Banshee should toggle the 'stop when finished' setting to 'true'. This error isn't just a warning, whereby the desired action would occur despite the debug error message; I checked in the GUI after issuing the command, the action fails entirely.

Does this happen every time?
Yes.

Other information:
Comment 1 Chris Neary 2009-02-09 22:09:09 UTC
Command-line playback controls also take quite an unexpected while to come into effect. --pause --play --next and --previous all work as expected, but there's always a pause before this happens, which means the command-line interface is slightly more delayed than the graphical interface.

It would be appreciated if this delay could be squashed a little in the process of fixing this bug. :)

Thanks, and I look forward to 1.4.3, or 1.5 (or 2.0?)
Comment 2 Bertrand Lorentz 2009-02-10 19:55:46 UTC
Thanks for the bug report. This particular bug has already been reported into our bug tracking system, but please feel free to report any further bugs you find.

Please keep it to one issue per bug. Feel free to open a new bug for the issue mentioned in your second comment.

*** This bug has been marked as a duplicate of 541279 ***